From report at bugs.python.org Wed Feb 1 00:08:54 2017 From: report at bugs.python.org (Eugene Toder) Date: Wed, 01 Feb 2017 05:08:54 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485925734.85.0.416650798816.issue11549@psf.upfronthosting.co.za> Eugene Toder added the comment: > We have already Constant and NameConstant. So it seems there are no need for > None, Bool, TupleConst, SetConst nodes. Yes, Constant is Victor's version of Lit. > I think converting Num, Str, Bytes, Ellipsis into Constant in folding stage > is easier than fixing all tests. Fixing tests was fairly easy the last time. I think the question is what changes to the public API of AST are acceptable. > Take docstring before constant folding isn't enough? > (I'm sorry if I'm wrong. I haven't tried it yet.) It may be doable, but seems very messy. Instead of a clean pipeline text -> AST -> Optimized AST -> bytecode, you have to collect all docstrings, and pass them around in a side structure. With the current code there can be a simple fix. If original string literals are Str, but constant-folded string constants are Constant, only treat Strs as docstrings. Then the optimizer needs a change to always preserve Str as a first statement in a function/module, and that's it. I still think that having a dedicated docstring attribute in AST is cleaner, though. > They are all NameConstant already. Keep in mind this patch is 6 years old :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 01:29:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 06:29:15 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485930555.34.0.717877154176.issue11549@psf.upfronthosting.co.za> INADA Naoki added the comment: >> We have already Constant and NameConstant. So it seems there are no need for >> None, Bool, TupleConst, SetConst nodes. > Yes, Constant is Victor's version of Lit. Then, may I remove ast.Lit, and use Constant and NameConstant? >> I think converting Num, Str, Bytes, Ellipsis into Constant in folding stage >> is easier than fixing all tests. > Fixing tests was fairly easy the last time. I think the question is what changes to the public API of AST are acceptable. I think backward compatibility is not guaranteed. But there are some usage of ast. (https://github.com/search?l=Python&p=2&q=ast.Num&type=Code&utf8=%E2%9C%93 ) So I think we should make change small as possible. >> Take docstring before constant folding isn't enough? >> (I'm sorry if I'm wrong. I haven't tried it yet.) > It may be doable, but seems very messy. Instead of a clean pipeline text -> AST -> Optimized AST -> bytecode, you have to collect all docstrings, and pass them around in a side structure. > > With the current code there can be a simple fix. If original string literals are Str, but constant-folded string constants are Constant, only treat Strs as docstrings. Then the optimizer needs a change to always preserve Str as a first statement in a function/module, and that's it. > I still think that having a dedicated docstring attribute in AST is cleaner, though. OK. >> They are all NameConstant already. > Keep in mind this patch is 6 years old :) I know. I want to move this patch forward, but I'm not frontend (parser, AST, and compiler) expert. I can't make design decision without expert's advice. Thanks for your reply. Then, may I update the patch in following direction? * Remove ast.Lit. * Keep docstring change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:02:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 07:02:05 +0000 Subject: [issue29410] Moving to SipHash-1-3 Message-ID: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> New submission from INADA Naoki: Rust and Ruby moved from SipHash-2-4 to SipHash-1-3. https://github.com/rust-lang/rust/issues/29754 https://bugs.ruby-lang.org/issues/13017 SipHash-1-3 seems faster than 2-4 and secure enough. ---------- messages: 286590 nosy: inada.naoki priority: normal severity: normal status: open title: Moving to SipHash-1-3 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:04:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 07:04:07 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1485930555.34.0.717877154176.issue11549@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: If you would like to implement constant folding at the AST level, I suggest you to look at my fatoptimizer project: https://github.com/haypo/fatoptimizer/blob/master/fatoptimizer/const_fold.py The tricky part is to avoid operations when we know that it will raise an exception or create an object too big according to our constraints. I would prefer to implement an AST optimizer in Python, but converting C structures to Python objects and then back to C structures has a cost. I'm not sure that my optimizer implemented in Python is fast enough. By the way, an idea would be to skip all optimizations in some cases like for script.py when running python3 script.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:16:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 07:16:25 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485933385.66.0.0840644223241.issue11549@psf.upfronthosting.co.za> INADA Naoki added the comment: Before trying advanced optimizations, I want move suspended obvious optimizations forwards. For example, removing unused constants is suspended because constant folding should be moved from peephole to AST. This is why I found this issue. After that, I'm thinking about shrinking stacksize. frame_dealloc (scans whole stack) is one of hot functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:19:02 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 07:19:02 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485933542.86.0.395898588289.issue29410@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- components: +Interpreter Core type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:31:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 07:31:32 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <20170201073127.7540.70640.188D7AF6@psf.io> Roundup Robot added the comment: New changeset 167beb21b527 by Benjamin Peterson in branch '3.5': gc types needs to be allocated as such (closes #29398) https://hg.python.org/cpython/rev/167beb21b527 New changeset b0463c5073fc by Benjamin Peterson in branch '3.6': merge 3.5 (#29398) https://hg.python.org/cpython/rev/b0463c5073fc New changeset 0e8c13da4f32 by Benjamin Peterson in branch 'default': merge 3.6 (#29398) https://hg.python.org/cpython/rev/0e8c13da4f32 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 02:31:54 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 01 Feb 2017 07:31:54 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485934314.73.0.137150538186.issue29410@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 The discussions on the Rust and Ruby lists seem persuasive. ---------- assignee: -> christian.heimes nosy: +christian.heimes, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:25 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936025.3.0.465712656363.issue29398@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch '3.6': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 New changeset 9e499c39bc298b0803033b0ccbc79481cc60054c by Benjamin Peterson in branch '3.6': merge 3.5 (#29398) https://github.com/python/cpython/commit/9e499c39bc298b0803033b0ccbc79481cc60054c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:25 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936025.37.0.69974940011.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:25 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936025.41.0.55032038488.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:25 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936025.45.0.827725989191.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:27 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936027.13.0.432488390253.issue29398@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch '3.5': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:27 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936027.19.0.731153959179.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:27 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936027.23.0.846138547945.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:27 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936027.25.0.723092652208.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:29 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936029.37.0.177944938802.issue29398@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 24bff360c2aa6d52f7a40ef35a5d7e5660d13402 by Benjamin Peterson in branch 'master': gc types needs to be allocated as such (closes #29398) https://github.com/python/cpython/commit/24bff360c2aa6d52f7a40ef35a5d7e5660d13402 New changeset 9e499c39bc298b0803033b0ccbc79481cc60054c by Benjamin Peterson in branch 'master': merge 3.5 (#29398) https://github.com/python/cpython/commit/9e499c39bc298b0803033b0ccbc79481cc60054c New changeset 123c453b3beb505a46d4708d811f7f52d1d5793c by Benjamin Peterson in branch 'master': merge 3.6 (#29398) https://github.com/python/cpython/commit/123c453b3beb505a46d4708d811f7f52d1d5793c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:29 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936029.45.0.199718704846.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:29 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936029.53.0.229615377003.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 08:00:29 +0000 Subject: [issue29398] memory corruption in xxlimited In-Reply-To: <1485874593.96.0.823310722961.issue29398@psf.upfronthosting.co.za> Message-ID: <1485936029.57.0.269013198539.issue29398@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 03:18:41 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 08:18:41 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485937121.53.0.820854841247.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm running pyperformance. BTW, hashlib doesn't provide siphash24. So can we simply replace siphash24 with siphash13, like ruby? https://github.com/ruby/ruby/commit/04c94f95d1a1c6a12f5412228a2bcdc00f5de3b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:03:57 2017 From: report at bugs.python.org (Manuel Krebber) Date: Wed, 01 Feb 2017 09:03:57 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485939837.79.0.972016942749.issue29377@psf.upfronthosting.co.za> Manuel Krebber added the comment: One question I was wondering about is whether those types should be checked by inspect.isroutine() as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:14:58 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Feb 2017 09:14:58 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485940498.52.0.731443649589.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: PEP 456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4. On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:21:46 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 09:21:46 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485940906.72.0.687034824175.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: $ ../python.default -m perf compare_to default.json patched4.json -G Slower (2): - scimark_sor: 479 ms +- 8 ms -> 485 ms +- 9 ms: 1.01x slower (+1%) - genshi_xml: 196 ms +- 2 ms -> 196 ms +- 2 ms: 1.00x slower (+0%) Faster (19): - json_loads: 62.7 us +- 0.5 us -> 61.5 us +- 1.1 us: 1.02x faster (-2%) - django_template: 402 ms +- 3 ms -> 395 ms +- 4 ms: 1.02x faster (-2%) - logging_format: 36.6 us +- 0.5 us -> 36.1 us +- 0.4 us: 1.01x faster (-1%) - xml_etree_generate: 277 ms +- 5 ms -> 274 ms +- 5 ms: 1.01x faster (-1%) - sympy_str: 461 ms +- 5 ms -> 456 ms +- 3 ms: 1.01x faster (-1%) - call_method_unknown: 16.6 ms +- 1.2 ms -> 16.4 ms +- 0.2 ms: 1.01x faster (-1%) - raytrace: 1.31 sec +- 0.02 sec -> 1.30 sec +- 0.01 sec: 1.01x faster (-1%) - python_startup_no_site: 9.81 ms +- 0.02 ms -> 9.74 ms +- 0.02 ms: 1.01x faster (-1%) - python_startup: 16.2 ms +- 0.0 ms -> 16.1 ms +- 0.0 ms: 1.01x faster (-1%) - logging_simple: 31.2 us +- 0.3 us -> 31.0 us +- 0.4 us: 1.01x faster (-1%) - 2to3: 742 ms +- 4 ms -> 739 ms +- 4 ms: 1.00x faster (-0%) - hexiom: 22.7 ms +- 0.2 ms -> 22.6 ms +- 0.2 ms: 1.00x faster (-0%) - call_simple: 14.2 ms +- 0.5 ms -> 14.2 ms +- 0.2 ms: 1.00x faster (-0%) - sympy_integrate: 46.2 ms +- 0.3 ms -> 46.1 ms +- 0.4 ms: 1.00x faster (-0%) - regex_compile: 434 ms +- 4 ms -> 433 ms +- 4 ms: 1.00x faster (-0%) - deltablue: 17.7 ms +- 0.2 ms -> 17.7 ms +- 0.2 ms: 1.00x faster (-0%) - chaos: 299 ms +- 3 ms -> 299 ms +- 3 ms: 1.00x faster (-0%) - call_method_slots: 14.6 ms +- 0.2 ms -> 14.6 ms +- 0.1 ms: 1.00x faster (-0%) - regex_dna: 283 ms +- 3 ms -> 283 ms +- 2 ms: 1.00x faster (-0%) Benchmark hidden because not significant (43) I'm creating siphash13 from reference implementation to double check the output. ---------- keywords: +patch Added file: http://bugs.python.org/file46476/siphash13.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:24:45 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 09:24:45 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485941085.33.0.74553625636.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: > PEP 456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4. OK, I'll add siphash13, instead of replacing siphash24. > On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode? siphash implementation uses 64bit unit. I don't know how to implement partial update like: m.update(b'foo'); b.update(b'bar') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:28:20 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 01 Feb 2017 09:28:20 +0000 Subject: [issue29397] linux/random.h present but cannot be compiled In-Reply-To: <1485872500.79.0.0659257887821.issue29397@psf.upfronthosting.co.za> Message-ID: <1485941300.73.0.031914669903.issue29397@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Could you upload a copy of config.log? Also added developers that play in random.h games ---------- components: +Build nosy: +Chi Hsuan Yen, benjamin.peterson, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:29:21 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 01 Feb 2017 09:29:21 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485941361.79.0.178239255341.issue29377@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, I attach the full patch now, as you asked. (Initially I was not sure about tests, but now I understand more these types, so that I added even few more tests than in original patch) > Maybe we need to wait for the github migration to complete though? I think it is OK to merge this now, but if it would be easier for you then it is not a problem to wait until GH migration is complete. Manuel, I think that probably the answer is yes, but I would prefer a separate issue for the inspect module. You could open a new issue and mention this one as a dependency. ---------- Added file: http://bugs.python.org/file46477/combined-patch-full-total.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:35:25 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Feb 2017 09:35:25 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485941725.96.0.953555600262.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: I added SipHash13 as additional hash algorithm in https://github.com/tiran/cpython/tree/siphash13 . Still need to verify the finalizer. For hashlib I'd need to move to a different implementation of SipHash. The implementation in pyhash.c is optimized for speed and has a fixed key. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed Feb 1 04:45:16 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 1 Feb 2017 10:45:16 +0100 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485940498.52.0.731443649589.issue29410@psf.upfronthosting.co.za> References: <1485940498.52.0.731443649589.issue29410@psf.upfronthosting.co.za> Message-ID: On 01.02.2017 10:14, Christian Heimes wrote: > > PEP 456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4. +1 on adding the 1-3 and making it the default; the faster the better. Hash speed for strings needs to be excellent in Python due to the many dict lookups we use in the interpreter. Reading up a bit on the Rust thread and looking at this benchmark which is mentioned in the thread: https://imgur.com/5dKecOW it seems as if it would make sense to not use a fixed hash algorithm for all strings lengths, but instead a hybrid one to increase performance for short strings (which are used a lot in Python). Is there a good hash algorithm with provides better performance for short strings than siphash ? > On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode? +1 as well. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed Feb 1 04:45:24 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 01 Feb 2017 09:45:24 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485940498.52.0.731443649589.issue29410@psf.upfronthosting.co.za> Message-ID: Marc-Andre Lemburg added the comment: On 01.02.2017 10:14, Christian Heimes wrote: > > PEP 456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4. +1 on adding the 1-3 and making it the default; the faster the better. Hash speed for strings needs to be excellent in Python due to the many dict lookups we use in the interpreter. Reading up a bit on the Rust thread and looking at this benchmark which is mentioned in the thread: https://imgur.com/5dKecOW it seems as if it would make sense to not use a fixed hash algorithm for all strings lengths, but instead a hybrid one to increase performance for short strings (which are used a lot in Python). Is there a good hash algorithm with provides better performance for short strings than siphash ? > On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode? +1 as well. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 04:50:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 09:50:44 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485942644.07.0.463511504547.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: > it seems as if it would make sense to not use a fixed > hash algorithm for all strings lengths, but instead a > hybrid one to increase performance for short strings > (which are used a lot in Python). > > Is there a good hash algorithm with provides better > performance for short strings than siphash ? There is undocumented option "Py_HASH_CUTOFF" to use DJBX33A for short string. See https://github.com/python/cpython/blob/master/Include/pyhash.h#L98 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:07:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 10:07:26 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485943646.24.0.611150475238.issue29410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The performance of hash algorithm shouldn't affect general benchmarks since hash value is cached inside string object. Almost all dict lookups in critical parts are lookups with interned strings. But in corner cases the difference can be measurable. We should look not on results of macrobenchmarks, but find worst cases. There is also an alignment issue with the implementation of SipHash-2-4 (and I suppose with SipHash-1-3). See issue28055. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:13:33 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 01 Feb 2017 10:13:33 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485942644.07.0.463511504547.issue29410@psf.upfronthosting.co.za> Message-ID: <4662a5f9-ebbc-bf12-730d-d4d514dae563@egenix.com> Marc-Andre Lemburg added the comment: On 01.02.2017 10:50, INADA Naoki wrote: > >> it seems as if it would make sense to not use a fixed >> hash algorithm for all strings lengths, but instead a >> hybrid one to increase performance for short strings >> (which are used a lot in Python). >> >> Is there a good hash algorithm with provides better >> performance for short strings than siphash ? > > There is undocumented option "Py_HASH_CUTOFF" to use DJBX33A for short string. > > See https://github.com/python/cpython/blob/master/Include/pyhash.h#L98 Thanks. I found a reference in the PEP 456: """ ... However a fast function like DJBX33A is not as secure as SipHash24. A cutoff at about 5 to 7 bytes should provide a decent safety margin and speed up at the same time. The PEP's reference implementation provides such a cutoff with Py_HASH_CUTOFF . The optimization is disabled by default for several reasons. For one the security implications are unclear yet and should be thoroughly studied before the optimization is enabled by default. Secondly the performance benefits vary. On 64 bit Linux system with Intel Core i7 multiple runs of Python's benchmark suite [pybench] show an average speedups between 3% and 5% for benchmarks such as django_v2, mako and etree with a cutoff of 7. Benchmarks with X86 binaries and Windows X86_64 builds on the same machine are a bit slower with small string optimization. The state of small string optimization will be assessed during the beta phase of Python 3.4. The feature will either be enabled with appropriate values or the code will be removed before beta 2 is released. """ The mentioned speedup sounds like enabling this by default would make a lot of sense (keeping the compile time option of setting Py_HASH_CUTOFF to 0). Aside: I haven't been following this since the days I proposed the collision counting method as solution to the vulnerability, which was rejected at the time. It's interesting how much effort went into trying to fix the string hashing in dicts over the years. Yet the much easier to use integer key hash collisions have still not been addressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:13:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 10:13:37 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1485944017.89.0.302220946553.issue29404@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:14:24 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 01 Feb 2017 10:14:24 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485943646.24.0.611150475238.issue29410@psf.upfronthosting.co.za> Message-ID: <1740630a-e68c-6f96-7026-9fc34ade47c3@egenix.com> Marc-Andre Lemburg added the comment: On 01.02.2017 11:07, Serhiy Storchaka wrote: > > The performance of hash algorithm shouldn't affect general benchmarks since hash value is cached inside string object. Almost all dict lookups in critical parts are lookups with interned strings. But in corner cases the difference can be measurable. We should look not on results of macrobenchmarks, but find worst cases. Good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:31:29 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 10:31:29 +0000 Subject: [issue29402] Problem with Checkbutton and duplicate last name components In-Reply-To: <1485898494.74.0.656128703551.issue29402@psf.upfronthosting.co.za> Message-ID: <1485945089.12.0.152112090848.issue29402@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The variable option of the checkbutton widget specifies the name of a global variable to set to indicate whether or not this button is selected. It defaults to the name of the button within its parent (i.e. the last element of the button window's path name). There are two workarounds: specify either name or variable arguments explicitly. There can be similar issues with other widgets. ---------- components: +Library (Lib), Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:43:53 2017 From: report at bugs.python.org (Michal Cyprian) Date: Wed, 01 Feb 2017 10:43:53 +0000 Subject: [issue29411] Option --executable for entry_points Message-ID: <1485945833.17.0.354426636585.issue29411@psf.upfronthosting.co.za> New submission from Michal Cyprian: 1. python3 setup.py build --executable="/usr/bin/binary" 2. python3 setup.py install -O1 --skip-build These two commands are typically used to build and install Python packages from sources. Let's assume there is a setup.py script of package foo, containing a script foo. The --executable option of build command (1) should set the shebang of the script foo to #!/usr/bin/binary. The problem is that this option doesn't work for scripts listed in setup.py as entry_points, which is the most common way of handling scripts these days. The idea of the original design was probably to pass the value of --executable to the build_scripts command and set shebang there. However, this command is not executed if the package contains only entry_points. The scripts listed as entry_points are processed during execution of the install command (2) (specifically, in the easy_install command), which is completely isolated from the build command (1) and doesn't have access to the value specified in the --executable option. The only reasonable solution that came to my mind was to add the --executable option to the install command as well, pass it to the easy_install command and make the ScriptWriter class use this value. I prepared a patch that fixes this issue in setuptools [1]. To make it work, a small patch [2] will have to be applied to distutils as well. Would this or something similar be acceptable for distutils? I've already sent this proposal to pypa-dev mailing list, they replied that patch will be useful. The patch [2] needs to go to distutils first, to make patch for setuptools work. [1] https://github.com/mcyprian/python-setuptools/blob/system-python/add-executable-option.patch [2] https://github.com/mcyprian/python-setuptools/blob/system-python/add-executable-option.patch ---------- components: Distutils messages: 286612 nosy: Michal Cyprian, dstufft, eric.araujo priority: normal severity: normal status: open title: Option --executable for entry_points type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 06:05:13 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Feb 2017 11:05:13 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1485947113.7.0.432053776591.issue27647@psf.upfronthosting.co.za> Terry J. Reedy added the comment: AFAIK, the Windows x.y compiled release and installer is normally updated to the latest stable tcl/tk, about the time of beta 1, and never changed for bugfix releases. 2.7 was an exception because of its long life and because later 8.5.z releases has some critical bugfixes, such as working with European keyboards. I believe the current OSX binary compiles _tkinter against tcl/tk 8.5, and we recommend replacing the Apple's old 8.5 with the latest 8.5 from ActiveState, and that people who instead install ActiveState 8.6 have to make or obtain a new Python binary that compiles _tkinter for 8.6. (Prior to Py3.6, there was also a Mac release for older Macs, and it was compiled for tcl/tk 8.4.) We don't compile Python on *nix and there are multiple versions of tcl/tk in use. I would prefer to have the latest tcl/tk at least for bugfixes, and a Python binary that can use if, even if tkinter does not give access to the latest tk features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 06:19:35 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Feb 2017 11:19:35 +0000 Subject: [issue27647] Update Windows 2.7 build to Tcl/Tk 8.5.19 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1485947975.47.0.564757920383.issue27647@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I changed title to match what might and, I think, should happen. My take: x.y is normally followed within 2 years by x.(y+1), which on Windows includes the latest tcl/tk. So, on Windows, anyone who wants the new tcl/tk can upgrade to the newer Python. For 2.7, there will be no 2.8 with newer tcl/tk. So we updated tcl/tk once already within 2.7 and it seems time to do so again. If there are more 8.5 bugfixes before the last 2.7 release in 2020, we should do so a third time. ---------- title: Update Windows build to Tcl/Tk 8.6.6 -> Update Windows 2.7 build to Tcl/Tk 8.5.19 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 06:19:58 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Feb 2017 11:19:58 +0000 Subject: [issue27647] Update Windows 2.7 build to Tcl/Tk 8.5.19 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1485947998.3.0.256982410354.issue27647@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 06:26:26 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 01 Feb 2017 11:26:26 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1485948386.61.0.876461356183.issue27200@psf.upfronthosting.co.za> Marco Buttu added the comment: Thank you Raymond for your time. I just want to note that does not distrac the reader, because it is not show in the output. Furthermore, to doctest an example we do not need to add the prompt (>>>): we can use the testcode/testoutput Sphinx directives. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:02:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 12:02:29 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <20170201120225.128369.76472.A9B05122@psf.io> Roundup Robot added the comment: New changeset 7b279c263708 by doko in branch '3.5': Issue #29169: Fix NEWS entry. https://hg.python.org/cpython/rev/7b279c263708 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:03:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 12:03:44 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485950624.11.0.457171347122.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: Current Py_HASH_CUTOFF implementation seems weak. ``` switch(len) { /* ((hash << 5) + hash) + *p == hash * 33 + *p */ case 7: hash = ((hash << 5) + hash) + *p++; /* fallthrough */ ... case 1: hash = ((hash << 5) + hash) + *p++; break; default: assert(0); } hash ^= len; hash ^= (Py_uhash_t) _Py_HashSecret.djbx33a.suffix; x = (Py_hash_t)hash; ``` HashSecret used at last. Conflicting pair without secret conflict with secrets too. ``` >>> def djbx33a(bs): ... h = 5381 ... for i in bs: ... h = h*33+i ... h ^= len(bs) ... h ^~ secret ... return h & 0xffff_ffff_ffff_ffff ... >>> for i in [0, 3, 7]: # range(8) ... for j in [0, 4, 7]: # range(8) ... for k in [0, 5, 7]: # range(8) ... print(i,j,k, djbx33a([7-i, 7-j+33*i, 7-k+33*j, 33*k])) ... 0 0 0 6381700318 0 0 5 6381700318 0 0 7 6381700318 0 4 0 6381700318 ... 7 4 7 6381700318 7 7 0 6381700318 7 7 5 6381700318 7 7 7 6381700318 >>> ``` So there are 8^(Py_HASH_CUTOFF-1) conflicting sequence can be built. Maybe, we should remove Py_HASH_CUTOFF completely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:11:01 2017 From: report at bugs.python.org (Christopher Schramm) Date: Wed, 01 Feb 2017 12:11:01 +0000 Subject: [issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize In-Reply-To: <1467035358.55.0.678180807375.issue27400@psf.upfronthosting.co.za> Message-ID: <1485951061.6.0.665368825964.issue27400@psf.upfronthosting.co.za> Christopher Schramm added the comment: This issue should have a much higher priority as it basically breaks Python embedding unless the user either does not re-initialize the interpreter or avoid the use of _datetime.strptime. We're currently testing with a patch based on Christian and Alexander's idea but using m_free as using m_clear and Py_CLEAR neither makes sense to me nor did it work in conjunction with Py_Finalize when testing it. A version matching the current tip is attached. We did not run into any issues so far (and the only thing I can think of is clearing the static variable too often and thus causing some extra imports). ---------- Added file: http://bugs.python.org/file46478/27400.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:20:11 2017 From: report at bugs.python.org (Gareth Rees) Date: Wed, 01 Feb 2017 12:20:11 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485951611.56.0.0295509954938.issue14376@psf.upfronthosting.co.za> Gareth Rees added the comment: Is there any chance of making progress on this issue? Is there anything wrong with my patch? Did I omit any relevant point in my message of 2016-06-11 16:26? It would be nice if this were not left in limbo for another four years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:20:23 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Feb 2017 12:20:23 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485951623.42.0.730564949057.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: Py_HASH_CUTOFF was an experimental feature for low-performance platforms. On modern hardware the performance increase is marginal to non-existing. I planned to deprecate the feature in 3.6 but forgot. We can deprecate it now and remove it in either 3.7 or 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:28:15 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 01 Feb 2017 12:28:15 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485950624.11.0.457171347122.issue29410@psf.upfronthosting.co.za> Message-ID: <5cfb9665-4218-1302-feac-7d10720e4a8c@egenix.com> Marc-Andre Lemburg added the comment: On 01.02.2017 13:03, INADA Naoki wrote: > Maybe, we should remove Py_HASH_CUTOFF completely? I think we ought to look for a better hash algorithm for short strings, e.g. a CRC based one. Some interesting investigations on this: http://www.orthogonal.com.au/computers/hashstrings/ http://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed PS: It may also be wise not to use the hash randomization with these, since the secret would leak. Again, collision counting comes to mind, since for short strings it is much more important to have a good bucket distribution than crypto security to protect hash secrets :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:31:11 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Feb 2017 12:31:11 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485952271.88.0.962172116122.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: We can and should still use hash randomization for short strings, but a different key than for hash randomization for longer strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:41:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 12:41:33 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485952893.03.0.517796308708.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: Py_HASH_CUTOFF uses different secret from siphash already. The problem is the secret doesn't affects to collision at all. Attacker can produce large number of collision, without knowing the secret. BTW, we have FNV already. Let's survey about FNV-1 short string collisions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 07:59:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 12:59:44 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485953984.44.0.553961507971.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/ Murmur may be safe for <16 byte too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:29 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954029.95.0.691970199696.issue29169@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7c1f136e83fe9a145f509b27417a8dd2a37ac27c by doko in branch '3.6': Issue #29169: Fix NEWS entry. https://github.com/python/cpython/commit/7c1f136e83fe9a145f509b27417a8dd2a37ac27c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:30 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954030.04.0.650099290899.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:30 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954030.09.0.978940453665.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:30 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954030.14.0.448351916338.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:31 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954031.69.0.624233063804.issue29169@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7c1f136e83fe9a145f509b27417a8dd2a37ac27c by doko in branch '3.5': Issue #29169: Fix NEWS entry. https://github.com/python/cpython/commit/7c1f136e83fe9a145f509b27417a8dd2a37ac27c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:31 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954031.78.0.295194566738.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:31 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954031.84.0.721630094057.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:31 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954031.92.0.315774117572.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:33 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954033.76.0.781039057127.issue29169@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7c1f136e83fe9a145f509b27417a8dd2a37ac27c by doko in branch 'master': Issue #29169: Fix NEWS entry. https://github.com/python/cpython/commit/7c1f136e83fe9a145f509b27417a8dd2a37ac27c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:33 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954033.84.0.166430362559.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:33 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954033.89.0.538346462977.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 13:00:33 +0000 Subject: [issue29169] update zlib to 1.2.11 In-Reply-To: <1483629107.49.0.982374684244.issue29169@psf.upfronthosting.co.za> Message-ID: <1485954033.95.0.104198564626.issue29169@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:07:00 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Feb 2017 13:07:00 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485954420.68.0.737764795873.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: Unless somebody is able to show a real-world example with a considerable performance boost (>5%), I'm strictly against any kind of special casing for short strings. I don't want to trade security for performance. You might be able to persuade me to go for a more complex system, when you can both proof security and performance boost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:41:48 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Feb 2017 13:41:48 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485956508.16.0.447524088468.issue14376@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Summary of overt and implied votes: Core Devs: +1 Mark Dickenson +1 Ethan Furman ?? Serhiy Storchaka -1 Alexander Belopolsky (at first, but unclear after) Other: +1 Ryan Gonzales, quoting Guido about equivalence of ints and longs. The sys.exit docstring says "If the status is an integer, it will be used as the system exit status." In 2.7, 'integer' clearly includes longs. Does anyone know the Windows equivalent of 'echo $?'? Gareth, I think the problem is that this is a minor 2.7-only, non-security issue and therefore a low priority for most Core Devs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:52:56 2017 From: report at bugs.python.org (Gareth Rees) Date: Wed, 01 Feb 2017 13:52:56 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485957176.51.0.467416809089.issue14376@psf.upfronthosting.co.za> Gareth Rees added the comment: In Windows, under cmd.exe, you can use %errorlevel% ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:53:21 2017 From: report at bugs.python.org (Joel Uckelman) Date: Wed, 01 Feb 2017 13:53:21 +0000 Subject: [issue29412] IndexError thrown on email.message.M Message-ID: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> New submission from Joel Uckelman: Test case: import email import email.policy txt = '''From: juckelman at strozfriedberg.co.uk To: (Recipient list suppressed) Date: Thu, 22 Aug 2013 04:13:02 +0000 Subject: ADSF-1082 Hey! ''' msg = email.message_from_string(txt) msg.get('to') msg = email.message_from_string(txt, policy=email.policy.default) msg.get('to') The second msg.get() throws an IndexError: Traceback (most recent call last): File "test.py", line 16, in print(msg.get('to')) # throws IndexError File "/usr/lib64/python3.5/email/message.py", line 472, in get return self.policy.header_fetch_parse(k, v) File "/usr/lib64/python3.5/email/policy.py", line 153, in header_fetch_parse return self.header_factory(name, ''.join(value.splitlines())) File "/usr/lib64/python3.5/email/headerregistry.py", line 586, in __call__ return self[name](name, value) File "/usr/lib64/python3.5/email/headerregistry.py", line 197, in __new__ cls.parse(value, kwds) File "/usr/lib64/python3.5/email/headerregistry.py", line 337, in parse kwds['parse_tree'] = address_list = cls.value_parser(value) File "/usr/lib64/python3.5/email/headerregistry.py", line 328, in value_parser address_list, value = parser.get_address_list(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2336, in get_address_list token, value = get_address(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2313, in get_address token, value = get_group(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2269, in get_group token, value = get_display_name(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2095, in get_display_name token, value = get_phrase(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1770, in get_phrase token, value = get_word(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1745, in get_word if value[0]=='"': IndexError: string index out of range The docs say that email.policy.default has raise_on_defect set to False, hence parse errors ought to be reported via EmailMessage.defects, not by throwing an exception. ---------- components: email messages: 286631 nosy: barry, r.david.murray, uckelman priority: normal severity: normal status: open title: IndexError thrown on email.message.M type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:53:52 2017 From: report at bugs.python.org (Joel Uckelman) Date: Wed, 01 Feb 2017 13:53:52 +0000 Subject: [issue29412] IndexError thrown on email.message.EmailMessage.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1485957232.72.0.311015510851.issue29412@psf.upfronthosting.co.za> Changes by Joel Uckelman : ---------- title: IndexError thrown on email.message.M -> IndexError thrown on email.message.EmailMessage.get _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:04:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 14:04:43 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485957883.36.0.834146113899.issue14376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Count me as +1. The patch LGTM. See also issue28998. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:09:35 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Feb 2017 14:09:35 +0000 Subject: [issue29412] IndexError thrown on email.message.EmailMessage.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1485958175.36.0.389387724143.issue29412@psf.upfronthosting.co.za> R. David Murray added the comment: Does the patch from issue 27931 fix your problem as well? I haven't looked closely enough to see if I think it should, I'm just hoping :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:12:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Feb 2017 14:12:46 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1485958366.56.0.0432647212.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Rather than "rejected" per se, I've closed this as "postponed" - I still think there's potential value in bundling a component management GUI in the future, but it should be *after* a project has established itself as the de facto introductory approach via PyPI. ---------- resolution: -> postponed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:17:25 2017 From: report at bugs.python.org (Joel Uckelman) Date: Wed, 01 Feb 2017 14:17:25 +0000 Subject: [issue29412] IndexError thrown on email.message.EmailMessage.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1485958645.02.0.45901411811.issue29412@psf.upfronthosting.co.za> Joel Uckelman added the comment: No dice. I get the same exception with issue27931_v2.patch. I briefly looked at the other two, and don't expect those will help, either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:19:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Feb 2017 14:19:30 +0000 Subject: [issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize In-Reply-To: <1467035358.55.0.678180807375.issue27400@psf.upfronthosting.co.za> Message-ID: <1485958770.51.0.683337269344.issue27400@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've added Steve Dower to the nosy list, as he's done some work recently on making the Windows builds more embedding-friendly, and I believe at least some of that time may have been funded work. Unfortunately, we don't currently have anyone I'm aware of that's being specifically paid to improve or maintain CPython's embedding support in general, so getting attention for these kinds of interpreter reinitialization bugs can be a bit hit-or-miss. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:28:13 2017 From: report at bugs.python.org (Gareth Rees) Date: Wed, 01 Feb 2017 14:28:13 +0000 Subject: [issue24869] shlex lineno inaccurate with certain inputs In-Reply-To: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za> Message-ID: <1485959293.78.0.0982450680221.issue24869@psf.upfronthosting.co.za> Gareth Rees added the comment: Here's a patch that implements my proposal (1) -- under this patch, tokens read from an input stream belong to a subtype of str with startline and endline attributes giving the line numbers of the first and last character of the token. This allows the accurate reporting of error messages relating to a token. I updated the documentation and added a test case. ---------- keywords: +patch Added file: http://bugs.python.org/file46479/issue24869.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 09:44:15 2017 From: report at bugs.python.org (Joel Uckelman) Date: Wed, 01 Feb 2017 14:44:15 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1485960255.06.0.761655899316.issue29412@psf.upfronthosting.co.za> Changes by Joel Uckelman : ---------- title: IndexError thrown on email.message.EmailMessage.get -> IndexError thrown on email.message.Message.get _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 10:30:10 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 15:30:10 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <20170201153005.16582.6122.49956A77@psf.io> Roundup Robot added the comment: New changeset 54fa95b19fae by Victor Stinner in branch 'default': python-gdb.py supports method-wrapper https://hg.python.org/cpython/rev/54fa95b19fae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 10:55:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 15:55:39 +0000 Subject: [issue29362] regrtest: don't fail immediately if a child does crash In-Reply-To: <1485272121.72.0.342410390691.issue29362@psf.upfronthosting.co.za> Message-ID: <1485964539.01.0.41209188314.issue29362@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached patch changes libregrtest to handle CHILD_ERROR as a normal result and continue the execution of following tests. As a result, it displays the test summary as usual on such crash. -- Ammar Askar: Thanks for regrtest_crash.diff, but I prefer to execute other unit tests rather than exiting immediatly. The --failfast option can be used with my patch to exit at the first crash or failure (with my patch, a crash is handled as a test failure). ---------- Added file: http://bugs.python.org/file46480/regrtest_crashed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:00:50 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:00:50 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485964850.21.0.11453313139.issue29367@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 30867b703933d6ba30bc5f609a1a2337925ead33 by Victor Stinner in branch 'master': python-gdb.py supports method-wrapper https://github.com/python/cpython/commit/30867b703933d6ba30bc5f609a1a2337925ead33 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:00:50 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:00:50 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485964850.47.0.536357603108.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:00:50 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:00:50 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485964850.69.0.742207174711.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:00:50 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:00:50 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485964850.85.0.318002934542.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:00:56 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:00:56 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <20170201160050.15845.53284.5DA5335F@psf.io> Roundup Robot added the comment: New changeset ffd2e5f9256a by Victor Stinner in branch 'default': Make test_gdb.test_wrapper_call() make reliable https://hg.python.org/cpython/rev/ffd2e5f9256a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:05:01 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:05:01 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <20170201160458.26197.17386.05E4D21A@psf.io> Roundup Robot added the comment: New changeset fcba9c9d987b by Victor Stinner in branch 'default': Document that _PyFunction_FastCallDict() must copy kwargs https://hg.python.org/cpython/rev/fcba9c9d987b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:08:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:08:07 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485965287.21.0.873673085913.issue29318@psf.upfronthosting.co.za> STINNER Victor added the comment: INADA Naoki: "Since mutating kw dict shouldn't affect caller's dict, caller and callee can't share the dict." Oh, I knew that, it's not the first time that I propose to implement this optimization and that I got this answer !? So I added a comment for myself, to remind me not to propose this optimization anymore :-D I close this issue. Serhiy Storchaka: "In most cases kw is empty or very small. I doubt any optimization can have significant effect." I have no opinion on Naoki's optimization idea. Naoki: Feel free to implement your idea to measure the speedup, but please open a new issue for that if you consider that it's worth it. FYI Naoki and me started to list ideas to optimize CPython 3.7: http://faster-cpython.readthedocs.io/cpython37.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:08:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:08:45 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485965325.28.0.752471486618.issue29318@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:11:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:11:52 +0000 Subject: [issue29311] Argument Clinic: convert dict methods In-Reply-To: <1484758450.31.0.717694851278.issue29311@psf.upfronthosting.co.za> Message-ID: <1485965512.47.0.0453536131696.issue29311@psf.upfronthosting.co.za> STINNER Victor added the comment: Thank you very much for the docstring enhancement Serhiy! I like your new docstrings. It seems like all known issues are now fixed, so I close the issue. Thanks Naoki and Martin too for the reviews. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:16:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:16:55 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1485965815.15.0.0448809409697.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: Would you mind to review my latest patch, struct_fastcall-6.patch? It should address all your remarks, except your proposal to write a converter for cache_struct(): see my previous comment about this idea. Thanks in advance ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:18:43 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:18:43 +0000 Subject: [issue29289] Convert OrderedDict methods to Argument Clinic In-Reply-To: <1484609084.15.0.406928886689.issue29289@psf.upfronthosting.co.za> Message-ID: <1485965923.99.0.653945499217.issue29289@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks again Serhiy for the better docstrings! Known issues are now fixed, so I close the issue. Thanks for the review Naoki. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:36:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:36:30 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485966990.73.0.644658837626.issue29286@psf.upfronthosting.co.za> STINNER Victor added the comment: Recently, I saw complains that I push changes too fast without reviews. This issue is a good example. So let me elaborate myself a little bit on these changes. I'm not really proud of the "Rename _PyArg_ParseStack to _PyArg_ParseStackAndKeywords" change. It should be called _PyArg_ParseStackAndKeywords() from the beginning, but when I designed FASTCALL, my plan was to only check arguments (positional and keyword arguments) in the callee, and remove checks in the caller. I expected that all functions will get positional + keyword arguments. I didn't know that not accepting keywords but only positional arguments like in str.replace(), was a deliberate language design choice. So yes, for functions accepting only positional arguments, _PyArg_ParseStack() + _PyArg_NoStackKeywords() makes sense. IMHO the implementation of the new _PyArg_ParseStack() and _PyArg_NoStackKeywords() functions was simple enough to avoid a review, they reuse existing code with minimum changes. In general for FASTCALL, I only add private functions. I consider that it's ok to push code quickly, since the private property allows us to change these functions anytime. Again, I consider that the "Argument Clinic: Use METH_FASTCALL for positionals" change is simple enough to avoid a review, I don't think that they are many ways to use FASTCALL for functions using positional-only parameters. I mean, I only see a single way to implement it. Again, if someone sees a new way to handle such parameters, we can change it anytime, Argument Clinic and FASTCALL are stil private. More generally, FASTCALL requires a lot of tiny changes everywhere. GitHub will allow to get reviews on long patch series. It will be easier to handle large changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:42:56 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 16:42:56 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <20170201164250.96227.78468.E18828A6@psf.io> Roundup Robot added the comment: New changeset 758674087b12 by Victor Stinner in branch 'default': Issue #29286: Rename private PyArg_UnpackStack_impl() to unpack_stack() https://hg.python.org/cpython/rev/758674087b12 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:43:58 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:43:58 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485967438.35.0.447029955949.issue29286@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "Oh, I have wrote almost the same patch before going to sleep yesteday! ;) But the building crashed (likely due to a bug in _PyStack_UnpackDict()) and it was too late to resolve this." Oh, sorry that you wrote almost the same code. Well, at least it means that we agree on the design :-) Serhiy: "I would prefer to rename "l" to "nargs" in PyArg_UnpackStack_impl and don't use upper case and namespace prefix in static functions." Done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:45:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:45:08 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485967508.91.0.733676807057.issue29286@psf.upfronthosting.co.za> STINNER Victor added the comment: str type still has a few methods using METH_VARARGS (slower than METH_FASTCALL): * count() * find() * index() * rfind() * rindex() * startswith() * endswith() * format() Maybe I will propose a change later to convert these methods to Argument Clinic, but I consider that the initial issue "Currently, Argument Clinic doesn't use METH_FASTCALL for these methods, but METH_VARARGS" is now fixed, so I close the issue. Thanks Naoki and Serhiy. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:49:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:49:11 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1485967751.0.0.672274617394.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: INADA Naoki: "Maybe, we should do: * Make clinic use more METH_FASTCALL * Use clinic more in builtin methods; before trying this optimization." I created the issue #29286 "Use METH_FASTCALL in str methods" which is now fixed. I started to propose patches for other funnctions, types and modules. Would you mind to rebase your loadmethod-fastcall.patch patch Naoki? With my change 0b219348ec9e, I'm not sure that your change on methoddescr_call() is still needed. I tried to rebase your change, but I failed to get the "1.10x faster" result. Maybe I did something wrong, maybe my change 0b219348ec9e already optimized method calls for C functions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 11:52:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 16:52:57 +0000 Subject: [issue29260] Use designated initializers to define PyTypeObject types In-Reply-To: <1484317865.58.0.725398845848.issue29260@psf.upfronthosting.co.za> Message-ID: <1485967977.2.0.738186354852.issue29260@psf.upfronthosting.co.za> STINNER Victor added the comment: The question was discussed on the python-dev mailing list: [Python-Dev] Can we use "designated initializer" widely in core modules? https://mail.python.org/pipermail/python-dev/2017-January/147154.html I understood that it's ok to use them in new code, but not to convert existing code: Guido van Rossum: "I'm against changing any existing code to use it -- such massive changes are high risk and low reward. Just do it for new fields or new types." https://mail.python.org/pipermail/python-dev/2017-January/147175.html So I close this issue. Note: I rejected my changes to add new tp_fastnew, tp_fastinit and tp_fastcall slots, issues #29358 and #29259. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485968421.01.0.0466438655754.issue29286@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 5910fd7231d34363798d2815be2f66909e638d1c by Victor Stinner in branch 'master': Issue #29286: Rename private PyArg_UnpackStack_impl() to unpack_stack() https://github.com/python/cpython/commit/5910fd7231d34363798d2815be2f66909e638d1c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485968421.12.0.799730228081.issue29286@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485968421.18.0.200402309322.issue29286@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29286] Use METH_FASTCALL in str methods In-Reply-To: <1484587851.78.0.529922329593.issue29286@psf.upfronthosting.co.za> Message-ID: <1485968421.24.0.604347176252.issue29286@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485968421.33.0.969711718838.issue29318@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 2c145e9eda756aa2001282d7c016e740dd00a2d7 by Victor Stinner in branch 'master': Document that _PyFunction_FastCallDict() must copy kwargs https://github.com/python/cpython/commit/2c145e9eda756aa2001282d7c016e740dd00a2d7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485968421.38.0.24439970084.issue29318@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485968421.43.0.920755128803.issue29318@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- resolution: rejected -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485968421.48.0.106644576423.issue29318@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485968421.55.0.10012302634.issue29367@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 88835e6022a81d8107a296c9f6e5f16c7d39e27a by Victor Stinner in branch 'master': Make test_gdb.test_wrapper_call() make reliable https://github.com/python/cpython/commit/88835e6022a81d8107a296c9f6e5f16c7d39e27a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485968421.64.0.0936035950946.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485968421.6.0.846121504435.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:00:21 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485968421.67.0.784609137295.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:03:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:03:48 +0000 Subject: [issue29234] Disable inlining of _PyStack_AsTuple() to reduce the stack consumption In-Reply-To: <1484093111.93.0.908854837348.issue29234@psf.upfronthosting.co.za> Message-ID: <1485968628.71.0.470095100439.issue29234@psf.upfronthosting.co.za> STINNER Victor added the comment: The initial issue has been fixed. With the issue #28870 (msg285169): "The default branch is now as good as Python 3.4, in term of stack consumption, and Python 3.4 was the Python version which used the least stack memory according to my tests." Serhiy: As I wrote, for _PyStack_AsDict(), we need numbers to see if this function is inlined or not, and check its usage of the stack. Since I consider that the stack usage is now low enough, I'm not interested to continue to investigate the stack usage. Feel free to continue the effort, but please open a new issue in this case. I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:05:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:05:28 +0000 Subject: [issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za> Message-ID: <1485968728.06.0.786322178729.issue28870@psf.upfronthosting.co.za> STINNER Victor added the comment: "The default branch is now as good as Python 3.4, in term of stack consumption, and Python 3.4 was the Python version which used the least stack memory according to my tests." I consider that the initial issue is now fixed, so I close the issue. Thanks Serhiy for the tests, reviews, ideas and obvious the bug report ;-) I never looked at the stack usage before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:10:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:10:46 +0000 Subject: [issue29227] Reduce C stack consumption in function calls In-Reply-To: <1484070646.73.0.530578838486.issue29227@psf.upfronthosting.co.za> Message-ID: <1485969046.56.0.407215399373.issue29227@psf.upfronthosting.co.za> STINNER Victor added the comment: Victor: "I plan to run a benchmark when all my patches to reduce the stack consumption will be ready." msg285200 of issue #28870: "I also ran the reliable performance benchmark suite with LTO+PGO. There is no significant performance change on these benchmarks (...)" less_stack.patch: -#define _PY_FASTCALL_SMALL_STACK 5 +#define _PY_FASTCALL_SMALL_STACK 3 With the issue #28870, reducing _PY_FASTCALL_SMALL_STACK value is no more needed. Larger _PY_FASTCALL_SMALL_STACK means better performances, so I prefer to keep the value 5 (arguments). The main change, inline call_function(), was merged, so I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:13:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 17:13:16 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1485969196.74.0.0897110156095.issue29300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that the type of the self parameter can be changed from PyObject* to PyStructObject*. This will make the patch larger but the final code simpler. class Struct "PyStructObject *" "&PyStructType" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:14:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:14:40 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1485969280.57.0.657637774091.issue29157@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed the bug in Python 2.7, 3.5, 3.6 and 3.7 (default). Thanks for the reviews Nick & Christian! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:15:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:15:10 +0000 Subject: [issue29140] time_hash() reads the wrong bytes to get microseconds In-Reply-To: <1483451829.62.0.434619516952.issue29140@psf.upfronthosting.co.za> Message-ID: <1485969310.46.0.885837465922.issue29140@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:20:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 17:20:02 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1485968421.39.0.952888263478.issue29318@psf.upfronthosting.co.za> Message-ID: <20932018.VLc9mFPNfj@raxxla> Serhiy Storchaka added the comment: > Changes by Roundup Robot : Why Roundup Robot spams with empty or almost empty messages? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:21:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:21:32 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1485969692.47.0.737723194089.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: Victor: "FYI I wrote an article about this issue: https://haypo.github.io/analysis-python-performance-issue.html Sadly, it seems like I was just lucky when adding __attribute__((hot)) fixed the issue, because call_method is slow again!" I upgraded speed-python server (running benchmarks) to Ubuntu 16.04 LTS to support PGO compilation. I removed all old benchmark results and ran again benchmarks with LTO+PGO. It seems like benchmark results are much better now. I'm not sure anymore that _Py_HOT_FUNCTION is really useful to get stable benchmarks, but it may help code placement a little bit. I don't think that it hurts, so I suggest to keep it. Since benchmarks were still unstable with _Py_HOT_FUNCTION, I'm not interested to continue to tag more functions with _Py_HOT_FUNCTION. I will now focus on LTO+PGO for stable benchmarks, and ignore small performance difference when PGO is not used. I close this issue now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:21:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 17:21:59 +0000 Subject: [issue29234] Disable inlining of _PyStack_AsTuple() to reduce the stack consumption In-Reply-To: <1485968628.71.0.470095100439.issue29234@psf.upfronthosting.co.za> Message-ID: <3092203.5xlLQMhSQd@raxxla> Serhiy Storchaka added the comment: Thank you Victor. Your work on reducing the stack consumption is great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:22:29 2017 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 01 Feb 2017 17:22:29 +0000 Subject: [issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers In-Reply-To: <1485909545.04.0.650924943503.issue29406@psf.upfronthosting.co.za> Message-ID: <1485969749.57.0.302212294386.issue29406@psf.upfronthosting.co.za> Alexander Mohr added the comment: Thanks so much for the patch! may want to change spelling of what was supposed to be "shutdown" =) Also think it's worth a comment stating why it's needed? Like certain Apache servers were noticed to not complete the SSL shutdown process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:26:52 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 17:26:52 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <20170201172648.16815.46498.605D4706@psf.io> Roundup Robot added the comment: New changeset efaf32ac89ec by Victor Stinner in branch 'default': Fix test_gdb.test_wrapper_call() on Python 2 https://hg.python.org/cpython/rev/efaf32ac89ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:28:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 17:28:37 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1485970117.1.0.701188373192.issue29318@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "Why Roundup Robot spams with empty or almost empty messages?" It smells like the migration to GitHub started :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:38:56 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 17:38:56 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485970736.59.0.781535386185.issue29407@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM, and should be committed to 3.5 and merged upwards from there. And yes, it's time for the asyncio docs to converge on async/await everywhere, making `yield from` a footnoot to history. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:49:44 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Feb 2017 17:49:44 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485971384.47.0.955739823885.issue11549@psf.upfronthosting.co.za> Brett Cannon added the comment: Dropping ast.Lit is fine. As for the docstring part, I'm torn. Yes it's nice as that will show up semantically in the Python code, but it's also easy to check for by just looking if the first statement is a Str (or Constant if that's what we make all strings). So I'll say I'm +0 on the docstring part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:52:18 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Feb 2017 17:52:18 +0000 Subject: [issue29364] msilib Fetch raises MSIError rather than return None In-Reply-To: <1485284065.77.0.143549147327.issue29364@psf.upfronthosting.co.za> Message-ID: <1485971538.06.0.373710351424.issue29364@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Jason. I think this is a duplicate of issue 1102. The second patch (_msi_fetch.patch.txt) there should fix your problem (if I read MSDN correctly, 103 is ERROR_NO_MORE_ITEMS.) I don't have access to a Windows box at the moment so could you please verify my theory so we can close this as a duplicate? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 12:55:18 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Feb 2017 17:55:18 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1485971718.94.0.0609737524791.issue29404@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm not quite sure what you're asking for here. The Python 2.7 semantics can't change because Python 2.7 is only receiving bugfixes. So do you want the Python 3 case to become an error? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:00:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 18:00:19 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485972019.95.0.732528130235.issue29367@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset da331c7d12c4648b9734ebb07e9f722c8478d269 by Victor Stinner in branch 'master': Fix test_gdb.test_wrapper_call() on Python 2 https://github.com/python/cpython/commit/da331c7d12c4648b9734ebb07e9f722c8478d269 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 18:00:20 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485972020.03.0.220592944906.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 18:00:20 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485972020.07.0.690078764107.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 18:00:20 +0000 Subject: [issue29367] python-gdb: display wrapper_call() In-Reply-To: <1485336576.45.0.391174330106.issue29367@psf.upfronthosting.co.za> Message-ID: <1485972020.1.0.768582233863.issue29367@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:19:47 2017 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 01 Feb 2017 18:19:47 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485973187.5.0.67981917793.issue14376@psf.upfronthosting.co.za> Mark Dickinson added the comment: The test portion of the existing patch doesn't apply cleanly to 2.7 tip. Here's an updated patch that does, with slightly expanded tests and a Misc/NEWS entry. There was discussion above about two overflow cases: C long to C int, and C int to byte, but with this patch there's now a 3rd overflow case to consider, namely Python long to C long. In this case PyInt_AsLong sets an exception and returns -1, and since we don't check for exceptions that -1 then gets used as the exit code. I'm not sure whether that's the right thing to do or not, but it does match what Python 3 currently does, and that's good enough for me. ---------- Added file: http://bugs.python.org/file46481/exit2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 13:34:03 2017 From: report at bugs.python.org (Gareth Rees) Date: Wed, 01 Feb 2017 18:34:03 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1485974043.27.0.776390577621.issue14376@psf.upfronthosting.co.za> Gareth Rees added the comment: Thanks for the revised patch, Mark. The new tests look good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:05:31 2017 From: report at bugs.python.org (Greg Stark) Date: Wed, 01 Feb 2017 19:05:31 +0000 Subject: [issue29413] ssl.SSLSocket.unwrap() is not flexible enough Message-ID: <1485975931.82.0.260230728322.issue29413@psf.upfronthosting.co.za> New submission from Greg Stark: This is not a bug, but rather a request for API improvements. Correct SSL shutdown processing is frequent source of confusion. Python?s ssl module unfortunately lacks the flexibility to accommodate some common paradigms. The problem is that the unwrap() method of SSLObject and SSLSocket always blocks until it receives the peer?s close_notify alert. This is the sensible default since it is the most secure. However, it is also common (and secure) to send the close_notify and then shutdown the socket immediately after without waiting for the peer?s close_notify alert. More details can be found in section 7.2.1 of RFC 2246 and its successors. Another good source is the discussion at http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify To accommodate the range of SSL shutdown behaviors in the real world I propose two small API changes. One is to add a keyword argument to the unwrap() method of SSLSocket and SSLObject. The new keyword argument is wait_for_peer, and it?s default value should be True. unwrap(wait_for_peer=True) would be the default behavior, and would match the current behavior: always wait for the peer to send the close_notify. unwrap(wait_for_peer=False) however, would return successfully after sending the close_notify whether or not the peer has sent their close_notify. In addition, a new method ?get_shutdown_state()? is needed to retrieve the current shutdown state of the SSL connection or object. Or perhaps the method could be a simple boolean ?has_peer_sent_shutdown()?. This is just one proposal for adding some necessary flexibility with minimal API changes. Other approaches are possible. ---------- assignee: christian.heimes components: SSL messages: 286674 nosy: Greg Stark, christian.heimes priority: normal severity: normal status: open title: ssl.SSLSocket.unwrap() is not flexible enough type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:05:59 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 19:05:59 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <20170201190556.15872.15681.436F813A@psf.io> Roundup Robot added the comment: New changeset 3db1959c2c53 by Guido van Rossum in branch 'default': Issue #29377: Add three new wrappers to types.py (Manuel Krebber). https://hg.python.org/cpython/rev/3db1959c2c53 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:07:29 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 19:07:29 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485976049.3.0.366791839142.issue29377@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks Manuel and Ivan! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:10:08 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 19:10:08 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1485976208.92.0.688562977849.issue29344@psf.upfronthosting.co.za> Guido van Rossum added the comment: OP is correct. sock_recv(), sock_sendall(), sock_connect(), sock_accept() all are functions that return Futures. The docs are wrong, as are the docstrings in the code. ---------- versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:10:16 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Wed, 01 Feb 2017 19:10:16 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial Message-ID: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: The current line is confusing hinting that the for statement is actually an object, it also makes a reference to iterators which the tutorial doesn't disambiguate until the chapter on Classes. I've added a small patch that, in my opinion, makes it clearer by using the terminology of the previous sentence. ---------- assignee: docs at python components: Documentation messages: 286678 nosy: Jim Fasarakis-Hilliard, docs at python priority: normal severity: normal status: open title: Change 'the for statement is such an iterator' in Tutorial versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:11:11 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Wed, 01 Feb 2017 19:11:11 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1485976271.41.0.400468809279.issue29414@psf.upfronthosting.co.za> Changes by Jim Fasarakis-Hilliard : ---------- keywords: +patch Added file: http://bugs.python.org/file46482/issue29414.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:32:23 2017 From: report at bugs.python.org (Jason Matthew) Date: Wed, 01 Feb 2017 19:32:23 +0000 Subject: [issue29364] msilib Fetch raises MSIError rather than return None In-Reply-To: <1485284065.77.0.143549147327.issue29364@psf.upfronthosting.co.za> Message-ID: <1485977543.76.0.497579226847.issue29364@psf.upfronthosting.co.za> Jason Matthew added the comment: Thanks for pointing that one out Berker. I agree, this is a dup. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:33:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 19:33:25 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <20170201193322.111010.77928.F94BB257@psf.io> Roundup Robot added the comment: New changeset e4f6874abda6 by Berker Peksag in branch '3.5': Issue #29407: Remove redundant ensure_future() calls in factorial example https://hg.python.org/cpython/rev/e4f6874abda6 New changeset 7196ab02b7ce by Berker Peksag in branch '3.6': Issue #29407: Merge from 3.5 https://hg.python.org/cpython/rev/7196ab02b7ce New changeset 0990a071751f by Berker Peksag in branch 'default': Issue #29407: Merge from 3.6 https://hg.python.org/cpython/rev/0990a071751f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:34:04 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Feb 2017 19:34:04 +0000 Subject: [issue29364] msilib Fetch raises MSIError rather than return None In-Reply-To: <1485284065.77.0.143549147327.issue29364@psf.upfronthosting.co.za> Message-ID: <1485977644.25.0.478274995242.issue29364@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> resolved superseder: -> Add support for _msi.Record.GetString() and _msi.Record.GetInteger() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:35:06 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Feb 2017 19:35:06 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485977706.47.0.592078649495.issue29407@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Guido. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:37:09 2017 From: report at bugs.python.org (Joshua Kinard) Date: Wed, 01 Feb 2017 19:37:09 +0000 Subject: [issue27647] Update Windows 2.7 build to Tcl/Tk 8.5.19 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1485977829.23.0.831856445467.issue27647@psf.upfronthosting.co.za> Joshua Kinard added the comment: Fair enough. I am stuck working with 2.7 for quite a while longer due to platform constraints, but hopefully can migrate over to 3.x at some point. Was worth asking :) At least try to cherrypick that one commit from the TCL/Tk source I referenced so that the Spinbox works correctly under Vista/Aero. I am not sure when that might wind up in a future Tk release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:45:34 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 01 Feb 2017 19:45:34 +0000 Subject: [issue29070] Integration tests for pty.spawn on Linux and all other platforms In-Reply-To: <1482684225.17.0.467768789806.issue29070@psf.upfronthosting.co.za> Message-ID: <1485978334.03.0.207545677817.issue29070@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I have left some comments on Rietveld after a partial code review. IMO for reasons of repeatability and easier maintenance [1], all the tests should be run with the pty set in a known mode, whether canonical or raw, and a test involving pty.spawn() should ensure that the chosen mode will be set by this function, or should skip it otherwise. [1] For example when investigating the random failures in PtyTest reported by Cornelius in the patch comments, one has to wonder: "Oh, maybe it fails on this foreign system because the pty is not in raw mode there". ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:49:24 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Feb 2017 19:49:24 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1485978564.57.0.131253081603.issue29344@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch. sock_connect() wrapped by @coroutine in Lib/asyncio/selector_events.py so I left it as-is. Let me know if it still needs to be updated: @coroutine def sock_connect(self, sock, address): """Connect to a remote socket at address. This method is a coroutine. """ ... return (yield from fut) ---------- assignee: -> docs at python components: +Documentation keywords: +patch nosy: +docs at python stage: -> patch review Added file: http://bugs.python.org/file46483/issue29344.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:26 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979226.49.0.601618712593.issue29407@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 94aa4efdf0196de9f99b6f1bd68322939d8d6974 by Berker Peksag in branch '3.6': Issue #29407: Remove redundant ensure_future() calls in factorial example https://github.com/python/cpython/commit/94aa4efdf0196de9f99b6f1bd68322939d8d6974 New changeset 96104636fa5bd3054367d4667d86d43690c24293 by Berker Peksag in branch '3.6': Issue #29407: Merge from 3.5 https://github.com/python/cpython/commit/96104636fa5bd3054367d4667d86d43690c24293 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:26 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979226.59.0.36796809805.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:26 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979226.65.0.511640339593.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:26 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979226.7.0.682444904742.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:28 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979228.63.0.712169572845.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:28 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979228.52.0.498720746591.issue29407@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 94aa4efdf0196de9f99b6f1bd68322939d8d6974 by Berker Peksag in branch '3.5': Issue #29407: Remove redundant ensure_future() calls in factorial example https://github.com/python/cpython/commit/94aa4efdf0196de9f99b6f1bd68322939d8d6974 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:28 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979228.69.0.864596087532.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:28 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979228.74.0.259051978931.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:30 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979230.7.0.254527598692.issue29407@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 94aa4efdf0196de9f99b6f1bd68322939d8d6974 by Berker Peksag in branch 'master': Issue #29407: Remove redundant ensure_future() calls in factorial example https://github.com/python/cpython/commit/94aa4efdf0196de9f99b6f1bd68322939d8d6974 New changeset 96104636fa5bd3054367d4667d86d43690c24293 by Berker Peksag in branch 'master': Issue #29407: Merge from 3.5 https://github.com/python/cpython/commit/96104636fa5bd3054367d4667d86d43690c24293 New changeset 6b569a0de28e3c341837030d6aa739422d315a6f by Berker Peksag in branch 'master': Issue #29407: Merge from 3.6 https://github.com/python/cpython/commit/6b569a0de28e3c341837030d6aa739422d315a6f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:30 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979230.79.0.655696324121.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:30 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979230.85.0.56818940318.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:30 +0000 Subject: [issue29407] Remove redundant ensure_future() calls in factorial example In-Reply-To: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za> Message-ID: <1485979230.89.0.917778404771.issue29407@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:30 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485979230.95.0.603343721451.issue29377@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 1947d33a0a1c2ba006397579ec6235528faea9fd by Guido van Rossum in branch 'master': Issue #29377: Add three new wrappers to types.py (Manuel Krebber). https://github.com/python/cpython/commit/1947d33a0a1c2ba006397579ec6235528faea9fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:31 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485979231.0.0.785166862138.issue29377@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:31 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485979231.12.0.43656353228.issue29377@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:00:31 +0000 Subject: [issue29377] Add the 'wrapper_descriptor' type to the types module In-Reply-To: <1485425778.09.0.153066086326.issue29377@psf.upfronthosting.co.za> Message-ID: <1485979231.05.0.958099364659.issue29377@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:06:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Feb 2017 20:06:00 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1485979560.83.0.375108885525.issue29344@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think the original idea was to document that all methods of the loop are coroutines, so that: 1. if a user needs a Future object they call ensure_future: fut = asyncio.ensure_future(loop.method()) 2. it gives us ability to refactor things. For instance, sock_connect was a method that returned Futures, but at one point of 3.5 we changed it to be coroutine. Because the method was documented as a coroutine, it wasn't strictly a backwards incompatible way. In general, I think it would be safer for us to simple make all loop methods coroutines. Or, less radical, just keeping the status quo: document everything as a coroutine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:39:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 20:39:08 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previous line In-Reply-To: <1485039375.56.0.473197770315.issue29339@psf.upfronthosting.co.za> Message-ID: <1485981548.79.0.553431256398.issue29339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible. IPython3 solved this issue by adding special magic functions, but this is not a way for CPython. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:42:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 20:42:02 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1485981722.23.0.0485620622015.issue29368@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please make a review of my explanation comment? I have doubts about a wording. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:54:54 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:54:54 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <20170201205451.96147.91480.12B3A455@psf.io> Roundup Robot added the comment: New changeset a889c5524520 by Serhiy Storchaka in branch '2.7': Issue #29354: Fixed inspect.getargs() for parameters which are cell https://hg.python.org/cpython/rev/a889c5524520 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 15:54:54 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 20:54:54 +0000 Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za> Message-ID: <20170201205450.96147.65515.1F9100CA@psf.io> Roundup Robot added the comment: New changeset 8cfa6d3065b3 by Serhiy Storchaka in branch '2.7': Issue #29028: Fixed possible use-after-free bugs in the subscription of the https://hg.python.org/cpython/rev/8cfa6d3065b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 21:00:24 +0000 Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za> Message-ID: <1485982824.05.0.130336348817.issue29028@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 97c8ec91eb10a04c797e4dac99971e4152abcbec by Serhiy Storchaka in branch '2.7': Issue #29028: Fixed possible use-after-free bugs in the subscription of the https://github.com/python/cpython/commit/97c8ec91eb10a04c797e4dac99971e4152abcbec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:00:46 2017 From: report at bugs.python.org (12345 67890) Date: Wed, 01 Feb 2017 21:00:46 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previousline In-Reply-To: <1485981548.79.0.553431256398.issue29339@psf.upfronthosting.co.za> Message-ID: <58924c7b.88aaca0a.cfa79.b263@mx.google.com> 12345 67890 added the comment: That one is pretty tricky. The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab. From: Serhiy Storchaka Sent: Wednesday, February 1, 2017 2:39 PM To: xoviat at gmail.com Subject: [issue29339] Interactive: Move to same indentation level as previousline Serhiy Storchaka added the comment: Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible. IPython3 solved this issue by adding special magic functions, but this is not a way for CPython. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ ---------- title: Interactive: Move to same indentation level as previous line -> Interactive: Move to same indentation level as previousline _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:07:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 21:07:25 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <1485983245.26.0.69301505448.issue29354@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You were on right way Emily. Sorry for crossing your road, but I already had a written patch. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:09:32 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 01 Feb 2017 21:09:32 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485983372.99.0.0322148134681.issue29400@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:10:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 21:10:15 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485983415.66.0.207258751683.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: At the AST level, you have a wide range of possible optimizations. See the optimizations that I implemented in fatoptimizer (FAT Python) to have an idea: http://fatoptimizer.readthedocs.io/en/latest/optimizations.html FAT Python adds guards checked at runtime, something not possible (not wanted) here. But if you start with constant folding, why not implementing constant propagation as well? What about loop unrolling? Where is the limit? If you implement the AST optimizer in C, the limit will probably be your C skills and your motivation :-) In Python, the limit is more the Python semantics which is... hum... not well defined. For example, does it break the Python semantics to replace [i for i in (1, 2, 3)] with [1, 2, 3]? What if you use a debugger? Do yo expect a list comprehension or a literal list? FYI I suspended my work on FAT Python because almost no other core developer was interested. I didn't get any support, whereas I need support to push core FAT Python features like function specialization and runtime checks (PEP 510, see also PEP 511). Moreover, I failed to show any significant speedup on non-trivial functions. I abandoned before investigating function inlining, even if FAT Python already has a basic support for function inlining. This issue is open since 2011. The question is always the same: is it worth it? An alternative is to experiment an AST optimizer outside CPython and come back later with more data to drive the design of such optimizer. With FAT Python, I chose to add hooks in the Python compiler, but different people told me that it's possible to do that without such hook but importlib (importlib hooks). What do you think Naoki? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:12:45 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 21:12:45 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <20170201211241.25629.3754.5536D588@psf.io> Roundup Robot added the comment: New changeset aa7ac93d23b2 by Serhiy Storchaka in branch 'default': Issue #20185: Converted the int class to Argument Clinic. https://hg.python.org/cpython/rev/aa7ac93d23b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:13:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 21:13:51 +0000 Subject: [issue23980] Documentation for format units starting with 'e' is inconsistent In-Reply-To: <1429227526.01.0.733275706487.issue23980@psf.upfronthosting.co.za> Message-ID: <1485983631.82.0.815407351745.issue23980@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:14:27 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 21:14:27 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <1485983667.03.0.944233459783.issue29354@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:17:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 21:17:39 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previousline In-Reply-To: <1485039375.56.0.473197770315.issue29339@psf.upfronthosting.co.za> Message-ID: <1485983859.74.0.91584723655.issue29339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab. This will not help for "else" or "except". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:17:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 21:17:45 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1485983865.07.0.404733938141.issue29368@psf.upfronthosting.co.za> STINNER Victor added the comment: > Could anyone please make a review of my explanation comment? I have doubts about a wording. I'm not fluent in english, so I'm not the best for this task. But I reviewed your patch ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:29:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Feb 2017 21:29:23 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1485984563.82.0.794869318808.issue29368@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Victor. Your wording looks simpler to me. ---------- Added file: http://bugs.python.org/file46484/pickle-appends-extend-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:30:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Feb 2017 21:30:22 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <1485984622.89.0.32922185581.issue29354@psf.upfronthosting.co.za> Yury Selivanov added the comment: Emily, if you have time and want to help us with the inspect module, we have many other unresolved issues. I'd be happy to help you with code reviews etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:32:34 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 21:32:34 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1485984754.39.0.00325334146915.issue29344@psf.upfronthosting.co.za> Guido van Rossum added the comment: The word coroutine has a more specific meaning though (and we have iscoroutine*() inspection functions to check for it). Maybe we should switch all these to "awaitable"? Also note that in proactor_events.py, sock_connect() is *not* a coroutine. In fact I'm not sure what it is -- it calls self._proactor.connect() which appears to return None from the code in windows_events.py. That's presumably a separate bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:36:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 21:36:32 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1485984992.56.0.350863569507.issue29368@psf.upfronthosting.co.za> STINNER Victor added the comment: pickle-appends-extend-3.patch LGTM. Even if I don't see any refleak, you might just run "./python -m test -R 3:3 test_pickle" just to be sure :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:40:24 2017 From: report at bugs.python.org (Emily Morehouse) Date: Wed, 01 Feb 2017 21:40:24 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <1485985223.99.0.788324661878.issue29354@psf.upfronthosting.co.za> Emily Morehouse added the comment: Serhiy, thank you for the update. I looked over your patch to ensure that I understood your solution. I also appreciate your tests, as I was able to see other edge cases that I perhaps would not have thought of. Yury, I'm more than happy to help! I've spent a decent amount of time learning about code objects, byte code, etc. and I'd love to put that knowledge to use. Let me know the best way to find these issues on the tracker or otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:46:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Feb 2017 21:46:57 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1485985617.34.0.102213112583.issue29344@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Maybe we should switch all these to "awaitable"? I like this! Would it be OK to add a new sphinx declaration? So that: .. coroutinemethod:: AbstractEventLoop.shutdown_asyncgens() would become: .. awaitable:: AbstractEventLoop.shutdown_asyncgens() ? > Also note that in proactor_events.py, sock_connect() is *not* a coroutine. Yeah, those small incompatibilities are inevitable for asyncio programs/frameworks -- something that returns a Future may occasionally become a coroutine. Your idea to document API methods as "awaitables" seems to be the right way to go. > In fact I'm not sure what it is -- it calls self._proactor.connect() which appears to return None from the code in windows_events.py. That's presumably a separate bug. It looks like it returns the result of "IocpProactor.connect()" call, which returns an _OverlappedFuture instance (I don't really know Windows part of asyncio code, so I might be missing something). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:51:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 21:51:26 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485985886.2.0.350853680857.issue29400@psf.upfronthosting.co.za> STINNER Victor added the comment: inst-tracing-2.diff: * Rebased patch applied on Mercurial, I had to fix a conflict in sys_settrace() * I replaced your PyEval_SetTraceInstructions() function with a new private _PyEval_SetTraceEx() method * I changed sys.settrace() API to convert the trace_instructions parameter to keyword only: sys.settrace(func, True) raises a TypeError (I added an unit test for that). About the API, I see an issue: the "old=sys.gettrace(); sys.settrace(old)" pattern doesn't work anymore, since old doesn't contain the trace_instructions flag :-/ So I suggest to add a new method and make it exclusive with sys.settrace(), sys.settraceinstr() / sys.gettraceinstr(): * sys.settrace() raises an exception of sys.gettraceinstr() is not None * sys.settraceinstr() raises an exception of sys.gettrace() is not None The sys module is a critical module, so the API should probably be discussed on python-dev (later?). About performances: it's fine to add anything to maybe_call_line_trace(), it cannot impact performances when tracing is not used. Can you please try to reimplement something like __lltrace__ on top of sys.settraceinstr()? It would be a nice example of the API, but also a good reason to add sys.settraceinstr(). See the issue #25571 "Improve the lltrace feature with the Py_Debug mode". Currently, the __lltrace__ feature requires a Python compiled in debug mode, which is not convenient. Moreover, it requires to put a __ltrace__ variable in global variables. The best would be able to add an instruction level debugger inside pdb! It would be a cool tool to learn Python and to play with the bytecode! ---------- Added file: http://bugs.python.org/file46485/inst-tracing-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:51:35 2017 From: report at bugs.python.org (Max) Date: Wed, 01 Feb 2017 21:51:35 +0000 Subject: [issue29415] Exposing handle._callback and handle._args in asyncio Message-ID: <1485985895.46.0.167923746012.issue29415@psf.upfronthosting.co.za> New submission from Max: Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it possible to officially expose them as public API? My use case: handle = event_loop.call_later(delay, callback) # this function can be triggered by some events def reschedule(handle): event_loop.call_later(new_delay, handle._callback, *handle._args) handle.cancel() ---------- components: asyncio messages: 286709 nosy: gvanrossum, max, yselivanov priority: normal severity: normal status: open title: Exposing handle._callback and handle._args in asyncio type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:58:49 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 01 Feb 2017 21:58:49 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485985617.34.0.102213112583.issue29344@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: A new Sphinx declaration sounds great to me, but you might want to check with some Sphinx or Python-docs expert. I somehow misread the code of IocpProactor.connect(), so ignore that part -- the point is that it's not always a coroutine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Feb 2017 22:00:22 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1485986422.06.0.135682418888.issue20185@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 9f889393ab0362229c42bc31056f3ef9735a1d27 by Serhiy Storchaka in branch 'master': Issue #20185: Converted the int class to Argument Clinic. https://github.com/python/cpython/commit/9f889393ab0362229c42bc31056f3ef9735a1d27 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:02:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 22:02:00 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1485986519.99.0.723170838102.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: > It looks to me that the type of the self parameter can be changed from PyObject* to PyStructObject*. This will make the patch larger but the final code simpler. I like the idea, but I prefer to do in a separated change, once the first big one is merged. Otherwise, the first patch will do too many unrelated things at the same time IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:03:28 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Feb 2017 22:03:28 +0000 Subject: [issue29354] Python 2.7.12: pydoc.help(lambda (a, ): lambda x: a) raises IndexError In-Reply-To: <1485208238.9.0.161996393795.issue29354@psf.upfronthosting.co.za> Message-ID: <1485986608.36.0.123545183133.issue29354@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury, I'm more than happy to help! I've spent a decent amount of time learning about code objects, byte code, etc. and I'd love to put that knowledge to use. Let me know the best way to find these issues on the tracker or otherwise. Certainly! There seem to be a lot of issues with inspect.findsource and inspect.getsource functions. Quick search results: #28121 and #26890 (and I know there are few more open issues). For PEP 525 we need to add two new functions to the inspect module (I overlooked them and didn't add them to 3.6): inspect.getasyncgeneratorstate and inspect.getasyncgeneratorlocals (mirroring inspect.getgeneratorstate and inspect.getgeneratorlocals). There are some issues that nobody even replied to, like #26577. For those the protocol is usually to reproduce the problem first, and then make a patch/tests. You can use advanced search on this tracker to find issues like that one. If you are into async world, you can work on adding contextlib.asyncontextmanager decorator. Although this one should first be discussed on the python-ideas mailing list. Also, if you are into C programming, Victor Stinner, INADA Naoki and I are trying to optimize Python ceval loop from time to time (you knowledge of dis/opcodes can be helpful), so you can look for those kind of open issues too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:08:21 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Feb 2017 22:08:21 +0000 Subject: [issue29415] Exposing handle._callback and handle._args in asyncio In-Reply-To: <1485985895.46.0.167923746012.issue29415@psf.upfronthosting.co.za> Message-ID: <1485986901.08.0.968915872375.issue29415@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it possible to officially expose them as public API? I'd be -1 on exposing them. Alternative asyncio event loop implementations such as uvloop don't have those attributes, and it's not always possible to add them. > My use case: > def reschedule(handle): > event_loop.call_later(new_delay, handle._callback, *handle._args) > handle.cancel() Why don't you just call `event_loop.call_later(delay, callback)`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:28:00 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 01 Feb 2017 22:28:00 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485988080.19.0.715381234876.issue29400@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > About performances: it's fine to add anything to maybe_call_line_trace(), it cannot impact performances when tracing is not used. I do not agree, Python debuggers are already really really slow. They should not have to process 'instruction' trace events as this would happen if George does "Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than as an alternate to PyTrace_LINE as it does now". I understand that this was a suggestion :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:37:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 22:37:31 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485988651.5.0.148822192922.issue29400@psf.upfronthosting.co.za> STINNER Victor added the comment: > I do not agree, Python debuggers are already really really slow. They should not have to process 'instruction' trace events as this would happen if George does "Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than as an alternate to PyTrace_LINE as it does now". Hum, there are two things: * attached patch adds an else to the C maybe_call_line_trace(): I don't think that it's possible to notice the overhead in a debugger implemented in pure Python. If you are concerned by the change, we need a micro-benchmark. * existing debuggers may have to be extended to support PyTrace_INSTRUCTION and so may be slowed down. Maybe I misunderstood what you wrote? For me, it's an opt-in feature: you must call sys.settraceinstr() instead of sys.settrace(), otherwise you don't get PyTrace_INSTRUCTION events. From the user point of view, I expect that the debugger starts at LINE level, but only switch to instruction level when I explicitly ask it to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:46:32 2017 From: report at bugs.python.org (Dan Buchoff) Date: Wed, 01 Feb 2017 22:46:32 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop Message-ID: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> New submission from Dan Buchoff: If a path has a non-existent anchor, Path.mkdir can get into a RecursionError as it tries to recursively create the parent. I expect a more sane error. This is readily reproducible in Windows with `Path('Z:').mkdir(parents=True)` Example execution: Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from pathlib import Path >>> Path('Z:').mkdir(parents=True) Traceback (most recent call last): File "C:\Python36\lib\pathlib.py", line 1231, in mkdir self._accessor.mkdir(self, mode) File "C:\Python36\lib\pathlib.py", line 388, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [WinError 3] The system cannot find the path specified: 'Z:' During handling of the above exception, another exception occurred: ... During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) [Previous line repeated 989 more times] File "C:\Python36\lib\pathlib.py", line 1231, in mkdir self._accessor.mkdir(self, mode) File "C:\Python36\lib\pathlib.py", line 388, in wrapped return strfunc(str(pathobj), *args) RecursionError: maximum recursion depth exceeded ---------- components: Library (Lib), Windows messages: 286717 nosy: Dan Buchoff, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Path.mkdir can get into a recursive error loop versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:47:35 2017 From: report at bugs.python.org (Dan Buchoff) Date: Wed, 01 Feb 2017 22:47:35 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1485989255.23.0.545699597111.issue29416@psf.upfronthosting.co.za> Changes by Dan Buchoff : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:55:21 2017 From: report at bugs.python.org (George King) Date: Wed, 01 Feb 2017 22:55:21 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485989721.13.0.00476341686194.issue29400@psf.upfronthosting.co.za> George King added the comment: Xavier, this is a misunderstanding; sorry for not being more clear. When I said "remove the `else`", I was proposing this: + if (tstate->inst_tracing) { + result = call_trace(func, obj, tstate, frame, PyTrace_INSTRUCTION, Py_None); + } Line-oriented tracers/debuggers would not have set trace_instructions, so they would not receive any 'instruction' events, and should not suffer. The motivation for this suggestion was that for tracers that *are* interested in instructions, it *might* be simpler to get two calls, one of 'line', and one of 'instruction'. Maybe it's a bad idea though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 18:02:25 2017 From: report at bugs.python.org (Max) Date: Wed, 01 Feb 2017 23:02:25 +0000 Subject: [issue29415] Exposing handle._callback and handle._args in asyncio In-Reply-To: <1485985895.46.0.167923746012.issue29415@psf.upfronthosting.co.za> Message-ID: <1485990145.9.0.616580981425.issue29415@psf.upfronthosting.co.za> Max added the comment: @yselivanov I just wanted to use the handler to avoid storing the callback and args in my own data structure (I would just store the handlers whenever I may need to reschedule). Not a big deal, I don't have to use handler as a storage space, if it's not supported across implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 18:29:12 2017 From: report at bugs.python.org (George King) Date: Wed, 01 Feb 2017 23:29:12 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485991752.94.0.468956968523.issue29400@psf.upfronthosting.co.za> George King added the comment: Attached is a demo of using the feature as a fancy replacement for __ltrace__. It demonstrates using a closure for the local trace function to track the previous offset, and prints the offset transitions as src -> dst pairs. This helped me learn a lot about how exception handling works at the bytecode level. ---------- Added file: http://bugs.python.org/file46486/inst-trace-demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 18:31:30 2017 From: report at bugs.python.org (George King) Date: Wed, 01 Feb 2017 23:31:30 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1485991890.12.0.75396690717.issue29400@psf.upfronthosting.co.za> George King added the comment: Thanks to both of you for your feedback. I will take a stab at updating the patch with Victor's suggestions as soon as I can. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 18:50:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Feb 2017 23:50:34 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485989721.13.0.00476341686194.issue29400@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hum, I don't know well how Python tracing works, but if we had a new "instruction level debugging" feature, it must be an opt-in feature. Existing debuggers must not be flooded by such events. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 19:09:24 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 02 Feb 2017 00:09:24 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1485994164.0.0.816793414528.issue29416@psf.upfronthosting.co.za> Steve Dower added the comment: Might be worth checking if this is resolved with issue29079, which is already in for 3.6.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 19:20:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Feb 2017 00:20:57 +0000 Subject: [issue29415] Exposing handle._callback and handle._args in asyncio In-Reply-To: <1485985895.46.0.167923746012.issue29415@psf.upfronthosting.co.za> Message-ID: <1485994857.64.0.433640589232.issue29415@psf.upfronthosting.co.za> Yury Selivanov added the comment: > @yselivanov I just wanted to use the handler to avoid storing the callback and args in my own data structure (I would just store the handlers whenever I may need to reschedule). Not a big deal, I don't have to use handler as a storage space, if it's not supported across implementations. Alright, closing the issue. Thanks! ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 19:32:29 2017 From: report at bugs.python.org (Eugene Toder) Date: Thu, 02 Feb 2017 00:32:29 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485995549.24.0.841187016176.issue11549@psf.upfronthosting.co.za> Eugene Toder added the comment: Yes, doing optimizations on AST in CPython is unlikely to give any sizable speed improvements in real world programs. Python as a language is not suited for static optimization, and even if you manage to inline a function, there's still CPython's interpreted overhead and boxed types that dwarf the effect of the optimization. The goal of this patch was never to significantly improve the speed. It was to replace the existing bytecode peephole pass with cleaner and simpler code, which also happens to produce slightly better results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 19:56:04 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 00:56:04 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485996964.31.0.613288387776.issue11549@psf.upfronthosting.co.za> INADA Naoki added the comment: My motivation is improve speed, reduce memory usage, and quicker startup time for real world applications. If some optimization in FAT optimizer has significant speedup, I want to try it. But this time, my motivation is I felt "everyone think constant folding should go to AST from peephole, there is a patch about it, but unfortunately it was suspended (because of lack of reviewers, maybe)." As reading #28813, I think there are consensus about constant folding should go AST. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 19:56:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 00:56:54 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1485997014.47.0.642315441422.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: OK, let's forget Py_HASH_CUTOFF for now and focus on SipHash-13. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:17:26 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 01:17:26 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1485998246.37.0.792073597156.issue29263@psf.upfronthosting.co.za> INADA Naoki added the comment: LOAD_METHOD support was based on tp_fastcall. Without LOAD_METHOD support, methoddescr_get is called and stack layout after LOAD_METHOD is: NULL, (bound)PyCFunction, arg1, arg2, ... argN With LOAD_METHOD support, stack layout is: PyMethodDescrObject, self, arg1, ... argN And tp_call (or tp_fastcall) of method descriptor is called when CALL_METHOD. Without tp_fastcall, it means pack&unpack tuple happens. It is more heavy than creating temporary PyCFunction. --- Other ideas to support LOAD_METHOD for C function are: * Add _PyMethodDescr_FastCallKeywords and call it in call_function. * Create unbound PyCFunction and cache it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:18:07 2017 From: report at bugs.python.org (Douglas Greiman) Date: Thu, 02 Feb 2017 01:18:07 +0000 Subject: [issue29417] Sort entries in foo.dist-info/RECORD Message-ID: <1485998286.97.0.0656038336058.issue29417@psf.upfronthosting.co.za> New submission from Douglas Greiman: Feature Request: It would make reproducible builds easier if the [package].dist-info/RECORD files were sorted in some deterministic way. For example, building a Docker image twice and comparing the results. The current ordering seems to be arbitrary, and I didn't find any PEPs that specify one way or the other. I'm not sure what would need to be updated for this change. The whole pip/distutils/setuptools ecosystem is a bit murky. ---------- components: Distutils messages: 286729 nosy: dgreiman, dstufft, eric.araujo priority: normal severity: normal status: open title: Sort entries in foo.dist-info/RECORD type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:27:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 01:27:34 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1485996964.31.0.613288387776.issue11549@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: INADA Naoki added the comment: > My motivation is improve speed, Ah, if the motivation is performance, I would like to see benchmark results :-) I understand that an AST optimizer would help to produce more efficient bytecode, right? > reduce memory usage, I noticed an issue with the peephole optimizer: the constant folding step keeps original constants. Moving constant folding to the AST stage fixes this issue by design. > and quicker startup time for real world applications. You mean faster import time on precompiled .pyc files, right? It's related to the hypothetical faster bytecode. > If some optimization in FAT optimizer has significant speedup, I want to try it. See http://fatoptimizer.readthedocs.io/en/latest/microbenchmarks.html#microbench FYI it took me something like 2 months to build FAT Python "infrastructure": fix CPython bugs, design guards, design the AST optimizer, write unit tests, etc. I didn't spend much time on efficient optimizations. But for my first rule was to not break the CPython test suite! Not break the Python semantics, otherwise it would be impossible to put enable the optimizer by default in CPython, which is my long term goal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:27:59 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Feb 2017 01:27:59 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1485998879.87.0.138299661401.issue29263@psf.upfronthosting.co.za> Yury Selivanov added the comment: > * Add _PyMethodDescr_FastCallKeywords and call it in call_function. This option seems to be the easiest to implement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:35:29 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Feb 2017 01:35:29 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1485999329.05.0.976174750819.issue11549@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:45:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 01:45:44 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1485999944.96.0.138506476762.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: INADA Naoki: "LOAD_METHOD support was based on tp_fastcall. (...) Other ideas to support LOAD_METHOD for C function are: * Add _PyMethodDescr_FastCallKeywords and call it in call_function." It seems like a very small subset of tp_fastcall. If it provides a significant speedup, I really like the idea :-) I would be happy to see a "subset of tp_fastcall" merged. At least my whole tp_fastcall experiment wouldn't be worthless :-) What would be the main change which would provide a speedup? Avoid the creation of a temporary tuple to pass positional arguments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:49:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 01:49:33 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486000173.54.0.473485820576.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: > * Create unbound PyCFunction and cache it Does it mean create a new private type, similar to PyCFunction_Type (PyCFunctionObject) but without the self attribute? IMHO creating a new type is complex. I'm not sure that it's worth it, especially if the _PyMethodDescr_FastCallKeywords() idea is simpler to implement and "fast enough". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:59:11 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 02 Feb 2017 01:59:11 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1486000751.33.0.382198461587.issue29416@psf.upfronthosting.co.za> Eryk Sun added the comment: This case is similar to issue 29079. It should only attempt to make the parent to handle ENOENT if self and self.parent aren't equal. Here's the snippet from Path.mkdir: try: self._accessor.mkdir(self, mode) except FileExistsError: if not exist_ok or not self.is_dir(): raise except OSError as e: if e.errno != ENOENT: raise self.parent.mkdir(parents=True) self._accessor.mkdir(self, mode) ---------- nosy: +eryksun stage: -> needs patch versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 23:17:46 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Feb 2017 04:17:46 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486009066.61.0.725518363842.issue29368@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Could anyone please make a review of my explanation comment? > I have doubts about a wording. The wording is correct and clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 23:21:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 04:21:39 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <20170202042135.25874.71162.E2DFD25B@psf.io> Roundup Robot added the comment: New changeset 3d712292f2fa by Mariatta Wijaya in branch '3.6': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://hg.python.org/cpython/rev/3d712292f2fa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:00:22 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486011622.96.0.40727776318.issue29381@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset abfa17511f7ce8f1a6394f28f82ffb9a916fcf03 by Mariatta Wijaya in branch '3.6': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://github.com/python/cpython/commit/abfa17511f7ce8f1a6394f28f82ffb9a916fcf03 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:00:23 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486011623.17.0.586091295762.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:00:23 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486011623.37.0.856387109761.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:00:23 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486011623.46.0.390527433788.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:04:01 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:04:01 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <20170202050358.8335.36941.9EF9A91B@psf.io> Roundup Robot added the comment: New changeset 483d9133fd7e by Mariatta Wijaya in branch '3.6': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://hg.python.org/cpython/rev/483d9133fd7e New changeset 762a93935afd by Mariatta Wijaya in branch 'default': Issue #29381: merge with 3.6 https://hg.python.org/cpython/rev/762a93935afd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:10:56 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 05:10:56 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486012256.49.0.606161537751.issue29263@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm running pyperformance. ---------- Added file: http://bugs.python.org/file46487/loadmethod-methoddescr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:17:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 05:17:42 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486012662.54.0.988002159179.issue29263@psf.upfronthosting.co.za> INADA Naoki added the comment: Here is the result. I'll investigate mako result. + ../python.default -m perf compare_to default.json patched.json -G --min-speed=1 Slower (20): - mako: 40.9 ms +- 0.4 ms -> 44.7 ms +- 0.6 ms: 1.09x slower (+9%) - chaos: 298 ms +- 3 ms -> 308 ms +- 2 ms: 1.03x slower (+3%) - telco: 19.7 ms +- 0.6 ms -> 20.2 ms +- 0.5 ms: 1.03x slower (+3%) - scimark_sor: 478 ms +- 7 ms -> 491 ms +- 11 ms: 1.03x slower (+3%) - xml_etree_process: 238 ms +- 3 ms -> 245 ms +- 4 ms: 1.03x slower (+3%) - logging_simple: 31.1 us +- 0.3 us -> 31.9 us +- 0.3 us: 1.03x slower (+3%) - logging_format: 36.4 us +- 0.3 us -> 37.2 us +- 0.4 us: 1.02x slower (+2%) - nqueens: 264 ms +- 3 ms -> 270 ms +- 3 ms: 1.02x slower (+2%) - fannkuch: 1.07 sec +- 0.02 sec -> 1.09 sec +- 0.03 sec: 1.02x slower (+2%) - django_template: 401 ms +- 5 ms -> 409 ms +- 3 ms: 1.02x slower (+2%) - call_method_slots: 14.6 ms +- 0.2 ms -> 14.9 ms +- 0.1 ms: 1.02x slower (+2%) - meteor_contest: 199 ms +- 2 ms -> 203 ms +- 2 ms: 1.02x slower (+2%) - logging_silent: 735 ns +- 9 ns -> 746 ns +- 11 ns: 1.02x slower (+2%) - sqlalchemy_declarative: 314 ms +- 4 ms -> 318 ms +- 4 ms: 1.01x slower (+1%) - genshi_text: 89.1 ms +- 1.3 ms -> 90.2 ms +- 1.3 ms: 1.01x slower (+1%) - unpack_sequence: 131 ns +- 2 ns -> 133 ns +- 2 ns: 1.01x slower (+1%) - call_method: 15.1 ms +- 0.2 ms -> 15.3 ms +- 0.1 ms: 1.01x slower (+1%) - scimark_monte_carlo: 263 ms +- 6 ms -> 266 ms +- 6 ms: 1.01x slower (+1%) - unpickle_pure_python: 834 us +- 16 us -> 843 us +- 15 us: 1.01x slower (+1%) - pathlib: 51.2 ms +- 0.9 ms -> 51.7 ms +- 0.7 ms: 1.01x slower (+1%) Faster (11): - scimark_lu: 457 ms +- 49 ms -> 407 ms +- 7 ms: 1.12x faster (-11%) - chameleon: 30.2 ms +- 0.6 ms -> 28.8 ms +- 0.4 ms: 1.05x faster (-5%) - xml_etree_parse: 314 ms +- 12 ms -> 303 ms +- 8 ms: 1.04x faster (-4%) - sqlite_synth: 10.3 us +- 0.2 us -> 9.94 us +- 0.25 us: 1.03x faster (-3%) - pickle_pure_python: 1.28 ms +- 0.02 ms -> 1.25 ms +- 0.02 ms: 1.03x faster (-3%) - xml_etree_iterparse: 223 ms +- 5 ms -> 218 ms +- 7 ms: 1.02x faster (-2%) - scimark_fft: 730 ms +- 19 ms -> 716 ms +- 18 ms: 1.02x faster (-2%) - nbody: 243 ms +- 5 ms -> 239 ms +- 6 ms: 1.02x faster (-2%) - tornado_http: 377 ms +- 4 ms -> 373 ms +- 4 ms: 1.01x faster (-1%) - sympy_expand: 1.02 sec +- 0.01 sec -> 1.01 sec +- 0.01 sec: 1.01x faster (-1%) - unpickle: 32.1 us +- 0.3 us -> 31.8 us +- 0.2 us: 1.01x faster (-1%) Benchmark hidden because not significant (33): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:20:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 05:20:42 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486012842.04.0.962048455342.issue29263@psf.upfronthosting.co.za> INADA Naoki added the comment: microbench: $ ./python.patched -m perf timeit --compare-to `pwd`/python.default -s "d = b''" -- "d.decode('ascii')" python.default: ..................... 109 ns +- 1 ns python.patched: ..................... 102 ns +- 1 ns Median +- std dev: [python.default] 109 ns +- 1 ns -> [python.patched] 102 ns +- 1 ns: 1.08x faster (-7%) $ ./python.patched -m perf timeit --compare-to `pwd`/python.default -s "l = [42]" -- "l.count(42)" python.default: ..................... 66.0 ns +- 0.9 ns python.patched: ..................... 60.0 ns +- 0.3 ns Median +- std dev: [python.default] 66.0 ns +- 0.9 ns -> [python.patched] 60.0 ns +- 0.3 ns: 1.10x faster (-9%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:21:16 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 05:21:16 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <20170202052113.7701.10871.571B1073@psf.io> Roundup Robot added the comment: New changeset df356d3c916e by Mariatta Wijaya in branch '2.7': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://hg.python.org/cpython/rev/df356d3c916e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 00:42:58 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 02 Feb 2017 05:42:58 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486014178.94.0.215543133238.issue29381@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Jim, Marco, and Raymond :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:22 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015222.78.0.0881624672436.issue29381@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 848eeb1debc94a82660bf5af4e3d554b02b81c2e by Mariatta Wijaya in branch '3.6': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://github.com/python/cpython/commit/848eeb1debc94a82660bf5af4e3d554b02b81c2e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:22 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015222.88.0.639037662154.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:23 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015223.14.0.619572009905.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:23 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015223.28.0.430682416013.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:24 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015224.7.0.677488988334.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:24 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015224.6.0.048592625285.issue29381@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 3f5b24dd4b38bf885a80f4bb5f605cd6b0c49ead by Mariatta Wijaya in branch '2.7': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://github.com/python/cpython/commit/3f5b24dd4b38bf885a80f4bb5f605cd6b0c49ead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:24 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015224.77.0.059328979313.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:24 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015224.83.0.314642242492.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:28 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015228.55.0.0470688286526.issue29381@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset abfa17511f7ce8f1a6394f28f82ffb9a916fcf03 by Mariatta Wijaya in branch 'master': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://github.com/python/cpython/commit/abfa17511f7ce8f1a6394f28f82ffb9a916fcf03 New changeset 848eeb1debc94a82660bf5af4e3d554b02b81c2e by Mariatta Wijaya in branch 'master': Issue #29381: Clarify ordering of UNIX shebang line as source encoding line https://github.com/python/cpython/commit/848eeb1debc94a82660bf5af4e3d554b02b81c2e New changeset 35519d021ece942efc4a710ea3e94bcc5c06b130 by Mariatta Wijaya in branch 'master': Issue #29381: merge with 3.6 https://github.com/python/cpython/commit/35519d021ece942efc4a710ea3e94bcc5c06b130 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:28 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015228.66.0.598533173687.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:28 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015228.73.0.0876637639931.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:00:28 +0000 Subject: [issue29381] Tutorial documentation contains undefined reference to #! In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za> Message-ID: <1486015228.78.0.737637937036.issue29381@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:22:28 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Feb 2017 06:22:28 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486016548.47.0.00296056144412.issue29329@psf.upfronthosting.co.za> Zachary Ware added the comment: LGTM. ---------- assignee: docs at python -> Mariatta nosy: +Mariatta, zach.ware stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:27:17 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 06:27:17 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <20170202062713.96198.75158.3B5D3721@psf.io> Roundup Robot added the comment: New changeset d7804789368a by Mariatta Wijaya in branch '2.7': Issue #29329: Improve documentation for hex(). Patch by Ammar Askar https://hg.python.org/cpython/rev/d7804789368a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:33:57 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 02 Feb 2017 06:33:57 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486017237.77.0.390590159532.issue29329@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Pekka, Eryk, Ammar, and Zachary :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 01:49:43 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 02 Feb 2017 06:49:43 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486018183.05.0.36969958199.issue29329@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- resolution: -> fixed stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 02:00:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 07:00:19 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486018819.45.0.66162438403.issue29329@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset d03fd5d041b6f514daf0aabc0c159d8727c33980 by Mariatta Wijaya in branch '2.7': Issue #29329: Improve documentation for hex(). Patch by Ammar Askar https://github.com/python/cpython/commit/d03fd5d041b6f514daf0aabc0c159d8727c33980 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 02:00:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 07:00:19 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486018819.58.0.19694637805.issue29329@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 02:00:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 07:00:19 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486018819.64.0.574791160411.issue29329@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 02:00:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 07:00:19 +0000 Subject: [issue29329] Incorrect documentation for custom `hex()` support on Python 2 In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za> Message-ID: <1486018819.71.0.459760846715.issue29329@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 04:13:16 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 09:13:16 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <20170202091313.25359.9375.7D6F97A4@psf.io> Roundup Robot added the comment: New changeset 94d630a02a81 by Serhiy Storchaka in branch 'default': Issue #29368: The extend() method is now called instead of the append() https://hg.python.org/cpython/rev/94d630a02a81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 04:32:53 2017 From: report at bugs.python.org (Manuel Krebber) Date: Thu, 02 Feb 2017 09:32:53 +0000 Subject: [issue29418] inspect.isroutine does not return True for some bound builtin methods Message-ID: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za> New submission from Manuel Krebber: Some of the builtin methods are not recognized as such by inspect.isroutine(). inspect.ismethoddescriptor() only returns True for the unbound versions of the methods but not the bound ones. For example: >>> inspect.isroutine(object.__str__) True >>> inspect.isroutine(object().__str__) False The second one should also return True as it does for user-defined classes: >>> class A: ... def f(self): ... pass >>> inspect.isroutine(A.f) True >>> inspect.isroutine(A().f) True The types needed for that have already been added to the types module in issue #29377. Here is the commit: https://github.com/python/cpython/commit/1947d33a0a1c2ba006397579ec6235528faea9fd ---------- components: Library (Lib) messages: 286752 nosy: Wheerd, levkivskyi, yselivanov priority: normal severity: normal status: open title: inspect.isroutine does not return True for some bound builtin methods type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 04:58:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 09:58:40 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <20170202095837.16593.98181.EB510B11@psf.io> Roundup Robot added the comment: New changeset 328147c0edc3 by Victor Stinner in branch 'default': Issue #29368: Fix _Pickle_FastCall() usage in do_append() https://hg.python.org/cpython/rev/328147c0edc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 10:00:20 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029620.66.0.0406157417819.issue29368@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 10:00:20 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029620.58.0.284985709746.issue29368@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 10:00:20 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029620.62.0.434097974525.issue29368@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 10:00:20 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029620.51.0.122438360896.issue29368@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset f89fdc29937139b55dd68587759cadb8468d0190 by Serhiy Storchaka in branch 'master': Issue #29368: The extend() method is now called instead of the append() https://github.com/python/cpython/commit/f89fdc29937139b55dd68587759cadb8468d0190 New changeset 4d7e63d9773a766358294593fc00b1f8c8f41b5d by Victor Stinner in branch 'master': Issue #29368: Fix _Pickle_FastCall() usage in do_append() https://github.com/python/cpython/commit/4d7e63d9773a766358294593fc00b1f8c8f41b5d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:01:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 10:01:07 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029667.06.0.710092355109.issue29368@psf.upfronthosting.co.za> STINNER Victor added the comment: > Even if I don't see any refleak, you might just run "./python -m test -R 3:3 test_pickle" just to be sure :-) Change 94d630a02a81 introduced a crash in test_pickle: Fatal Python error: ..\Modules\_pickle.c:5847 object at 000002B7F7BED2F8 has negative ref count -1 Seen on buildbots, but can always be reproduce on Linux as well. It seems like you was biten by the surprising _Pickle_FastCall() API which decreases the reference counter of its second parameter. Don't ask me why it does that :-) (I don't know.) I fixed the bug in the change 328147c0edc3 to repair buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:02:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 10:02:55 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486029775.98.0.774519345827.issue29300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This doesn't make the patch much bigger. Usually such kind of changes are made in one patch. Here is a patch that also changes the type of the self parameter to PyStructObject*. struct_fastcall-6.patch LGTM, but I prefer struct_fastcall-7.patch. ---------- Added file: http://bugs.python.org/file46488/struct_fastcall-7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:04:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 10:04:40 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486029880.6.0.296775608496.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: I tried to benchmark b''.decode(encoding='ascii'): CALL_METHOD is not used for this call, but CALL_FUNCTION_KW :-/ So the call is not affected by your patch. I also ran a quick benchmark on loadmethod-methoddescr.patch: b''.decode(): 71.1 ns +- 0.5 ns -> 65.4 ns +- 0.2 ns: 1.09x faster (-8%) b''.decode('utf8'): 92.8 ns +- 0.4 ns -> 85.5 ns +- 0.3 ns: 1.09x faster (-8%) I confirm the speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:05:48 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 10:05:48 +0000 Subject: [issue29368] Optimize unpickling list-like objects: use extend() instead of append() In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za> Message-ID: <1486029948.34.0.59309445191.issue29368@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:12:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 10:12:12 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486030332.38.0.287033154896.issue29263@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:17:08 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 02 Feb 2017 10:17:08 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1486030628.84.0.800148769546.issue27659@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Hello, any updates here? I hope this merged soon so that potential issues on obscure platforms can be fixed as soon as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:21:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 10:21:11 +0000 Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za> Message-ID: <1486030871.56.0.952735014106.issue29079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure the fix is correct. os.path.dirname(s) can point to different place than os.path.abspath(os.path.join(s, os.pardir)) if the last component of s is "..", "." or a symbolic link. Would be nice to add tests. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 05:57:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 10:57:05 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486033025.36.0.712039106771.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: - if (PyObject_GetBuffer(input, &vbuf, PyBUF_SIMPLE) < 0) - return NULL; Oh by the way, I forgot to mention a subtle change. PyObject_GetBuffer(PyBUF_SIMPLE) is less strict that PyArg_Parse("y#") / "buffer" converter of Argument Clinic: getargs.c also checks that the buffer is contiguous, extract of getbuffer(): if (!PyBuffer_IsContiguous(view, 'C')) { PyBuffer_Release(view); *errmsg = "contiguous buffer"; return -1; } I don't know well the buffer protocol. I don't know any object which provide a non-contiguous buffer. At least, I can say that the last time I looked at this dark part of Python, the documentation was between tiny and non-existent :-/ The buffer protocol is complex but not well documented :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:10:28 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 11:10:28 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486033828.93.0.510178806446.issue29263@psf.upfronthosting.co.za> INADA Naoki added the comment: I confirmed bm_mako performance degrade is caused by L1 cache miss. (I didn't use --with-optimization) https://gist.github.com/methane/b33edbf1f123ae026e704b0e005c3606 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:10:41 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 02 Feb 2017 11:10:41 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1486033841.41.0.379284141192.issue29414@psf.upfronthosting.co.za> Marco Buttu added the comment: I agree with you that the current sentence: "We have seen that the for statement is such an iterator" is wrong. But also the new sentence IMHO is confusing, because it stills compare statementes with objects: "the for statement expects an object that is iterable. The function list is another; it creates lists from iterables". Also list is a class, not a function. IMHO the goal of the sentence you want to patch is to complete the previous one [1], adding an example of "construct" that operates with iterables, and of function that takes an iterable. If you want to follow that purpose, I suggest somethink like this: "We have seen that the for statement is such a construct, while examples of functions that take an iterable are ``sum()`` and ``max()``::" Written in better English than mine... [1] "We say such an object is iterable, that is, suitable as a target for functions and constructs that expect something from which they can obtain successive items until the supply is exhausted." ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:20:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 11:20:59 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486034459.05.0.0806431357324.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: Naoki> I confirmed bm_mako performance degrade is caused by L1 cache miss. I know this performance instability very well, the issue is called "code placement": https://haypo.github.io/journey-to-stable-benchmark-deadcode.html I tried to fight it with GCC __attribute__((hot)) in the issue #28618, but it doesn't fix the issue (at least, not completely): http://bugs.python.org/issue28618#msg281459 In my experience, the best fix is PGO. Slowly, I consider that it's worthless to try to "fight" against code placement, and that benchmark results are only reliable when PGO compilation was used. Otherwise, you should ignore small performance differences. Problem: What is the threshold? 5%? 10%? I already noticed a difference up to 70% only caused by code placement! https://haypo.github.io/analysis-python-performance-issue.html -- I ran benchmarks on loadmethod-methoddescr.patch on haypo at speed-python with LTO+PGO. If you only show performance difference of at least 5%, only 3 benchmarks are significant and are faster: --- haypo at speed-python$ python3 -m perf compare_to ~/benchmarks/*762a93935afd*json loadmethod-methoddesc_ref_762a93935afd.json -G --min-speed=5 Faster (3): - regex_v8: 50.3 ms +- 0.4 ms -> 43.2 ms +- 0.3 ms: 1.17x faster (-14%) - scimark_monte_carlo: 230 ms +- 6 ms -> 208 ms +- 4 ms: 1.11x faster (-10%) - scimark_lu: 390 ms +- 17 ms -> 370 ms +- 13 ms: 1.05x faster (-5%) Benchmark hidden because not significant (61): (...) --- In my experience, regex_v8 and scimark_* benchmarks are not really reliable. I'm not surprised to not see a major speedup on performance, since the speedup on microbenchmarks is only 10% faster. IHMO 10% faster on method calls is significant enough, since it's a core, very common, and widely used Python feature. -- To be more explicitl: loadmethod-methoddescr.patch LGTM except of minor comments on the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:27:42 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 02 Feb 2017 11:27:42 +0000 Subject: [issue29400] Instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486034862.5.0.321292479044.issue29400@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The motivation for this suggestion was that for tracers that *are* interested in instructions, it *might* be simpler to get two calls, one of 'line', and one of 'instruction'. Maybe it's a bad idea though. Thanks for the clarification. It's ok if instruction tracing remains an opt-in feature. As for this suggestion, I am not sure it is useful for debuggers based on the bdb module as trace_dispatch() (the bdb trace function) receives notification of the trace event type as the 'event' argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:32:01 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 11:32:01 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <20170202113157.128024.81764.355D9A90@psf.io> Roundup Robot added the comment: New changeset f3ff4a3ce77c by Victor Stinner in branch 'default': Issue #29300: Convert _struct module to Argument Clinic https://hg.python.org/cpython/rev/f3ff4a3ce77c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 06:37:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 11:37:15 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486035435.1.0.158630955714.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: I also prefer Serhiy's struct_fastcall-7.patch over my struct_fastcall-6.patch. Serhiy Storchaka: "This doesn't make the patch much bigger. Usually such kind of changes are made in one patch." Well, it's just that you prefer to reduce the number of commits and so fold tiny changes into a single big commit, whereas I now prefer multiple tiny commits. I have not strong preferences between the two ways to commit, so I pushed your patch. Here is the full commit message, since Roundbot bot only shows the first line: --- Issue #29300: Convert _struct module to Argument Clinic * The struct module now requires contiguous buffers. * Convert most functions and methods of the _struct module to Argument Clinic * Use "Py_buffer" type for the "buffer" argument. Argument Clinic is responsible to create and release the Py_buffer object. * Use "PyStructObject *" type for self to avoid explicit conversions. * Add an unit test on the _struct.Struct.unpack_from() method to test passing arguments as keywords. * Rephrase docstrings. * Rename "fmt" argument to "format" in docstrings and the documentation. As a side effect, functions and methods which used METH_VARARGS calling convention like struct.pack() now use the METH_FASTCALL calling convention which avoids the creation of temporary tuple to pass positional arguments and so is faster. For example, struct.pack("i", 1) becomes 1.56x faster (-36%):: $ ./python -m perf timeit \ -s 'import struct; pack=struct.pack' 'pack("i", 1)' \ --compare-to=../default-ref/python Median +- std dev: 119 ns +- 1 ns -> 76.8 ns +- 0.4 ns: 1.56x faster (-36%) Significant (t=295.91) Patch co-written with Serhiy Storchaka. --- So yeah, the "side effect" is that struct.pack("i", 1) becomes 1.56x faster (-36%). Ok, maybe it was my main goal ;-) I also mentioned the "new" (?) contiguous requirement on buffers. Thanks Serhiy for your multiple reviews, very useful as usual. I like the final result: better documentation, better docstrings and better code! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 12:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486036826.33.0.0889889135387.issue29300@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset e552e185f3087204d326409e8631eb33dd0e7958 by Victor Stinner in branch 'master': Issue #29300: Convert _struct module to Argument Clinic https://github.com/python/cpython/commit/e552e185f3087204d326409e8631eb33dd0e7958 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 12:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486036826.42.0.872508058045.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 12:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486036826.48.0.504352040679.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 12:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486036826.55.0.396140917578.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:00:30 2017 From: report at bugs.python.org (jordan-pittier) Date: Thu, 02 Feb 2017 12:00:30 +0000 Subject: [issue27715] call-matcher breaks if a method is mocked with spec=True In-Reply-To: <1470710605.81.0.432461136624.issue27715@psf.upfronthosting.co.za> Message-ID: <1486036830.88.0.446227868153.issue27715@psf.upfronthosting.co.za> jordan-pittier added the comment: I stumbled onto this today. I can confirm the issue. ---------- nosy: +jordan-pittier _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:16:38 2017 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Feb 2017 12:16:38 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486037798.11.0.282075175836.issue29300@psf.upfronthosting.co.za> Martin Panter added the comment: Shouldn?t the top-level unpack() parameter be called ?buffer? like the other functions and methods, not ?inputstr?? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:22:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 12:22:43 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486038163.06.0.51755178621.issue29300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Propose for your consideration a patch that uses Argument Clinic for getting possible cached struct object from the format. This simplifies the implementation of module level functions. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file46489/cache_struct.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:24:31 2017 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Feb 2017 12:24:31 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486038270.99.0.492063865674.issue29300@psf.upfronthosting.co.za> Martin Panter added the comment: FYI Victor, you can make non-C-contiguous buffers by slicing memoryview: >>> struct.unpack(">L", memoryview(b"1234")[::-1]) Traceback (most recent call last): File "", line 1, in BufferError: memoryview: underlying buffer is not C-contiguous Can also use the built-in _testbuffer module to create stranger buffers. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:25:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 12:25:09 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486038309.09.0.797229796227.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin> Shouldn?t the top-level unpack() parameter be called ?buffer? like the other functions and methods, not ?inputstr?? Hum. I reopen the issue. Attached patch renames unpack() "inputstr" argument to "buffer" and uses the Py_buffer type for it. I had to fix unit tests which passed str instead of bytes to buffer. Before this error was missed because the unit test is written to test the format string value, not the type of arguments. ---------- resolution: fixed -> Added file: http://bugs.python.org/file46490/unpack_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:37:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 12:37:24 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1486033025.36.0.712039106771.issue29300@psf.upfronthosting.co.za> Message-ID: <11346678.dGhT4LBDOC@raxxla> Serhiy Storchaka added the comment: > Oh by the way, I forgot to mention a subtle change. > PyObject_GetBuffer(PyBUF_SIMPLE) is less strict that PyArg_Parse("y#") / > "buffer" converter of Argument Clinic: getargs.c also checks that the > buffer is contiguous, extract of getbuffer(): We already made such changes in the past. The difference is subtle and I have doubts that choosing any of ways was deliberate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:43:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 12:43:13 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1486035435.1.0.158630955714.issue29300@psf.upfronthosting.co.za> Message-ID: <1665105.2yPUgnUkr1@raxxla> Serhiy Storchaka added the comment: > So yeah, the "side effect" is that struct.pack("i", 1) becomes 1.56x faster > (-36%). Ok, maybe it was my main goal ;-) I also mentioned the "new" (?) > contiguous requirement on buffers. struct.pack() always was faster than int.to_bytes(). I wanted to speed up int.to_bytes(), and after converting to Argument Clinic in issue20185 it have became faster than struct.pack(). But after converting the struct module to Argument Clinic struct.pack() is faster than int.to_bytes() again! Now I need to find other ways to make int.to_bytes() even faster to win this chase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:49:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 12:49:16 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486039756.74.0.0540840792472.issue29300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: unpack_buffer.patch LGTM. Please backport test changes and other changes discussed before to other branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:49:36 2017 From: report at bugs.python.org (Vincent Pelletier) Date: Thu, 02 Feb 2017 12:49:36 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1486039776.42.0.806922551837.issue29404@psf.upfronthosting.co.za> Vincent Pelletier added the comment: My original point of view was that: - python3 is right to only accept integers, consistently with "str != bytes" - python2 is rather right to accept str, consistently with "str == bytes" - maybe the bug is that python2 should not reject integers, making the upgrade path to python3 (or the backward compatibility with python2, same thing) easy. The context is that I develop a (pure-python) module interfacing with a C library, and somewhere in there I want to expose a read/write memory area (the bytearray) which first few bytes must not be accessible from the application using my module (because the application does not care about these bytes, and slicing everywhere is not convenient). Also, I do not want to expose ctypes instances (I'm supposed to be the python/C interface so the application does not have to care). So exposing that memory chunk via a memoryview slice over the original bytearray seems (and please do correct me if I am wrong) the right way to implement this: >>> b = bytearray(16) # the "real" buffer >>> c = (ctypes.c_char * 16).from_buffer(b) # for C library >>> v = memoryview(b)[8:] # for host program But because of this memoryview behaviour difference my API will behave inconsistently between python2 and python3. My (na?ve) initial idea submitting this bug report was that python2 would be modified to tolerate integers passed to memoryview.__setitem__. But I later realised such change would not be sufficient: python2's memoryview.__getitem__ returns strings where python3's returns integers. I agree that changing such visible behaviour in python2 would be bad. Am I stuck with developing my own proxy class then (likely wrapping memoryview with type-casting glue) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:50:49 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 12:50:49 +0000 Subject: [issue29419] Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)? Message-ID: <1486039849.42.0.101303637281.issue29419@psf.upfronthosting.co.za> New submission from STINNER Victor: Argument Clinic calls one the following functions depending on parameters: * PyArg_UnpackTuple(), _PyArg_UnpackStack() * PyArg_ParseTuple(), _PyArg_ParseStack() * PyArg_ParseTupleAndKeywords(), _PyArg_ParseStackAndKeywords() * etc. Would it make sense to emit C code instead of calling complex and slow PyArg_ParseXXX() functions? It would emit the most efficient C code to parse arguments. I don't recall where this idea comes from. Maybe Larry Hastings told me once that he wants to implement this idea :-) I'm sure that Larry has a big plan but lacks time to implement all of his cool ideas. Using profiled guided optimization (PGO), the compiler should be able to easily detect that error cases are unlikely and mark these code paths as unlikely. We should probably experiment an implementation to be able to measure the speedup, to be able to say if the idea is worth it or not, in term of performance, since the motivation here is clearly performance. We can begin with format strings only made of "O" format. Most simple example with divmod(), replace: if (!_PyArg_UnpackStack(args, nargs, "divmod", 2, 2, &x, &y)) { return NULL; } with something like: if (nargs != 2) { _PyArg_ErrNumArgs(nargs, 2, 2, "divmod"); return NULL; } x = args[0]; y = args[1]; The next question is if we should go further with more complex formats. Example with the format() function, replace: if (!_PyArg_ParseStack(args, nargs, "O|U:format", &value, &format_spec)) { ... } with: if (nargs < 1 || nargs > 2) { _PyArg_ErrNumArgs(nargs, 1, 2, "format"); return NULL; } value = args[0]; if (nargs == 2) { format_spec = args[1]; if (!PyUnicode_Check(format_spec)) { .. raise an exception ...; return NULL; } /* getargs.c calls PyUnicode_READY(), we should also do it here */ if (PyUnicode_READY(format_spec) == -1) { return NULL; } } else { format_spec = NULL; } ---------- components: Argument Clinic messages: 286778 nosy: haypo, inada.naoki, larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)? type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:02:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 13:02:24 +0000 Subject: [issue29419] Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)? In-Reply-To: <1486039849.42.0.101303637281.issue29419@psf.upfronthosting.co.za> Message-ID: <1486040544.26.0.372116824938.issue29419@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue23867 for the first step (unfinished). After that I planned to inline parsing code for PyArg_ParseTuple() with multiple arguments. Then split PyArg_ParseTupleAndKeywords() on two parts: first unpack keywords to linear sparse array and then handle it as positional arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:11:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 13:11:38 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1486041098.84.0.635835543444.issue29404@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > - maybe the bug is that python2 should not reject integers, making the upgrade path to python3 (or the backward compatibility with python2, same thing) easy. It is too late for this. You can use the helper that converts the argument to appropriate depending on the version. if PY2: def helper(arg): if isinstance(ar, (int, long)): return chr(arg) return arg else: def helper(arg): return arg ... v[0] = helper(42) Or just have different branches for performance critical code: if PY2: v[0] = b'\x2a' else: v[0] = 42 I don't think Python interpreter should be changed here. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:15:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 13:15:48 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486041348.9.0.18913765479.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "But after converting the struct module to Argument Clinic struct.pack() is faster than int.to_bytes() again!" Sorry about that ;-) Serhiy Storchaka: "Now I need to find other ways to make int.to_bytes() even faster to win this chase." I ran a microbenchmark: $ ./python -m perf timeit -s 'to_bytes=int.to_bytes' 'to_bytes(1, 4, "little")' Reference: ~154 ns Replace int_to_bytes_impl() body with: PyBytes_FromStringAndSize("1", 1) => ~120 ns (-34 ns) Replace int_to_bytes() body with: return int_to_bytes_impl(self, 4, NULL, 1); => ~76 ns (-44 ns) _PyArg_ParseStackAndKeywords() with _PyArg_Parser{"nU|$p:to_bytes"} takes 44 ns on a total of 154 ns. 29% of the runtime is spent on parsing arguments. If you want to optimize further int.to_bytes(), IMHO we should explore the issue #29419: "Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)?". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:19:49 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 13:19:49 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <20170202131945.16804.18470.F7A3A2EC@psf.io> Roundup Robot added the comment: New changeset 32380d41e788 by Victor Stinner in branch '3.5': Issue #29300: test_struct tests unpack_from() with keywords https://hg.python.org/cpython/rev/32380d41e788 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:24:52 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 13:24:52 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <20170202132449.97083.58217.B9514014@psf.io> Roundup Robot added the comment: New changeset faa1e4f4b156 by Victor Stinner in branch 'default': Rename struct.unpack() 2nd parameter to "buffer" https://hg.python.org/cpython/rev/faa1e4f4b156 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:25:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 13:25:50 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486041950.27.0.593755677851.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "We already made such changes in the past. The difference is subtle and I have doubts that choosing any of ways was deliberate." Right. IMHO it's safe to make sure that the buffer is contiguous. I'm quite sure that the code doesn't support non-contiguous buffers. Serhiy Storchaka: "Please backport test changes and other changes discussed before to other branches." Done. Sorry, I forgot this part. Serhiy Storchaka: "unpack_buffer.patch LGTM." Thanks for the review, it's now merged. It was a regression in unpack() docstring, Python 3.5 docstring contains "unpack(fmt, buffer)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:34:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 13:34:51 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486042491.68.0.227427220935.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Panter: """FYI Victor, you can make non-C-contiguous buffers by slicing memoryview: >>> struct.unpack(">L", memoryview(b"1234")[::-1]) Traceback (most recent call last): File "", line 1, in BufferError: memoryview: underlying buffer is not C-contiguous""" Oh, it means that the Argument Clinic change doesn't add new checks on the buffer? In Python 3.6, memory_getbuf() raises an exception in the following code: if (!REQ_STRIDES(flags)) { if (!MV_C_CONTIGUOUS(baseflags)) { PyErr_SetString(PyExc_BufferError, "memoryview: underlying buffer is not C-contiguous"); return -1; } view->strides = NULL; } I undersrtand that memory_getbuf() is smart enough to raise an exception becaues the buffer is not contiguous. But a weaker implementation of getbuffer may not implement such check, whereas getbuffer() double check that the buffer is C-contiguous. Am I right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:36:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 13:36:03 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486042563.71.0.75054783382.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the overall cache_struct.patch change, but I have questions: see my review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:37:47 2017 From: report at bugs.python.org (Maximilian Blochberger) Date: Thu, 02 Feb 2017 13:37:47 +0000 Subject: [issue29394] Cannot tunnel TLS connection through TLS connection In-Reply-To: <1485847183.69.0.499542154053.issue29394@psf.upfronthosting.co.za> Message-ID: <1486042667.59.0.883968067297.issue29394@psf.upfronthosting.co.za> Maximilian Blochberger added the comment: Okay, I see, thanks for the hint. That worked perfectly ??I found `asyncio.sslproto._SSLPipe` very useful for that purpose. I personally consider the behaviour of `ssl.SSLContext.wrap_socket()` unexpected and would raise an exception if that method call is tried on an instance of `ssl.SSLSocket`. But as this would be a change that could lead to backwards compatibility issues (if developers depend on that behaviour) this is probably not a good idea. I think that the documentation for `ssl.SSLContext.wrap_socket()` has this behaviour to avoid future confusion ??including a hint to make use of `ssl.SSLContext.wrap_bio()` instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 08:50:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 13:50:39 +0000 Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument functions In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za> Message-ID: <1486043439.87.0.382370321852.issue23867@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the idea since I just proposed something similar in the issue #29419, but it seems like your change removes the function name from error messages which can become much more obscure. Maybe we should wrap all exceptions into a new TypeError which contains at least the function name, or even the parameter name/position. I mean chained exception to keep the original exception which contains more information. The best would be to have all information in a single error message, but it is likely to be much more complex to implement, especially if you want to support arbitrary converter function, not only simple formats like i". So I think that two chained exceptions is a reasonable compromise. What do you think? If we succeed to get the function name and the parameter name or position, the error messages will be MUCH MORE better than currently! And Argument Clinic allows us to implement this feature. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044026.17.0.783880941423.issue29300@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch 'master': Issue #29300: test_struct tests unpack_from() with keywords https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784 New changeset dcd4b1af2c59b0aae33cbac00d9f6fb47782ac57 by Victor Stinner in branch 'master': Rename struct.unpack() 2nd parameter to "buffer" https://github.com/python/cpython/commit/dcd4b1af2c59b0aae33cbac00d9f6fb47782ac57 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044026.3.0.460929740991.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044026.38.0.169379468944.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:26 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044026.45.0.599728316775.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:29 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044029.38.0.817699270638.issue29300@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch '3.5': Issue #29300: test_struct tests unpack_from() with keywords https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:29 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044029.56.0.271081505635.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:29 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044029.62.0.630091166483.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:29 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044029.69.0.233618008302.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:31 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044031.71.0.34493086118.issue29300@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a88eb4fa9e7fdf1a1050786223044c6bb7949784 by Victor Stinner in branch '3.6': Issue #29300: test_struct tests unpack_from() with keywords https://github.com/python/cpython/commit/a88eb4fa9e7fdf1a1050786223044c6bb7949784 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:31 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044031.81.0.570686287088.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:31 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044031.94.0.608507785217.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:00:31 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044031.87.0.319670180344.issue29300@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:04:32 2017 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Feb 2017 14:04:32 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044272.88.0.802722802101.issue29300@psf.upfronthosting.co.za> Stefan Krah added the comment: PyBUF_SIMPLE implies C-contiguous for a conforming buffer provider. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:07:57 2017 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Feb 2017 14:07:57 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1486044477.44.0.753389827358.issue29404@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree it's too late to change 2.7, and 3.x cannot (and should not) be changed at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:10:45 2017 From: report at bugs.python.org (Matthew Brett) Date: Thu, 02 Feb 2017 14:10:45 +0000 Subject: [issue29420] Python 3.6 change in dict iteration when inserting keys Message-ID: <1486044645.48.0.643305374135.issue29420@psf.upfronthosting.co.za> New submission from Matthew Brett: The behavior of dict iteration has changed in Python 3.6, in that inserting keys during iteration has a different and unpredictable affect. For this code: d = {'foo': 1} for key in d: print(key) d.pop(key) d[key] = 1 Python 3.5 prints a single 'foo' (one pass through the loop). Python 3.6 generates five lines of 'foo' (five passes through the loop). Of course this code is pathological, but I found this behavior from a bug in code where the pathology was a lot less obvious - see https://github.com/nipy/nipy/issues/420 ---------- messages: 286794 nosy: matthew.brett priority: normal severity: normal status: open title: Python 3.6 change in dict iteration when inserting keys type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:15:21 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 14:15:21 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486044921.82.0.388432675611.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Stefan Krah: "PyBUF_SIMPLE implies C-contiguous for a conforming buffer provider." Oh ok, thanks for the confirmation. So my change didn't add new checks and my commit message is wrong :-) Only non-conforming objects are impacted, but in such case, it's more a bug in the object than a bug in struct. I guess that non-conforming non-contiguous objects are very rare in the wild ;-) The new code is more strict, so is safe in all corner cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:31:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 14:31:54 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster Message-ID: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes int.to_bytes() and int.from_bytes() slightly faster. $ ./python -m perf timeit '1 .to_bytes(4, "little")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.28 us +- 0.07 us -> [python] 1.17 us +- 0.07 us: 1.09x faster (-8%) $ ./python -m perf timeit '1 .to_bytes(4, "big")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.30 us +- 0.07 us -> [python] 1.19 us +- 0.05 us: 1.10x faster (-9%) $ ./python -m perf timeit 'int.from_bytes(b"\1\0\0\0", "little")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.70 us +- 0.13 us -> [python] 1.41 us +- 0.06 us: 1.20x faster (-17%) $ ./python -m perf timeit 'int.from_bytes(b"\0\0\0\1", "big")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.71 us +- 0.15 us -> [python] 1.40 us +- 0.05 us: 1.22x faster (-18%) ---------- components: Interpreter Core files: int-to_bytes-from_bytes.patch keywords: patch messages: 286796 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make int.to_bytes() and int.from_bytes() slightly faster type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46491/int-to_bytes-from_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:38:17 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Feb 2017 14:38:17 +0000 Subject: [issue29420] Python 3.6 change in dict iteration when inserting keys In-Reply-To: <1486044645.48.0.643305374135.issue29420@psf.upfronthosting.co.za> Message-ID: <1486046297.94.0.174155033649.issue29420@psf.upfronthosting.co.za> R. David Murray added the comment: This "bug" has always existed, its just that its manifestation has changed. See issue 19332 for background. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Guard against changing dict during iteration _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:44:21 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 14:44:21 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486046661.77.0.194466481889.issue29421@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah yes, I began with the exact same change when I experimented optimizing to_bytes(): http://bugs.python.org/issue29300#msg286781 I was going to suggest you the same, but the speedup was low compared to the cost of parsing arguments. Anyway, int-to_bytes-from_bytes.patch is safe, LGTM, and the speedup is significant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:52:30 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 14:52:30 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486047150.29.0.528774430285.issue29300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Dear Roundup Robot, please don't close issues. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file46492/cache_struct-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:54:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 14:54:19 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486047259.16.0.498334858509.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "Dear Roundup Robot, please don't close issues." For what it's worth, I reported issues of this robot to python-dev: https://mail.python.org/pipermail/python-dev/2017-February/147317.html https://mail.python.org/pipermail/python-dev/2017-February/147325.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:55:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 14:55:20 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <20170202145517.96094.12535.D3BC4B30@psf.io> Roundup Robot added the comment: New changeset 52c51111a7c6 by Serhiy Storchaka in branch 'default': Issue #29421: Make int.to_bytes() and int.from_bytes() slightly faster https://hg.python.org/cpython/rev/52c51111a7c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:57:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 14:57:43 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486047463.08.0.954261589184.issue29421@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I tried this optimization few years ago. But with slow PyArg_ParseTupleAndKeywords() the effect was smaller and without _PyUnicode_EqualToASCIIId() the code was more cumbersome. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:58:05 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Feb 2017 14:58:05 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1486047485.09.0.4415405219.issue29414@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 10:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 15:00:25 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486047625.68.0.263714678891.issue29421@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset f0c1bbce09dc21d82965f1706b30b69e285ca4d3 by Serhiy Storchaka in branch 'master': Issue #29421: Make int.to_bytes() and int.from_bytes() slightly faster https://github.com/python/cpython/commit/f0c1bbce09dc21d82965f1706b30b69e285ca4d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 10:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 15:00:25 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486047625.76.0.811678787267.issue29421@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 10:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 15:00:25 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486047625.84.0.709479260049.issue29421@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 10:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 15:00:25 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> Message-ID: <1486047625.88.0.523543235638.issue29421@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 10:23:38 2017 From: report at bugs.python.org (Matthew Brett) Date: Thu, 02 Feb 2017 15:23:38 +0000 Subject: [issue29420] Python 3.6 change in dict iteration when inserting keys In-Reply-To: <1486044645.48.0.643305374135.issue29420@psf.upfronthosting.co.za> Message-ID: <1486049018.4.0.534414173186.issue29420@psf.upfronthosting.co.za> Matthew Brett added the comment: To clarify from comments on issue 19332: """ * The normal rule (not just for Python) is that a data structures have undefined behavior for mutating while iterating, unless there is a specific guarantee """ The change in Python 3.6 is just a different undefined behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:20:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 16:20:52 +0000 Subject: [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster In-Reply-To: <1486047625.85.0.488241799948.issue29421@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 3 empty notifications from Roundup Robot :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:30:53 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 02 Feb 2017 16:30:53 +0000 Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za> Message-ID: <1486053053.65.0.291793922943.issue29079@psf.upfronthosting.co.za> Steve Dower added the comment: At the point this code is running, it doesn't matter. The path doesn't exist, so trimming irrelevant segments from it will just cause a few extra iterations through resolve until we clear out enough of the absent segments to find something that does exist. abspath just prepends the current working directory unless the path is rooted, so we essentially have unbounded concatenation of "\.." in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:48:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 16:48:15 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486054095.11.0.103610339669.issue29263@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file46493/loadmethod-methoddescr-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:51:34 2017 From: report at bugs.python.org (Patrick Michaud) Date: Thu, 02 Feb 2017 16:51:34 +0000 Subject: [issue29422] add socket independent timeout to httplib/http.client read Message-ID: <1486054294.14.0.838994744532.issue29422@psf.upfronthosting.co.za> New submission from Patrick Michaud: Using python's httplib, there is no way to set a timeout for the full request cycle. A timeout can be given, which will apply to the connection attempt and each blocking socket operation. However, a malicious (or poorly performing) server can keep a connection open for an indefinite amount of time by slowly sending data. Consider this server process: https://gist.github.com/vegitron/bc883ddc88fe9253adc3e0bccea6445e and this client: https://gist.github.com/vegitron/4ee269b6492ff80d350e108363689d5c With a timeout of 0.5, the client takes 0.501363039017 seconds. With a timeout of 2.5, it takes 10.0041370392 seconds. This is explained in the documentation, but it's a problem. A commonly suggested solution is to use SIGALRM to set a timeout, but that doesn't work in a multi-threaded environment. Moving to multi-process introduces big slow downs as I can't use connection pools, and data needs to be serialized and deserialized for the parent process. I would like to propose an addition to httplib that would add a hook to httplib.HTTPResponse._read_chunked (python 2) and http.client.HTTPResponse._readall_chunked (python 3) that would either: 1) support an overall read timeout, by tracking a per-response start time and raising a timeout exception if that chunk read finishes after the given timeout 2) support a per-chunk callback function, so a client of httplib/http.client could define that logic for themselves. Current possible timeouts, and where they can happen: connect | read chunk | read chunk | read chunk [ timeout ] [ timeout ] [ timeout ] [ timeout ] Proposed addition: connect | read chunk | read chunk | read chunk [ timeout ] [ timeout ] [ timeout ] [ timeout ] [ total read time out ] ---------- messages: 286807 nosy: Patrick Michaud priority: normal severity: normal status: open title: add socket independent timeout to httplib/http.client read type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:55:43 2017 From: report at bugs.python.org (jan matejek) Date: Thu, 02 Feb 2017 16:55:43 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486054543.54.0.833399242206.issue29324@psf.upfronthosting.co.za> jan matejek added the comment: The "'0' * taglen" part is now considered part of plaintext. Which makes a lot of sense :) Removing the "empty taglen" fixes the encryption part of the tests for me. Similarly, for the decryption test, we must only read and check the message without the tag. ---------- nosy: +matejcik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:59:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 16:59:32 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486054771.99.0.0507464795893.issue29263@psf.upfronthosting.co.za> STINNER Victor added the comment: loadmethod-methoddescr-2.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 12:30:16 2017 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Feb 2017 17:30:16 +0000 Subject: [issue29404] "TypeError: 'int' does not have the buffer interface" on memoryview over bytearray In-Reply-To: <1485907211.51.0.510192590668.issue29404@psf.upfronthosting.co.za> Message-ID: <1486056616.01.0.458353755313.issue29404@psf.upfronthosting.co.za> Brett Cannon added the comment: As Serhiy and Stefan pointed out, it's too late to change Python 2.7 semantics. Closing as "not a bug". ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 12:37:08 2017 From: report at bugs.python.org (jan matejek) Date: Thu, 02 Feb 2017 17:37:08 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486057028.55.0.862497400683.issue29324@psf.upfronthosting.co.za> jan matejek added the comment: the attached patch fixes the test for me ---------- keywords: +patch Added file: http://bugs.python.org/file46494/test_socket_aead_kernel49.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 13:00:42 2017 From: report at bugs.python.org (Saida Dhanavath) Date: Thu, 02 Feb 2017 18:00:42 +0000 Subject: [issue29347] Python 2.7.8 is crashing while creating weakref for a given object. In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486058442.44.0.319401394614.issue29347@psf.upfronthosting.co.za> Changes by Saida Dhanavath : ---------- versions: +Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:10:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 19:10:40 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1486062640.97.0.623661232146.issue28749@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:18:04 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 19:18:04 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <20170202191759.16088.84134.329197D9@psf.io> Roundup Robot added the comment: New changeset 1bf1d36463b4 by Vinay Sajip in branch '3.5': Fixes #24875: pip can now be installed in a venv with --system-site-packages. https://hg.python.org/cpython/rev/1bf1d36463b4 New changeset 7d4701b4210f by Vinay Sajip in branch '3.6': Fixes #24875: Merged fix from 3.5. https://hg.python.org/cpython/rev/7d4701b4210f New changeset 7fd931727764 by Vinay Sajip in branch 'default': Closes #24875: Merged fix from 3.6. https://hg.python.org/cpython/rev/7fd931727764 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:27:51 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 19:27:51 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <20170202192747.7485.93895.E14FB53E@psf.io> Roundup Robot added the comment: New changeset 2b9e5cbdb0b1 by Vinay Sajip in branch '3.5': Fixes #29213: regularised EOLs of venv scripts. https://hg.python.org/cpython/rev/2b9e5cbdb0b1 New changeset 0f3ebeb389fe by Vinay Sajip in branch '3.6': Fixes #29213: merged fix from 3.5. https://hg.python.org/cpython/rev/0f3ebeb389fe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:32:12 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 19:32:12 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <20170202193209.26437.67151.E0FD17C9@psf.io> Roundup Robot added the comment: New changeset 14682d00b09a by Mark Dickinson in branch '2.7': Issue #14376: sys.exit now accepts longs as well as ints. Thanks Gareth Rees. https://hg.python.org/cpython/rev/14682d00b09a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:33:23 2017 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 02 Feb 2017 19:33:23 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486064003.54.0.727578600234.issue14376@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:33:50 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 19:33:50 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <20170202193348.7540.79505.21EFE742@psf.io> Roundup Robot added the comment: New changeset c23224ebc9e5 by Vinay Sajip in branch 'default': Closes #29213: Merged fix from 3.6. https://hg.python.org/cpython/rev/c23224ebc9e5 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:41:41 2017 From: report at bugs.python.org (Gareth Rees) Date: Thu, 02 Feb 2017 19:41:41 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486064501.7.0.13985121966.issue14376@psf.upfronthosting.co.za> Gareth Rees added the comment: Thank you, Mark (and everyone else who helped). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 14:51:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 19:51:01 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486065061.33.0.622118410288.issue20185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch for the gc module is synchronized with current sources and addresses Martin's comments. The only problem with this patch is that it exposes the default value for gc.collect() argument as constant 2 in Python instead of actual NUM_GENERATIONS-1. The latter value can't be exposed in Python. On other side it is 2 in the documentation, and it is not so easy to change the value of NUM_GENERATIONS. ---------- Added file: http://bugs.python.org/file46495/clinic_gc_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:38 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065758.51.0.699195966446.issue29213@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset ef0264af4d1a1844c2feb32714870d636e583b3a by Vinay Sajip in branch 'master': Closes #29213: Merged fix from 3.6. https://github.com/python/cpython/commit/ef0264af4d1a1844c2feb32714870d636e583b3a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:38 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065758.62.0.695217552732.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:38 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065758.7.0.800039736901.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:38 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065758.77.0.379706212073.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:38 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065758.87.0.76952561189.issue24875@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset fca720360f87f6dd2cd2030f7f98f689809c45d9 by Vinay Sajip in branch 'master': Fixes #24875: pip can now be installed in a venv with --system-site-packages. https://github.com/python/cpython/commit/fca720360f87f6dd2cd2030f7f98f689809c45d9 New changeset e3b461cf4327bc933b2421121daa5f938d929db3 by Vinay Sajip in branch 'master': Fixes #24875: Merged fix from 3.5. https://github.com/python/cpython/commit/e3b461cf4327bc933b2421121daa5f938d929db3 New changeset 2a2f5a741c509381ea8d0da09944aafdfc40b670 by Vinay Sajip in branch 'master': Closes #24875: Merged fix from 3.6. https://github.com/python/cpython/commit/2a2f5a741c509381ea8d0da09944aafdfc40b670 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065759.05.0.295991474479.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065759.13.0.32725331349.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065759.21.0.919450263062.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065759.67.0.110994719638.issue29213@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a7dc69b8956ad223ff6c239299896dd5195ce430 by Vinay Sajip in branch '3.5': Fixes #29213: regularised EOLs of venv scripts. https://github.com/python/cpython/commit/a7dc69b8956ad223ff6c239299896dd5195ce430 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065759.8.0.310626629031.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065759.88.0.0397853852285.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:39 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065759.96.0.827795168852.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065760.06.0.965851072228.issue24875@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset fca720360f87f6dd2cd2030f7f98f689809c45d9 by Vinay Sajip in branch '3.5': Fixes #24875: pip can now be installed in a venv with --system-site-packages. https://github.com/python/cpython/commit/fca720360f87f6dd2cd2030f7f98f689809c45d9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065760.21.0.344601542255.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065760.31.0.236685494038.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065760.4.0.861713168287.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065760.75.0.0795284069605.issue29213@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a7dc69b8956ad223ff6c239299896dd5195ce430 by Vinay Sajip in branch '3.6': Fixes #29213: regularised EOLs of venv scripts. https://github.com/python/cpython/commit/a7dc69b8956ad223ff6c239299896dd5195ce430 New changeset 1b105fac40b341980b290729a7ed403c73f5cf61 by Vinay Sajip in branch '3.6': Fixes #29213: merged fix from 3.5. https://github.com/python/cpython/commit/1b105fac40b341980b290729a7ed403c73f5cf61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065760.88.0.890822730139.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:40 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065760.95.0.257605687134.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486065761.03.0.473663716176.issue29213@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065761.14.0.509603157876.issue24875@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset fca720360f87f6dd2cd2030f7f98f689809c45d9 by Vinay Sajip in branch '3.6': Fixes #24875: pip can now be installed in a venv with --system-site-packages. https://github.com/python/cpython/commit/fca720360f87f6dd2cd2030f7f98f689809c45d9 New changeset e3b461cf4327bc933b2421121daa5f938d929db3 by Vinay Sajip in branch '3.6': Fixes #24875: Merged fix from 3.5. https://github.com/python/cpython/commit/e3b461cf4327bc933b2421121daa5f938d929db3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065761.28.0.105097820703.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065761.36.0.295799300034.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1486065761.43.0.79875414464.issue24875@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486065761.62.0.377578781444.issue14376@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 12b49507177368204085bd6e2b464f45e3b569e2 by Mark Dickinson in branch '2.7': Issue #14376: sys.exit now accepts longs as well as ints. Thanks Gareth Rees. https://github.com/python/cpython/commit/12b49507177368204085bd6e2b464f45e3b569e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486065761.72.0.217624925255.issue14376@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486065761.88.0.580223201347.issue14376@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 15:02:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 20:02:41 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1486065761.94.0.203889105497.issue14376@psf.upfronthosting.co.za> Changes by Roundup Robot : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:00:20 2017 From: report at bugs.python.org (spencera) Date: Thu, 02 Feb 2017 21:00:20 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 Message-ID: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> New submission from spencera: I'm unable to use concurrent.futures.ProcessPoolExecutor within a class in 3.6 the way I can in 3.5.x. I get the following in 3.6 (python3.6 test.py): Traceback (most recent call last): File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 241, in _feed obj = _ForkingPickler.dumps(obj) File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) TypeError: can't pickle _thread.RLock objects --------------------- No issues in 3.5.x: 0 1 2 3 4 5 6 7 8 9 0 ... ---------- components: Library (Lib) files: test.py messages: 286825 nosy: spencera priority: normal severity: normal status: open title: using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46496/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:13:57 2017 From: report at bugs.python.org (12345 67890) Date: Thu, 02 Feb 2017 21:13:57 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previousline In-Reply-To: <1485039375.56.0.473197770315.issue29339@psf.upfronthosting.co.za> Message-ID: <1486070037.9.0.377823224578.issue29339@psf.upfronthosting.co.za> 12345 67890 added the comment: The user is going to have to outdent anyway if we return them to the previous indentation level. Essentially it would be this: [ENTER] set_cursor_to_previous_indentation_level() if first_char_in_is_space: erase_first_char_in() reset_cursor_to_zero_indentation() type_first_char() else: pass So if we have this line: some_line [ENTER] some_line ^ [BACKSPACEX4] some_line ^ <---- cursor direction The other case is some_line [ENTER] some_line ^ [SPACEX4] some_line ^ ----> cursor direction Does that make sense? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:22:41 2017 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 02 Feb 2017 21:22:41 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1486070561.81.0.309569905905.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: test ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:33:01 2017 From: report at bugs.python.org (Meitar Moscovitz) Date: Thu, 02 Feb 2017 21:33:01 +0000 Subject: [issue29424] Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks Message-ID: <1486071181.22.0.61090318362.issue29424@psf.upfronthosting.co.za> New submission from Meitar Moscovitz: SUMMARY: In the Python standard library, the BaseHTTPRequestHandler class?s send_header() method[0] does not correctly construct HTTP/1.1 message headers as described by Section 4.2 of RFC 2616[1] when it is given maliciously-crafted input, leaving applications that rely on it vulnerable to HTTP response splitting[2] if they do not take extra precautions, themselves. A similar vulnerability affects the BaseHTTPRequestHandler class?s send_response_only() method, as well, although this is not likely to be as exploitable in the wild. This second vulnerability can result in HTTP response splitting due to incorrect construction of the Reason-Phrase portion of an HTTP Status-Line.[3] Since these APIs are designed to handle user-supplied input, it is reasonable to assume that developers will expect the standard library to consume arbitrary input safely. Unfortunately, the library fails to do that in these cases. According to a simple GitHub code search, slightly more than 100,000 repositories are directly using BaseHTTPRequestHandler,[4] so it is possible that a significant percentage of those applications are affected by this vulnerability. PYTHON VERSIONS AFFECTED: * Current development tip at time of writing: https://hg.python.org/cpython/file/tip/Lib/http/server.py#l511 * Current stable version 3.6 release (https://hg.python.org/cpython/file/3.6/Lib/http/server.py#l508) * Current stable version 2.7.13 release (https://hg.python.org/cpython/file/2.7/Lib/BaseHTTPServer.py#l412) DETAILS: According to the HTTP specification, an HTTP message header field content *MUST NOT* contain the sequence CRLF (carriage return, line feed). The RFC defines a message header as: message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = The RFC defines *TEXT to be the same as defined in RFC 822 section 3.3:[5] text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. However, the send_header() method does not perform any checking to ensure that a message header field-name nor field-content contains no CRLF sequences. The vulnerable Python 3.x code is in Lib/http/server.py on lines 507 and 508: self._headers_buffer.append( ("%s: %s\r\n" % (keyword, value)).encode('latin-1', 'strict')) An impacted application is one that passes user-provided input into the send_header() method, such as is common for setting HTTP Cookies. An example of an affected application may run Python code such as: def do_POST(self): # receive user-supplied data from a POST?ed HTTP request form_input = parse.unquote_plus( self.rfile.read(int(self.headers.get('content-length'))).decode('utf8') ).split('=') username = form_input[1] # extract a user-supplied value self.send_header('Set-Cookie', 'user={}'.format(username)) # use that value, assuming library will provide safety! self.end_headers() # ... send HTTP response body ... Assuming the code above, this HTTP POST request? POST https://victim.example/ HTTP/1.1 Host: victim.example Content-Type: application/x-www-form-urlencoded Content-Length: 10 user=alice ?would produce something like this (safe) HTTP response: HTTP/1.0 200 OK Server: BaseHTTP/0.6 Python/3.4.5 Date: Thu, 19 Jan 2017 22:58:44 GMT Set-Cookie: user=alice ...HTTP RESPONSE BODY... However, if an attacker supplies the following, maliciously-crafted HTTP POST payload? POST https://victim.example/ HTTP/1.1 Host: victim.example Content-Type: application/x-www-form-urlencoded Content-Length: 46 user=%0d%0aContent-Length: 6%0d%0a%0d%0aHACKED ?then the application would serve a page that simply read ?HACKED? as its output: HTTP/1.0 200 OK Server: BaseHTTP/0.6 Python/3.4.5 Date: Thu, 19 Jan 2017 22:58:44 GMT Set-Cookie: user= Content-Length: 6 HACKED The remainder of the application?s original, intended HTTP response would be ignored by the client. This allows the attacker to submit arbitrary data to clients, including hijacking complete pages and executing XSS attacks. SOLUTION: To fix this issue, ensure that CRLF sequences in the relevant user-supplied values are replaced with a single SPACE character, as the RFC instructs.[1] For example, Python code referencing value should become value.replace("\r\n", ' ') Similar replacements should be made to the other relevant arguments in the affected methods. Two patches are attached to this email, one for each associated affected version of Python. Apply each patch with: cd Python-$VERSION patch -p1 < python-$VERSION.patch where $VERSION is the version of Python to be patched. The patch for Python 3.6.0 applies cleanly to the current development tip, as well. EXTERNAL REFERENCES: [0] https://hg.python.org/cpython/file/3.6/Lib/http/server.py#l502 [1] https://tools.ietf.org/html/rfc2616#section-4.2 [2] https://www.owasp.org/index.php/HTTP_Response_Splitting [3] https://tools.ietf.org/html/rfc2616#section-6.1 [4] https://github.com/search?q=BaseHTTPRequestHandler+language%3Apython&type=Code [5] https://tools.ietf.org/html/rfc822#section-3.3 SEE ALSO: https://bugs.python.org/issue17319 P.S. This is my first time reporting a bug to the Python Software Foundation. I can prioritize improving this report with feedback from you if you need any clarifications or further details. ---------- components: Library (Lib) files: python-3.6.0.patch keywords: patch messages: 286828 nosy: meitar priority: normal severity: normal status: open title: Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46497/python-3.6.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:34:07 2017 From: report at bugs.python.org (Meitar Moscovitz) Date: Thu, 02 Feb 2017 21:34:07 +0000 Subject: [issue29424] Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks In-Reply-To: <1486071181.22.0.61090318362.issue29424@psf.upfronthosting.co.za> Message-ID: <1486071247.79.0.749543632534.issue29424@psf.upfronthosting.co.za> Meitar Moscovitz added the comment: A separate patch for Python 2.7+ that handles the issue described in the same way as the 3.4+ patch. ---------- Added file: http://bugs.python.org/file46498/python-2.7.13.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:39:39 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Feb 2017 21:39:39 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486071579.56.0.855829486801.issue29423@psf.upfronthosting.co.za> R. David Murray added the comment: The fact that RLock's *appeared* to be picklable was a bug in previous versions of python (see issue 22995). If you had code that worked before actually using the locks then perhaps there is a deeper error, though, so I'm nosying Serhiy to take a look at this (I don't use concurrent.futures so I'm not qualified to evaluate your example for validity). ---------- assignee: -> terry.reedy nosy: +r.david.murray, serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:51:57 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Feb 2017 21:51:57 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1486072317.4.0.329023223873.issue2771@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: fixed -> stage: resolved -> status: closed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:52:07 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Feb 2017 21:52:07 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1486072327.61.0.724892282903.issue2771@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:58:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Feb 2017 21:58:24 +0000 Subject: [issue29107] traceback module incorrectly formats args-less syntax errors In-Reply-To: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za> Message-ID: <1486072704.63.0.0969042288406.issue29107@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 17:23:19 2017 From: report at bugs.python.org (Christian H) Date: Thu, 02 Feb 2017 22:23:19 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1486074199.05.0.896091994281.issue22385@psf.upfronthosting.co.za> Changes by Christian H : ---------- nosy: +Christian H _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 17:31:34 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Feb 2017 22:31:34 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486074694.39.0.954872837052.issue29423@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, didn't mean to assign this to terry :( ---------- assignee: terry.reedy -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 17:43:14 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 22:43:14 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <20170202224311.96586.20559.52425B5D@psf.io> Roundup Robot added the comment: New changeset 135a9a0c09f9 by INADA Naoki in branch 'default': Issue #29263: LOAD_METHOD support for C methods https://hg.python.org/cpython/rev/135a9a0c09f9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 18:00:21 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Feb 2017 23:00:21 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486076421.75.0.556944189828.issue29263@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 48bde5d2cc5b9e98f55cd23ee57f3996d81caeb5 by INADA Naoki in branch 'master': Issue #29263: LOAD_METHOD support for C methods https://github.com/python/cpython/commit/48bde5d2cc5b9e98f55cd23ee57f3996d81caeb5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 18:13:20 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 02 Feb 2017 23:13:20 +0000 Subject: [issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions In-Reply-To: <1484323792.44.0.217164349535.issue29263@psf.upfronthosting.co.za> Message-ID: <1486077200.1.0.554655296811.issue29263@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- dependencies: -Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 18:40:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 23:40:18 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486078818.58.0.937388766078.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: cache_struct-2.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 19:04:13 2017 From: report at bugs.python.org (Walter Szeliga) Date: Fri, 03 Feb 2017 00:04:13 +0000 Subject: [issue29425] File-altering aspects of pathlib should return new pathlib objects Message-ID: <1486080253.05.0.537199940287.issue29425@psf.upfronthosting.co.za> New submission from Walter Szeliga: Methods on pathlib.PosixPath() and other objects that alter files on the file system should return new object instances with new information. For example, if there exists a file on the system called 'bar', then bar_var = pathlib.PosixPath('bar') bar_var.rename('foo') will rename the file 'bar' to 'foo' on the system and leave 'bar' as a still-valid object that no longer points to a system file. Changing the return type of .rename() to return a new pathlib.PosixPath() object with path 'foo' could help reduce confusion about the behavior. For example: bar_var = pathlib.PosixPath('bar') foo_var = bar_var.rename('foo') and foo_var would then be a pathlib.PosixPath() object pointing to 'foo'. ---------- components: Library (Lib) messages: 286835 nosy: Walter Szeliga priority: normal severity: normal status: open title: File-altering aspects of pathlib should return new pathlib objects type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 19:14:13 2017 From: report at bugs.python.org (Mark Tischler) Date: Fri, 03 Feb 2017 00:14:13 +0000 Subject: [issue29426] Using pywin32 on Python3 on linux Message-ID: <1486080853.04.0.234101899085.issue29426@psf.upfronthosting.co.za> New submission from Mark Tischler: I downloaded pywin32 build 220 from https://sourceforge.net/projects/pywin32/files/pywin32/, and tried to install it using 'python3 setup.py install' as well as 'python3 pywin32_postinstall.py -install' ("python3" = python 3.6.0), and the former gave me a syntax error about 'print' needing parentheses, and the latter gave me a syntax error about an 'except' statement having a syntax error, both of which tell me that this pywin32 package is not compatible with Python 3. So, I went searching and found https://pypi.python.org/pypi/pypiwin32. This is the same build number -- 220. Given that it is a full year newer than the other (it's odd that its build number is the same), I thought that this might have changes in it to support Python3. However, given that I'm installing on a Linux platform, I don't think I can deal with wheel files. These downloadable files appear to be for Windows installations only. I'm attempting to have an app, which is installed on a RedHat Linux machine, use SQL Server as its database, so my understanding is that I need the django-mssql package (I have version 1.8 ready to go) and that is dependent upon pywin32. So, I'm wondering if there is a version of pywin32 that is compatible with Python 3.6.0 and that is installable on Red Hat Linux. I am not using 'pip' to install packages, because my installation is not in the normal system area. I have a library of multiple Python installations, so that the various apps installed on that machine can be pointed to one of several different versions of Python. Note, I am somewhat new to Python and Python installations. Any help would be appreciated. ---------- components: Installation messages: 286836 nosy: mtischler priority: normal severity: normal status: open title: Using pywin32 on Python3 on linux type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 20:25:17 2017 From: report at bugs.python.org (Brian Thorne) Date: Fri, 03 Feb 2017 01:25:17 +0000 Subject: [issue29427] Option to skip padding for base64 urlsafe encoding/decoding Message-ID: <1486085117.43.0.563120448637.issue29427@psf.upfronthosting.co.za> New submission from Brian Thorne: Suggest changing base64 module to better handle encoding schemes that don't use padding. Because RFC4648 [1] allows other RFCs that implement RFC4648-compliant base64url encoding to explicitly stipulate that there is no padding. Dropping the padding is lossless when we know the length [2]. Various standard specifications require this - often crypto related (e.g., JWS [3] or named hashes [4]). RFC4648 specifically makes an exemption for this and it should be better supported in Python's standard library. There is a related closed issue [5] asking for the padding to be removed or altered which wouldn't comply with the spec. This request is different with a view to better support the wider specification. Proposed behaviour adapted from resolution that ruby discussion on same topic [6]: - base64.urlsafe_b64encode(s) should continue to produce padded output, but have an additional argument, padding, which defaults to True. - base64.urlsafe_b64decode(s) should accept both padded and unpadded inputs. It can still reject incorrectly-padded input. If that sounds sensible I'd like to put a patch/PR together. >From wikipedia [7]: > Some variants allow or require omitting the padding '=' signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries will encode '=' to '.'. - [1] https://tools.ietf.org/html/rfc4648#page-4 - [2] http://stackoverflow.com/questions/4080988/why-does-base64-encoding-requires-padding-if-the-input-length-is-not-divisible-b - [3] https://tools.ietf.org/html/rfc7515 - [4] https://tools.ietf.org/html/rfc6920#section-3 - [5] http://bugs.python.org/issue1661108 - [6] https://bugs.ruby-lang.org/issues/10740 - [7] https://en.wikipedia.org/wiki/Base64#Output_Padding ---------- components: Library (Lib) messages: 286837 nosy: Thorney, georg.brandl, lemburg, loewis priority: normal severity: normal status: open title: Option to skip padding for base64 urlsafe encoding/decoding type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 21:26:00 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Feb 2017 02:26:00 +0000 Subject: [issue29426] Using pywin32 on Python3 on linux In-Reply-To: <1486080853.04.0.234101899085.issue29426@psf.upfronthosting.co.za> Message-ID: <1486088760.77.0.122082224696.issue29426@psf.upfronthosting.co.za> Eryk Sun added the comment: I'm closing this as a third-party issue that's unrelated to the development of CPython. PyWin32 is a package of extension modules for accessing Windows C and COM APIs in Windows Python. You can't install it in Linux Python. You should be able to access SQL Server on Linux via django-pyodbc, using pyodbc and the FreeTDS driver. ---------- nosy: +eryksun resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 21:37:49 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Fri, 03 Feb 2017 02:37:49 +0000 Subject: [issue28972] Document all "python -m" utilities In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za> Message-ID: <1486089469.37.0.893811903782.issue28972@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi, I've just watched the old David Beazley video about the packaging system in python and got me thinking about this issue. I'm throwing the idea, please critize it! If we were to make a "hook" for the .rst files of the modules to go and scan the __main__.py file for the comments, generating the 'index' of all those options from the comments inside the file (__main__.py). That would be in my opinion a solution to make sure they are kept to date and would also insure someone knows minimally what he's doing as he's playing inside the main of a package. The idea is similar to the autodoc module of sphinx that scan a module for the doc, but would apply to the __main__.py only. However, I've just started with .rst files and I'm not sure how we could 'implement' that and even less if it's possible at all. (BTW, I would only enable the .rst "hook" option generation on the __main__.py file as to keep sort of a standardisation but not obligation) P.S. I know I initially seems skeptical, but I have started to see the use thanks to you :) The example was good (msg283470). Regards, Eric Lafontaine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 23:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Feb 2017 04:00:26 +0000 Subject: [issue29213] python -m venv activate.bat has weird mix of line endings In-Reply-To: <1483971138.02.0.292455070123.issue29213@psf.upfronthosting.co.za> Message-ID: <1486094426.12.0.564468011791.issue29213@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a7dc69b8956ad223ff6c239299896dd5195ce430 by Vinay Sajip in branch 'master': Fixes #29213: regularised EOLs of venv scripts. https://github.com/python/cpython/commit/a7dc69b8956ad223ff6c239299896dd5195ce430 New changeset 1b105fac40b341980b290729a7ed403c73f5cf61 by Vinay Sajip in branch 'master': Fixes #29213: merged fix from 3.5. https://github.com/python/cpython/commit/1b105fac40b341980b290729a7ed403c73f5cf61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 23:14:44 2017 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 03 Feb 2017 04:14:44 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486095284.0.0.734371929785.issue29423@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Looks like the problem here is that pickling self._consume implicitly pickles self, and after the first submission, self._futures contains Future objects. Those are probably what have the RLock in them (to synchronize between reading and populating threads), and it's correct not to pickle them; they're only meaningful in the parent process, and sending them to the workers would break, badly. Given you don't seem to be using self for anything, you could either make _consume a staticmethod (if you need state from self, pass that specific state in as arguments) so it's not implicitly pickling and transmitting self, or failing that, define custom pickling functions that explicitly exclude self._futures from the set of attributes to pickle. There is nothing to fix behaviorally on Python's side that wouldn't lead to confusion/breakage in other code. It would be nice if Python could give more detail on pickle chain that led to the unpicklable object (so you know it's self._consume->self->self._futures->some future object->future._rlock or whatever), but I'm not sure the pickling protocol design can preserve that sort of chain for error reporting... ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 00:24:29 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 03 Feb 2017 05:24:29 +0000 Subject: [issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods In-Reply-To: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za> Message-ID: <1486099469.34.0.528581711712.issue18842@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Martin, I reviewed the patch (rm-finite.patch) and ran the tests. The patch no longer applies cleanly to the default branch, but otherwise looks good. Assigning this back to you as per Raymond's suggestion. Thanks :) ---------- assignee: Mariatta -> martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 01:25:12 2017 From: report at bugs.python.org (spencera) Date: Fri, 03 Feb 2017 06:25:12 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486103112.92.0.012536534036.issue29423@psf.upfronthosting.co.za> spencera added the comment: Interesting. So, out of curiosity, what has changed from 3.5.2 to 3.6.0 that causes this new behavior? Was an instance associated with an instance method that was passed to submit not implicitly pickled before 3.6.0? Is it from the changes to the pickle module in 3.6? Something else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 01:25:12 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 03 Feb 2017 06:25:12 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures Message-ID: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: I just had a problem with doctests. It manifested as an error that occurred when I did >>> import StringIO in my doctest. After some investigation, I realised that my actual problem was that the doctest library documentation https://docs.python.org/3/library/doctest.html left me unclear about three aspects of multi-line doctest fixtures. 1. There is no example of a multiple-line doctest fixture: specifically, a fixture which involves at least one line to set up state, and another line to be the example that tested. I suggest adding such an example as a new section, "26.3.2. Usage: multi-line tests". Note that the example in 26.3.3.2 doesn't count: that is a Compound Statement, and I'm talking about a test consisting of multiple interactive statements. 2. Section "26.3.3.2. How are Docstring Examples Recognized?" does not talk about when to use a PS1 prefix (>>>) and when to use a PS2 prefix (...). It should say to use the PS1 at the start of each Python "interactive statement", that is, a statement list ending with a newline, or a Compound Statement. And, to use the PS2 to prefix each continuing line within a Compound Statement. 3. Section "26.3.3.3. What?s the Execution Context?" is not clear about the crucial difference between state that accumulates within a single docstring from Example to Example, and that is reset from one docstring to another. The phrase "so that one test in M can?t leave behind crumbs that accidentally allow another test to work" can be interpreted as applying within a single docstring. The phrase "names defined earlier in the docstring being run" is easy to miss. A StackOverflow Question and Answer describing my problem and my insight about what the library documentation didn't tell me is at http://stackoverflow.com/questions/41070547/why-is-importing-a-module-breaking-my-doctest-python-2-7 . A blog post of mine, a source for documentation improvements, is at http://blog.jdlh.com/en/2017/01/31/multi-line-doctests/ . I actually encountered this problem in a Python 2.7 context, with https://docs.python.org/2/library/doctest.html . But it also applies to Python 3.6 https://docs.python.org/3/library/doctest.html and to the current dev https://docs.python.org/dev/library/doctest.html . In the spirit of fixing the new stuff first, I am filing this issue against Python 3.7. Unless someone tells me otherwise, I'll get around to filing similar issues against Python 3.6 and Python 2.7. Then it's my intention to write improvements to the documentation for Python 3.7, 3.6, and 2.7, and submit each of those. It looks like they will be pretty similar, because the library documentation is pretty similar in each version. I'm new to Python issue filing and doc fixing, so I would appreciate correction if (when?) I start to blunder. ---------- assignee: docs at python components: Documentation messages: 286843 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Doctest documentation unclear about multi-line fixtures type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 01:45:08 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 06:45:08 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1486104308.65.0.141824650731.issue29412@psf.upfronthosting.co.za> Xiang Zhang added the comment: This seems not related to #27931. The problem is that the receiver's content is only CFWS. It's just like it's empty and for the default policy, it checks `value[0] == '"'` in `get_word`. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 01:55:56 2017 From: report at bugs.python.org (Christian H) Date: Fri, 03 Feb 2017 06:55:56 +0000 Subject: [issue27744] Add AF_ALG (Linux Kernel crypto) to socket module In-Reply-To: <1470997290.77.0.995104201782.issue27744@psf.upfronthosting.co.za> Message-ID: <1486104956.04.0.854069966965.issue27744@psf.upfronthosting.co.za> Changes by Christian H : ---------- nosy: +Christian H _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 03:05:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Feb 2017 08:05:47 +0000 Subject: [issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods In-Reply-To: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za> Message-ID: <1486109147.02.0.66798994531.issue18842@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 03:57:22 2017 From: report at bugs.python.org (reason) Date: Fri, 03 Feb 2017 08:57:22 +0000 Subject: [issue29429] Requests package is incompatible with py2exe Message-ID: <1486112242.43.0.799450044508.issue29429@psf.upfronthosting.co.za> New submission from reason: I use py2exe to compile some py files importing 'Requests' package into executable files user Windows.But I get unexpected exception , 'missing modules'. Even I tried to specify the '-p requests',I still got failure. ---------- messages: 286846 nosy: reason priority: normal severity: normal status: open title: Requests package is incompatible with py2exe type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 03:57:52 2017 From: report at bugs.python.org (reason) Date: Fri, 03 Feb 2017 08:57:52 +0000 Subject: [issue29429] Requests package is incompatible with py2exe In-Reply-To: <1486112242.43.0.799450044508.issue29429@psf.upfronthosting.co.za> Message-ID: <1486112272.01.0.0532336258124.issue29429@psf.upfronthosting.co.za> Changes by reason : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:13:14 2017 From: report at bugs.python.org (Lucas Moeskops) Date: Fri, 03 Feb 2017 09:13:14 +0000 Subject: [issue29430] zipfile: invalid link Message-ID: <1486113194.67.0.258347417914.issue29430@psf.upfronthosting.co.za> New submission from Lucas Moeskops: The ZipFile documentation shows a link to the PKZip Application Node. This link, with address "https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT" goes to a "Page Not Found" document. ---------- messages: 286847 nosy: lucasmus priority: normal severity: normal status: open title: zipfile: invalid link versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:29:15 2017 From: report at bugs.python.org (Marco Buttu) Date: Fri, 03 Feb 2017 09:29:15 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486114155.31.0.761428422055.issue29428@psf.upfronthosting.co.za> Marco Buttu added the comment: > I just had a problem with doctests. It manifested as an > error that occurred when I did > >>> import StringIO in my doctest. Maybe you are running the doctest with Python 3. The StringIO module is no more available in Python 3, so your doctest will fail on Python 3 and will pass on Python 2. > 1. There is no example of a multiple-line doctest fixture: > specifically, a fixture which involves at least one line to > set up state, and another line to be the example that tested. > I suggest adding such an example as a new section, "26.3.2. > Usage: multi-line tests". > Note that the example in 26.3.3.2 doesn't count: that is a > Compound Statement, and I'm talking about a test consisting > of multiple interactive statements. The example in section 26.3.3.2 [1], before the compound statement (the if/else), contains two simple statements. I also think the example is complete and straightforward for its purpose, and it does not have to be complicated adding avanced features. If you want a more complex control over your tests, for instance adding fixtures, you can find how to do it later, in [2]. > 2. Section "26.3.3.2. How are Docstring Examples Recognized?" does > not talk about when to use a PS1 prefix (>>>) and when to use a > PS2 prefix (...). It should say to use the PS1 at the start of each > Python "interactive statement", that is, a statement list ending with > a newline, or a Compound Statement. And, to use the PS2 to prefix each > continuing line within a Compound Statement. I am -1 on this. IMHO there is no need to add extra description to a such self-explaining, clear and concise example. But this I think is also clear from the beginning. Infact, the first line of the doc says: "The doctest module searches for pieces of text that look like interactive Python sessions" > 3. Section "26.3.3.3. What?s the Execution Context?" is not > clear about the crucial difference between state that accumulates > within a single docstring from Example to Example, and that is reset > from one docstring to another. The phrase "so that one test in M can?t > leave behind crumbs that accidentally allow another test to work" > can be interpreted as applying within a single docstring. The phrase > "names defined earlier in the docstring being run" is easy to miss. Also this section IMO is well written and clear. I do not know what to say... If someone else thinks it is not enough understandable, maybe the better think to do is to add a very small example, with two functions, that shows their docstrings have independent globals. > Unless someone tells me otherwise, I'll get around to filing similar > issues against Python 3.6 and Python 2.7. > Then it's my intention to write improvements to the documentation > for Python 3.7, 3.6, and 2.7, and submit each of those. Keep in mind that writing a patch is not enough. The patch has to be reviewed, and that means other people have to find the time to work on it. I suggest you to watch this talk of Raymond Hettinger, before going on: https://www.youtube.com/watch?v=voXVTjwnn-U [1] https://docs.python.org/3/library/doctest.html#how-are-docstring-examples-recognized [2] https://docs.python.org/3/library/doctest.html#unittest-api ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:37:45 2017 From: report at bugs.python.org (lamby) Date: Fri, 03 Feb 2017 09:37:45 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable Message-ID: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> New submission from lamby: Due to implementation changes, since CPython 3.6 dict keys are returned in insertion order. However, in order to test for reproducible builds [0], it would be convenient to be able to reverse this ordering; we would then run a build of an arbitrary package both with and without this flag and compare the resulting binary. (We already run such a testing framework, so specifying this environment variable would be trivial. Note that this "reverse" would actually find more issues than simply relying on the pre-3.6 non-deterministic behaviour.) This patch changes the behaviour of: * for x in d: * d.popitem() * d.items() * _PyDict_Next [0] https://reproducible-builds.org/ ---------- components: Interpreter Core files: 0001-Add-a-PYTHONREVERSEDICTKEYORDER-environment-variable.patch keywords: patch messages: 286849 nosy: lamby priority: normal severity: normal status: open title: Add a PYTHONREVERSEDICTKEYORDER environment variable type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46499/0001-Add-a-PYTHONREVERSEDICTKEYORDER-environment-variable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:40:41 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 09:40:41 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486114841.31.0.226032439019.issue29431@psf.upfronthosting.co.za> INADA Naoki added the comment: Why don't you use OrderdDict and reversed()? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:48:39 2017 From: report at bugs.python.org (lamby) Date: Fri, 03 Feb 2017 09:48:39 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486115319.29.0.283858885523.issue29431@psf.upfronthosting.co.za> lamby added the comment: > Why don't you use OrderdDict and reversed()? This isn't for my own code; I want to change the behaviour of CPython itself so it affects arbitrary third-party code - this is what we are testing when we are testing for reproducibility :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:58:46 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 09:58:46 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486115926.02.0.489495209354.issue29431@psf.upfronthosting.co.za> INADA Naoki added the comment: I can't understand what is the problem. If the package produce same binary when dict keeps insertion order, isn't it a "reproducible build"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 05:02:18 2017 From: report at bugs.python.org (lamby) Date: Fri, 03 Feb 2017 10:02:18 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486116138.5.0.834294498342.issue29431@psf.upfronthosting.co.za> lamby added the comment: > If the package produce same binary when dict keeps insertion order, > isn't it a "reproducible build"? No, as that's a CPython-specific (and 3.6+) implementation detail. Hence "forcing" a test for it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 05:11:51 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 10:11:51 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486116711.2.0.433491410887.issue29387@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. -t is not removed but only ignored in Py3 for backwards compatibility. And I am fine with the wording. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 05:20:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 10:20:15 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486117215.32.0.0753039102088.issue29431@psf.upfronthosting.co.za> INADA Naoki added the comment: For checking compatibility with other implementation, I want to wait until other implementation compatible with 3.6+ which doesn't keep insertion order of dict. For now, there are no 3.6+ compatible Python implementation except CPython. For checking compatibility with Python 3.5-, I -1 to add such flag. Python 3.6 has many new features. You should use 3.5 instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 05:22:52 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 10:22:52 +0000 Subject: [issue29429] Requests package is incompatible with py2exe In-Reply-To: <1486112242.43.0.799450044508.issue29429@psf.upfronthosting.co.za> Message-ID: <1486117372.68.0.24996737758.issue29429@psf.upfronthosting.co.za> INADA Naoki added the comment: Here is issue tracker of Python. py2exe and requests are third party project. Please report an issue to py2exe issue tracker. ---------- nosy: +inada.naoki resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:12:32 2017 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 03 Feb 2017 11:12:32 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1486120352.51.0.175622136994.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: @Terry, The attached files contain the master branch of the pip_gui. It contains all the work done by me till now in pip_gui. If this projects need to be continued as open source project, is it expected to be continued as independent project, or CPython project or pip project. I am confused about it. However, I think that the project should be continued with pip, which will also help speed up the process of standardization of output of pip for different commands. I believe still there are a lot of pip commands not having 'json' output. ---------- Added file: http://bugs.python.org/file46500/pip_gui-master.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:25:24 2017 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 03 Feb 2017 11:25:24 +0000 Subject: [issue29432] wait_for(gather(...)) logs weird error message Message-ID: <1486121124.44.0.178086142975.issue29432@psf.upfronthosting.co.za> New submission from Martin Teichmann: when waiting for a gather that times out, everything works as expected, yet a weird error message is logged. To give a minimal example: import asyncio @asyncio.coroutine def main(): try: sleep = asyncio.sleep(0.2) yield from asyncio.wait_for(asyncio.gather(sleep), timeout=0.1) except asyncio.TimeoutError: print("timed out: fine") yield from asyncio.sleep(0.1) asyncio.get_event_loop().run_until_complete(main()) This outputs: timed out: fine _GatheringFuture exception was never retrieved future: <_GatheringFuture finished exception=CancelledError()> concurrent.futures._base.CancelledError As you can see, I used the pre-3.5 syntax so I could test whether it works on older systems. No, it doesn't. I wrote a unit test for this problem, unfortunately I couldn't solve it yet. ---------- components: asyncio messages: 286858 nosy: Martin.Teichmann, gvanrossum, yselivanov priority: normal pull_requests: 24 severity: normal status: open title: wait_for(gather(...)) logs weird error message versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:26:06 2017 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 03 Feb 2017 11:26:06 +0000 Subject: [issue29432] wait_for(gather(...)) logs weird error message In-Reply-To: <1486121124.44.0.178086142975.issue29432@psf.upfronthosting.co.za> Message-ID: <1486121166.8.0.209804150535.issue29432@psf.upfronthosting.co.za> Changes by Martin Teichmann : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:43:19 2017 From: report at bugs.python.org (sedrubal) Date: Fri, 03 Feb 2017 11:43:19 +0000 Subject: [issue29433] any, all and sum should accept variadic args Message-ID: <1486122199.09.0.757475243638.issue29433@psf.upfronthosting.co.za> New submission from sedrubal: any, all and sum (and maybe some other functions) should accept variadic args. It should be possible to do things like this: >>> any(True, False, True) True >>> all(True, False, True) False >>> sum(1, 2, 3) 6 This was compliant to max and min behaviour: >>> max(1, 2, 3) 3 >>> min(1, 2, 3) 1 ---------- messages: 286859 nosy: sedrubal priority: normal severity: normal status: open title: any, all and sum should accept variadic args type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 07:04:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Feb 2017 12:04:51 +0000 Subject: [issue29433] any, all and sum should accept variadic args In-Reply-To: <1486122199.09.0.757475243638.issue29433@psf.upfronthosting.co.za> Message-ID: <1486123491.16.0.686137169103.issue29433@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no such need. You can use operators. any(arg1, arg2, arg3) -> arg1 or arg2 or arg3 all(arg1, arg2, arg3) -> arg1 and arg2 and arg3 sum(arg1, arg2, arg3) -> arg1 + arg2 + arg3 ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 07:16:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 12:16:12 +0000 Subject: [issue29434] tuple.__repr__ may segv when it contains NULL Message-ID: <1486124172.44.0.836163463521.issue29434@psf.upfronthosting.co.za> New submission from INADA Naoki: sys.getobjects() contains tuples including NULLs. Even without pydebug, tuple under construction can be exposed accidentally. Allowing repr() for such tuples ease investigating what is the tuple. ---------- components: Interpreter Core files: tuple-repr-NULL.patch keywords: patch messages: 286861 nosy: inada.naoki priority: normal severity: normal status: open title: tuple.__repr__ may segv when it contains NULL versions: Python 3.7 Added file: http://bugs.python.org/file46501/tuple-repr-NULL.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 07:23:57 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 12:23:57 +0000 Subject: [issue29434] tuple.__repr__ may segv when it contains NULL In-Reply-To: <1486124172.44.0.836163463521.issue29434@psf.upfronthosting.co.za> Message-ID: <1486124637.4.0.388722931587.issue29434@psf.upfronthosting.co.za> INADA Naoki added the comment: The patch missed `continue;`. And I couldn't reproduce the problem for now. I'll reopen when I can reproduce the problem. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 08:09:51 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 13:09:51 +0000 Subject: [issue29378] Invalid example in documentation for PyErr_Fetch In-Reply-To: <1485447904.37.0.693014852804.issue29378@psf.upfronthosting.co.za> Message-ID: <1486127391.6.0.787060158724.issue29378@psf.upfronthosting.co.za> Xiang Zhang added the comment: I can't see any problem with the example either. So I just close this issue for now. But if you still think it gets problems please reopen it and tell your thoughts. ---------- nosy: +xiang.zhang resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 08:38:54 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Feb 2017 13:38:54 +0000 Subject: [issue29433] any, all and sum should accept variadic args In-Reply-To: <1486122199.09.0.757475243638.issue29433@psf.upfronthosting.co.za> Message-ID: <1486129134.8.0.10373232361.issue29433@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Serhiy, that doesn't generalise to code like: any(a, b, c, *extras) which is hard to write out by hand. You would have to say bool(a or b or c or any(extras)) I think this might be worth considering on Python-Ideas. It will probably be rejected, but if Sedrubal cares enough to raise the idea, it could be discussed. However, sum should be taken off the list. The problem with accepting variadic args is that it clashes with current behaviour: sum( [[1], [2], [3]], [4, 5] ) That would be ambiguous. Under the suggested variadic form, that should return a list: [[1], [2], [3], 4, 5] but it already has a meaning in Python today: [4, 5, 1, 2, 3] So sum() with variadic args would be ambiguous, or would break backwards compatibility. Neither of those would be acceptable. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 08:41:40 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 13:41:40 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486129299.99.0.163268933104.issue29423@psf.upfronthosting.co.za> R. David Murray added the comment: See the issue I linked to. RLocks were incorrectly pickled before but the resulting unpickled object was broken. If the unpickled RLock never got used such code would not break, but the objects were inherently broken and this could lead to hard to debug problem when the objects were used. Thus we fixed it in 3.6 only so as to not break working code in a maintenance release. But in 3.6 and later, RLocks (among other things that were also broken) are no longer pickleable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 08:46:25 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 13:46:25 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486129585.67.0.197706431743.issue29423@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I take it back, it looks like the change was backported. I think that's bad, but I wasn't involved in the decision :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 08:49:25 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 13:49:25 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1486129765.89.0.0680122554288.issue29412@psf.upfronthosting.co.za> R. David Murray added the comment: I'm really short on time to even review patches these days, but I'll see if I can pry any loose if someone wants to propose a patch. ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:09:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Feb 2017 14:09:32 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486129585.67.0.197706431743.issue29423@psf.upfronthosting.co.za> Message-ID: <5367962.kkSYkb3vJg@raxxla> Serhiy Storchaka added the comment: It was backported but later reverted (54dd5c105334). I concur with Josh. Thank you for good analysis Josh. As for your idea about more detailed error reporting, I think it can be implemented. Separate exception can be raised for every object in the chain, with chaining one exception to other. This is separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:37:33 2017 From: report at bugs.python.org (Thom Wiggers) Date: Fri, 03 Feb 2017 14:37:33 +0000 Subject: [issue29435] Allow to pass fileobj to is_tarfile Message-ID: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za> New submission from Thom Wiggers: The tarfile.is_tarfile() function only supports opening from paths. However, the `Tarfile` class also supports opening from `fileobj`s. It would be useful if the is_tarfile function would also accept those. For reference, this is the current implementation: https://github.com/python/cpython/blob/fcc3915a266b6cd220483c7020de0d71e293b2cb/Lib/tarfile.py#L2432 ---------- components: Library (Lib) messages: 286869 nosy: twiggers priority: normal severity: normal status: open title: Allow to pass fileobj to is_tarfile type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:42:56 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 14:42:56 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486132976.88.0.95919708864.issue29428@psf.upfronthosting.co.za> R. David Murray added the comment: It does appear that "test" is being used ambiguously in the docs. In most places it means a single statement, but in execution context it appears to be being used as a synonym for "docstring". In that section it should be replaced by "docstring". It would probably be worth checking the rest of the doc to make sure it is used consistently elsewhere as well. As for the prompts, I agree with Marco: I don't think there is any need to add words, since it clearly says it is supposed to look like an interactive session and the reader gets reminded of the rules for that by the example provided. IMO it is not appropriate to re-document those rules here. However, if you come up with a really concise addition that clarifies it, we'll consider it. I don't think an additional example of using previous state is required, and certainly not an additional section. The execution context section makes it clear that you can use names defined earlier, as does the fact that doctests emulate interactive sessions. Both of these make it clear you can do multi line examples that use shared state. However, if you come up with an example that adds value to the documentation, we'll certainly consider it. So in summary, I think we *need* a one word change in the execution context section, and we'll consider any other enhancements you want to propose. ---------- nosy: +r.david.murray versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:44:17 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 14:44:17 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486133057.87.0.782169346745.issue29428@psf.upfronthosting.co.za> R. David Murray added the comment: And thanks for wanting to improve the docs! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:50:36 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 14:50:36 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486133436.7.0.333775019294.issue29431@psf.upfronthosting.co.za> R. David Murray added the comment: Inada: we haven't 100% decided that this is going to become a language feature. However it is likely to become so, so adding such a flag is probably wasted effort. Further, if the goal is to test compatibility with other python implementations, shouldn't you actually be testing against those other implementations? You are likely to catch more problems than just dict order that way. So I vote -1 on this. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:58:01 2017 From: report at bugs.python.org (Anthony Scopatz) Date: Fri, 03 Feb 2017 14:58:01 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1486133881.37.0.946739994487.issue15451@psf.upfronthosting.co.za> Changes by Anthony Scopatz : ---------- nosy: +Anthony Scopatz versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:58:27 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 14:58:27 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1486133907.44.0.598805782709.issue29376@psf.upfronthosting.co.za> Xiang Zhang added the comment: This seems an regression from #18808, so nosy Tim and Antoine. Since _DummyThread is always alive and daemonic, I think the solution could be overriding is_alive in _DummyThread and always returning True. ---------- keywords: +patch nosy: +xiang.zhang stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4 Added file: http://bugs.python.org/file46502/issue29376.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:58:46 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 14:58:46 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1486133926.02.0.492198180056.issue29376@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +pitrou, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 10:14:25 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 15:14:25 +0000 Subject: [issue29347] Python 2.7.8 is crashing while creating weakref for a given object. In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486134865.74.0.639635691756.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 10:56:48 2017 From: report at bugs.python.org (sedrubal) Date: Fri, 03 Feb 2017 15:56:48 +0000 Subject: [issue29433] any, all and sum should accept variadic args In-Reply-To: <1486122199.09.0.757475243638.issue29433@psf.upfronthosting.co.za> Message-ID: <1486137408.76.0.555855242931.issue29433@psf.upfronthosting.co.za> sedrubal added the comment: Thanks for your answers and for showing the issue with sum. I think this would make python just a bit more sexier as it already is ;) Are there any other disadvantages (performance, ...)? Do you think I should send a mail to the ideas list? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 10:59:13 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 15:59:13 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486137553.18.0.759542598859.issue29423@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Josh> There is nothing to fix behaviorally on Python's side ... Serhiy> I concur with Josh.... This implies to me that we should close this as 'not a bug', with possibly a new issue for better error reporting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 11:04:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Feb 2017 16:04:24 +0000 Subject: [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 In-Reply-To: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> Message-ID: <1486137864.71.0.839625558982.issue29423@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 11:10:32 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 03 Feb 2017 16:10:32 +0000 Subject: [issue29433] any, all and sum should accept variadic args In-Reply-To: <1486137408.76.0.555855242931.issue29433@psf.upfronthosting.co.za> Message-ID: <20170203161025.GO7345@ando.pearwood.info> Steven D'Aprano added the comment: > Do you think I should send a mail to the ideas list? Personally, I don't think so. You want to write any(a, b, c, d), but you can get the same effect now by writing any([a, b, c, d]). There is unlikely to be any significant performance difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 11:56:31 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 03 Feb 2017 16:56:31 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 Message-ID: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Since Android NDK r14 beta 2, unified headers provide langinfo.h but there's no nl_langinfo() in it, causing linking failures: libpython3.7m.a(pylifecycle.o): In function `get_locale_encoding': /home/yen/Projects/python3-android/src/cpython/Python/pylifecycle.c:234: undefined reference to `nl_langinfo' libpython3.7m.a(fileutils.o): In function `_Py_device_encoding': /home/yen/Projects/python3-android/src/cpython/Python/fileutils.c:65: undefined reference to `nl_langinfo' libpython3.7m.a(_localemodule.o): In function `PyLocale_nl_langinfo': /home/yen/Projects/python3-android/src/cpython/./Modules/_localemodule.c:447: undefined reference to `nl_langinfo' Or compiler errors due to implicit function declarations if the patch at issue22747 is applied. nl_langinfo.patch fixes it by adding some extra guarding macros. Added some people from issue22747 to the nosy list, where the last change about langinfo.h and Android occurred. ---------- components: Build files: nl_langinfo.patch keywords: patch messages: 286877 nosy: Chi Hsuan Yen, haypo, skrah, xdegaye priority: normal severity: normal status: open title: Compilation failure against Android NDK r14 beta 2 type: compile error versions: Python 3.7 Added file: http://bugs.python.org/file46503/nl_langinfo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 12:00:56 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 03 Feb 2017 17:00:56 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1486141256.08.0.00132547085803.issue29436@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Here's a copy of $ANDROID_NDK/sysroot/usr/include/langinfo.h. (/sysroot/ stores unified headers [1]) To use those headers correctly, packagers have to add -D__ANDROID_API__=XY to CPPFLAGS. On the other hand, __ANDROID_API_FUTURE__ is defined in $ANDROID_NDK/sysroot/usr/include/android/api-level.h: /* * Magic version number for a current development build, which has * not yet turned into an official release. */ #ifndef __ANDROID_API_FUTURE__ #define __ANDROID_API_FUTURE__ 10000 #endif As a result nl_langinfo() does not exist in all real API versions. [1] https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md ---------- Added file: http://bugs.python.org/file46504/langinfo.h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 12:01:32 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 Feb 2017 17:01:32 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486141292.79.0.473898292711.issue29431@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with David and Inada on this one (it is likely to become a wasted effort and it impacts maintainability to try to support this even for the short run). ---------- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 12:05:06 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Feb 2017 17:05:06 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486141506.06.0.486638734134.issue29405@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 12:48:05 2017 From: report at bugs.python.org (Mike) Date: Fri, 03 Feb 2017 17:48:05 +0000 Subject: [issue29437] installation not listed for all users Message-ID: <1486144085.37.0.437097595793.issue29437@psf.upfronthosting.co.za> New submission from Mike: When installing Python 3.6 using the official installer and selecting "install for all users" from an account with admin privileges, the installation completes successfully and it shows in the list of installed programs for that user. However, because it's installation key is written into HKEY_CURRENT_USER, it is listed as installed program only for the user that ran the installation. While Python still seems to run from another account, it is not listed as an installed program for the other user. In the "install for all users" case, it should be registered in HKEY_LOCAL_MACHINE, instead of HKEY_CURRENT_USER. ---------- components: Installation, Windows messages: 286880 nosy: mray, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: installation not listed for all users versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:00:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Feb 2017 18:00:33 +0000 Subject: [issue29434] tuple.__repr__ may segv when it contains NULL In-Reply-To: <1486124172.44.0.836163463521.issue29434@psf.upfronthosting.co.za> Message-ID: <1486144833.38.0.44919159338.issue29434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks similar to issue26811. I think that if the reproducer is found it would be better to fix the case of leaking a tuple containing NULL rather than making repr() be aware of NULLs. repr() is not the only way to crash with such tuples. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:25:44 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Feb 2017 18:25:44 +0000 Subject: [issue29437] installation not listed for all users In-Reply-To: <1486144085.37.0.437097595793.issue29437@psf.upfronthosting.co.za> Message-ID: <1486146344.18.0.355213135739.issue29437@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks, this is the same as issue25166. In short, we need a significant update to the WiX framework before this can be enabled, and so far the core WiX developers are not interested in doing it. I've been working on a patch, but it's actually fairly complicated to get right and I haven't managed it yet. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Windows AllUsers installation places uninstaller in user profile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:43:20 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:43:20 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1486147400.69.0.712029851514.issue28833@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:43:59 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:43:59 +0000 Subject: [issue29180] skip tests that raise PermissionError in test_os (non-root user on Android) In-Reply-To: <1483715692.75.0.979129057464.issue29180@psf.upfronthosting.co.za> Message-ID: <1486147439.99.0.0173586963861.issue29180@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:44:25 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:44:25 +0000 Subject: [issue29181] skip tests that raise PermissionError in test_tarfile (non-root user on Android) In-Reply-To: <1483720295.96.0.810571843517.issue29181@psf.upfronthosting.co.za> Message-ID: <1486147465.77.0.460686667601.issue29181@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:44:47 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:44:47 +0000 Subject: [issue29184] skip tests of test_socketserver when bind() raises PermissionError (non-root user on Android) In-Reply-To: <1483732137.12.0.493215743488.issue29184@psf.upfronthosting.co.za> Message-ID: <1486147487.06.0.731867443294.issue29184@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:45:12 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:45:12 +0000 Subject: [issue29185] test_distutils fails on Android API level 24 In-Reply-To: <1483737507.74.0.0285105710282.issue29185@psf.upfronthosting.co.za> Message-ID: <1486147512.8.0.697278136308.issue29185@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:45:58 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:45:58 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486147558.01.0.217634859227.issue29176@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:47:06 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:47:06 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1486147626.13.0.766253068449.issue27640@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:47:20 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Feb 2017 18:47:20 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1486147640.19.0.0715055711273.issue26855@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: xdegaye -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 13:49:30 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Feb 2017 18:49:30 +0000 Subject: =?utf-8?q?=5Bissue29395=5D_Edit_with_IDLE_3=2E6_don=C2=B4t_work_if_Name_o?= =?utf-8?q?f_File_=22code=2Epy=22?= In-Reply-To: <1485853403.69.0.0659896818047.issue29395@psf.upfronthosting.co.za> Message-ID: <1486147770.36.0.982504924561.issue29395@psf.upfronthosting.co.za> Steve Dower added the comment: I assume this is because Idle is doing "import code" somewhere and picking up your file instead of the real one. Renaming the file to not conflict with the standard library is an immediate workaround, but perhaps Idle should do some sys.path protection around wherever it's importing that module. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 14:57:32 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 03 Feb 2017 19:57:32 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486151852.15.0.436397381295.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Marco, thank you for your prompt comment. However, > Maybe you are running the doctest with Python 3. The StringIO module is no more available in Python 3, so your doctest will fail on Python 3 .... Please let me be clear. This issue is not about the StringIO module or about any of my doctests. It is about the documentation of the doctests module, and the ways in which that documentation is less helpful than it could be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:14:01 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 03 Feb 2017 20:14:01 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486152841.89.0.854304207707.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Marco, thank you for the suggestion to watch Raymond Hettinger's talk. > I suggest you to watch this talk of Raymond Hettinger, before going on: > > https://www.youtube.com/watch?v=voXVTjwnn-U That video is 63 minutes long, and a lot of those minutes are taken up by stories. I will watch the rest when I get time. I wish his insights were summarised in writing; I'll bet that would take much less than 63 minutes to read. I find that written text is a much faster way to deliver information, though maybe it takes the teacher more time to write well than to give a talk. I understand your point about the need for a review, and reviews being the bottleneck. The "Lifecycle of a Patch" document[1] is clear about that. [1] https://docs.python.org/devguide/patch.html#reviewing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:16:57 2017 From: report at bugs.python.org (lamby) Date: Fri, 03 Feb 2017 20:16:57 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486153017.94.0.015533627338.issue29431@psf.upfronthosting.co.za> lamby added the comment: I think we are misunderstanding each other regarding our goals here :) I'm not trying to test against other Python implementations or versions of CPython itself but rather "flush out" reproducibility issues in third-party Python code that (incorrectly) relies on dict ordering being relatively stable and/or in insertion order, etc. etc. (The only reason I mention 3.6 is because the insertion-order behaviour there simply makes it easier to have a 'reverse' order) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:21:40 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 03 Feb 2017 20:21:40 +0000 Subject: [issue18859] README.valgrind should mention --with-valgrind In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za> Message-ID: <1486153300.29.0.967655078111.issue18859@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:22:26 2017 From: report at bugs.python.org (Rohit Jamuar) Date: Fri, 03 Feb 2017 20:22:26 +0000 Subject: [issue26876] Extend MSVCCompiler class to respect environment variables In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za> Message-ID: <1486153346.69.0.364053434479.issue26876@psf.upfronthosting.co.za> Rohit Jamuar added the comment: Steve, I've limited the changes to _msvccompiler for the master-branch's patch. Is it alright? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:50:27 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Feb 2017 20:50:27 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486155027.92.0.193547187178.issue29431@psf.upfronthosting.co.za> R. David Murray added the comment: But that reliance/reproducibility-error would be an issue only on interpreters that don't preserve insertion order, and we're expecting we'll make that a language requirement. So for now, or for as long as you think it is warranted, just test against interpreters that randomize the order. Note that this is different from the pre-randomization dict behavior, where lots of programs depended on the accident-of-the-implementation order in which keys were returned. What we think is coming is a guaranteed ordering, which is, thus, reproducible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:52:43 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 03 Feb 2017 20:52:43 +0000 Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and later) In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> Message-ID: <1486155163.13.0.690023990803.issue27435@psf.upfronthosting.co.za> Michael Felt added the comment: On 31/01/2017 20:22, Michael Haubenwallner wrote: > Michael Haubenwallner added the comment: > > Feels like it is up to me to shed some light on various topics here: Many thanks! > > AIX defines (static) "Object" files and "Shared Object" files. Both can (but do not need to) be members of an "Archive Library". > > When talking about (dynamically loading) a "shared library" on non-AIX systems, the correct wording for AIX is (dynamically loading) a "Shared Object" - independent of whether it is a standalone file or an archive member. > > As you already agreed on, ctypes.util.find_library() indeed should return the location of the Shared Object - as either "/path/to/file" or "/path/to/file(member)". And ctypes.CDLL() should add the RTLD_MEMBER flag to _ctypes.dlopen() if there is the "(member)" part. > > However, that does not necessarily mean the RTLD_MEMBER value needs to be available through the ctypes API. Instead, RTLD_MEMBER feels more appropriate for the _ctypes API - and on AIX only. > > Anyway: > Unfortunately, there is no concept of embedding something like ELF's DT_SONAME tag into the Shared Object. The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the linker is recorded into the just-linked executable (or Shared Object). This implies that the runtime loader does search for the very same filename (and member eventually) as the linker (at linktime). I assume this is why there are many systems besides AIX that do not support/use DT_SONAME. At least I see many references to "Shared Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with the latter three being symbolic links to the first). > > However, to still get some kind of shared library versioning, multiple versions of one Shared Object are put into one single Archive Library, where the "old" versions get the LOADONLY flag set (via 'strip -e') - so executables linked against an old version still can load their "old" Shared Object, while the linker discovers the "current" version only. > > But this "single-filename" based shared library versioning is a huge burden for packages managers - either human or software, even when they maintain their packages in a private prefix (like /opt/freeware, /usr/local and similar). Neither can they put their "current" Shared Object's version into the single (system's) Archive Library, nor can they mark existing Shared Objects as LOADONLY. > On the other hand, they also do not want to pull all the system versions into their own Archive Library. Another issue is support for what I believe MacOS calls "fat" objects - that support both 32-bit and 64-bit applications - rather than /XXX/lib for 32-bit objects and /XXX/lib/lib64 or /XXX/lib64 for 64-bit objects. > > So for package managers it is crucial to have "multi-filename" based shared library versioning instead. > > But there is help: > AIX also provides (plain text) "Import Files": They contain a list of symbols for the linker, and a (PATH,BASE,MEMBER) tuple naming the Shared Object that provides these symbols at runtime. a) Yes to above b) One of the difficulties I faced is trying to guess what version -lFOO should find when there is more than one version available. Applications that are already linked do not look for a latest version - they know the member name that the linker found initially. ctypes.utils.find_library() does not provide a way to say which version should be found. Each implementation has it's way to find a version (e.g., a search of ldconfig -p output for a best guess) > So yes, Import Files can be used for "multi-filename" based shared library versioning. > > Thus, libtool now offers the "--with-aix-soname=svr4" configure flag, where "libNAME.so.X" really is created as an Archive Library, containing the Shared Object "shr.o" with the LOADONLY flag set, and the Import File "shr.imp" referring to "libNAME.so.X(shr.o)" for runtime. Combined with the symlink "libNAME.so", for the "-lNAME" argument the linker discovers the Import File "libNAME.so(shr.imp)" now, while recording "libNAME.so.X(shr.o)" into the executable for the runtime loader. > Note that for 64bit the Shared Object and Import File is named "shr_64.o" and "shr_64.imp", respectively. > > While libtool's "--with-aix-soname=svr4" variant creates "libNAME.a" from static Objects only, both libtool's "--with-aix-soname=aix" and "--with-aix-soname=both" - for backwards compatibility - create "libNAME.a" for traditional "single-filename" based versioning: Without any static Object - as even Shared Objects can be linked statically(!). But to statically link the Shared Object (as an archive member), neither the LOADONLY flag must be set, nor an Import File must be found (as Import Files cannot serve for static linking). > > And "--with-aix-soname=aix", libtool still creates standalone "libNAME.so.X.Y.Z" along the (versioning-wise useless) symlinks. > > So it is up to the package manager which "aix-soname" variant to choose within its prefix: For example, in Gentoo Prefix I'm using "--with-aix-soname=svr4" only. > > But still, how to get ctypes.find_library() working - ideally for each variant, is another story. Right now it does not work for any variant, Do you mean all systems, or specific to AIX - I am assuming you mean AIX. > but I guess that search algorithm should follow how the linker discovers the (PATH,BASE,MEMBER) values to I am not a tool builder. My comments are based on observations and experience from when I was a developer 25+ years ago. The AIX linker is not interested in the member name - it seems to go through the PATH/libBASE.a looking for the first object it can find to resolve a symbol. The name of the object it finds becomes the MEMBER it records in it's internal table of where to look later when the application runs. This is why (on AIX) when a new archive is installed - even though there is a MEMBER that could resolve a symbol, if the MEMBER name has changed the rtld activity will fail. This is where (at least on AIX) using the LDONLY flag is important. The "old" MEMBER is there for "old" applications, but "new" applications will use a different object to resolve symbols. I would say the linker seraches for something to resolve a symbol (get it defined) while the rtld (run-time loader) locates a known BASE,MEMBER pair based on the internal "blibpath" and/or an optional environmental variable (LD_LIB_PATH, LD_LIBRARY - must check exact names - in any case AIX dlopen() knows, better recognizes two environmental variables, as a list of PATHs to follow to locate the BASE(MEMBER) pair. > write into just-linked executables, combined with how the runtime loader finds the Shared Object to actually load. I worked on a patch - to do all that - taking into consideration the way libtool names .so files/members and then looking into/at "legacy" aka IBM dev ways they did things before the libtool model was so prominent. My algorithm - attempts to solve the (PATH, BASE, MEMBER) problem as "dynamically" as possible. PATH and BASE are fairly straight forward - but MEMBER is clearly more complex. PATH: start by looking at the python executable - and looking at it's "blibpath" - and using that as the default colon separated list of PATHs to search for BASE.a archive. Once a BASE.a file is found it is examined for a MEMBER. If all PATH/BASE.a do not find a potential MEMBER then the PATHs are examined again for PATH/BASE.so. When a .so file is found that is returned - versioning must be accomplished via a symbolic link to a versioned library. The program "dump -H" provides this information for both executables and archive (aka BASE) members. Starting from the "blibpath" values in the executable mean a cpython packager can add a specific PATH by adding it to LDFLAGS="-L/my/special/libdir:$LDFLAGS". Note that AIX archives also have their own "blibpath" - so libraries dynamically loaded may also follow additional paths that the executable is not aware of (nor need to be). So - once the PATHS are determined the system is examined looking for ${PATH}/BASE.a. If a target BASE.a is found, it is examined for a MEMBER is set to BASE.so (now used a MEMBER.so) . If MEMBER.so is not found then look for the "highest X[.Y[.Z]] aka MEMBER.so.X[.Y[.Z]] name. If that is not found check AIX legacy names (mainly shr.o or shr_64.o, although there are also certain key libraries that have additional variations (boring)). Again, if PATH, BASE, MEMBER is not located as a .a archive - look for libFOO.so in all the PATH directories known to the executable. I hope above is clear enough to continue the discussion. Thanks again for the discussion. Michael > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- nosy: -aixtools at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 15:58:25 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 03 Feb 2017 20:58:25 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486155505.02.0.239316045168.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Marco and David, thank you again for your prompt replies. Let me respond to both of your comments on the doctest module documentation itself. [Marco] > The example in section 26.3.3.2 [1], before the compound statement (the if/else), contains two simple statements. I also think the example is complete and straightforward for its purpose, and it does not have to be complicated adding avanced features. You are correct, it contain two simple statements. I missed this when I first read the example. Part of the problem is that the example is contrived. It is an actual test. I think it would be better to replace these two lines by a two-line test, one which sets up state and another which exercises the module under test. You believe "the example is complete and straightforward for its purpose, and it does not have to be complicated adding avanced features." I am giving you feedback that it was not complete and straightforward for me, as an ordinary software developer trying to use the documentation. [Marco] > If you want a more complex control over your tests, for instance adding fixtures, you can find how to do it later... No, control over tests is not what I am bringing up in this issue. I an concerned with documentation of doctest "Examples". [Marco] > I am -1 on this [changing 26.3.3.2]. IMHO there is no need to add extra description to a such self-explaining, clear and concise example. But this I think is also clear from the beginning. Infact, the first line of the doc says: "The doctest module searches for pieces of text that look like interactive Python sessions" [David] > As for the prompts, I agree with Marco: I don't think there is any need to add words, since it clearly says it is supposed to look like an interactive session and the reader gets reminded of the rules for that by the example provided. IMO it is not appropriate to re-document those rules here. My feedback to you is that for me, as an ordinary software developer trying to use the doctest module, this section is not "self-explaining, clear and concise", and that "How Docstring examples are recognised" is not "clear from the beginning". Perhaps we have a difference of opinion on how clear and effective this documentation is. The best way to resolve that would be to gather data: having several ordinary software developers reading the document, then measuring their comprehension. That would be hard to arrange. At least this bug report will serve as a data point. I believe that a library module documentation should at some point clearly specify how the module works. I believe section Section "26.3.3.2. How are Docstring Examples Recognized?" does poorly at that. To say, "In most cases a copy-and-paste of an interactive console session works fine, but doctest isn?t trying to do an exact emulation of any specific Python shell." is not a specification. It's a blurry generalisation. The list of "fine print" is at a better level of detail, but still doesn't mention how the parser treats statements, nor how prefixes relate to statement boundaries. I am giving you feedback that for me, as a developer trying to use the doctest module, this documentation failed to give me the comprehension I needed to be effective. [Marco] >Also this section [26.3.3.3, execution context] IMO is well written and clear. I do not know what to say... If someone else thinks it is not enough understandable, maybe the better think to do is to add a very small example, with two functions, that shows their docstrings have independent globals. [David] > It does appear that "test" is being used ambiguously in the docs. In most places it means a single statement, but in execution context it appears to be being used as a synonym for "docstring". In that section it should be replaced by "docstring". It would probably be worth checking the rest of the doc to make sure it is used consistently elsewhere as well. [David] > The execution context section makes it clear that you can use names defined earlier, as does the fact that doctests emulate interactive sessions. Both of these make it clear you can do multi line examples that use shared state. Again, I am giving you feedback that this document was not "clear" for me. I am taking the time to write this issue because I think the documentation has weaknesses, and would like to help improve it. I agree with David, that one problem in this section is that the word "test" is used with three different meanings. Some instances of the word "test" should be changed to "docstring" or similar. That would help. [David] > So in summary, I think we *need* a one word change in the execution context section, and we'll consider any other enhancements you want to propose. All right, I'll work on a patch that makes that one-word change, and offers some other concise improvements. I expect it will be more that you think necessary, given that we disagree on how "clear" the current documentation is. Given that reviews are a bottleneck, I fear my patch may grind to a halt waiting for review. But this is my first contribution to Python. We'll see. I clearly have a lot to learn. [David] > And thanks for wanting to improve the docs! You are welcome! Thank you again for your prompt responses. And thank you for all your work to build this marvelous Python language, which helps so many. [1] https://docs.python.org/3/library/doctest.html#how-are-docstring-examples-recognized ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 16:20:01 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 21:20:01 +0000 Subject: [issue25488] IDLE: Remove '', user_dir, and idlelib from sys.path when added In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za> Message-ID: <1486156801.28.0.673339610489.issue25488@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I should have said that the problem with having '' at the beginning of the path is that when IDLE tries to import an stdlib module and '' (usually a user directory) contain a file with the same name, IDLE will import the user file instead and at some point likely exit. For example, a user file named code.py masks the stdlib code.py, which is essential to Shell operation (#29395). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 16:47:27 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 21:47:27 +0000 Subject: [issue25488] IDLE: Remove '', user_dir, and idlelib from sys.path when added In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za> Message-ID: <1486158447.39.0.558253339905.issue25488@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The sys.pyth manipulation will be different in the idle and user processes. If IDLE is started with -n, so both processes are the same, even more care is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 16:50:05 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 21:50:05 +0000 Subject: =?utf-8?q?=5Bissue29395=5D_Edit_with_IDLE_3=2E6_don=C2=B4t_work_if_Name_o?= =?utf-8?q?f_File_=22code=2Epy=22?= In-Reply-To: <1485853403.69.0.0659896818047.issue29395@psf.upfronthosting.co.za> Message-ID: <1486158605.71.0.516000801055.issue29395@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Steve is correct. lib/code.py is used for IDLE's Shell. One should generally avoid naming files the same as stdlib files. To do so, one can either look in the module index of the docs or try 'import somename'. When Python starts, it imports the modules it uses *before* it adds '' or to the front of sys.path. Applications that both import modules and run user code need to at least temporarily remove the addition to do imports. Having IDLE fix sys.path is #25488. Duplicate names can also sabotage user code. More than one person has written, for instance, a random.py, forgotten about it, and later written a mystuff.py in the same directory. If mystuff has 'import random' with the intent to use the stdlib module, mystuff usually fails, often mysteriously. When IDLE fails, make sure you run it from a console with 'python -m idlelib' (python3 on some systems, idlelib.idle on 2.7). There will usually be an error message, which may or may not help. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE: Remove '', user_dir, and idlelib from sys.path when added _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:13:19 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 22:13:19 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1486159999.26.0.8203777472.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As far as I am concerned, this upload fulfills your obligation to CPython and PSF with respect to sponsoring your GSOC project. I wanted to get at least this loose end completed. I have no further expectation of you. I would *like* for you to make this pip installable by listing it on PyPI, so it can get some field testing. If you do, we can think about what to do from the pydev/cpython side. This was the meaning of Nick's last sentence above. If you want to do this, I am sure you can get help, maybe from Nick, certainly from others. I have never done a PyPI project, but I suppose I should learn how. I do not remember *any* json output from pip. Is this something new? the beginning of an API? Any coordination with pip people depends on them, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:28:21 2017 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 03 Feb 2017 22:28:21 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1486160901.25.0.337539515213.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: @Terry, I believe pip package doesn't solve the core purpose of GUI. Instead of that I should make a .deb, .rpm or .exe package so that beginners can directly install it. However, I will create the PyPI package by 10th Feb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:30:25 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 22:30:25 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486161025.23.0.40718362786.issue29387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree with Marco in that I do not understand the 'should'. Py 3 has a definite rule for when it raises. (I don't remember the exact details as I don't use tabs.) "Python raises xxxError if one mixes tabs and spaces in the same file." (Or whatever the rule is.) ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:34:19 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 22:34:19 +0000 Subject: [issue29394] Cannot tunnel TLS connection through TLS connection In-Reply-To: <1485847183.69.0.499542154053.issue29394@psf.upfronthosting.co.za> Message-ID: <1486161259.07.0.76239435471.issue29394@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Maximilian, I could not tell if you are still requesting that something be changed, or if this should be closed. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:36:37 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 22:36:37 +0000 Subject: [issue29400] Add instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486161397.57.0.0404048646556.issue29400@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed title: Instruction level tracing via sys.settrace -> Add instruction level tracing via sys.settrace versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 17:43:01 2017 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 03 Feb 2017 22:43:01 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1486161781.12.0.527448732155.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: I have tried to inquire about the possibility of a pip API, however currently it doesn't seem that it is top priority for pip organisation as per these issue threads : 1. https://github.com/pypa/pip/issues/924 2. https://github.com/pypa/pip/issues/3999 Currently pip list has --format option to give output as json format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 18:01:09 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 23:01:09 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1486162869.9.0.855476595192.issue29414@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The preceding sentences are also off. "In many ways the object returned by range() behaves as if it is a list, but in fact it isn?t. It is an object which returns the successive items of the desired sequence when you iterate over it, but it doesn?t really make the list, thus saving space." A range object is more like a tuple than a list. Ranges and tuples are immutable sequences and the only non-dunder methods of both are count and index. Lists, on the other hand, are mutable and several other exposed methods. The difference between range and tuple is that ranges generate items as requested while tuples can be added and multiplied. "Ranges are similar to tuples in being sequences with count and index methods. Both can be indexed, sliced, and iterated. However, ranges cannot be added or multiplied. They generate their items on request, thus saving space" I am still thinking about the next two sentences, discussed above. I do not like 'construct' to mean 'statement' (or callable). ---------- nosy: +terry.reedy versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 18:07:55 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Feb 2017 23:07:55 +0000 Subject: [issue29430] zipfile: invalid link In-Reply-To: <1486113194.67.0.258347417914.issue29430@psf.upfronthosting.co.za> Message-ID: <1486163275.81.0.606753713712.issue29430@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The Applicaton Note link in both the doc and here work for me with Firefox and Edge. ''' ...''' You must have been hit by a temporary glitch. ---------- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 19:16:42 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Feb 2017 00:16:42 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1486167402.35.0.220182704154.issue15451@psf.upfronthosting.co.za> Eryk Sun added the comment: > difference from the behaviour of Posix's execvpe() was deliberate POSIX doesn't define execvpe [1]. GNU glibc implemented it in 2009 [2]. On Windows, MSC has had execvpe and spawnvpe since at least 5.0 [3], and I think it arrived in 4.0 in 1986. Guido added os._execvpe in 1.2b4 [4] in 1995. I think it's the only implementation of execvpe that searches the passed environment. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/execvp.html [2]: https://sourceware.org/ml/libc-alpha/2009-10/msg00063.html [3]: https://openlibrary.org/works/OL2028669W [4]: https://hg.python.org/cpython/file/534a97c400cc/Lib/os.py ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 19:52:56 2017 From: report at bugs.python.org (Audric Schiltknecht) Date: Sat, 04 Feb 2017 00:52:56 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 Message-ID: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> New submission from Audric Schiltknecht: I've managed to create a minimal test file that causes python to crashe when run with python 3.6.0 (packaged in my distribution or from hg repository), 3.6 branch from hg repository and 3.7 branch from hg repository, but works fine on 3.5.3 and 3.5 branch. It also does not crash when python is compiled with '--with-pydebug' option (3.6/3.7) $ uname -a Linux 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux $ python --version Python 3.6.0 $ pip freeze appdirs==1.4.0 packaging==16.8 pyparsing==2.1.10 python-dateutil==2.6.0 six==1.10.0 SQLAlchemy==1.1.5 To reproduce, use the attached file (minimal_crash.py): $ virtualenv3 venv $ source venv/bin/activate $ pip install sqlalchemy Run once to create DB and insert some stuff into it (no crash): $ ./minimal_crash.py -d sqlite:///crash.db -v -c Then re-run same thing WITHOUT re-creating the base: $ ./minimal_crash.py -d sqlite:///crash.db -v INFO:__main__:Connecting to DB 'sqlite:///crash.db' Segmentation fault (core dumped) Runing with GDB: https://gist.github.com/audricschiltknecht/5564034c5aac78d881e03f29e069a8f5 ---------- files: minimal_crash.py messages: 286902 nosy: audric priority: normal severity: normal status: open title: SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 type: crash versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46505/minimal_crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 20:37:10 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 01:37:10 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486172230.07.0.707771558892.issue27867@psf.upfronthosting.co.za> Martin Panter added the comment: Not a big deal, but the change produces compiler warnings with GCC 6.1.1: /home/proj/python/cpython/Objects/bytesobject.c: In function ?bytes_subscript?: /home/proj/python/cpython/Objects/bytesobject.c:1701:13: warning: ?slicelength? may be used uninitialized in this function [-Wmaybe-uninitialized] for (cur = start, i = 0; i < slicelength; ^~~ /home/proj/python/cpython/Objects/listobject.c: In function ?list_ass_subscript?: /home/proj/python/cpython/Objects/listobject.c:2602:13: warning: ?slicelength? may be used uninitialized in this function [-Wmaybe-uninitialized] for (i = 0; i < slicelength; i++) { ^~~ /home/proj/python/cpython/Objects/unicodeobject.c: In function ?unicode_subscript?: /home/proj/python/cpython/Objects/unicodeobject.c:14013:16: warning: ?slicelength? may be used uninitialized in this function [-Wmaybe-uninitialized] result = PyUnicode_New(slicelength, max_char); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /media/disk/home/proj/python/cpython/Modules/_elementtree.c: In function ?element_ass_subscr?: /media/disk/home/proj/python/cpython/Modules/_elementtree.c:1896:50: warning: ?slicelen? may be used uninitialized in this function [-Wmaybe-uninitialized] self->extra->children[i + newlen - slicelen] = self->extra->children[i]; ~~~~~~~~~~~^~~~~~~~~~ /media/disk/home/proj/python/cpython/Modules/_ctypes/_ctypes.c: In function ?Array_subscript?: /media/disk/home/proj/python/cpython/Modules/_ctypes/_ctypes.c:4327:16: warning: ?slicelen? may be used uninitialized in this function [-Wmaybe-uninitialized] np = PyUnicode_FromWideChar(dest, slicelen); ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My build used to be free of warnings. This warning is enabled via -Wall. The reason is probably that the new macro skips the slicelength assignment if PySlice_Unpack() fails. Workarounds could be to assign or initialize slicelength to zero (at the call sites or inside the macro), or to compile with -Wno-maybe-uninitialized. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 22:40:54 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 03:40:54 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486179654.27.0.356155059747.issue29438@psf.upfronthosting.co.za> Xiang Zhang added the comment: I could reproduce this using Audric's command. And yes, debug build doesn't suffer from this crash. Nosy Victor. DEBUG:root:Called with: ['/tmp/minimal_crash.py', '-d', 'sqlite:///crash.db', '-v'] INFO:__main__:Connecting to DB 'sqlite:///crash.db' INFO:sqlalchemy.engine.base.Engine:SELECT CAST('test plain returns' AS VARCHAR(60)) AS anon_1 INFO:sqlalchemy.engine.base.Engine:() INFO:sqlalchemy.engine.base.Engine:SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 INFO:sqlalchemy.engine.base.Engine:() INFO:sqlalchemy.engine.base.Engine:BEGIN (implicit) INFO:sqlalchemy.engine.base.Engine:SELECT table_name.id AS table_name_id, table_name.att_1 AS table_name_att_1, table_name.att_2 AS table_name_att_2, table_name.att_3 AS table_name_att_3, table_name.date_1 AS table_name_date_1, table_name.date_2 AS table_name_date_2 FROM table_name WHERE table_name.id = ? AND table_name.att_1 = ? AND table_name.att_2 = ? AND table_name.att_3 = ? INFO:sqlalchemy.engine.base.Engine:('12345678912345', '123456789123456', 2, 4) DEBUG:__main__:No item found, new item DEBUG:__main__:Documents processed INFO:sqlalchemy.engine.base.Engine:INSERT INTO table_name (id, att_1, att_2, att_3, date_1, date_2) VALUES (?, ?, ?, ?, ?, ?) INFO:sqlalchemy.engine.base.Engine:('12345678912345', None, None, None, None, None) INFO:sqlalchemy.engine.base.Engine:ROLLBACK Program received signal SIGSEGV, Segmentation fault. _PyObject_Alloc (ctx=0x0, elsize=296, nelem=1, use_calloc=0) at Objects/obmalloc.c:1258 1258 if ((pool->freeblock = *(block **)bp) != NULL) { (gdb) bt #0 _PyObject_Alloc (ctx=0x0, elsize=296, nelem=1, use_calloc=0) at Objects/obmalloc.c:1258 #1 _PyObject_Malloc (ctx=0x0, nbytes=296) at Objects/obmalloc.c:1437 #2 0x000055555564082c in new_keys_object (size=) at Objects/dictobject.c:536 #3 dictresize (mp=mp at entry=0x7ffff7e36510, minsize=) at Objects/dictobject.c:1242 #4 0x000055555564456f in insertion_resize (mp=0x7ffff7e36510) at Objects/dictobject.c:1094 #5 insertdict (value=, hash=, key=, mp=) at Objects/dictobject.c:1142 #6 PyDict_SetItem (value=0x7ffff39f5d68, key=0x7ffff66f9260, op=0x7ffff7e36510) at Objects/dictobject.c:1564 #7 dict_ass_sub (mp=0x7ffff7e36510, v=0x7ffff66f9260, w=0x7ffff39f5d68) at Objects/dictobject.c:2148 #8 0x00005555555af8d4 in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:1673 #9 0x00005555555ab211 in PyEval_EvalFrameEx (throwflag=0, f=0x7ffff3487da0) at Python/ceval.c:664 #10 _PyFunction_FastCall (co=, args=, nargs=2, globals=) at Python/ceval.c:4926 #11 0x00005555555b30ff in call_function (kwnames=0x0, oparg=, pp_stack=) at Python/ceval.c:4868 #12 _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3290 #13 0x00005555556e37b0 in PyEval_EvalFrameEx (throwflag=0, f=0x555555eb0ce8) at Python/ceval.c:664 #14 _PyEval_EvalCodeWithName (_co=0x7ffff7e34300, globals=, locals=locals at entry=0x0, args=, argcount=2, kwnames=0x7ffff7e360f0, kwargs=0x555555eaf210, kwcount=3, kwstep=1, defs=0x0, defcount=0, kwdefs=0x7ffff7e36480, closure=0x0, name=0x7ffff7e30420, qualname=0x7ffff7e31f60) at Python/ceval.c:4165 #15 0x00005555556e395b in fast_function (func=, stack=, nargs=, kwnames=) at Python/ceval.c:4987 #16 0x00005555555b22a8 in call_function (kwnames=0x7ffff7e360d8, oparg=, pp_stack=) at Python/ceval.c:4868 #17 _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3336 ... ---------- nosy: +haypo, xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 23:30:56 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Feb 2017 04:30:56 +0000 Subject: [issue29430] zipfile: invalid link In-Reply-To: <1486113194.67.0.258347417914.issue29430@psf.upfronthosting.co.za> Message-ID: <1486182656.65.0.0460459009657.issue29430@psf.upfronthosting.co.za> Berker Peksag added the comment: > I think that HTML output suggests that their server configuration is broken. If you look at further down the page there is this error message:

Something has triggered missing webpage on your website. This is the default 404 error page for nginx that is distributed with EPEL. It is located /usr/share/nginx/html/404.html

And: $ curl -I https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT HTTP/1.1 404 Not Found ... https://support.pkware.com/display/PKZIP/Application+Note+Archives might be a suitable alternative to the broken link. I'm adding Serhiy to nosy list since he knows a lot about the ZIP file format. ---------- assignee: -> docs at python components: +Documentation nosy: +berker.peksag, docs at python, serhiy.storchaka resolution: not a bug -> stage: resolved -> needs patch status: closed -> open type: -> behavior versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:07:30 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 05:07:30 +0000 Subject: [issue29439] _decimal on Android requires linking with libm Message-ID: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Just like issue21668, _decimal requires -lm on Android. This wasn't fixed because _decimal didn't build before issue26846 lands. More specificially, log10 is called https://hg.python.org/cpython/file/tip/Modules/_decimal/libmpdec/mpdecimal.c#l7862 Added _decimal and Android experts ---------- components: Cross-Build files: decimal.patch keywords: patch messages: 286906 nosy: Alex.Willmer, Chi Hsuan Yen, skrah, xdegaye priority: normal severity: normal status: open title: _decimal on Android requires linking with libm type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file46506/decimal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:18:54 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 05:18:54 +0000 Subject: [issue29440] _dbm requires -lgdbm if gdbm is built as static libraries Message-ID: <1486185534.28.0.954859942515.issue29440@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: In setup.py, _dbm links to gdbm_compat only. If gdbm is built as dynamic libraries, libgdbm_compat.so has a NEEDED flag for libgdbm.so, so both symbols in libgdbm and libgdbm_compat can be used. However, as static libraries does not provide such a flag, importing _dbm raises ImportError: shell at ASUS_Z00E_2:/data/local/tmp $ python3.7m -c 'import _dbm' Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: cannot locate symbol "gdbm_errno" referenced by "/data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_dbm.cpython-37m.so"... gdbm_errno is a symbol in libgdbm.a. gdbm manual [1] suggests linking to both libraries, too. [1] http://www.gnu.org.ua/software/gdbm/manual/html_node/Compatibility.html ---------- components: Build files: gdbm.patch keywords: patch messages: 286907 nosy: Chi Hsuan Yen priority: normal severity: normal status: open title: _dbm requires -lgdbm if gdbm is built as static libraries type: compile error versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46507/gdbm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:21:06 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 05:21:06 +0000 Subject: [issue29440] _dbm requires -lgdbm if gdbm is built as static libraries In-Reply-To: <1486185534.28.0.954859942515.issue29440@psf.upfronthosting.co.za> Message-ID: <1486185666.9.0.944791252551.issue29440@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Add the developer who wrote this line (issue15044) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:36:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 05:36:08 +0000 Subject: [issue29430] zipfile: invalid link In-Reply-To: <1486113194.67.0.258347417914.issue29430@psf.upfronthosting.co.za> Message-ID: <1486186568.77.0.754455926746.issue29430@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: https://support.pkware.com/display/PKZIP/Application+Note+Archives contains links to old versions of APPNOTE (the last is 6.3.3). But the actual version was at least 6.3.4 (I have a local copy). All external links refer to http://www.pkware.com/documents/casestudies/APPNOTE.TXT. I think we should report a bug to PKWare. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:41:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 05:41:26 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486186886.88.0.678954909693.issue27867@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point Martin. I missed this because warnings are not emitted in non-debug build and were emitted only once in incremental debug build. Your idea about initializing slicelength in a macro LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:49:52 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Feb 2017 05:49:52 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst Message-ID: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> New submission from Berker Peksag: Attached patch converts all examples that use @coroutine decorator in Doc/library/asyncio-task.rst. I also removed the generator example at https://docs.python.org/3/library/asyncio-task.html#example-coroutine-displaying-the-current-date See issue 29407 for context. ---------- assignee: docs at python components: Documentation, asyncio files: update-examples-task.diff keywords: patch messages: 286911 nosy: berker.peksag, docs at python, gvanrossum, yselivanov priority: normal severity: normal stage: patch review status: open title: Update examples to use async and await keywords in asyncio-task.rst type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46508/update-examples-task.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:05:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 06:05:31 +0000 Subject: [issue29311] Argument Clinic: convert dict methods In-Reply-To: <1484758450.31.0.717694851278.issue29311@psf.upfronthosting.co.za> Message-ID: <20170204060528.110885.57127.6DD862C4@psf.io> Roundup Robot added the comment: New changeset 222b9392a83b by Serhiy Storchaka in branch 'default': Issue #29311: Regenerate Argument Clinic. https://hg.python.org/cpython/rev/222b9392a83b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:11:41 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 06:11:41 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486188701.26.0.440474340936.issue29405@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sounds reasonable. IIUC if the sample data gets 11 lines the total could be 20. I also think the second min is redundant. Would you mind review my patch Milt? ---------- keywords: +patch stage: -> patch review type: behavior -> enhancement versions: +Python 3.7 -Python 3.5 Added file: http://bugs.python.org/file46509/csv_sniffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:13:58 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 06:13:58 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <20170204061355.16815.62837.30180AF2@psf.io> Roundup Robot added the comment: New changeset fe29826af634 by Berker Peksag in branch '3.5': Issue #29198: Document typing.AsyncGenerator https://hg.python.org/cpython/rev/fe29826af634 New changeset b475b076cc1f by Berker Peksag in branch '3.6': Issue #29198: Merge from 3.5 https://hg.python.org/cpython/rev/b475b076cc1f New changeset 2b55b18bf151 by Berker Peksag in branch 'default': Issue #29198: Merge from 3.6 https://hg.python.org/cpython/rev/2b55b18bf151 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:28:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 06:28:05 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486189685.08.0.997919850675.issue27867@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46510/PySlice_GetIndicesEx-silence-warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:30:02 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 06:30:02 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <20170204062959.96794.21037.D6220D69@psf.io> Roundup Robot added the comment: New changeset d7eb9526c4f4 by Berker Peksag in branch '3.5': Issue #29198: Fix indentation and markup in typing.rst https://hg.python.org/cpython/rev/d7eb9526c4f4 New changeset f49b6c35d1e3 by Berker Peksag in branch '3.6': Issue #29198: Merge from 3.5 https://hg.python.org/cpython/rev/f49b6c35d1e3 New changeset 8a898cfd089a by Berker Peksag in branch 'default': Issue #29198: Merge from 3.6 https://hg.python.org/cpython/rev/8a898cfd089a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 01:30:47 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Feb 2017 06:30:47 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <1486189847.61.0.473298306538.issue29198@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patches, Jelle :) ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 07:00:33 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <1486191633.85.0.559084899162.issue29198@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7fd9559c9c97fcf0519ace33b9d76a81ae156523 by Berker Peksag in branch 'master': Issue #29198: Document typing.AsyncGenerator https://github.com/python/cpython/commit/7fd9559c9c97fcf0519ace33b9d76a81ae156523 New changeset 34c0c17d5774524dae63d9e2e693ad4b97386bbe by Berker Peksag in branch 'master': Issue #29198: Merge from 3.5 https://github.com/python/cpython/commit/34c0c17d5774524dae63d9e2e693ad4b97386bbe New changeset b6d785d86dbf4ea9b90da57f11da4fff1bb36c9d by Berker Peksag in branch 'master': Issue #29198: Merge from 3.6 https://github.com/python/cpython/commit/b6d785d86dbf4ea9b90da57f11da4fff1bb36c9d New changeset 2c6ff7794c1b1af545d8ff17f54acef41cab089e by Berker Peksag in branch 'master': Issue #29198: Fix indentation and markup in typing.rst https://github.com/python/cpython/commit/2c6ff7794c1b1af545d8ff17f54acef41cab089e New changeset 9ea15544818e9186277efda1ce9da3a5e48ff1c7 by Berker Peksag in branch 'master': Issue #29198: Merge from 3.5 https://github.com/python/cpython/commit/9ea15544818e9186277efda1ce9da3a5e48ff1c7 New changeset bab4b9b5a4c16298b17a77cf2aec43320f296717 by Berker Peksag in branch 'master': Issue #29198: Merge from 3.6 https://github.com/python/cpython/commit/bab4b9b5a4c16298b17a77cf2aec43320f296717 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 07:00:34 +0000 Subject: [issue29311] Argument Clinic: convert dict methods In-Reply-To: <1484758450.31.0.717694851278.issue29311@psf.upfronthosting.co.za> Message-ID: <1486191634.04.0.860479289297.issue29311@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7baf0a0b90da5bb0b1ed5d27374f5a6b1c7b5dae by Serhiy Storchaka in branch 'master': Issue #29311: Regenerate Argument Clinic. https://github.com/python/cpython/commit/7baf0a0b90da5bb0b1ed5d27374f5a6b1c7b5dae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:00:36 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 07:00:36 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <1486191636.84.0.0897873707505.issue29198@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7fd9559c9c97fcf0519ace33b9d76a81ae156523 by Berker Peksag in branch '3.6': Issue #29198: Document typing.AsyncGenerator https://github.com/python/cpython/commit/7fd9559c9c97fcf0519ace33b9d76a81ae156523 New changeset 34c0c17d5774524dae63d9e2e693ad4b97386bbe by Berker Peksag in branch '3.6': Issue #29198: Merge from 3.5 https://github.com/python/cpython/commit/34c0c17d5774524dae63d9e2e693ad4b97386bbe New changeset 2c6ff7794c1b1af545d8ff17f54acef41cab089e by Berker Peksag in branch '3.6': Issue #29198: Fix indentation and markup in typing.rst https://github.com/python/cpython/commit/2c6ff7794c1b1af545d8ff17f54acef41cab089e New changeset 9ea15544818e9186277efda1ce9da3a5e48ff1c7 by Berker Peksag in branch '3.6': Issue #29198: Merge from 3.5 https://github.com/python/cpython/commit/9ea15544818e9186277efda1ce9da3a5e48ff1c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:00:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 07:00:38 +0000 Subject: [issue29198] AsyncGenerator is missing from typing In-Reply-To: <1483825061.03.0.644790904886.issue29198@psf.upfronthosting.co.za> Message-ID: <1486191638.68.0.0889100697992.issue29198@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 7fd9559c9c97fcf0519ace33b9d76a81ae156523 by Berker Peksag in branch '3.5': Issue #29198: Document typing.AsyncGenerator https://github.com/python/cpython/commit/7fd9559c9c97fcf0519ace33b9d76a81ae156523 New changeset 2c6ff7794c1b1af545d8ff17f54acef41cab089e by Berker Peksag in branch '3.5': Issue #29198: Fix indentation and markup in typing.rst https://github.com/python/cpython/commit/2c6ff7794c1b1af545d8ff17f54acef41cab089e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:14:22 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Feb 2017 07:14:22 +0000 Subject: [issue29411] Option --executable for entry_points In-Reply-To: <1485945833.17.0.354426636585.issue29411@psf.upfronthosting.co.za> Message-ID: <1486192462.88.0.874371907625.issue29411@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Michal. Note that both [1] and [2] point to the same patch. Perhaps you meant to paste a link to a separate patch for distutils? (I removed 3.3 and 3.4 from the versions field since they are in security-fix-only mode now. I don't know whether this can be applied as a bugfix or not without reading the pypa-dev thread and the patch for distutils so I left rest of it selected.) ---------- nosy: +berker.peksag versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:20:15 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 07:20:15 +0000 Subject: [issue18069] Subprocess searches special directories before PATH on Windows In-Reply-To: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za> Message-ID: <1486192815.37.0.857902927041.issue18069@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: Subprocess picks the wrong executable on Windows -> Subprocess searches special directories before PATH on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:26:28 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 07:26:28 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py Message-ID: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: The change is clear and self-explained. See the patch. Motivations: 1. The hack "To prevent optparse from raising an exception..." works for single letter flags (-I, -L, etc.) only. I plan to add --sysroot related codes for Android builds and I don't want more hacks. Apparently argparse does not need this hack as it can parse all known flags before throwing an error 2. optparse is deprecated Add the developer that introduced this hack. Also Serhiy, who sseems interested in removing optparse from the code base. (issue18973, issue18971) ---------- components: Build files: setup-argparse.patch keywords: patch messages: 286922 nosy: Chi Hsuan Yen, brett.cannon, serhiy.storchaka priority: normal severity: normal status: open title: Use argparse and drop dirty optparse hacks in setup.py type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46511/setup-argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:33:35 2017 From: report at bugs.python.org (Milt Epstein) Date: Sat, 04 Feb 2017 07:33:35 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486193615.51.0.565470409263.issue29405@psf.upfronthosting.co.za> Milt Epstein added the comment: That's right, with 11 lines in the sample data, total will become 20 on the second iteration. And that throws off some of the computations done in that function. Your patch looks good, in that it will achieve what I'm requesting. But :-), your pointing out that other redundant min() made me take a closer look at the code, and led me to produce the attached patch as an alternate suggestion. I think it makes the code a bit more sensible and cleaner. Please review, and go with what you think best. Thanks. ---------- Added file: http://bugs.python.org/file46512/csv.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:36:24 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 07:36:24 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486193784.37.0.355422954715.issue29405@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:48:01 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 07:48:01 +0000 Subject: [issue13196] subprocess: undocumented if shell=True is necessary to find executable in Windows PATH In-Reply-To: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za> Message-ID: <1486194481.68.0.233917406065.issue13196@psf.upfronthosting.co.za> Martin Panter added the comment: It is hard to make sense of this without decoding your URLs, downloading the repository and finding the relevant commit. Anyway, what you have posted sounds like a duplicate of Issue 8557. ---------- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> subprocess PATH semantics and portability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:48:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 07:48:21 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486194501.05.0.724775017685.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: valgrind output is here. https://gist.github.com/methane/3c010daba71a374fd0b6a41a0d98e3ff It seems another bug relating to key-sharing dict... ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:02:38 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 08:02:38 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486195358.01.0.527299907947.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: After reading the code I could see the possibility. A weakref object gets two linkedlist pointers which are not initialized by new_weakref (actually they are initialized by insert_head or insert_after). But the weakref object is possible to be destroyed in [1] and [2]. So we are going to dereference two uninitialized pointers in clear_weakref and then crash. So simply initialize the two pointers to NULL in init_weakref could solve this problem? Are you willing to test Saida? [1] https://github.com/python/cpython/blob/master/Objects/weakrefobject.c#L770 [2] https://github.com/python/cpython/blob/master/Objects/weakrefobject.c#L833 ---------- keywords: +patch stage: -> patch review title: Python 2.7.8 is crashing while creating weakref for a given object. -> Python could crash while creating weakref for a given object Added file: http://bugs.python.org/file46513/weakref_crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:03:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 08:03:21 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486195401.97.0.144347293153.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: 4385 int was_shared = cached == ((PyDictObject *)dict)->ma_keys; 4386 res = PyDict_SetItem(dict, key, value); 4387 if (was_shared && cached != ((PyDictObject *)dict)->ma_keys) { 4388 /* PyDict_SetItem() may call dictresize and convert split table ... 4401 */ 4402 if (cached->dk_refcnt == 1) { 4403 CACHED_KEYS(tp) = make_keys_shared(dict); 4404 } 4405 else { 4406 CACHED_KEYS(tp) = NULL; 4407 } L4402 accessed free `cached` object. At PyDict_SetItem() in L4386, some callback is called through weakref callback, and the callback inserts something into this dict. shared key object (cached) is freed. So right way to fix it may be DK_INCREF() before PyDict_SetItem(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:05:20 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 08:05:20 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486195520.84.0.692892372886.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:09:30 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 08:09:30 +0000 Subject: [issue20927] Different behaviour on Posix and Windows when using subprocess.Popen(..., cwd=path) In-Reply-To: <1394816385.18.0.912805951896.issue20927@psf.upfronthosting.co.za> Message-ID: <1486195770.7.0.394030943491.issue20927@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> subprocess.Popen(cwd) documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:29:42 2017 From: report at bugs.python.org (Maximilian Blochberger) Date: Sat, 04 Feb 2017 08:29:42 +0000 Subject: [issue29394] Cannot tunnel TLS connection through TLS connection In-Reply-To: <1485847183.69.0.499542154053.issue29394@psf.upfronthosting.co.za> Message-ID: <1486196982.72.0.777729112276.issue29394@psf.upfronthosting.co.za> Maximilian Blochberger added the comment: Yes. There should be at least an explanation of this behaviour in the documentation of the wrap_socket() function. I would additionally raise an exception if wrap_socket() is called and a socket is passed that is already wrapped. But I'm not sure if that is considered as an acceptable choice, as I am unfamiliar with Python development. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:33:17 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 08:33:17 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486197197.55.0.824286912155.issue29387@psf.upfronthosting.co.za> Martin Panter added the comment: Marco: I agree ?Python reports an error? would have been simpler. That is what I meant to say. Anyway, perhaps we should put Python raises :exc:`IndentationError` if mixed tabs and spaces are causing problems in leading whitespace. In general, the exception seems to be IndentationError. TabError is a subclass, but is not raised in all circumstances. It seems the compiler assumes a particular tab model, so the exact exception depends on the amount of tabs and spaces: >>> exec("if True:\n" + " "*8 + "1\n" "\t2\n") Traceback (most recent call last): File "", line 1, in File "", line 3 2 ^ TabError: inconsistent use of tabs and spaces in indentation >>> exec("if True:\n" + " "*9 + "1\n" "\t2\n") Traceback (most recent call last): File "", line 1, in File "", line 3 2 ^ IndentationError: unindent does not match any outer indentation level ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:43:01 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 08:43:01 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1486197781.59.0.362310245856.issue15451@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps this is a duplicate of Issue 8557 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:45:05 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Feb 2017 08:45:05 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1486197905.1.0.7524230556.issue15533@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Windows stage: test needed -> needs patch title: subprocess.Popen(cwd) documentation -> subprocess.Popen(cwd) documentation: Posix vs Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 03:45:51 2017 From: report at bugs.python.org (Michal Cyprian) Date: Sat, 04 Feb 2017 08:45:51 +0000 Subject: [issue29411] Option --executable for entry_points In-Reply-To: <1485945833.17.0.354426636585.issue29411@psf.upfronthosting.co.za> Message-ID: <1486197951.23.0.0129974151838.issue29411@psf.upfronthosting.co.za> Michal Cyprian added the comment: Yes, both references in my previous message point to the patch for setuptools, sorry for that. Here [3] is the patch that I prepared for distutils. I marked all the versions, because this functionality is missing in all of them. In my opinion it will be enough to apply this patch to the latest Python3 and Python2 version. pypa-dev thread is here [4]. The response that I've got is not publicly visible. I am not sure why it was sent directly to my address. I will ask them to make it public. In short this PR will be helpful for setuptools and they asked me to check also how can distlib and pip support this use case. [3] https://github.com/mcyprian/python3/commit/9f843468a0185516520bb1a70c0de18e7038c0e8#diff-31675636be8fb69017233f887ec14006R1 [4] https://groups.google.com/forum/#!topic/pypa-dev/qP8vcZlEfw8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:08:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 09:08:31 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <20170204090827.15965.40327.FCC4F469@psf.io> Roundup Robot added the comment: New changeset d7b637af5a7e by Serhiy Storchaka in branch '3.5': Issue #27867: Silenced may-be-used-uninitialized warnings after https://hg.python.org/cpython/rev/d7b637af5a7e New changeset 17d0cfc64a32 by Serhiy Storchaka in branch '2.7': Issue #27867: Silenced may-be-used-uninitialized warnings after https://hg.python.org/cpython/rev/17d0cfc64a32 New changeset b8fc4de84b9a by Serhiy Storchaka in branch '3.6': Issue #27867: Silenced may-be-used-uninitialized warnings after https://hg.python.org/cpython/rev/b8fc4de84b9a New changeset af8315720e67 by Serhiy Storchaka in branch 'default': Issue #27867: Silenced may-be-used-uninitialized warnings after https://hg.python.org/cpython/rev/af8315720e67 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:10:43 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 09:10:43 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <20170204091036.26489.19096.80B7523C@psf.io> Roundup Robot added the comment: New changeset 110ec861e5ea by Serhiy Storchaka in branch '2.7': Issue #27867: Fixed merging error. https://hg.python.org/cpython/rev/110ec861e5ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:15:16 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 09:15:16 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <20170204091509.16288.43371.2B68F98C@psf.io> Roundup Robot added the comment: New changeset 9245894af223 by Serhiy Storchaka in branch 'default': Issue #29300: Use Argument Clinic for getting struct object from the format. https://hg.python.org/cpython/rev/9245894af223 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:18:41 2017 From: report at bugs.python.org (Saida Dhanavath) Date: Sat, 04 Feb 2017 09:18:41 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486199921.01.0.393863418332.issue29347@psf.upfronthosting.co.za> Saida Dhanavath added the comment: Hi xiang, I have already patched our build environment with the fix and tested it locally. Although I cannot test it in production, have taken out the code of new_weakref, init_weakref and clear_weakref from weakrefobject.c. Changed init_weakref to initialize wr_prev and wr_next with NULL and verified that test program does crash after fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:20:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 09:20:26 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <20170204092023.111010.58058.9DF16F4B@psf.io> Roundup Robot added the comment: New changeset 50958e13c833 by Serhiy Storchaka in branch 'default': Issue #20185: Converted the gc module to Argument Clinic. https://hg.python.org/cpython/rev/50958e13c833 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:23:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Feb 2017 09:23:46 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486195401.97.0.144347293153.issue29438@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: You may try to reproduce with a release build and PYTHONMALLOC=debug to check for buffer over/underflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:37:50 2017 From: report at bugs.python.org (lamby) Date: Sat, 04 Feb 2017 09:37:50 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486201070.87.0.152596128078.issue29431@psf.upfronthosting.co.za> lamby added the comment: > we're expecting we'll make that a language requirement Mmm, but only for (at least) 3.7+. It would still be very useful to find software that is relying on (currently) undefined behaviour, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 04:48:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 09:48:32 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1486201712.95.0.833600774968.issue20186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Argument Clinic generates incorrect parsing code for _csv.field_size_limit(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:25 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486202425.81.0.782875654079.issue27867@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset faa1891d4d1237d6df0af4622ff520ccd6768e04 by Serhiy Storchaka in branch '3.5': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/faa1891d4d1237d6df0af4622ff520ccd6768e04 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:27 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486202427.8.0.15338590054.issue27867@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 745dda46d2e3e27206bb33188c770e1f6c73766e by Serhiy Storchaka in branch '2.7': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/745dda46d2e3e27206bb33188c770e1f6c73766e New changeset e9d77e9fce477b5589c7eb5e1b4179b1d8e1fecc by Serhiy Storchaka in branch '2.7': Issue #27867: Fixed merging error. https://github.com/python/cpython/commit/e9d77e9fce477b5589c7eb5e1b4179b1d8e1fecc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:31 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486202431.82.0.550171298997.issue20185@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 725c112c941ca6ac7fb995449f85501ea100647e by Serhiy Storchaka in branch 'master': Issue #20185: Converted the gc module to Argument Clinic. https://github.com/python/cpython/commit/725c112c941ca6ac7fb995449f85501ea100647e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:32 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486202431.99.0.329322649721.issue29300@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset e21cda70a3a13eb6e6238e436a5c0e2c4e4bebef by Serhiy Storchaka in branch 'master': Issue #29300: Use Argument Clinic for getting struct object from the format. https://github.com/python/cpython/commit/e21cda70a3a13eb6e6238e436a5c0e2c4e4bebef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:32 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486202432.12.0.229336048807.issue27867@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset faa1891d4d1237d6df0af4622ff520ccd6768e04 by Serhiy Storchaka in branch 'master': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/faa1891d4d1237d6df0af4622ff520ccd6768e04 New changeset 8bd58e9c725a15854a99d19daf935fb08df77a05 by Serhiy Storchaka in branch 'master': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/8bd58e9c725a15854a99d19daf935fb08df77a05 New changeset 65febbec9d09101f76a04efeef6b3dc7f9b06ee8 by Serhiy Storchaka in branch 'master': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/65febbec9d09101f76a04efeef6b3dc7f9b06ee8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:00:34 +0000 Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za> Message-ID: <1486202434.87.0.526384739982.issue27867@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset faa1891d4d1237d6df0af4622ff520ccd6768e04 by Serhiy Storchaka in branch '3.6': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/faa1891d4d1237d6df0af4622ff520ccd6768e04 New changeset 8bd58e9c725a15854a99d19daf935fb08df77a05 by Serhiy Storchaka in branch '3.6': Issue #27867: Silenced may-be-used-uninitialized warnings after https://github.com/python/cpython/commit/8bd58e9c725a15854a99d19daf935fb08df77a05 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:02:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 10:02:31 +0000 Subject: [issue26901] Argument Clinic test is broken In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za> Message-ID: <1486202551.12.0.228449582831.issue26901@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any chance to fix Argument Clinic test? Without this we can't add new features, fix bugs and add tests for searching new bugs. This is critical for further converting to Argument Clinic. ---------- priority: high -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:08:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 10:08:16 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1486202896.54.0.0842815420549.issue20186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem with lsprof_clinic.patch is that it exposes default value of _lsprof.Profiler.enable() parameters as -1. Actually _lsprof.Profiler.enable() should accept boolean arguments without default value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:08:36 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 10:08:36 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486202916.42.0.0835160973632.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, what's your test program? Would you mind show it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:12:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 10:12:05 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486203125.6.0.853006890515.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: This is use after free, not overflow. This patch is based on Python 3.6, but I think 3.5 has same issue. I'll check it. ---------- keywords: +patch Added file: http://bugs.python.org/file46514/29438-sharedkey-useafterfree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:13:46 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:13:46 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <20170204101343.96877.18052.DE7295F7@psf.io> Roundup Robot added the comment: New changeset 7f8a3eb3459e by Serhiy Storchaka in branch 'default': Issue #20186: Converted the symtable module to Argument Clinic. https://hg.python.org/cpython/rev/7f8a3eb3459e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:15:04 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 10:15:04 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486203304.21.0.204750737633.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: (PYTHONMALLOC=malloc valgrind find it soon. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:18:53 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 10:18:53 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <20170204101850.96794.19695.98049809@psf.io> Roundup Robot added the comment: New changeset e1df73b46094 by Serhiy Storchaka in branch 'default': Issue #20186: Converted the tracemalloc module to Argument Clinic. https://hg.python.org/cpython/rev/e1df73b46094 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:39:57 2017 From: report at bugs.python.org (Saida Dhanavath) Date: Sat, 04 Feb 2017 10:39:57 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486204797.91.0.250305370294.issue29347@psf.upfronthosting.co.za> Saida Dhanavath added the comment: Please find the test program attached. Readme.txt has steps to comiple and run program. ---------- Added file: http://bugs.python.org/file46515/verify_crash_in_weakref.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:45:05 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Feb 2017 10:45:05 +0000 Subject: [issue15451] PATH is not honored in subprocess.Popen in win32 In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za> Message-ID: <1486205105.03.0.282444861241.issue15451@psf.upfronthosting.co.za> Eryk Sun added the comment: Sure, let's close this in favor of the older documentation issue 8557. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> subprocess PATH semantics and portability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 05:48:48 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Feb 2017 10:48:48 +0000 Subject: [issue8557] subprocess PATH semantics and portability In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za> Message-ID: <1486205328.69.0.608816004351.issue8557@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.6, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 06:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 11:00:20 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1486206020.97.0.867158295602.issue20186@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset b0ef37ec83f337b4b77275b367288a5656a0682c by Serhiy Storchaka in branch 'master': Issue #20186: Converted the symtable module to Argument Clinic. https://github.com/python/cpython/commit/b0ef37ec83f337b4b77275b367288a5656a0682c New changeset 18a02e9d1f8e981b7b2f4287a4ed871021b13ade by Serhiy Storchaka in branch 'master': Issue #20186: Converted the tracemalloc module to Argument Clinic. https://github.com/python/cpython/commit/18a02e9d1f8e981b7b2f4287a4ed871021b13ade ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 06:02:42 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 11:02:42 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486206162.91.0.642310649226.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: But your weakref_crash.c doesn't look correct to me. Your test.object type doesn't support weak references at all. How could you use GET_WEAKREFS_LISTPTR then? See https://docs.python.org/3/extending/newtypes.html#weakref-support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 06:31:27 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 04 Feb 2017 11:31:27 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486207887.34.0.885393123121.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: Pinging again. I think this would be a great enhancement to the sqlite module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 06:33:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 11:33:44 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486208024.78.0.991490203554.issue29431@psf.upfronthosting.co.za> INADA Naoki added the comment: At least, ordering of namespace dict and kwargs dict are language spec for 3.6. This option breaks it. When this option is set, CPython 3.6 is not Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 06:55:49 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 04 Feb 2017 11:55:49 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1486209349.2.0.660482767605.issue29414@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Agreed. The issue I see with the additional suggestions by you and Marco (p.s the English was perfect!) is the introduction of other functions and/or objects that haven't been introduced yet. If you want to draw parallels with tuples, you'll need to introduce them first, right? (or would a link to the definition of tuples suffice?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 08:41:00 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Feb 2017 13:41:00 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486215660.64.0.00712269974934.issue29439@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks. Strange that on other systems the compilers don't complain (usually they do). ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 08:59:42 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 13:59:42 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <20170204135939.110308.66967.32DB4D7E@psf.io> Roundup Robot added the comment: New changeset b60b46ad8751 by Stefan Krah in branch '3.6': Issue29439: _decimal on Android requires linking with libm. https://hg.python.org/cpython/rev/b60b46ad8751 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 14:00:25 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486216825.47.0.745284282693.issue29439@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset aa26a5712a80849e968171b71b6bc8d9da3ac163 by Stefan Krah in branch '3.6': Issue29439: _decimal on Android requires linking with libm. https://github.com/python/cpython/commit/aa26a5712a80849e968171b71b6bc8d9da3ac163 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 14:00:27 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486216827.34.0.0954451779064.issue29439@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset aa26a5712a80849e968171b71b6bc8d9da3ac163 by Stefan Krah in branch 'master': Issue29439: _decimal on Android requires linking with libm. https://github.com/python/cpython/commit/aa26a5712a80849e968171b71b6bc8d9da3ac163 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:04:35 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Feb 2017 14:04:35 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486217075.92.0.654446615847.issue29439@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:16:16 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Feb 2017 14:16:16 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486217776.26.0.43355568367.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: Saida, I changed your test program to use set instead of self created type (see attachment). I tested it under Py2.7 and it seems no crash happens. python test.py 1 1 2.7.10 (default, Oct 14 2015, 16:09:02) [GCC 5.2.1 20151010] 0x101010101010101 0x1010101010101 Segmentation fault (core dumped) python test.py 1 1 2.7.10 (default, Oct 14 2015, 16:09:02) [GCC 5.2.1 20151010] (nil) (nil) It's appreciated if you are willing to make more tests or even in your build environment. :-) ---------- Added file: http://bugs.python.org/file46516/weakref_crash.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:30:42 2017 From: report at bugs.python.org (Saida Dhanavath) Date: Sat, 04 Feb 2017 14:30:42 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1486218642.29.0.804829868563.issue29347@psf.upfronthosting.co.za> Saida Dhanavath added the comment: Xiang, Sure, I will run it with other python versions and post the results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:43:49 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Feb 2017 14:43:49 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486203304.21.0.204750737633.issue29438@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Please update the issue title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 09:55:52 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Feb 2017 14:55:52 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1486220152.61.0.134793874137.issue15533@psf.upfronthosting.co.za> Eryk Sun added the comment: The Unix implementation of subprocess.Popen follows the behavior of os.execvpe, which is an outlier. Other execvpe implementations, such as the one added to glibc in 2009, search PATH in the current environment instead of the passed environment. As such, and given the natural expectations of a Windows programmer, I do not see the current behavior of the Windows implementation as incorrect. It's a documentation bug. On a related note, the Popen documentation for Windows should also mention that defining the environment variable NoDefaultCurrentDirectoryInExePath removes the current directory from the executable search path, in both CreateProcess and cmd.exe (i.e. w/ shell=True). This feature was introduced in Windows Vista, so it applies to Python 3.5+. > Python actually executes the program, but argv[0] is inconsistent with > cwd. Imagine that the called program wants to resolve its own path: > It joins cwd and argv[0] and gets > "C:\Users\Jenda\Bug reports\Python\subprocess\subdir\subdir\print_argv+cwd.exe" A Windows program would call GetModuleFileName with hModule as NULL, which returns the path of the process executable. There's also the pseudo-environment variable __APPDIR__. Using argv[0] from the command line would be unreliable. For example: >>> _ = run('"spam & eggs" /c echo %__APPDIR__%', ... executable=os.environ['ComSpec']) C:\Windows\system32\ >>> _ = run('"spam & eggs" -m calendar 2017 2', ... executable=sys.executable) February 2017 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:29:17 2017 From: report at bugs.python.org (Dave Brondsema) Date: Sat, 04 Feb 2017 15:29:17 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH Message-ID: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> New submission from Dave Brondsema: If you miss the checkbox to set the "PATH" when installing Python for the first time, there isn't any easy way to set it again. (And for new programmers, having it set automatically is extremely useful). Uninstalling and re-installing does work to get PATH set, but that isn't ideal. When you re-run the installer it does offer "Modify" and "Repair" options, but neither of those let you set the PATH. It would be nice if "Modify" did offer that option. ---------- components: Installation, Windows messages: 286968 nosy: brondsem, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Re-running Windows installer should have option to set PATH type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:36:57 2017 From: report at bugs.python.org (Dave Brondsema) Date: Sat, 04 Feb 2017 15:36:57 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH In-Reply-To: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> Message-ID: <1486222617.27.0.728730540847.issue29443@psf.upfronthosting.co.za> Dave Brondsema added the comment: A colleague has pointed out to me that this is available in the 2nd step within "Modify". I didn't realize there were more options after the first "Modify" screen. So perhaps the UI could be improved, but the functionality is there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:49:16 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Feb 2017 15:49:16 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH In-Reply-To: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> Message-ID: <1486223356.24.0.558378816769.issue29443@psf.upfronthosting.co.za> Eryk Sun added the comment: The user is presented with 3 buttons: Back, Next, and Cancel. The "Next" button is the only way forward to modify the installation. Did you assume "Next" would start the modification rather than take you to another dialog with options? How about if it had a more detailed name like "Next (Advanced Options)"? ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:50:03 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 15:50:03 +0000 Subject: [issue29440] _dbm requires -lgdbm if gdbm is built as static libraries In-Reply-To: <1486185534.28.0.954859942515.issue29440@psf.upfronthosting.co.za> Message-ID: <1486223403.1.0.122448131334.issue29440@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Sorry, -lgdbm should come after -lgdbm_compat, or symbols in libgdbm.a are still not resolved. I don't know why - linking is a magic :( ---------- Added file: http://bugs.python.org/file46517/gdbm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:55:37 2017 From: report at bugs.python.org (Dave Brondsema) Date: Sat, 04 Feb 2017 15:55:37 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH In-Reply-To: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> Message-ID: <1486223737.14.0.798295503106.issue29443@psf.upfronthosting.co.za> Dave Brondsema added the comment: Yes, exactly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:16:56 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 04 Feb 2017 16:16:56 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486225016.6.0.169682481504.issue29428@psf.upfronthosting.co.za> Marco Buttu added the comment: IMO if you would like to apply big changes to the current doc, as you wrote before, maybe is worth considering to propose a separate howto, instead of wide changes to the current page. I am suggesting this to you, because looking at the other modules of the standard library, I see they just explain the API, extending with examples when needed. When is worth adding extra documentation, in a different style, I see the usual solution is to extend with an howto. Look at the argparse module and related howto, for instance: https://docs.python.org/3/library/argparse.html https://docs.python.org/3/howto/argparse.html I also think an howto in this case is appropriate, because there is more to say than only the API. If you want to follow the howto way, I would like to contribute. In any case, I am disposed to review your patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:23:03 2017 From: report at bugs.python.org (WGH) Date: Sat, 04 Feb 2017 16:23:03 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index Message-ID: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> New submission from WGH: In [1]: import re In [2]: b = bytearray(b'A'*100) In [3]: m = re.search(b'A*', b) In [4]: m.group() Out[4]: b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' In [5]: del b[:] In [6]: m.group() Out[6]: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x9a\xc4\xb2i\x7f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' I will attach the patch shortly. ---------- components: Regular Expressions messages: 286974 nosy: WGH, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Out-of-bounds buffer access in match_getslice_by_index type: security versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:31:04 2017 From: report at bugs.python.org (WGH) Date: Sat, 04 Feb 2017 16:31:04 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486225864.67.0.719069934653.issue29444@psf.upfronthosting.co.za> Changes by WGH : ---------- keywords: +patch Added file: http://bugs.python.org/file46518/match_getslice_by_index.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:42:22 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Feb 2017 16:42:22 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486226542.11.0.00737300896341.issue29439@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > This wasn't fixed because _decimal didn't build before issue26846 lands. This is misleading, the problem went unnoticed when not linking with '-lm' because: * The _decimal extension module builds without any warning. * test_decimal does not fail. One way to demonstrate the problem in the interactive interpreter on Android: >>> import decimal >>> import _decimal Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: cannot locate symbol "log10" referenced by "_decimal.cpython-37dm.so"... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:45:06 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Feb 2017 16:45:06 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486226706.86.0.371237333506.issue29438@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +3.6regression -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:45:40 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Feb 2017 16:45:40 +0000 Subject: [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486226740.04.0.210176946623.issue29438@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:51:39 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 04 Feb 2017 16:51:39 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486227099.37.0.377048109282.issue29387@psf.upfronthosting.co.za> Marco Buttu added the comment: I think you are right about the TAB model (Parser/tokenizer.c:40 and Lib/tokenize.py:215), that is why the difference between the two cases. In any case, I am not sure whether expliciting the type of the exeption is the best choice. So, to me +1 to just change "should report" with "reports" in the proposed patch, and +0 to indicate the exeption type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:55:21 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Feb 2017 16:55:21 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486227321.6.0.512593214481.issue29442@psf.upfronthosting.co.za> Stefan Krah added the comment: I didn't look at this one, but some "hacks" are necessary in setup.py (example: usage of os.system() in some places). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 12:10:26 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Feb 2017 17:10:26 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486228226.39.0.222040402017.issue29439@psf.upfronthosting.co.za> Stefan Krah added the comment: Perhaps test_decimal should fail for CPython if _decimal can't be imported. All compilers that I tested seem to link fine without -lm in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 12:12:27 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 04 Feb 2017 17:12:27 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1486228347.89.0.970533183497.issue29414@psf.upfronthosting.co.za> Marco Buttu added the comment: Even though the Terry suggestion is formally correct, we are just at the beginning of the tutorial, and unluckily the tuples have not been introduced yet. To avoid adding to much complication here, IMHO we can just left the preceding sentences as they are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 12:24:45 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Feb 2017 17:24:45 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486229085.27.0.734006204741.issue29387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would add the exception type after testing all versions patched. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 13:56:09 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 18:56:09 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486234569.51.0.32350952359.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: I can reproduce it on Python 3.5 with attached script. I think this bug is from Python 3.3, since key-sharing dict is implemented. "Trigger key sharing dict resize while callbacks (weakref or __del__) called from setitem" is step to reproduce. It's not easy to exploit because external input (JSON, form, etc) doesn't use key-sharing dict. Should I fix it for 3.3~ (security fix only) or 3.5~ (bugfix)? ---------- keywords: +3.3regression -3.6regression, patch title: SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 -> use after free in key sharing dict Added file: http://bugs.python.org/file46519/29438-minimum.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 14:04:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 19:04:57 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486235097.75.0.0237707936355.issue29438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is it related to issue27945? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 14:15:48 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 04 Feb 2017 19:15:48 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486235748.76.0.964233955276.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: It's similar to issue27945, but different. I confirmed this issue is in 3.4 too. https://github.com/python/cpython/blob/3.4/Objects/dictobject.c#L3798 // _PyObjectDict_SetItem() if ((tp->tp_flags & Py_TPFLAGS_HEAPTYPE) && (cached = CACHED_KEYS(tp))) { ... res = PyDict_DelItem(dict, key); // <- may run arbitrary code. CACHED_KEYS(tp) can be changed and cached can be freed here. if (cached != ((PyDictObject *)dict)->ma_keys) { CACHED_KEYS(tp) = NULL; DK_DECREF(cached); // !!! } } else { res = PyDict_SetItem(dict, key, value); // Same to DelItem(). if (cached != ((PyDictObject *)dict)->ma_keys) { /* Either update tp->ht_cached_keys or delete it */ if (cached->dk_refcnt == 1) { // !!! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 14:52:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 19:52:19 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486237939.8.0.592063332266.issue29444@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch WGH. It is correct and fixes out-of-bounds buffer access. But I don't know what would be the better solution: silently adjust indices or raise RuntimeError? ---------- nosy: +serhiy.storchaka versions: +Python 2.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:06:47 2017 From: report at bugs.python.org (WGH) Date: Sat, 04 Feb 2017 20:06:47 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486238807.29.0.510019468506.issue29444@psf.upfronthosting.co.za> WGH added the comment: Python 2.7 (CPython and PyPy) and also PyPy's Python 3 adjust the indices, like my patch does, if that matters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:25:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 20:25:17 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486239917.13.0.981760870801.issue29444@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, this is good reason. The patch LGTM. ---------- assignee: -> serhiy.storchaka stage: -> commit review versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:29:53 2017 From: report at bugs.python.org (Guillaume Boudreau) Date: Sat, 04 Feb 2017 20:29:53 +0000 Subject: [issue29445] http.client: missing response headers when malformed header is part of the response Message-ID: <1486240193.44.0.0804410028853.issue29445@psf.upfronthosting.co.za> New submission from Guillaume Boudreau: Tested using urllib3 1.20 ``` >>> import urllib3 >>> http = urllib3.PoolManager() >>> r = http.request('GET', 'https://online.chasecanada.ca/ChaseCanada_Consumer/Login.do') >>> r.status 200 >>> r.headers HTTPHeaderDict({'Date': 'Sat, 04 Feb 2017 20:09:21 GMT'}) >>> ``` I'm pretty sure the problem is caused by an invalid HTTP header returned by the server: HTTP/1.1 200 OK Date: Sat, 04 Feb 2017 19:16:34 GMT My Param: None [...] It directly follows the Date response header, which is returned fine, but since no other response headers is returned, I think this broken header is breaking the HTTP response headers parser. Of note: the `http.client.HTTPresponse.headers` object (`HTTPMessage`) shows all headers in `_payload`, but only the `Date` header in `_headers`. Thus why I think this is a http.client issue, and not a urllib3 issue. ---------- components: Library (Lib) messages: 286987 nosy: gboudreau priority: normal severity: normal status: open title: http.client: missing response headers when malformed header is part of the response type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:46:49 2017 From: report at bugs.python.org (lamby) Date: Sat, 04 Feb 2017 20:46:49 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486241209.68.0.245134566211.issue29431@psf.upfronthosting.co.za> lamby added the comment: > ordering of namespace dict and kwargs dict are language spec for 3.6 Are they really _specced_ for 3.6? I was under the impression that it was just an implementation detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:53:01 2017 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 04 Feb 2017 20:53:01 +0000 Subject: [issue18069] Subprocess searches special directories before PATH on Windows In-Reply-To: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za> Message-ID: <1486241581.87.0.899266585128.issue18069@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:58:07 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 20:58:07 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <20170204205804.96794.92570.5ADD4A93@psf.io> Roundup Robot added the comment: New changeset 4e65d6c20dae by Serhiy Storchaka in branch '3.5': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://hg.python.org/cpython/rev/4e65d6c20dae New changeset 393969776989 by Serhiy Storchaka in branch '3.6': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://hg.python.org/cpython/rev/393969776989 New changeset 476b0fa34db4 by Serhiy Storchaka in branch 'default': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://hg.python.org/cpython/rev/476b0fa34db4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:58:55 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Feb 2017 20:58:55 +0000 Subject: [issue29445] http.client: missing response headers when malformed header is part of the response In-Reply-To: <1486240193.44.0.0804410028853.issue29445@psf.upfronthosting.co.za> Message-ID: <1486241935.84.0.431510994912.issue29445@psf.upfronthosting.co.za> R. David Murray added the comment: This appears to be a duplicate of issue 24363. Does the patch there fix the problem for you? ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> httplib fails to handle semivalid HTTP headers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:59:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 20:59:58 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486241998.85.0.704439561413.issue29444@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 21:00:28 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486242028.19.0.0856152004366.issue29444@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 83d13325dec591676eeafb12a4caa01a67ef2f7e by Serhiy Storchaka in branch 'master': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/83d13325dec591676eeafb12a4caa01a67ef2f7e New changeset 929374345586086c9860a3937b275511dcc8185a by Serhiy Storchaka in branch 'master': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/929374345586086c9860a3937b275511dcc8185a New changeset e0a10190f88e474a159da92b7b5be472e0d7f325 by Serhiy Storchaka in branch 'master': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/e0a10190f88e474a159da92b7b5be472e0d7f325 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 21:00:31 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486242031.43.0.344233486135.issue29444@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 83d13325dec591676eeafb12a4caa01a67ef2f7e by Serhiy Storchaka in branch '3.6': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/83d13325dec591676eeafb12a4caa01a67ef2f7e New changeset 929374345586086c9860a3937b275511dcc8185a by Serhiy Storchaka in branch '3.6': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/929374345586086c9860a3937b275511dcc8185a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 21:00:33 +0000 Subject: [issue29444] Out-of-bounds buffer access in match_getslice_by_index In-Reply-To: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> Message-ID: <1486242033.19.0.344353419906.issue29444@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 83d13325dec591676eeafb12a4caa01a67ef2f7e by Serhiy Storchaka in branch '3.5': Issue #29444: Fixed out-of-bounds buffer access in the group() method of https://github.com/python/cpython/commit/83d13325dec591676eeafb12a4caa01a67ef2f7e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:02:37 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sat, 04 Feb 2017 21:02:37 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486242157.53.0.265263592215.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Marco, thank you for the suggestion of a howto. That is a good idea. In parallel, I was thinking of some howto content that I would like to see documented. ? How to decide what to test with doctests and what with unittests. I have a feeling that the sweet spot of doctests is functionality which you can invoke in one line, and which produces one line of output which you can match against a reference string. If it takes many lines to set up, or invoke, or checking for correctness is more than a test for string equality, then maybe unittest is a better tool. ? An effective way to write doctests. I suspect that some people write doctests by exercising the functionality in Python's interactive mode, then copy and paste the transcript from that session to the doctests. I don't do it that way, I author in the docstring. Maybe I'm not doing it the best way. ? How to author doctests so that they both prove the module correct, and provide clear and readable documentation. I imagine some effective tests for edge cases and error conditions are important to have, but are not readable documentation. Maybe such tests belong in a unittest framework instead of as doctests. ? How to run doctests from a unittest harness (your earlier note about the unittest API would be a part of this). A problem for me is that I think I don't have the experience and wisdom to give good advice in these areas. I would be happy to start such a howto, and to accept feedback, and to edit it into good prose. I would need wiser people to contribute good ideas for the howto. Also, Marco, thank you for being willing to review a patch. That is helpful. My next step is to check out the documentation source, to be in a position to make a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:03:51 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 21:03:51 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH In-Reply-To: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> Message-ID: <1486242231.51.0.562208726894.issue29443@psf.upfronthosting.co.za> Steve Dower added the comment: I consider this another vote against putting the check box on the front page of the installer, rather than a positive vote for any particular change. There's no way to miss the screen with the real checkbox when you are modifying the install, and modifying PATH from any installer is not recommended in any case. The py.exe launcher is recommended on Windows, or modifying your PATH for a console session rather than globally (granted, we don't offer much to help in the latter case other than the activate script for virtual environments, but I'm open to ideas). Adding check boxes in random places in the installer or changing buttons from their conventional text is not going to happen (on my watch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:04:09 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 21:04:09 +0000 Subject: [issue29443] Re-running Windows installer should have option to set PATH In-Reply-To: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> Message-ID: <1486242249.5.0.192186380614.issue29443@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:24:25 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Feb 2017 21:24:25 +0000 Subject: [issue29446] Improve tkinter 'import *' situation Message-ID: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Tkinter naming was designed so that 'from tkinter import *' can work, in the sense of not conflicting with built-in and stdlib module names. But there are currently two problems. 1. The current doc ...to use Tkinter all you need is a simple import statement: import tkinter Or, more often: from tkinter import * over-promotes 'import *' as the common and therefore normal import (as opposed to a convenience for interactive use). It neglects the alternatives 'import tkinter as tk' or 'from tkinter import Tk, ...', and consequently makes no mention of the relative advantages. 2. The current code does not define __all__. So the stdlib imports of enum, re, and sys get carried over with 'import *'. Guido recommends defining __all__ to prevent this.* Since tkinter defines about 160 names, and since there are only 3 names to block, and there are used pretty sparingly, I prefer the uglier alternative of renaming with underscores: 'import enum as _enum', etc. I will work on patches. Since the doc change can apply to all current versions while the code change might be restricted to 3.7, I will keep then separate. * From pydev thread 'Imports with underscores', 2017-1-9: "I would focus on changing habits to discourage "import *" rather than uglifying all new code with this "os as _os" pattern. Very occasionally one designs a module to explicitly support "import *", and that usually entails using __all__ (like it or not), making the problem go away without uglifying the code." ---------- components: Tkinter messages: 286996 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: test needed status: open title: Improve tkinter 'import *' situation type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:38:32 2017 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Feb 2017 21:38:32 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486244312.46.0.983040983906.issue29446@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 17:20:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Feb 2017 22:20:40 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486246840.74.0.0772002266665.issue29446@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is yet one name that doesn't make sense to import -- wantobjects. It can't be renamed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 17:39:42 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 22:39:42 +0000 Subject: [issue29409] Implement PEP 529 for io.FileIO In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za> Message-ID: <1486247982.53.0.624912171137.issue29409@psf.upfronthosting.co.za> Steve Dower added the comment: Merging this in now, along with a few other patches. This is the test I'm adding, in case anyone spots any problems with it before I push (copied from the test for pure-ASCII bytes): @unittest.skipIf(sys.getfilesystemencoding() != 'utf-8', "test only works for utf-8 filesystems") def testUtf8BytesOpen(self): # Opening a UTF-8 bytes filename try: fn = TESTFN_UNICODE.encode("utf-8") except UnicodeEncodeError: self.skipTest('could not encode %r to utf-8' % TESTFN_UNICODE) f = self.FileIO(fn, "w") try: f.write(b"abc") f.close() with open(TESTFN_UNICODE, "rb") as f: self.assertEqual(f.read(), b"abc") finally: os.unlink(TESTFN_UNICODE) ---------- assignee: -> steve.dower stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 17:57:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 22:57:24 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <20170204225721.26385.59931.59E2D8B9@psf.io> Roundup Robot added the comment: New changeset 8061d0967988 by Steve Dower in branch '3.5': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://hg.python.org/cpython/rev/8061d0967988 New changeset 3de58a54ed98 by Steve Dower in branch '3.6': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://hg.python.org/cpython/rev/3de58a54ed98 New changeset 09c018897fb3 by Steve Dower in branch 'default': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://hg.python.org/cpython/rev/09c018897fb3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 17:57:46 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 22:57:46 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1486249066.9.0.815249423189.issue29416@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:00:25 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1486249225.98.0.169530883391.issue29416@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 661c40ba59855ebe4967424fcabd41be6f799137 by Steve Dower in branch 'master': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/661c40ba59855ebe4967424fcabd41be6f799137 New changeset 77da63372461ddeb82dbfdef86e702e43e24e1da by Steve Dower in branch 'master': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/77da63372461ddeb82dbfdef86e702e43e24e1da New changeset c05ffe646dc009c01365db917f0ca6b738fda69b by Steve Dower in branch 'master': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/c05ffe646dc009c01365db917f0ca6b738fda69b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:00:28 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1486249228.79.0.684070897076.issue29416@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 661c40ba59855ebe4967424fcabd41be6f799137 by Steve Dower in branch '3.6': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/661c40ba59855ebe4967424fcabd41be6f799137 New changeset 77da63372461ddeb82dbfdef86e702e43e24e1da by Steve Dower in branch '3.6': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/77da63372461ddeb82dbfdef86e702e43e24e1da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:00:30 +0000 Subject: [issue29416] Path.mkdir can get into a recursive error loop In-Reply-To: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> Message-ID: <1486249230.58.0.582753156479.issue29416@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 661c40ba59855ebe4967424fcabd41be6f799137 by Steve Dower in branch '3.5': Issue #29416: Prevent infinite loop in pathlib.Path.mkdir https://github.com/python/cpython/commit/661c40ba59855ebe4967424fcabd41be6f799137 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:06:04 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:06:04 +0000 Subject: [issue29392] msvcrt.locking crashes python In-Reply-To: <1485797426.48.0.513516354213.issue29392@psf.upfronthosting.co.za> Message-ID: <20170204230601.128178.73486.9BA25E95@psf.io> Roundup Robot added the comment: New changeset f48bdcd02b57 by Steve Dower in branch '3.5': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://hg.python.org/cpython/rev/f48bdcd02b57 New changeset 15bbb18d87fd by Steve Dower in branch '3.6': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://hg.python.org/cpython/rev/15bbb18d87fd New changeset fb6a48fa8da3 by Steve Dower in branch 'default': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://hg.python.org/cpython/rev/fb6a48fa8da3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:06:24 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 23:06:24 +0000 Subject: [issue29392] msvcrt.locking crashes python In-Reply-To: <1485797426.48.0.513516354213.issue29392@psf.upfronthosting.co.za> Message-ID: <1486249584.01.0.53905697938.issue29392@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:14:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:14:35 +0000 Subject: [issue29409] Implement PEP 529 for io.FileIO In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za> Message-ID: <20170204231432.7410.42451.71667815@psf.io> Roundup Robot added the comment: New changeset 0bf72810f8ea by Steve Dower in branch '3.6': Issue #29409: Implement PEP 529 for io.FileIO (Patch by Eryk Sun) https://hg.python.org/cpython/rev/0bf72810f8ea New changeset a5538734cc87 by Steve Dower in branch 'default': Merge issue #28164 and issue #29409 https://hg.python.org/cpython/rev/a5538734cc87 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:14:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:14:35 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <20170204231432.7410.57724.D229DB84@psf.io> Roundup Robot added the comment: New changeset ed0c05c739c9 by Steve Dower in branch '3.6': Issue #28164: Correctly handle special console filenames (patch by Eryk Sun) https://hg.python.org/cpython/rev/ed0c05c739c9 New changeset a5538734cc87 by Steve Dower in branch 'default': Merge issue #28164 and issue #29409 https://hg.python.org/cpython/rev/a5538734cc87 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:15:27 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 23:15:27 +0000 Subject: [issue29409] Implement PEP 529 for io.FileIO In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za> Message-ID: <1486250127.52.0.126289659743.issue29409@psf.upfronthosting.co.za> Steve Dower added the comment: Committed, but I'll leave this open for a bit in case anyone wants to comment on the commit. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:20:09 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:20:09 +0000 Subject: [issue29326] Blank lines in ._pth file are not ignored In-Reply-To: <1484844872.11.0.819349056222.issue29326@psf.upfronthosting.co.za> Message-ID: <20170204232006.25629.79062.F7990263@psf.io> Roundup Robot added the comment: New changeset 54fea351e3f9 by Steve Dower in branch '3.6': Issue #29326: Ignores blank lines in ._pth files (Patch by Alexey Izbyshev) https://hg.python.org/cpython/rev/54fea351e3f9 New changeset a0ff777ab153 by Steve Dower in branch 'default': Issue #29326: Ignores blank lines in ._pth files (Patch by Alexey Izbyshev) https://hg.python.org/cpython/rev/a0ff777ab153 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:20:32 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 23:20:32 +0000 Subject: [issue29326] Blank lines in ._pth file are not ignored In-Reply-To: <1484844872.11.0.819349056222.issue29326@psf.upfronthosting.co.za> Message-ID: <1486250432.55.0.905672606541.issue29326@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:41:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Feb 2017 23:41:34 +0000 Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za> Message-ID: <20170204234131.26385.85901.D092099C@psf.io> Roundup Robot added the comment: New changeset c6506f759db1 by Steve Dower in branch '3.5': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://hg.python.org/cpython/rev/c6506f759db1 New changeset 0965e2967056 by Steve Dower in branch '3.6': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://hg.python.org/cpython/rev/0965e2967056 New changeset d0f28ee3affe by Steve Dower in branch 'default': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://hg.python.org/cpython/rev/d0f28ee3affe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:43:35 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 23:43:35 +0000 Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za> Message-ID: <1486251815.04.0.810024695358.issue29319@psf.upfronthosting.co.za> Steve Dower added the comment: That change fixes overwriting sys.path[0], the new logic is essentially: try: sys_path0 = sys.path[0] except: sys.path.append(argv0) else: if sys_path0: sys.path.insert(0, argv0) else: sys.path[0] = argv0 I'm leaving this open for the better API fix for 3.7. ---------- versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 18:54:50 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Feb 2017 23:54:50 +0000 Subject: [issue26876] Extend MSVCCompiler class to respect environment variables In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za> Message-ID: <1486252490.15.0.155700662938.issue26876@psf.upfronthosting.co.za> Steve Dower added the comment: Taking another look at the patch, I'm not real keen on the C/LDFLAGS section. I think if we want to support setting these, we should fully override the default settings (otherwise you can't specify certain options that are in the defaults), and avoid splitting them (which probably means changing the spawn() call to not quote arguments - right now the .split() logic is just wrong). I'm sorry this is tough to get together - the distutils compilers are really fragile, which is why we would really rather migrate people off them onto some other build framework. Right now though, that framework doesn't exist. (One potential starting point is my msbuildcompiler at https://github.com/zooba/pyfindvs/tree/master/pyfindvs/msbuildcompiler will generate a .vcxproj file and build it, which allows much more reliable behaviour for options and detecting installs.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:29 +0000 Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za> Message-ID: <1486252829.13.0.817932746857.issue29319@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset baa426f44b86fb146dc17178f61b53ed5ffb08f0 by Steve Dower in branch '3.5': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/baa426f44b86fb146dc17178f61b53ed5ffb08f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:29 +0000 Subject: [issue29392] msvcrt.locking crashes python In-Reply-To: <1485797426.48.0.513516354213.issue29392@psf.upfronthosting.co.za> Message-ID: <1486252829.3.0.00684051372974.issue29392@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 by Steve Dower in branch '3.5': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:31 +0000 Subject: [issue29326] Blank lines in ._pth file are not ignored In-Reply-To: <1484844872.11.0.819349056222.issue29326@psf.upfronthosting.co.za> Message-ID: <1486252831.17.0.330661738001.issue29326@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6d90b135e36c5b2794a29f650ebebf8bbd96f3fb by Steve Dower in branch 'master': Issue #29326: Ignores blank lines in ._pth files (Patch by Alexey Izbyshev) https://github.com/python/cpython/commit/6d90b135e36c5b2794a29f650ebebf8bbd96f3fb New changeset 3ba099c135cdbced6c2ff168a90a689a83b376db by Steve Dower in branch 'master': Issue #29326: Ignores blank lines in ._pth files (Patch by Alexey Izbyshev) https://github.com/python/cpython/commit/3ba099c135cdbced6c2ff168a90a689a83b376db ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:31 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486252831.47.0.940603001152.issue28164@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 164fc49825081694c9c44c4a17c75b30c5ba8f51 by Steve Dower in branch 'master': Issue #28164: Correctly handle special console filenames (patch by Eryk Sun) https://github.com/python/cpython/commit/164fc49825081694c9c44c4a17c75b30c5ba8f51 New changeset 965f8d68a8dcc2ebb2480fe7e9121ac7efdee54e by Steve Dower in branch 'master': Merge issue #28164 and issue #29409 https://github.com/python/cpython/commit/965f8d68a8dcc2ebb2480fe7e9121ac7efdee54e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:31 +0000 Subject: [issue29409] Implement PEP 529 for io.FileIO In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za> Message-ID: <1486252831.61.0.394709372999.issue29409@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset fe7e868bad5bffaf863c80fa2bcc4e3bf87a413a by Steve Dower in branch 'master': Issue #29409: Implement PEP 529 for io.FileIO (Patch by Eryk Sun) https://github.com/python/cpython/commit/fe7e868bad5bffaf863c80fa2bcc4e3bf87a413a New changeset 965f8d68a8dcc2ebb2480fe7e9121ac7efdee54e by Steve Dower in branch 'master': Merge issue #28164 and issue #29409 https://github.com/python/cpython/commit/965f8d68a8dcc2ebb2480fe7e9121ac7efdee54e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:31 +0000 Subject: [issue29392] msvcrt.locking crashes python In-Reply-To: <1485797426.48.0.513516354213.issue29392@psf.upfronthosting.co.za> Message-ID: <1486252831.7.0.025125365049.issue29392@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 by Steve Dower in branch 'master': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 New changeset ed8b523b9f6495806a38262ca9d1676bf7d5e830 by Steve Dower in branch 'master': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/ed8b523b9f6495806a38262ca9d1676bf7d5e830 New changeset 01c3bdbb25068e7558ff8f275d0ed22c9f4e6b32 by Steve Dower in branch 'master': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/01c3bdbb25068e7558ff8f275d0ed22c9f4e6b32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:31 +0000 Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za> Message-ID: <1486252831.82.0.440906886645.issue29319@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset baa426f44b86fb146dc17178f61b53ed5ffb08f0 by Steve Dower in branch 'master': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/baa426f44b86fb146dc17178f61b53ed5ffb08f0 New changeset 5003ad354c6ffd33fa71537a0b33c7f0e17d0093 by Steve Dower in branch 'master': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/5003ad354c6ffd33fa71537a0b33c7f0e17d0093 New changeset a4c1827b15cc8309b4b375db33ee2d85c49475c8 by Steve Dower in branch 'master': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/a4c1827b15cc8309b4b375db33ee2d85c49475c8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:34 +0000 Subject: [issue29326] Blank lines in ._pth file are not ignored In-Reply-To: <1484844872.11.0.819349056222.issue29326@psf.upfronthosting.co.za> Message-ID: <1486252834.25.0.830063529629.issue29326@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6d90b135e36c5b2794a29f650ebebf8bbd96f3fb by Steve Dower in branch '3.6': Issue #29326: Ignores blank lines in ._pth files (Patch by Alexey Izbyshev) https://github.com/python/cpython/commit/6d90b135e36c5b2794a29f650ebebf8bbd96f3fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:34 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486252834.45.0.301337962505.issue28164@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 164fc49825081694c9c44c4a17c75b30c5ba8f51 by Steve Dower in branch '3.6': Issue #28164: Correctly handle special console filenames (patch by Eryk Sun) https://github.com/python/cpython/commit/164fc49825081694c9c44c4a17c75b30c5ba8f51 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:34 +0000 Subject: [issue29409] Implement PEP 529 for io.FileIO In-Reply-To: <1485918380.71.0.564330613462.issue29409@psf.upfronthosting.co.za> Message-ID: <1486252834.55.0.689393109594.issue29409@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset fe7e868bad5bffaf863c80fa2bcc4e3bf87a413a by Steve Dower in branch '3.6': Issue #29409: Implement PEP 529 for io.FileIO (Patch by Eryk Sun) https://github.com/python/cpython/commit/fe7e868bad5bffaf863c80fa2bcc4e3bf87a413a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:34 +0000 Subject: [issue29392] msvcrt.locking crashes python In-Reply-To: <1485797426.48.0.513516354213.issue29392@psf.upfronthosting.co.za> Message-ID: <1486252834.65.0.813287684507.issue29392@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset ed8b523b9f6495806a38262ca9d1676bf7d5e830 by Steve Dower in branch '3.6': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/ed8b523b9f6495806a38262ca9d1676bf7d5e830 New changeset cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 by Steve Dower in branch '3.6': Issue #29392: Prevent crash when passing invalid arguments into msvcrt module. https://github.com/python/cpython/commit/cb0c9718f7bd13df67b0d7df88b6f5b197ef05a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 00:00:34 +0000 Subject: [issue29319] Embedded 3.6.0 distribution cannot run pyz files In-Reply-To: <1484827891.73.0.559570067048.issue29319@psf.upfronthosting.co.za> Message-ID: <1486252834.76.0.152397612816.issue29319@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset baa426f44b86fb146dc17178f61b53ed5ffb08f0 by Steve Dower in branch '3.6': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/baa426f44b86fb146dc17178f61b53ed5ffb08f0 New changeset 5003ad354c6ffd33fa71537a0b33c7f0e17d0093 by Steve Dower in branch '3.6': Issue #29319: Prevent RunMainFromImporter overwriting sys.path[0]. https://github.com/python/cpython/commit/5003ad354c6ffd33fa71537a0b33c7f0e17d0093 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:10:37 2017 From: report at bugs.python.org (Guillaume Boudreau) Date: Sun, 05 Feb 2017 00:10:37 +0000 Subject: [issue29445] http.client: missing response headers when malformed header is part of the response In-Reply-To: <1486240193.44.0.0804410028853.issue29445@psf.upfronthosting.co.za> Message-ID: <1486253437.84.0.369173840525.issue29445@psf.upfronthosting.co.za> Guillaume Boudreau added the comment: Yes, indeed. The latest patch in 24363 resolves this issue. Sorry for the duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:11:37 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Feb 2017 00:11:37 +0000 Subject: [issue23462] All os.exec*e variants crash on Windows In-Reply-To: <1423903526.7.0.282245151833.issue23462@psf.upfronthosting.co.za> Message-ID: <1486253497.77.0.693171104943.issue23462@psf.upfronthosting.co.za> Steve Dower added the comment: It's straightforward to detect path->narrow == NULL and raise instead of crashing. We can also trivially check path->wide on Windows and raise with a more specific error. Given it's already fixed for 3.6.0 and there's only one more binary release for 3.5 (and Windows has *very* limited uptake apart from the binary releases), I don't think it's worth making this work given how many versions have been broken in the past. ---------- assignee: -> steve.dower keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file46520/23462_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:14:10 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Feb 2017 00:14:10 +0000 Subject: [issue29232] Quiet Install In-Reply-To: <1484083752.73.0.652797539276.issue29232@psf.upfronthosting.co.za> Message-ID: <1486253650.56.0.909884589216.issue29232@psf.upfronthosting.co.za> Steve Dower added the comment: I think there's something else going on with your install, as I do these frequently and they work fine (modulo issue25166). Can you grab all your log files from your %TEMP% directory and attach them here? I'm keen to see what the installer is trying to do vs. what's actually happening. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:15:18 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Feb 2017 00:15:18 +0000 Subject: [issue29147] registry value to be cleared when python is uninstalled In-Reply-To: <1483505292.36.0.945723017008.issue29147@psf.upfronthosting.co.za> Message-ID: <1486253718.37.0.20655097192.issue29147@psf.upfronthosting.co.za> Steve Dower added the comment: Without logs showing what went wrong, there's nothing we can fix. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 19:30:43 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Feb 2017 00:30:43 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486254643.89.0.773882854161.issue28164@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like the "need to check Win7" part was actually important... there are buildbot failures from this. I *think* they only require test handling updates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 20:14:25 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Feb 2017 01:14:25 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486257265.9.0.125662561205.issue29446@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This issue is spun-off from #29162, which was about idlelib.pyshell depending on import * importing sys. 'wantobjects' does not have the same bug potential as stdlib imports. But, Serhiy, if you care about it or otherwise prefer __all__, __all__ = [name for name in globals() if not name.startswith('_') and name not in {'enum', 're', 'sys', 'wantobjects'}] should work if placed near the end of the file, just before 'def _test'. Except for the exclusion set, I presume that 'import *' does essentially the same iteration ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 20:28:01 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 01:28:01 +0000 Subject: [issue28489] Fix comment in tokenizer.c In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za> Message-ID: <20170205012756.7410.78101.55083777@psf.io> Roundup Robot added the comment: New changeset 8b20ed083a94 by Berker Peksag in branch '3.6': Issue #28489: Fix comment in tokenizer.c https://hg.python.org/cpython/rev/8b20ed083a94 New changeset 72ec2c599301 by Berker Peksag in branch 'default': Issue #28489: Merge from 3.6 https://hg.python.org/cpython/rev/72ec2c599301 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 20:30:16 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Feb 2017 01:30:16 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486258216.13.0.937969608338.issue28164@psf.upfronthosting.co.za> Steve Dower added the comment: Okay, seems like Windows 7 GetFullPathName on conin$ and conout$ returns the path appended to the current directory, and you need to specify the full name as "conin$" or "conout$" to access the console - otherwise you have a file by that name. We should include a comparison for these names exactly before using GetFullPathName. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 20:30:32 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Feb 2017 01:30:32 +0000 Subject: [issue28489] Fix comment in tokenizer.c In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za> Message-ID: <1486258232.71.0.643824621079.issue28489@psf.upfronthosting.co.za> Berker Peksag added the comment: I've applied Ryan's patch since it's been sitting in the 'commit review' queue. Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 21:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 02:00:23 +0000 Subject: [issue28489] Fix comment in tokenizer.c In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za> Message-ID: <1486260023.41.0.406345902912.issue28489@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset bc2b2193520cea1adc44d27c9f7721fc6ad37293 by Berker Peksag in branch '3.6': Issue #28489: Fix comment in tokenizer.c https://github.com/python/cpython/commit/bc2b2193520cea1adc44d27c9f7721fc6ad37293 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 21:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 02:00:25 +0000 Subject: [issue28489] Fix comment in tokenizer.c In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za> Message-ID: <1486260025.31.0.052700798951.issue28489@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset bc2b2193520cea1adc44d27c9f7721fc6ad37293 by Berker Peksag in branch 'master': Issue #28489: Fix comment in tokenizer.c https://github.com/python/cpython/commit/bc2b2193520cea1adc44d27c9f7721fc6ad37293 New changeset 9babb676a3c143099ab548ccc72c1ee897335e84 by Berker Peksag in branch 'master': Issue #28489: Merge from 3.6 https://github.com/python/cpython/commit/9babb676a3c143099ab548ccc72c1ee897335e84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 21:51:53 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 05 Feb 2017 02:51:53 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486263113.09.0.544468366756.issue29431@psf.upfronthosting.co.za> INADA Naoki added the comment: see https://mail.python.org/pipermail/python-dev/2016-September/146348.html kwargs, __duct__, and namespace passed to metaclass are ordered by language design. order of other dicts are implementation detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 22:59:36 2017 From: report at bugs.python.org (irdb) Date: Sun, 05 Feb 2017 03:59:36 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1486267176.54.0.458617809977.issue14965@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 23:13:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 05 Feb 2017 04:13:21 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486268001.05.0.924105534313.issue29438@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- keywords: +patch Added file: http://bugs.python.org/file46521/29438-sharedkey-useafterfree-py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:37:41 2017 From: report at bugs.python.org (Marco Buttu) Date: Sun, 05 Feb 2017 05:37:41 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486273061.94.0.165151539995.issue29428@psf.upfronthosting.co.za> Marco Buttu added the comment: > In parallel, I was thinking of some howto content that I would like to > see documented. Great :-) > How to decide what to test with doctests and what with unittests. > I have a feeling that the sweet spot of doctests is functionality > which you can invoke in one line, and which produces one line of > output which you can match against a reference string. If it takes > many lines to set up, or invoke, or checking for correctness is > more than a test for string equality, then maybe unittest is a > better tool. All your questions come up every time I speak about doctest, and these doubts are the main reason for my previous sentence: "there is more to say [about doctest] than only the API". That is why IMO an howto could be really helpful. What doctest checks is not one line of output, but the output as a string, and of course it could have multiple lines. Try to execute the doctest (with the -v option) for this docstring: def foo(): """ >>> a = 33 >>> a 33 >>> for i in range(2): ... print(i) ... 0 1 """ Three tests will be executed: one for `a=33`, expecting nothing, one for `a`, expecting 33 as output, and one test for the whole `for` block, expecting one output composed of two lines. For several reasons IMO doctest is not a substitute for unittest. They are different tools for different purposes, as thier name point up. To have a wide view, usually it is a good idea to start from the beginning: https://groups.google.com/forum/#!msg/comp.lang.python/DfzH5Nrt05E/Yyd3s7fPVxwJ Anyway, IMO this is not the right place to discuss and explain the objectives of doctest. I propose you to open a repository on github, work and discuss there, and when all is ready, we can ask for a review. Please write here the link to the github repo, so anyone else wants to contribute can find it. Thanks again for your time ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:39:42 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Feb 2017 05:39:42 +0000 Subject: [issue29447] Add os.PathLike support to the tempfile module Message-ID: <1486273182.96.0.640027026479.issue29447@psf.upfronthosting.co.za> New submission from Brett Cannon: The various classes in the tempfile module could implement os.PathLike. ---------- components: Library (Lib) messages: 287036 nosy: brett.cannon priority: normal severity: normal status: open title: Add os.PathLike support to the tempfile module type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:41:24 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Feb 2017 05:41:24 +0000 Subject: [issue29448] Implement os.Pathlike for importlib.machinery Message-ID: <1486273284.58.0.20381224055.issue29448@psf.upfronthosting.co.za> New submission from Brett Cannon: Various classes in importlib.machinery define a 'path' attribute which could also be exposed through the os.PathLike interface. ---------- components: Library (Lib) messages: 287037 nosy: brett.cannon priority: normal severity: normal status: open title: Implement os.Pathlike for importlib.machinery _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:59:16 2017 From: report at bugs.python.org (Marco Buttu) Date: Sun, 05 Feb 2017 05:59:16 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486274356.01.0.0590348536808.issue29441@psf.upfronthosting.co.za> Marco Buttu added the comment: The patch is OK to me. I also executed the examples, and everything works fine :-) ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 02:37:48 2017 From: report at bugs.python.org (Jyotirmoy Bhattacharya) Date: Sun, 05 Feb 2017 07:37:48 +0000 Subject: [issue29449] clear() should return prior state in threading.Event Message-ID: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> New submission from Jyotirmoy Bhattacharya: The clear() method for Event objects currently does not return anything. It would be useful to have it return the state of the Event prior to it being cleared. This would be useful since multiple threads may wake up from an event at the same time and all may try to clear() the event. A return value from clear will indicate to a thread if it won the race to clear the event. ---------- components: Library (Lib) messages: 287039 nosy: jmoy priority: normal severity: normal status: open title: clear() should return prior state in threading.Event type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 03:00:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 08:00:25 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486281625.33.0.077980230801.issue24905@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry Aviv, I just forget about this issue. Added new comments on Rietveld. Many lines in sqlite3.rst still are too long. It would be worth to ask other developers about wanted interface. ---------- stage: -> patch review versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 03:06:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 08:06:09 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486281969.77.0.488599095201.issue29446@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 04:44:20 2017 From: report at bugs.python.org (Omar Sandoval) Date: Sun, 05 Feb 2017 09:44:20 +0000 Subject: [issue29450] xattr functions aren't in os.supports_fd, os.supports_follow_symlinks Message-ID: <1486287860.62.0.802712636976.issue29450@psf.upfronthosting.co.za> New submission from Omar Sandoval: {get,list,remove,set}xattr all support fds and follow_symlinks, but they are not in the os.supports_fds and os.supports_follow_symlinks sets. The attached patch adds them. There are no HAVE_* features for the f and l variants of these syscalls since it's an all-or-nothing thing, so we always add them if the functions are defined. ---------- components: Extension Modules files: xattrsupports.patch keywords: patch messages: 287042 nosy: Omar Sandoval, benjamin.peterson priority: normal severity: normal status: open title: xattr functions aren't in os.supports_fd, os.supports_follow_symlinks type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46522/xattrsupports.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:09:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 10:09:13 +0000 Subject: [issue29451] Use _PyArg_Parser for _PyArg_ParseStack(): support positional only arguments Message-ID: <1486289353.72.0.801621994712.issue29451@psf.upfronthosting.co.za> New submission from STINNER Victor: Serhiy Storshaka wrote a kind of cache for PyArg_ParseTupleAndKeywords(): _PyArg_Parser structure used by _PyArg_ParseTupleAndKeywordsFast(). It makes argument parser much faster. Would it be possible to modify it to be able to use it in _PyArg_ParseStack(). (Would it be faster?) See also issue #29419 "Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)?" for a different kind of optimization. ---------- components: Interpreter Core messages: 287043 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Use _PyArg_Parser for _PyArg_ParseStack(): support positional only arguments type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:09:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 10:09:27 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate Message-ID: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch changes index(), insert() and rotate() functions of the collections.deque type to use FASTCALL calling convention. I chose to only modify these functions since they use METH_VARARGS which requires to create a temporary tuple, whereas other functions use METH_NOARGS or METH_O which is already fast ;-) I know that Raymond, maintainer of the collections module, is not a big fan of Argument Clinic ;-) So I wrote the minimum change and chose to not use Argument Clinic yet. By the way, the index() method has the signature "D.index(value, [start, [stop]])" which is not supported by Argument Clinic yet: see issue #29299. For these reasons, I propose to wait to convert collections.deque to Argument Clinic, it can be done later. Ok, now the cool part: it makes these methods faster ;-) * d.rotate(): 1.10x faster * d.rotate(1): 1.24x faster * d.insert(): 1.18x faster * d.index(): 1.24x faster $ ./python -m perf timeit -s 'import collections; d=collections.deque()' 'd.rotate()' --compare-to=../default-ref/python Median +- std dev: [ref] 70.5 ns +- 0.9 ns -> [patch] 64.2 ns +- 0.3 ns: 1.10x faster (-9%) $ ./python -m perf timeit -s 'import collections; d=collections.deque()' 'd.rotate(1)' --compare-to=../default-ref/python Median +- std dev: [ref] 107 ns +- 1 ns -> [patch] 86.2 ns +- 1.1 ns: 1.24x faster (-20%) $ ./python -m perf timeit -s 'import collections' 'd=collections.deque(); d.insert(0, None); d.insert(1, None); d.insert(2, None); d.insert(3, None); d.insert(4, None)' --compare-to=../default-ref/python -p3 Median +- std dev: [ref] 699 ns +- 6 ns -> [patch] 591 ns +- 5 ns: 1.18x faster (-15%) $ ./python -m perf timeit -s 'import collections; d=collections.deque((None,))' 'd.index(None)' --compare-to=../default-ref/python Median +- std dev: [ref] 115 ns +- 1 ns -> [patch] 92.5 ns +- 0.8 ns: 1.24x faster (-19%) ---------- files: deque.patch keywords: patch messages: 287044 nosy: haypo, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Use FASTCALL for collections.deque methods: index, insert, rotate type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46523/deque.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:10:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 10:10:01 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486289401.66.0.405963494821.issue29452@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:39:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 10:39:10 +0000 Subject: [issue29451] Use _PyArg_Parser for _PyArg_ParseStack(): support positional only arguments In-Reply-To: <1486289353.72.0.801621994712.issue29451@psf.upfronthosting.co.za> Message-ID: <1486291150.57.0.0165817334629.issue29451@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't think it would be faster. But it is possible to get rid of some code duplication at the cost of making it slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 07:30:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 12:30:26 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486297826.57.0.520006003921.issue29452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think _PyArg_NoStackKeywords() should be called before _PyArg_ParseStack(), otherwise this can cause not correct error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 07:56:11 2017 From: report at bugs.python.org (Eryk Sun) Date: Sun, 05 Feb 2017 12:56:11 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486299371.53.0.681136526697.issue28164@psf.upfronthosting.co.za> Eryk Sun added the comment: It's an ugly inconsistency that GetFullPathName fails for bare CONIN$ and CONOUT$ prior to Windows 8, in that it gives a different result from simply passing those names to CreateFile. Anyway, thanks for modifying it to work correctly in this case. We should test that _WindowsConsoleIO isn't used on Windows 7 and earlier when accessing CONIN$ or CONOUT$ in a directory. How about the following? temp_path = tempfile.mkdtemp() self.addCleanup(support.rmtree, temp_path) conout_path = os.path.join(temp_path, 'CONOUT$') with open(conout_path, 'wb', buffering=0) as f: if sys.getwindowsversion()[:2] > (6, 1): self.assertIsInstance(f, ConIO) else: self.assertNotIsInstance(f, ConIO) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:17:27 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sun, 05 Feb 2017 15:17:27 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial Message-ID: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: Removes `keys = sorted(keywords.keys())` from function example and removes the text that describes why this was necessary. As per PEP 468, this note is obsolete for 3.6+ Also changes the ordering of the function call to match the previous output. ---------- assignee: docs at python components: Documentation files: controlflowdiff.patch keywords: patch messages: 287048 nosy: Jim Fasarakis-Hilliard, docs at python priority: normal severity: normal status: open title: Remove reference to undefined dictionary ordering in Tutorial versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46524/controlflowdiff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:28:28 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 05 Feb 2017 15:28:28 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486308508.98.0.736498829852.issue29453@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:35:45 2017 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 05 Feb 2017 15:35:45 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486308945.78.0.976579569924.issue29446@psf.upfronthosting.co.za> Eric V. Smith added the comment: Instead of: __all__ = [name for name in globals() if not name.startswith('_') and name not in {'enum', 're', 'sys', 'wantobjects'}] Maybe this would be less fragile: import types __all__ = [name for name, obj in globals().items() if not name.startswith('_') and not isinstance(obj, types.ModuleType) and name not in {'wantobjects'}] That is, exclude all modules. Admittedly, I had to import types, but there are other ways to do this test without that import. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:42:37 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 05 Feb 2017 15:42:37 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486309357.48.0.195512427359.issue29453@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:44:32 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Feb 2017 15:44:32 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486309472.9.0.718441920463.issue29453@psf.upfronthosting.co.za> R. David Murray added the comment: It is not (yet) a language requirement that ordinary dictionaries be ordered. This patch may become appropriate in 3.7, but that has not yet been determined. It is not appropriate for 3.6. In 3.6, the order of keys in an ordinary dictionary is still undefined, even though it is in practice consistent in CPython. ---------- nosy: +r.david.murray versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:45:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 15:45:37 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1486309537.03.0.853810781799.issue29446@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This also excludes "constants" implicitly added by importing names from tkinter.constants. I don't know whether this is good or bad. Interesting, but from tkinter import * import tkinter.ttk and import tkinter.ttk from tkinter import * have different effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:56:37 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sun, 05 Feb 2017 15:56:37 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486310197.67.0.00662123551917.issue29453@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Isn't it a language requirement that `**kwargs` be ordered in 3.6, David? PEP 468 states that `**kwargs` is to be an ordered *mapping* and, if I'm not mistaken, that was done in order to not depend on the fact that dicts became ordered. I might have understood something wrong, though :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:01:55 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 05 Feb 2017 16:01:55 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486310515.62.0.382795492665.issue29453@psf.upfronthosting.co.za> Xiang Zhang added the comment: David, actually I have the same thoughts as Jim. Ordered ordinary dicts is not a feature but ordered **kwargs is in 3.6. They seems not the same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:18:38 2017 From: report at bugs.python.org (Tom) Date: Sun, 05 Feb 2017 16:18:38 +0000 Subject: [issue29454] Shutting down consumer on a remote queue Message-ID: <1486311518.72.0.101525789296.issue29454@psf.upfronthosting.co.za> New submission from Tom: Using code adapted from the example in the docs (https://docs.python.org/3/library/multiprocessing.html#using-a-remote-manager), if you create a remote queue server, a producer which puts items in the queue and a consumer which consumes elements from the queue. If the consumer gets killed and restarted again, it misses one item from the queue. For a reproducable example see the stackoverflow reference below. Expected: items stay in the queue until a consumer consumes it Happens: one item still gets consumed from the queue even if after a consumer gets killed Version: Python 3.6.0 OS: Ubuntu 16.10 reference: http://stackoverflow.com/questions/42052248/remote-queue-consumer-misses-first-message-after-restart ---------- messages: 287055 nosy: Semi priority: normal severity: normal status: open title: Shutting down consumer on a remote queue versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:22:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 16:22:18 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486311738.12.0.355400838355.issue29453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would not change the order of keyword arguments, but rather change the output. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:24:48 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sun, 05 Feb 2017 16:24:48 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486311888.91.0.522823895041.issue29453@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: It was a random decision on my part, Serhiy, since I didn't see any difference. Why would you go the other way around? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:33:22 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 16:33:22 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486312402.13.0.325616811319.issue29453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Because it shows preserving the order of keyword arguments (rather than sorting by keyword name). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:41:05 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sun, 05 Feb 2017 16:41:05 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486312865.3.0.598037753052.issue29453@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Indeed, good point. Changed it to the suggested way. ---------- Added file: http://bugs.python.org/file46525/controlflowdiff2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:46:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 16:46:42 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486313202.44.0.653258272161.issue29453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thanks Jim. But maybe it is worth to mention that the output corresponds to the order of passed keyword arguments. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 14:21:01 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Feb 2017 19:21:01 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486322461.6.0.280206264057.issue29453@psf.upfronthosting.co.za> R. David Murray added the comment: You are correct, I didn't read the full context of the diff. My apologies. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 15:59:05 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 20:59:05 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <20170205205902.110213.36085.E4750ADC@psf.io> Roundup Robot added the comment: New changeset 8ccb3ad39ee4 by Serhiy Storchaka in branch 'default': Issue #20186: Regenerated Argument Clinic. https://hg.python.org/cpython/rev/8ccb3ad39ee4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 16:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Feb 2017 21:00:23 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1486328423.81.0.757271914183.issue20186@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 5762cf299f863e06244e6b44ba3a91efee7b35c1 by Serhiy Storchaka in branch 'master': Issue #20186: Regenerated Argument Clinic. https://github.com/python/cpython/commit/5762cf299f863e06244e6b44ba3a91efee7b35c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:13:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 22:13:10 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486332790.96.0.684464487101.issue20185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a set of patches based on issue20185_conglomerate_v4.diff. They are synchronized with current sources. Addressed Martin's comments,converted list.index(), float.__round__() and resource.prlimit() and made other minor changes. ---------- Added file: http://bugs.python.org/file46526/clinic_float_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:13:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 22:13:32 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486332812.25.0.208303724856.issue20185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46527/clinic_list_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:13:49 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 22:13:49 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486332829.33.0.0200004895941.issue20185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46528/clinic_type_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:14:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 22:14:06 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486332846.21.0.513579849284.issue20185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46529/clinic_marshal_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:14:21 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Feb 2017 22:14:21 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1486332861.78.0.0563360532547.issue20185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46530/clinic_resource_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:15:26 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Feb 2017 22:15:26 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486332926.86.0.871971643288.issue29442@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 17:20:19 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Sun, 05 Feb 2017 22:20:19 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486333219.95.0.554705804981.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: Thanks for the CR Serhiy. Attached is a new patch after the fixes from the CR. What other developers should I ask? The interface is file like and is the same as apsw. ---------- Added file: http://bugs.python.org/file46531/blob3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 18:38:17 2017 From: report at bugs.python.org (lamby) Date: Sun, 05 Feb 2017 23:38:17 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486337897.7.0.329746223316.issue29431@psf.upfronthosting.co.za> lamby added the comment: > order of other dicts are implementation detail. Right, exactly :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 18:58:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 23:58:10 +0000 Subject: [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable In-Reply-To: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> Message-ID: <1486339090.24.0.434336545756.issue29431@psf.upfronthosting.co.za> STINNER Victor added the comment: While the use case makes sense, test if an application relies on the dictionary iterating order, I'm not sure that adding an option to change the order. For me, it's a rare and very specific use case, whereas your option is public and "too easy" to find and use. For example, what if a developer decides that its application now requires this option to run? Moreover, your code changes performance critical code. I don't want to get a slowdown here for rare use case, since we spent a lot of time to optimize these functions! I suggest you to try to implement your feature in a dict subtype in a third party module, and try to monkey-patch applications to use your type. Attached hack_dict.py is an example, but it only handles code explicitly calling the "dict()" type to create a dictionray. Another option for you is to maintain your downstream CPython patch, sorry. ---------- nosy: +haypo Added file: http://bugs.python.org/file46532/hack_dict.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 19:00:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 00:00:59 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486339259.52.0.844072332181.issue29452@psf.upfronthosting.co.za> STINNER Victor added the comment: deque-2.patch calls _PyArg_NoStackKeywords() before _PyArg_ParseStack(). ---------- Added file: http://bugs.python.org/file46533/deque-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 20:48:43 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 01:48:43 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486345723.48.0.529012631421.issue24905@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 21:30:05 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 02:30:05 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486348205.5.0.86032537636.issue29453@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 21:36:14 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 02:36:14 +0000 Subject: [issue29454] Shutting down consumer on a remote queue In-Reply-To: <1486311518.72.0.101525789296.issue29454@psf.upfronthosting.co.za> Message-ID: <1486348574.52.0.134036706461.issue29454@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +davin type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 21:47:18 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 02:47:18 +0000 Subject: [issue968063] Add fileinput.islastline() Message-ID: <1486349238.3.0.172123511088.issue968063@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the updated patch, but I'm not sure FileInput class needs a islastline() method. I couldn't find any similar or duplicate feature requests on the tracker after this opened in 2004 (which is a sign that the need for this method is low.) Also, the patch needs some work. Some comments: * There is no documentation changes to Doc/library/fileinput.rst * 'mark' is unused in Lib/fileinput.py * Not sure why we need 't1 = t2 = t3 = None' in tests * We could use self.addCleanup() instead of 'try...finally' * fileinput.islastline() is not tested. We could reuse Test_fileinput_isfirstline. According to commit history of Lib/fileinput.py, Serhiy has done a lot of work in the past few years. I just added him to nosy list to get his feedback. ---------- nosy: +berker.peksag, serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 21:51:04 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 02:51:04 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <20170206025101.110427.92834.2C53E810@psf.io> Roundup Robot added the comment: New changeset 724d1aa7589b by Xiang Zhang in branch 'default': Issue #29405: Make total calculation in _guess_delimiter more accurate. https://hg.python.org/cpython/rev/724d1aa7589b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 21:53:45 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 02:53:45 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486349625.67.0.0886467663002.issue29405@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Milt. I committed with my change not because it's better, but I want to make the change small so others won't get unfamiliar with the new code. :-) ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 22:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 03:00:22 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486350022.82.0.781830263318.issue29405@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6d0a09623155710680ff19f05f279d45c007a304 by Xiang Zhang in branch 'master': Issue #29405: Make total calculation in _guess_delimiter more accurate. https://github.com/python/cpython/commit/6d0a09623155710680ff19f05f279d45c007a304 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 22:15:44 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 03:15:44 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486350944.69.0.966051689536.issue29405@psf.upfronthosting.co.za> Berker Peksag added the comment: > [...] but I want to make the change small so others won't get unfamiliar with the new code. :-) Assuming it doesn't cause any behavior changes, I find Milt's patch simple enough and easier to understand than the version uses 'iteration' variable. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 22:38:39 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 03:38:39 +0000 Subject: [issue29405] improve csv.Sniffer().sniff() behavior In-Reply-To: <1485908785.08.0.552892497325.issue29405@psf.upfronthosting.co.za> Message-ID: <1486352319.34.0.936123921442.issue29405@psf.upfronthosting.co.za> Xiang Zhang added the comment: I am fine with any version (both are simple and not the hardest part to understand in the logic). :-) I have no opinion on which is better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 22:39:07 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Feb 2017 03:39:07 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation Message-ID: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> New submission from Brett Cannon: In the trace module it would be nice to also mention that coverage.py is available. ---------- assignee: docs at python components: Documentation messages: 287075 nosy: brett.cannon, docs at python priority: normal severity: normal status: open title: Mention coverage.py in trace module documentation type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 23:00:55 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 06 Feb 2017 04:00:55 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486353655.22.0.57094943961.issue29371@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi everyone, I made a patch to clarify that "or'ed" here really means "bitwise-OR'ed", and made a reference to the section of the docs about bitwise OR. Please review and let me know if this will work. Thanks. ---------- keywords: +patch Added file: http://bugs.python.org/file46534/issue29371.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 23:01:29 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 06 Feb 2017 04:01:29 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486353689.57.0.459015364044.issue29371@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 23:27:52 2017 From: report at bugs.python.org (Wonsup Yoon) Date: Mon, 06 Feb 2017 04:27:52 +0000 Subject: [issue29456] bug in unicodedata.normalize: u1176 Message-ID: <1486355272.29.0.0894514518656.issue29456@psf.upfronthosting.co.za> New submission from Wonsup Yoon: unicodedata can't normalize(NFC) hangul strings which contain \u1176(HANGUL JUNGSEONG A-O). >>> from unicodedata import normalize >>> normalize("NFC", "\u1100\u1176\u11a8") '?' => should be "\u1100\u1176\u11a8" not '?' (\uae4d) I attached a patch for this issue. (Fixing boundary of modern medial vowels) ---------- components: Unicode files: u1176.patch keywords: patch messages: 287077 nosy: ezio.melotti, haypo, pusnow priority: normal severity: normal status: open title: bug in unicodedata.normalize: u1176 versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file46535/u1176.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 00:21:48 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 05:21:48 +0000 Subject: [issue29456] bug in unicodedata.normalize: u1176 In-Reply-To: <1486355272.29.0.0894514518656.issue29456@psf.upfronthosting.co.za> Message-ID: <1486358508.84.0.385821013029.issue29456@psf.upfronthosting.co.za> Xiang Zhang added the comment: How about the third character's range? The code seems assuming it's [11a7..11c3] while the spec is [11a8..11c2]? >>> unicodedata.normalize("NFC", "\u1100\u1175\u11a7") '?' while it should be '??'? ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 00:47:24 2017 From: report at bugs.python.org (Wonsup Yoon) Date: Mon, 06 Feb 2017 05:47:24 +0000 Subject: [issue29456] bug in unicodedata.normalize: u1176 In-Reply-To: <1486355272.29.0.0894514518656.issue29456@psf.upfronthosting.co.za> Message-ID: <1486360044.44.0.674166261909.issue29456@psf.upfronthosting.co.za> Wonsup Yoon added the comment: I think you are right. The modern final consonants is [11a8..11c2]. I attached another patch for this issue. ---------- Added file: http://bugs.python.org/file46536/u11a7u11c3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:15:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 06:15:55 +0000 Subject: [issue968063] Add fileinput.islastline() Message-ID: <1486361755.08.0.799682119671.issue968063@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is outdated. It uses private _buffer attribute which no longer exist (see issue15068). But even when _buffer was existing the patch was not correct, because _buffer contained only a part of the file. It is possible to implement islastline(), but at the cost of additional buffering. This effectively negates the result of issue15068. The user would need to enter two lines first than fileinput could return the fist one from stdin. And additional complication slows down reading for all users even if they don't need islastline(). If you need islastline() you can use a wrapper: def yield_line_and_islastline(f): try: prevline = next(f) except StopIteration: return for line in f: yield (prevline, f.isfirstline()) prevline = line yield prevline, True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:36:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 06:36:07 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486362967.77.0.245410068123.issue24905@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: apsw has different order of arguments for blobopen(), all arguments are mandatory, and the parameter for read/write mode is called "writeable" rather than "readonly". This part of API needs to be discussed. Ask for discussion on mailing lists: Python-Ideas and maybe Python-List. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:41:40 2017 From: report at bugs.python.org (Hugo Osvaldo Barrera) Date: Mon, 06 Feb 2017 06:41:40 +0000 Subject: [issue29457] strftime('%x') does not use my locale Message-ID: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> New submission from Hugo Osvaldo Barrera: As the the posix spec for strftime: %c The preferred date and time representation for the current locale. %x The preferred date representation for the current locale without the time. However, python doesn't seem to respect this: $ python3.5 -c "from datetime import datetime; print(datetime.now().strftime('%x'))" 02/06/17 $ date +%x # This one is right: 2017-02-06 $ echo $LC_TIME en_DK.UTF-8 * The same applies for '%c'. * The same applies for other python versions. * The same applies regardless of LC_TIME and LANG. * The same applies to time.strftime() * I tried a few different LC_TIME values, with the same result every time. ---------- components: Extension Modules messages: 287082 nosy: hobarrera priority: normal severity: normal status: open title: strftime('%x') does not use my locale type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:45:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 06:45:55 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486363555.83.0.613011715104.issue29452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is simple and technically it looks correct, but I'm not a fan of using FASTCALL outside of Argument Clinic at this stage. The API still can be changed. Fortunately only three deque methods could have a benefit from using FASTCALL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:51:55 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Feb 2017 06:51:55 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486363915.48.0.15160713235.issue29457@psf.upfronthosting.co.za> Martin Panter added the comment: Have you tried enabling the locale with locale.setlocale()? I believe Python only enables LC_CTYPE by default, so other locale aspects like LC_TIME won?t work until they are enabled. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:55:33 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Feb 2017 06:55:33 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486364133.1.0.669836739097.issue29457@psf.upfronthosting.co.za> Martin Panter added the comment: >>> datetime.now().strftime("%x") '02/06/17' >>> from locale import setlocale, LC_TIME >>> setlocale(LC_TIME) 'C' >>> setlocale(LC_TIME, "en_US.utf8") 'en_US.utf8' >>> datetime.now().strftime("%x") '02/06/2017' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:59:10 2017 From: report at bugs.python.org (Eryk Sun) Date: Mon, 06 Feb 2017 06:59:10 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486364350.81.0.678616991183.issue29457@psf.upfronthosting.co.za> Eryk Sun added the comment: As Martin said, you need to set the LC_TIME category using an empty string to use the locale LC_* environment variables. Python 3 sets LC_CTYPE at startup (on Unix platforms only), but LC_TIME is left in the initial C locale: >>> locale.setlocale(locale.LC_CTYPE, None) 'en_DK.UTF-8' >>> locale.setlocale(locale.LC_TIME, None) 'C' >>> time.strftime('%x') '02/06/17' >>> locale.setlocale(locale.LC_TIME, "") 'en_DK.UTF-8' >>> time.strftime('%x') '2017-02-06' ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:11:03 2017 From: report at bugs.python.org (Ammar Askar) Date: Mon, 06 Feb 2017 07:11:03 +0000 Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za> Message-ID: <1486365063.25.0.268151219533.issue29028@psf.upfronthosting.co.za> Ammar Askar added the comment: Did you forget to close this or is this not fixed, Serhiy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:22:14 2017 From: report at bugs.python.org (Hugo Osvaldo Barrera) Date: Mon, 06 Feb 2017 07:22:14 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486365734.75.0.306332832845.issue29457@psf.upfronthosting.co.za> Hugo Osvaldo Barrera added the comment: It would seem that locale.setlocale(locale.LC_TIME, "") fixes the issue. However, there seems to be no mention on this on the relevant documentation page[1], which is actually the source of my confusion. As a "fix" to this issue (since I'm probably not the first nor last person to come across it), can we add a note regarding this below the table in section 8.1.8. [1]: https://docs.python.org/3.6/library/datetime.html#strftime-strptime-behavior ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:27:36 2017 From: report at bugs.python.org (Maciej Obarski) Date: Mon, 06 Feb 2017 07:27:36 +0000 Subject: [issue29458] random.seed version=1 behavior Message-ID: <1486366056.6.0.968381064219.issue29458@psf.upfronthosting.co.za> New submission from Maciej Obarski: random.seed version=1 wont generate the same randint sequences in python2 and python3 Python 2.7: >>> seed(1); randint(0,100) 13 Python 3.6: >>> seed(1,version=1); randint(0,100) 17 The documentation states that versio=1 is "provided for reproducing random sequences from older versions of Python" and "If a new seeding method is added, then a backward compatible seeder will be offered." ---------- components: Extension Modules messages: 287089 nosy: Maciej Obarski priority: normal severity: normal status: open title: random.seed version=1 behavior type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:30:35 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 07:30:35 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486366235.79.0.954297319033.issue29457@psf.upfronthosting.co.za> Xiang Zhang added the comment: I doubt the info belongs to datetime module documentation. When you encounter locale related problems maybe it's better for you to refer locale module documentation, and it mentions this behaviour https://docs.python.org/3/library/locale.html#background-details-hints-tips-and-caveats. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:32:28 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Feb 2017 07:32:28 +0000 Subject: [issue29458] random.seed version=1 behavior In-Reply-To: <1486366056.6.0.968381064219.issue29458@psf.upfronthosting.co.za> Message-ID: <1486366348.21.0.651358252635.issue29458@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +haypo, mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:32:56 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 07:32:56 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486366376.62.0.184613989716.issue29452@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Over this looks good. Just one other minor tweak (one that has served me well elsewhere) would be to bypass the cross-module function call with a cheap (near zero cost) register variable test: if (kwnames != NULL && !_PyArg_NoStackKeywords("rotate", kwnames)) { return NULL; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:34:55 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 07:34:55 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486366495.86.0.254900221967.issue26355@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:36:02 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 07:36:02 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486366562.14.0.412603086828.issue29453@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Patch 2 looks fine to me. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:36:49 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 07:36:49 +0000 Subject: [issue29458] random.seed version=1 behavior In-Reply-To: <1486366056.6.0.968381064219.issue29458@psf.upfronthosting.co.za> Message-ID: <1486366609.46.0.156266776149.issue29458@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:41:24 2017 From: report at bugs.python.org (Hugo Osvaldo Barrera) Date: Mon, 06 Feb 2017 07:41:24 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486366884.68.0.948099609961.issue29457@psf.upfronthosting.co.za> Hugo Osvaldo Barrera added the comment: The problem is that the datetime/strftime documentation describes "%c" as: Locale?s appropriate date and time representation. However, this is not really accurate (this is not the *default* behaviour), that's why I was mentioning the clarification. IMHO, a mere mere link to that caveats section would be enough. Maybe looking at the locale section sounded intuitive to you because you're already familiar with it, but for people who don't KNOW that there's a caveats section there, it's not really obvious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:46:52 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 07:46:52 +0000 Subject: [issue29458] random.seed version=1 behavior In-Reply-To: <1486366056.6.0.968381064219.issue29458@psf.upfronthosting.co.za> Message-ID: <1486367212.2.0.333798341999.issue29458@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Marciej, this isn't a bug. The seeders are consistent. It is the code for randint() that has changed (to fix a minor imbalance in the distribution). $ python2.7 -c "from random import *; seed(1); print(repr(random()))" 0.13436424411240122 $ python3.5 -c "from random import *; seed(1); print(repr(random()))" 0.13436424411240122 The reproducibility guarantee is limited to the seeder and the output of random(). The downstream algorithms are allowed to change. See https://docs.python.org/3/library/random.html#notes-on-reproducibility ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:59:45 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 07:59:45 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486367985.39.0.590303519606.issue29371@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This mostly looks correct. I would change "bitwise-OR?ed" to "bitwise ORed". That latter form without the hyphen or apostrophe matches what is used in library/winsound.rst. Once that change is made (in two places), go ahead an apply the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:00:11 2017 From: report at bugs.python.org (irdb) Date: Mon, 06 Feb 2017 08:00:11 +0000 Subject: [issue29459] `__contains__` and `get` methods for match objects? Message-ID: <1486368011.75.0.401714465963.issue29459@psf.upfronthosting.co.za> New submission from irdb: __getitem__ was added to match objects as a resolution of issue24454. Wouldn't it be nice to also have `__contains__` and `get` methods for match objects? Is it even feasible to implement them in neat way? They should work similar to dictionaries, i.e: ``` match = re.match('(?Pa)', 'a') match.get('b') # should return None match.get(1) # should return 'a' 'a' in match # True 'b' in match # False ``` ---------- components: Library (Lib) messages: 287096 nosy: eric.smith, irdb, mrabarnett, serhiy.storchaka priority: normal severity: normal status: open title: `__contains__` and `get` methods for match objects? type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:05:47 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 08:05:47 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> Message-ID: <1486368347.86.0.638779082631.issue29449@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > A return value from clear will indicate to a thread if it > won the race to clear the event. Why would we care who won the race to clear? I would think that the important thing is that the event is cleared, not who did it. ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:09:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:09:51 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like Message-ID: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() macros. This eliminates the overhead of the cross-module function call in common case. This idea was previously discussed in issue26822 and raised again in issue29452. ---------- components: Interpreter Core files: _PyArg_NoKeywords_macro.patch keywords: patch messages: 287098 nosy: haypo, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Speed up _PyArg_NoKeywords() and like type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46537/_PyArg_NoKeywords_macro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:11:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:11:14 +0000 Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za> Message-ID: <1486368674.1.0.592891021108.issue26822@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems I missed to attach a patch. Opened issue29460 for this tweak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:12:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:12:45 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486368765.61.0.90550091601.issue29452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This already was discussed in issue26822. Issue29460 makes _PyArg_NoStackKeywords() cheaper. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:23:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:23:06 +0000 Subject: [issue29459] `__contains__` and `get` methods for match objects? In-Reply-To: <1486368011.75.0.401714465963.issue29459@psf.upfronthosting.co.za> Message-ID: <1486369386.98.0.909266069249.issue29459@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I predicted that that change will open a can of worms. The match object is not a dictionary. I don't see a need in new methods. The get() method you propose looks virtually the same as the group() method. "'a' in match" is virtually the same as "match.get('a') is not None". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:31:21 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 08:31:21 +0000 Subject: [issue29459] `__contains__` and `get` methods for match objects? In-Reply-To: <1486368011.75.0.401714465963.issue29459@psf.upfronthosting.co.za> Message-ID: <1486369881.34.0.827210061637.issue29459@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 for m.get(key[, default]) -1 for __contains__ The get() makes logical sense and it is perfectly reasonable to want a default value for a missing group. The contains idea makes less sense and is problematic on several fronts. "'a' in match" only works if the match object is not None but it looks like a traditional membership test. Also, I think it will lead to confusion over whether contains is testing the key or the value: m = re.match('(?P[ab])', 'a') 'a' in m # True 'b' in m # False m = re.match('(?P[ab])', 'b') 'a' in m # True 'b' in m # False m = re.match('(?P[ab])', 'c') 'a' in m # TypeError 'b' in m # TypeError IMO, it is better to leave out __contains__ and let people just use groupdict() where they know for sure that normal dict semantics apply. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:32:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:32:27 +0000 Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za> Message-ID: <1486369947.45.0.135230497593.issue29028@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I wanted first to finish issue27867 (expose new API as public). But this is not needed for this issue. ---------- dependencies: -various issues due to misuse of PySlice_GetIndicesEx resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:32:57 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 08:32:57 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <1486369977.84.0.388633161431.issue29460@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:42:12 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 08:42:12 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <20170206084209.7901.44288.E9109281@psf.io> Roundup Robot added the comment: New changeset 82d1c8d15e18 by Serhiy Storchaka in branch 'default': Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and https://hg.python.org/cpython/rev/82d1c8d15e18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:42:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:42:42 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <1486370562.78.0.508425822258.issue29460@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:50:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 08:50:04 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <1486371004.39.0.304479674692.issue29460@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh right, I recall that I proposed it. Thanks for this change :-) The next question might it: would it be worth it to try using unlikely() macro on (kwargs == NULL) test in the macro? ;-) I'm talking about GCC/Clang __builtin_expect: #define unlikely(x) __builtin_expect((x),0) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:54:28 2017 From: report at bugs.python.org (Marco Buttu) Date: Mon, 06 Feb 2017 08:54:28 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation In-Reply-To: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> Message-ID: <1486371268.72.0.358662005865.issue29455@psf.upfronthosting.co.za> Marco Buttu added the comment: I added a "seealso" at the end of the page. ---------- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file46538/issue29455.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:56:19 2017 From: report at bugs.python.org (Jyotirmoy Bhattacharya) Date: Mon, 06 Feb 2017 08:56:19 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486368347.86.0.638779082631.issue29449@psf.upfronthosting.co.za> Message-ID: Jyotirmoy Bhattacharya added the comment: > > A return value from clear will indicate to a thread if it > > won the race to clear the event. > > Why would we care who won the race to clear? I would think that the > important thing is that the event is cleared, not who did it. > Here's the scenario that prompted my report: the Event is set to indicate that certain 'work' has accumulated and one among a pool of workers uses clear() to claim the work accumulated till that point. If clear() returned a value, we could easily ensure that only one among the workers woken up actually does the work. Of course, in this case it would be more efficient to wake up just one worker using a Condition object and notify() but then one has to write the logic to maintain the state of the event. An Event whose clear() returned a value would allow for a quick and dirty solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:00:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 09:00:11 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> Message-ID: <1486371611.45.0.307322159511.issue29449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > A return value from clear will indicate to a thread if it won the race to clear the event. I think other synchronization primitives should be used for this. I'm not sure that other implementations of Event (e.g. multiprocessing.Event) can efficiently return the previous state. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 09:00:23 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <1486371623.54.0.777506083808.issue29460@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset f5ef851ff6b26529382747cfea4674158c7c1ebc by Serhiy Storchaka in branch 'master': Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and https://github.com/python/cpython/commit/f5ef851ff6b26529382747cfea4674158c7c1ebc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:13:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 09:13:28 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486371004.39.0.304479674692.issue29460@psf.upfronthosting.co.za> Message-ID: <2608040.4Gk9WDZscv@raxxla> Serhiy Storchaka added the comment: > The next question might it: would it be worth it to try using unlikely() > macro on (kwargs == NULL) test in the macro? ;-) Perhaps this may help in some critical tight loops (in implementations of dict, string operations or long integer arithmetic), but I doubt it can have any measurable effect when used once per a call of a function calling PyArg_Parse* and using many other stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:41:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 09:41:29 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core Message-ID: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute to provide the compiler with branch prediction information, it adds _Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros. I always wanted to experiment this change. I opened this issue to collect information and benchmark results to take a decision. I doubt that the change will really make Python faster, there is a risk of modifying a lot of code for no value, or worse: make Python slower. Extract of GCC doc: "as programmers are notoriously bad at predicting how their programs actually perform." My patch marks error cases as unlikely. A profiler like Linux perf should be used to check which branches are less likely, but I tried to use my guesses to expeeriment a first change. Since there is a risk that using such macro makes the code slower, or has no effect, I tried to restrict changes to the hot code and the most common functions/macros: * Py_EnterRecursiveCall() * _PyArg_NoKeywords() * Py_DECREF()... not sure about this case, is it really more likely that refcnt != 0 than refcnt==0? * Functions to call functions: _PyObject_FastCallKeywords(), fast_function(), etc. * etc. I'm not sure about the methodology to benchmark such patch neither. Is it worth it to benchmark a Python compiled without PGO? By the way, does GCC/Clang use __builtin_expect() information when Python is compiled with PGO? If PGO ignores this information, it would be better to not use it, since I now strongly recommend to use PGO. Otherwise, Python performance is too random because of the joy of code placement. Some links on __builtin_expect(): * http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html * http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel-how-do-they-work-whats-their * https://news.ycombinator.com/item?id=9411227 ---------- files: likely.patch keywords: patch messages: 287112 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Experiment usage of likely/unlikely in CPython core type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46539/likely.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:45:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 09:45:46 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486374346.45.0.948958746074.issue29461@psf.upfronthosting.co.za> STINNER Victor added the comment: Copy of msg287111 (issue #29460), Serhiy Storchaka (serhiy.storchaka): > The next question might it: would it be worth it to try using unlikely() > macro on (kwargs == NULL) test in the macro? ;-) Perhaps this may help in some critical tight loops (in implementations of dict, string operations or long integer arithmetic), but I doubt it can have any measurable effect when used once per a call of a function calling PyArg_Parse* and using many other stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:47:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 09:47:13 +0000 Subject: [issue29460] Speed up _PyArg_NoKeywords() and like In-Reply-To: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> Message-ID: <1486374433.74.0.927421706401.issue29460@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the issue #29461: "Experiment usage of likely/unlikely in CPython core". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:52:52 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 Feb 2017 09:52:52 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486374772.48.0.11958595668.issue29461@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 05:01:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 10:01:13 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486375273.69.0.0613827812447.issue29461@psf.upfronthosting.co.za> STINNER Victor added the comment: http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html Using __builtin_expect() in a very long loop 10^9 iteratos (1,000,000,000) makes the loop 15% faster (2.67 sec => 2.28 sec), *but* using PGO avoids the need of using __builtin_expect() explicitly and makes the code 27% faster (2.67 sec => 1.95 sec): "This optimized version runs significantly faster (1.95 versus 2.28 seconds) than our version that used __builtin_expect(). This is because, in addition to the branching in the if statement, the branching in the for loops was also optimized." The article also confirms that if __builtin_expect() is misused, it makes the code 5% slower (2.67 sec => 2.79 sec). -- Another story related to micro-optimization in the Linux kernel. The Linux kernel used explicit prefetch in some tiny loops. After many benchmarks, it was concluded that letting the developer uses prefetch makes the code slower, and so the micro-optimization was removed: https://lwn.net/Articles/444336/ ?So the conclusion is: prefetches are absolutely toxic, even if the NULL ones are excluded.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 05:03:25 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 10:03:25 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1486375405.08.0.213672526706.issue24459@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch and sorry for my late response. I did some tweaks and am planning to commit the tweaked version of your patch this week. ---------- Added file: http://bugs.python.org/file46540/issue24459_cleanup.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 05:21:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 10:21:29 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486376489.1.0.0734919519819.issue29452@psf.upfronthosting.co.za> STINNER Victor added the comment: > Over this looks good. Just one other minor tweak (one that has served me well elsewhere) would be to bypass the cross-module function call with a cheap (near zero cost) register variable test: (...) This has just been optimized by Serhiy, change 82d1c8d15e18. So, is deque-2.patch good now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 05:40:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 10:40:01 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486377601.8.0.0756365481962.issue29461@psf.upfronthosting.co.za> STINNER Victor added the comment: Benchmarks with Python compiled by gcc -O3 (without PGO). haypo at smithers$ ./python -m perf timeit 'len("abc")' --duplicate=1000 --compare-to=../default-ref/python Median +- std dev: [ref] 40.4 ns +- 0.8 ns -> [likely] 40.8 ns +- 2.1 ns: 1.01x slower (+1%) haypo at smithers$ ./python -m perf timeit 'sum(())' --duplicate=1000 --compare-to=../default-ref/python -p3 Median +- std dev: [ref] 86.4 ns +- 2.8 ns -> [likely] 86.3 ns +- 0.3 ns: 1.00x faster (-0%) Not significant! haypo at smithers$ ./python -m perf timeit -s 's=list("abc")' 'sorted(s)' --duplicate=100 --compare-to=../default-ref/python -p3 Median +- std dev: [ref] 224 ns +- 3 ns -> [likely] 222 ns +- 1 ns: 1.01x faster (-1%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:08:29 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Feb 2017 11:08:29 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1486379309.3.0.915301836235.issue24459@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file46541/issue24459_cleanup_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:28:50 2017 From: report at bugs.python.org (Alessandro Vesely) Date: Mon, 06 Feb 2017 11:28:50 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() Message-ID: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> New submission from Alessandro Vesely: Comments are allowed almost everywhere in an email message, and should be eliminated before attributing any meaning to a field. In the words of RFC5322, any CRLF that appears in FWS is semantically "invisible". In particular, some note that comments can be used to deceive an email filter. For example, like so: Content-Disposition: attachment; filename=''attached%2E"; filename*1*="%62"; filename*2=(fool filters)at (I don't know which, if any, email clients would execute that batch...) Anyway, removing comments is needed for any structured header field. One is usually interested in the unfolded, de-commented value. It is difficult to do correctly, because of nesting and quoting possibilities. This issue seems to be ignored, except for address lists (there is a getcomment() member in AddrlistClass). Why? ---------- components: email messages: 287119 nosy: ale2017, barry, r.david.murray priority: normal severity: normal status: open title: RFC822-comments in email header fields can fool, e.g., get_filename() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:40:31 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 06 Feb 2017 11:40:31 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1486381231.06.0.76233614829.issue11549@psf.upfronthosting.co.za> INADA Naoki added the comment: I've tried to update ast_opt.c[t] without changing AST. But I can't find clear way to solve "foo" + "bar" docstring problem. This patch adds only docstring to AST. ---------- Added file: http://bugs.python.org/file46542/ast-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:50:42 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 11:50:42 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1486381842.11.0.0645077621917.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: Naoki: Can you please open a new issue for your ast-docstring.patch change? I like it, but this issue became too big, and I'm not sure that everyone in the nosy list is interested by this specific change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:54:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 11:54:28 +0000 Subject: [issue29362] regrtest: don't fail immediately if a child does crash In-Reply-To: <1485272121.72.0.342410390691.issue29362@psf.upfronthosting.co.za> Message-ID: <20170206115425.96659.94091.51B8DDD5@psf.io> Roundup Robot added the comment: New changeset 4446613000a3 by Victor Stinner in branch 'default': regrtest: don't fail immediately if a child does crash https://hg.python.org/cpython/rev/4446613000a3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 07:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 12:00:25 +0000 Subject: [issue29362] regrtest: don't fail immediately if a child does crash In-Reply-To: <1485272121.72.0.342410390691.issue29362@psf.upfronthosting.co.za> Message-ID: <1486382425.34.0.828388491713.issue29362@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 99e4e687145a76ac28055a651ee31470496c3ac7 by Victor Stinner in branch 'master': regrtest: don't fail immediately if a child does crash https://github.com/python/cpython/commit/99e4e687145a76ac28055a651ee31470496c3ac7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 07:11:03 2017 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 06 Feb 2017 12:11:03 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1486383063.29.0.215529677193.issue11549@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: -alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:13:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 13:13:02 +0000 Subject: [issue29362] regrtest: don't fail immediately if a child does crash In-Reply-To: <1485272121.72.0.342410390691.issue29362@psf.upfronthosting.co.za> Message-ID: <1486386782.32.0.467317496215.issue29362@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed regrtest in Python 3.7. Maybe I will backport the fix later to other branches, but I prefer to limit regrtest changes in stable branches. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:16:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 13:16:50 +0000 Subject: [issue26901] Argument Clinic test is broken In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za> Message-ID: <1486387010.8.0.41459812727.issue26901@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:17:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 13:17:47 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486387067.11.0.811527258698.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: @Serhiy: Can we please now close this issue? Or is there still something to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:25:45 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 13:25:45 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <20170206132542.110213.67387.DD96C2B1@psf.io> Roundup Robot added the comment: New changeset ca2f024ce7cb by Victor Stinner in branch 'default': Prohibit implicit C function declarations https://hg.python.org/cpython/rev/ca2f024ce7cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:30:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 13:30:29 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1486387829.15.0.639132620182.issue27659@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Panter: "If there is an obscure platform where we don?t include the right header file for a function, changing the warning into an error would cause the build to fail." In my experience, calling a function which was not declared is very likely to cause a bug, or a crash in the worst case. For example, on 64-bit, if the return type is a pointer, the C compiler uses the int type by default, whereas a pointer is 32-bit, not 64-bit, and so it will immediately crash. Martin: "If we do make it an error, it should only be so for 3.7." Ok. I pushed the patch to Python 3.6. @Chi Hsuan Yen: Thanks for the patch! Is this change enough to fix the crypt build issue? If yes, can we close the issue? It is likely that the cause causes compilation errors on some platforms where we call non-existent functions or call functions with a missing header. IMHO it's a good thing to get a build error rather than a crash at runtime. A concrete issue is that the compilation of the curses module will probably fails now on Solaris: issue #13552, whereas before the build only emitted warnings. The curses module is broken for years on Solaris, and it seems like nobody is able to fix it, so it's not a big deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:45:59 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 06 Feb 2017 13:45:59 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1486388759.74.0.58829432179.issue27659@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: > If yes, can we close the issue? Yes and thanks! As a side note, on Android it prevents broken grp.cpython-37m.so, too. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:47:53 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Feb 2017 13:47:53 +0000 Subject: [issue29457] strftime('%x') does not use my locale In-Reply-To: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> Message-ID: <1486388873.79.0.357243891474.issue29457@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, it is the default behavior, because the default locale, as for most (almost all?) programming languages (not just Python), is the C locale, until you change it. The reason for this is to get consistent behavior no matter what the locale is set to, unless you explicitly enable the local locale (or some other locale) in your program. Whether it is worth adding a link is a separate question, but we really don't get this question often, unlike some other FAQs. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:50:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 13:50:39 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1486389039.44.0.358437342417.issue27659@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh by the way, if someone sees a build error because of a missing function declaration, please report a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 08:58:08 2017 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Feb 2017 13:58:08 +0000 Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za> Message-ID: <1486389488.47.0.0444025113064.issue29301@psf.upfronthosting.co.za> Stefan Krah added the comment: If the API can still change (msg287083), I think I'll wait with this until shortly before 3.7 beta. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 14:00:23 +0000 Subject: [issue27659] Prohibit implicit C function declarations In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1486389623.63.0.908187038145.issue27659@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 9a26d20d2baa27407501b13435d733dcc26f3d53 by Victor Stinner in branch 'master': Prohibit implicit C function declarations https://github.com/python/cpython/commit/9a26d20d2baa27407501b13435d733dcc26f3d53 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:01:22 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 14:01:22 +0000 Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za> Message-ID: <1486389682.52.0.514059040946.issue29301@psf.upfronthosting.co.za> STINNER Victor added the comment: > If the API can still change (msg287083), I think I'll wait with this until shortly before 3.7 beta. I do not understand why Serhiy keeps repeating that the API is going to change, I have no such plan. IMHO the FASTCALL API is now very well defined: (PyObject **args, Py_ssize_t nargs, PyObject *kwnames), and helper functions are now well tested. We might optimize Argument Clinic further, but for decimal, it seems like it's a no-no and that direct usage of METH_FASTCALL is preferred. So no, I don't plan or expect any API change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:05:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 14:05:36 +0000 Subject: [issue23980] Documentation for format units starting with 'e' is inconsistent In-Reply-To: <1429227526.01.0.733275706487.issue23980@psf.upfronthosting.co.za> Message-ID: <1486389936.96.0.621443221921.issue23980@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:10:09 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Feb 2017 14:10:09 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() In-Reply-To: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> Message-ID: <1486390209.82.0.529436767586.issue29462@psf.upfronthosting.co.za> R. David Murray added the comment: My reading of rfc 2231 is that CFWS is not allowed in that position. Can you explain your interpretation with specific cites to the RFC? Also please provide an example of specific behavior of the email package that you think is incorrect. An email processor should always be treating a filename as a dirty string, so I'm not clear on what you are worried about here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:17:59 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Feb 2017 14:17:59 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() In-Reply-To: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> Message-ID: <1486390679.19.0.143530578312.issue29462@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and the answer to you "why" is that the email package is only dealing with content semantically in address lists. Everywhere else it is up to the library using program to interpret the structured headers. In 2.7 the email package provides you the tools to process emails, but does not do very much hand holding. The python3 email package tries to do a much better job; but, frankly, I skimped on handling comments and have done almost no testing of the code that theoretically handles them, since they are so rarely encountered in the wild. Specifically they are supposed to be correctly parsed, but there is no way to access comment content and, as I said, there are few to zero tests that include comments to validate that syntactic handling. I would be interested in patches to complete the comment support in _header_value_parser in python3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:21:19 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 06 Feb 2017 14:21:19 +0000 Subject: [issue29463] Change docstring to attribute from first statement. Message-ID: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> New submission from INADA Naoki: spin off of #11549. http://bugs.python.org/issue11549#msg130955 > b) Docstring is now an attribute of Module, FunctionDef and ClassDef, > rather than a first statement. Docstring is a special syntactic > construction, it's not an executable code, so it makes sense to separate it. Otherwise, optimizer would have to take extra care not to introduce, change or remove docstring. For example: > > def foo(): > "doc" + "string" > >Without optimizations foo doesn't have a docstring. After folding, however, the first statement in foo is a string literal. This means that docstring depends on the level of optimizations. Making it an attribute avoids the problem. ---------- files: ast-docstring.patch keywords: patch messages: 287136 nosy: haypo, inada.naoki priority: normal severity: normal status: open title: Change docstring to attribute from first statement. versions: Python 3.7 Added file: http://bugs.python.org/file46543/ast-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:27:20 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Feb 2017 14:27:20 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1486391240.83.0.268026256994.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding pip installability, the intended beneficiaries of that are: * folks *collaborating* on the GUI, since it means it can be installed into virtual environments, tested across multiple versions with tox, etc * developers that would like a pip GUI, and already know how to use "pipsi" to install command line applications from PyPI into their own virtual environments * folks *distributing* the GUI, since being pip installable means that various tools like pyp2rpm, PyInstaller, etc, should be better able to work with it You can look at the PyPA sample project for more guidance on getting started with that: https://github.com/pypa/sampleproject ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:27:57 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Mon, 06 Feb 2017 14:27:57 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486391277.84.0.412602195918.issue29453@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: > But maybe it is worth to mention that the output corresponds to the order of passed keyword arguments Should I add this note? It looks fine to me as is but I'm not the experienced one here :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:57:03 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Feb 2017 14:57:03 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486393023.22.0.5392591321.issue26355@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Matthias! Regarding 2v3, the layout differences aren't a problem, since the canonical URLs are separate (/2/* vs /3/*). That's one of the benefits I actually hope for with this change - due to PEP 430, deep links still go to the Python 2 documentation by default, and once this change is made in the Python 2.7 branch it should teach search engines that those should start being presented in results as "/2/*" qualified links. We also don't tend to make wholesale changes to the URL layouts in the docs in X.Y releases, so I think the assumption of "the relative path of this page won't change" is fine. Georg, Berker - any further thoughts before we make this change to 3.4+ and the 2.7 docs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:57:07 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 14:57:07 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486393027.04.0.625204533204.issue29452@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, go ahead and apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:00:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 15:00:00 +0000 Subject: [issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za> Message-ID: <1486393200.83.0.432979853256.issue28870@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:08:07 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 15:08:07 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <20170206150716.110778.22625.B6D96B04@psf.io> Roundup Robot added the comment: New changeset 1c048539200c by Victor Stinner in branch 'default': Optimize deque index, insert and rotate() methods https://hg.python.org/cpython/rev/1c048539200c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:10:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 15:10:37 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486393837.92.0.177099196484.issue29452@psf.upfronthosting.co.za> STINNER Victor added the comment: Raymond: "Yes, go ahead and apply." Great, done. Thanks for the reviews Serhiy and Raymond. As I wrote, you can consider to use Argument Clinic later, but there is no urgency for that ;-) I close the issue. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:22:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 15:22:46 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters Message-ID: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes bare METH_FASTCALL be used for functions with positional-only parameters. This eliminates small cost that these functions pay for handling empty keywords: calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing kwnames. This also can slightly reduce stack consumption. ---------- components: Interpreter Core files: fastcall-no-keywords.patch keywords: patch messages: 287143 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Specialize FASTCALL for functions with positional-only parameters type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46544/fastcall-no-keywords.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:23:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 15:23:05 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486394585.5.0.451140661841.issue29464@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:51:24 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Feb 2017 15:51:24 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486396284.36.0.883911581306.issue29461@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I had read that likely/unlikely were hard to use well and often not worth the trouble. IIRC, they are used extensively in the Linux kernel but people were finding zero measurable effect when enabling or disabling the constructs. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:58:17 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 Feb 2017 15:58:17 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486396697.1.0.894260564683.issue29461@psf.upfronthosting.co.za> Christian Heimes added the comment: I would expect that PGO/LGO builds give better improvements with less coding bloat. Did you compare a PGO likely/unlikely build against a standard PGO build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:00:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 16:00:00 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486396800.36.0.12227235333.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: > Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes bare METH_FASTCALL be used for functions with positional-only parameters. While I tried to keep everything related to FASTCALL private, it seems like Cython uses some FASTCALL features. I don't know which ones exactly. Well, if only one project in the world uses FASTCALL, we can help them to support such backward incompatible change ;-) > This eliminates small cost that these functions pay for handling empty keywords: calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing kwnames. My idea when I designed FASTCALL was to move code to parse arguments in the function body rather than in _PyCFunction_FastCallKeywords(), and to have a single calling function METH_FASTCALL, rather than two (METH_FASTCALL and METH_FASTCALL|METH_KEYWORDS). The long term plan is also to support passing arguments by keyword in more functions. IMHO many functions don't accept keywords for technical reasons, but once we converted a module, function or type to Argument Clinic, it becomes trivial to accept keywords. If most functions accept keywords, I'm not sure that having a special case for positional-only is still worth it. But this plan was before I had discussions on supporting keywords in unicode methods. In fact, it's deliberate to not accept keywords in many functions or methods. Well, when I see your patch, I see that it removes a lot of code. So it's likely to be a good idea :-) > This also can slightly reduce stack consumption. You mean the removal of the "PyObject *kwnames" for METH_FASTCALL (positional arguments only)? Do you have an idea of the stack usage? Try maybe testcapi_stacksize.patch of the issue #28870? It would help to take a decision on this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 16:00:26 +0000 Subject: [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate In-Reply-To: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> Message-ID: <1486396826.95.0.283193286879.issue29452@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 55949f988dc1b943796d9852cc4d588c58cc4255 by Victor Stinner in branch 'master': Optimize deque index, insert and rotate() methods https://github.com/python/cpython/commit/55949f988dc1b943796d9852cc4d588c58cc4255 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:04:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 16:04:11 +0000 Subject: [issue29461] Experiment usage of likely/unlikely in CPython core In-Reply-To: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> Message-ID: <1486397051.61.0.972018846983.issue29461@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I also always wanted to experiment this change. But I was afraid that providing such macros can encourage of overusing it. I don't want to wrap any test for NULL or -1 with these macros. If we expect some benefit from using these macros, I would play with them in hot loops. For example in dict lookup function (unlikely comparing keys raise an exception or dict is modified in process of searching), in codecs (unlikely illegal sequence is occurred), etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:08:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 16:08:36 +0000 Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za> Message-ID: <1486397316.62.0.465344478447.issue29301@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh ok, it seems like Serhiy wants to change METH_FASTCALL. I didn't know :-) He just opened the issue #29464: "Specialize FASTCALL for functions with positional-only parameters". Interesting idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:13:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 16:13:01 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486397581.2.0.963808161663.issue29464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We can avoid breaking backward compatibility and introduce new call method METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. FASTCALL is not a part of stable ABI. I still didn't do any benchmarking or stack usage measurements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:22:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 16:22:04 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486398124.21.0.530937789989.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: > I still didn't do any benchmarking or stack usage measurements. I'm running benchmarks on the speed-python server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 11:50:46 2017 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Feb 2017 16:50:46 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486399846.05.0.994351363982.issue29464@psf.upfronthosting.co.za> Stefan Krah added the comment: Adding Stefan Behnel, perhaps Cython doesn't need backwards compatibility. ---------- nosy: +scoder, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:08:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:08:28 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption Message-ID: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> New submission from STINNER Victor: While testing issue #29464 patch, I failed to see a major enhancement on the stack usage of fast calls without keyword arguments. The problem is that functions like _PyObject_FastCallKeywords() and _PyObject_FastCallDict() still have to pass a NULL argument for kwargs/kwnames, and have code to handle keyword arguments. Attached patch adds _PyObject_FastCall() to reduce the stack consumption. At the C level, keyword arguments are almost never used. For example, PyObject_CallFunctionObjArgs() is commonly used, whereas it only uses positional arguments. The patch changes also _PyObject_FastCallKeywords() and _PyObject_FastCallDict() to move the "slow" path creating temporary tuple and dict in a subfunction which is not inlined. The slow path requires more stack memory. Morecall, _PyObject_FastCallKeywords() and _PyObject_FastCallDict() are modified to call _PyObject_FastCall() if there is no keyword. The patch might make function calls without keyword arguments faster, I didn't check. Stack usage. $ ./python -c 'import _testcapi, sys; sys.setrecursionlimit(10**5); n=1000; s=_testcapi.meth_fastcall_stacksize(n); print("%.1f B/call" % (s/n))' * Reference: 832.8 B/call * Patch: 656.6 B/call (-176.2 B) I don't know why the stack usage is not an integer number of bytes? Combined with the issue #29464 "Specialize FASTCALL for functions with positional-only parameters", the stack usage can be even more reduced by a few bytes. See the issue #28870 for the previous work on reducing stack consumption. ---------- components: Interpreter Core files: pyobject_fastcall.patch keywords: patch messages: 287153 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Add _PyObject_FastCall() to reduce stack consumption type: resource usage versions: Python 3.7 Added file: http://bugs.python.org/file46545/pyobject_fastcall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:11:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:11:05 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486401065.37.0.855156231502.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: meth_fastcall_stacksize.patch: Patch adding _testcapi.meth_fastcall_stacksize() to measure the stack usage to call a METH_FASTCALL function. ---------- Added file: http://bugs.python.org/file46546/meth_fastcall_stacksize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:12:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:12:18 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486401138.0.0.369216841372.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: I measured the stack consumption, it's not better. But I created the issue #29465 "Add _PyObject_FastCall() to reduce stack consumption" which would allow to reduce the stack consumption with this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:15:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:15:39 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486401339.08.0.779237982487.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: > We can avoid breaking backward compatibility and introduce new call method METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. FASTCALL is not a part of stable ABI. If we decide that having two FASTCALL calling convention, I prefer what you proposed: METH_FASTCALL (pos only) and METH_FASTCALL|METH_KEYWORDS (pos+kw). As you wrote, I like reusing the existing METH_KEYWORDS flag, it reduces the surprises if someone ports existing code using METH_VARARGS and METH_VARARGS|METH_KEYWORDS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:19:22 2017 From: report at bugs.python.org (George King) Date: Mon, 06 Feb 2017 17:19:22 +0000 Subject: [issue29400] Add instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486401562.24.0.702016933295.issue29400@psf.upfronthosting.co.za> George King added the comment: Attached is a new patch, which does not settrace/gettrace and instead offers new settraceinst/gettraceinst per Victor's recommendation. I did not implement the proposed behavior of raising an exception if the old APIs are used when the inst_tracing flag is set. However I do think it makes sense to do so. The new sys.settraceinst function takes two arguments: a function and an integer flag that is currently interpreted as a boolean (whether or not to enable instruction level tracing). I did it this way because I would like to consider adding a third mode, which would only trigger tracing for interesting control-flow events, namely steps for which the previous instruction was a branch. The motivation is that I expect per-instruction tracing to be very slow, and for the code coverage use case at least, these are the interesting events. For this to be useful, a (prev_offset, current_offset) pair would need to be passed as to the trace callback. I am not sure if this would be useful to other applications, e.g. pdb. ---------- Added file: http://bugs.python.org/file46547/settraceinst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:28:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:28:46 +0000 Subject: [issue29400] Add instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486402126.15.0.669815722506.issue29400@psf.upfronthosting.co.za> STINNER Victor added the comment: > I did it this way because I would like to consider adding a third mode, which would only trigger tracing for interesting control-flow events, namely steps for which the previous instruction was a branch. Hum, let's use https://en.wikipedia.org/wiki/Basic_block terminology. The callback would be called when you enter and exit a basic block? Or only on exit? Only on conditional branches? Or also on unconditional branches? In term of instructions, can give examples of instructions which would be traced or not? IMHO the two instruction level modes would be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:38:57 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Feb 2017 17:38:57 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation In-Reply-To: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> Message-ID: <1486402737.58.0.561521627355.issue29455@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Marco! Typically we put the mention at the top to give the 3rd-party library a better chance of being noticed (see the urllib.request docs to see how requests is mentioned). ---------- assignee: docs at python -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:03:38 2017 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Feb 2017 18:03:38 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486404218.42.0.362866919602.issue29441@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:05:14 2017 From: report at bugs.python.org (Marco Buttu) Date: Mon, 06 Feb 2017 18:05:14 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation In-Reply-To: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> Message-ID: <1486404314.4.0.312790973046.issue29455@psf.upfronthosting.co.za> Marco Buttu added the comment: Thank you Brett, here is another patch. I added the seealso directive right after the introduction of the trace module, in the same way as urllib.request does for requests. ---------- Added file: http://bugs.python.org/file46548/issue29455_2nd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:16:35 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Mon, 06 Feb 2017 18:16:35 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1486404995.86.0.266385583399.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: Uploading patch after fixes from berker CR. The `blob_open` API can can have the following options: 1. The table, column and row must be mandatory parameters. 2. The read/write permissions can have the following options: a. No default (mandatory parameter). b. default read-only c. default write-only 3. The dbname can be without a default of "main" and then it will be a mandatory parameter. I don't think that there is enough differences between the possible API's to justify sending a message to the mailing lists. ---------- Added file: http://bugs.python.org/file46549/blob4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:36:36 2017 From: report at bugs.python.org (Mark Diekhans) Date: Mon, 06 Feb 2017 18:36:36 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field Message-ID: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> New submission from Mark Diekhans: python3 pickle does not serialize the __cause__ field, as shown by the attached demo program. ---------- components: Library (Lib) files: cause_pickle.py messages: 287163 nosy: diekhans priority: normal severity: normal status: open title: pickle does not serialize Exception __cause__ field type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46550/cause_pickle.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:44:21 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Feb 2017 18:44:21 +0000 Subject: [issue29425] File-altering aspects of pathlib should return new pathlib objects In-Reply-To: <1486080253.05.0.537199940287.issue29425@psf.upfronthosting.co.za> Message-ID: <1486406661.23.0.659432642995.issue29425@psf.upfronthosting.co.za> Brett Cannon added the comment: The idea in general seems reasonable. Anyone else have an opinion? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 14:01:47 2017 From: report at bugs.python.org (George King) Date: Mon, 06 Feb 2017 19:01:47 +0000 Subject: [issue29400] Add instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486407707.18.0.620208064806.issue29400@psf.upfronthosting.co.za> George King added the comment: I'm not sure exactly, but the way I see it (for code coverage), we want to trace transitions between basic blocks. So I would define it as: each entry into a BB is traced, with a tuple of (previous_offset, current_offset). This way when a function call starts, we callback with (-1, 0), and then get a callback for every transition between BBs. The code is well covered if we observe every possible transition. I am not clear on the precise details, e.g. regarding unconditional branches. Since for code coverage this is essentially on optimization over per-instruction mode, I intend to first work out correctness details and test cases for the coverage tool, and then once the tests solid add the optimization. I'm happy to discuss more, but this aspect is a lower priority for me (I still have to work out remaining correctness issues with my opcode analysis). Would it make sense to split it out into a second issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 14:22:50 2017 From: report at bugs.python.org (Mark Diekhans) Date: Mon, 06 Feb 2017 19:22:50 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field In-Reply-To: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> Message-ID: <1486408970.18.0.667426594438.issue29466@psf.upfronthosting.co.za> Changes by Mark Diekhans : ---------- nosy: +alexandre.vassalotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 14:26:07 2017 From: report at bugs.python.org (Alessandro Vesely) Date: Mon, 06 Feb 2017 19:26:07 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() In-Reply-To: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> Message-ID: <1486409167.7.0.773429692359.issue29462@psf.upfronthosting.co.za> Alessandro Vesely added the comment: Neither I found CFWS in rfc2231. In addition, rfc 2045 (Introduction) says that Content-Disposition ?where filename is defined? cannot include comments. However, Content-Type can include RFC 822 comments, so the filename should be de-commented in case it is inferred from the name parameter there. I'm rather new to Python, and sticking to version 2 because of the packages I work with. I see Python3's email has a much more robust design. Does this mean Python2 cannot get fixed? I attach a de_comment() function, copied from the one I mentioned this morning. The rest of the file shows its intended use. (Oops, it removes comments even from where they are not supposed to be allowed ;-) Having that kind of functionality in email.utils would make it easier to read Message's, no? ---------- Added file: http://bugs.python.org/file46551/attachments.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 14:41:23 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 06 Feb 2017 19:41:23 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486410083.77.0.920876740816.issue29439@psf.upfronthosting.co.za> Xavier de Gaye added the comment: With the following module named dlsym.py, the command 'python dlsym.py log10' produces the same successful output on linux and on Android API 21 (when _decimal is not explicitly linked with libm.so, i.e.without changeset b60b46ad8751): 'The symbol "log10" is resolved.' ---------------------- dlsym.py --------------------------- import sys, os from ctypes import * if len(sys.argv) != 2: sys.exit('Error: the symbol name is required.') symbol = sys.argv[1] libdl = CDLL('libdl.so') libdl.dlopen.restype = c_void_p libdl.dlsym.restype = c_void_p hdle = libdl.dlopen(None, os.RTLD_NOW | RTLD_GLOBAL) if hdle is None: print('Cannot get a handle on the global symbol object.') else: v = libdl.dlsym(c_void_p(hdle), symbol.encode()) _not = 'not ' if v is None else '' print('The symbol "%s" is %sresolved.' % (symbol, _not)) ------------------------------------------------------------------- This is as expected since the python executable is linked with the math library. However on Android API 21 importing _decimal fails with the error message reported earlier: 'dlopen failed: cannot locate symbol "log10"'. So this seems to be a bug with Android dlopen() at API 21 since the 'log10' symbol does exist in the process image relocation tables as shown by dlsym.py. This is confirmed by the fact that the import does not fail anymore at API 24 (still without changeset b60b46ad8751). This change of behavior may be a side effect of the changes reported in this bionic (Android libc) changelog entry: https://android.googlesource.com/platform/bionic/+show/refs/heads/master/android-changes-for-ndk-developers.md#36 For completness, my (possibly wrong) interpretation of why changeset b60b46ad8751 fixes the problem at API 21: Changeset b60b46ad8751 adds the '-lm' command line option to the linker and this adds [1] a new DT_NEEDED entry to the .dynamic section of the shared library ELF file as shown by the command 'readelf -d build/lib.linux-x86_64-3.7-pydebug/_decimal.cpython-37dm-x86_64-linux-gnu.so': Dynamic section at offset 0x54d30 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] ... The Android loader lookup for 'log10' is now successful at API 21 and the symbol is found in the libm.so.6 library listed in the DT_NEEDED lists of needed libraries. [1] See option '--as-needed' in the 'ld' man pages or see the ELF specification. Note that the Android toolchains use the clang compiler but continue to use the GNU binutils tools including the linker 'ld'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 15:00:20 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 06 Feb 2017 20:00:20 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486411220.7.0.0355716878953.issue29439@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Perhaps test_decimal should fail for CPython if _decimal can't be imported. This is not a problem specific to _decimal, the same problem exists for third-party extension modules, for example pyephem (https://github.com/brandon-rhodes/pyephem/issues/114) and existed with some other Python extension modules (issue 21668). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 15:17:20 2017 From: report at bugs.python.org (Earl Maier) Date: Mon, 06 Feb 2017 20:17:20 +0000 Subject: [issue29232] Quiet Install In-Reply-To: <1484083752.73.0.652797539276.issue29232@psf.upfronthosting.co.za> Message-ID: <1486412240.74.0.427708304117.issue29232@psf.upfronthosting.co.za> Earl Maier added the comment: I have since rebuilt the machine that I was doing my testing on, so I am unable grab log files from the installs. I have not been able to reproduce the issue since the rebuild of the machine. On a good note: Everything is working as it should. I appreciate you looking into the issue. Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 15:40:15 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Feb 2017 20:40:15 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() In-Reply-To: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> Message-ID: <1486413615.24.0.866723422507.issue29462@psf.upfronthosting.co.za> R. David Murray added the comment: Your thought is correct: python2 no longer gets enhancements. So improved comment handling can only be added to python3, assuming anyone is interested in doing it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 15:59:59 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 06 Feb 2017 20:59:59 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486414799.83.0.669413359946.issue29371@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Raymond. I have an updated patch there the hypen and apostrophe are removed. ---------- versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file46552/issue29371v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 16:08:42 2017 From: report at bugs.python.org (Riccardo Polignieri) Date: Mon, 06 Feb 2017 21:08:42 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486415322.26.0.404583790158.issue28686@psf.upfronthosting.co.za> Riccardo Polignieri added the comment: > I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" undefined. I can't say I'm really happy with this answer. Fact is, 1) you almost always have to work from within a virtual env these days, 2) you really want to have meaningful shebangs (ie, version-specific) in your scripts because, well, 2017 and the world is still split between py2 and py3, 3) the py.exe launcher is the new shiny thing and we all just want to use it. So, it *could* annoy some people to find out that py.exe just can't handle both venvs and shebangs in a meaningful way, and you must give up on either venvs, or shebangs, or py.exe. As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script: 1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the system interpreter, never abides neither venvs nor shebangs. A perfectly defined, utterly useless behavior. 2) invoke interpreter (eg "python foo.py", the good old way): this will always be venvs-complaint, will never parse shebangs. And yet at the moment, it's probably your best option *when* inside a venv - and the worst when outside, of course. 3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will always abide version-specific shebangs (ie, "#!python3"); the only quirk being that when facing a generic shebang instead, it will pick Python 2 (because, 2017 and Linux...). Oh well, I can live with that. But when you are inside a venv, then - if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it will NOT abide the venv - frustrating, yet correct I suppose; - if it finds any kind of version-specific shebang (EVEN a "env"-type of shebang!), then again it will follow the shebang but NOT the venv, and will pick up the system interpreter. That, even when you are inside a venv that perfectly matches the shebang prescription. Now, this can be very frustrating because a useless "/usr/bin/env python" shebang triggers the correct behavior both inside and outside a venv, BUT a much more useful "usr/bin/env python3" will fail even if we are inside a matching venv. I feel that all it needs to be perfect is some kind of behavior like this: dear py.exe, - when you are invoked in a version-agnostic way, and - when you find an "env"-and-version-specific shebang in the script, then please, - just look at my %path% before doing anything else. It could be that the first interpreter you find there will just match the requirement from the shebang (that is, because on occasion I just know what I'm doing, and I've just activated a matching venv, you see). If so, just give me that Python and I will be ok; - otherwise, my bad: feel free to resume any other search strategy you find appropriate, and I will humbly accept whatever interpreter you may fetch, even a php one. I think this would be just reasonable enough. What I'm missing here? ---------- nosy: +ricpol _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 16:11:31 2017 From: report at bugs.python.org (Ted Shaneyfelt) Date: Mon, 06 Feb 2017 21:11:31 +0000 Subject: [issue29467] Allow return mismatch to be caught by function Message-ID: <1486415491.45.0.543077011727.issue29467@psf.upfronthosting.co.za> New submission from Ted Shaneyfelt: def f(): try: return 0 except: return 1,2 x = f() # x is 0 x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError It would make sense to be able to catch [TypeError: 'int' object is not iterable] and return the correct number of values. Yes, the way it's done now, the function is no longer running when it is caught - but is it possible and practical to determine if parameters match before the function returns instead of afterward, allowing the called function to catch the error attempting to return? ---------- components: Interpreter Core messages: 287173 nosy: Ted Shaneyfelt priority: normal severity: normal status: open title: Allow return mismatch to be caught by function type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 17:23:40 2017 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Feb 2017 22:23:40 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486419820.69.0.827773931079.issue28686@psf.upfronthosting.co.za> Paul Moore added the comment: > 2) you really want to have meaningful shebangs (ie, version-specific) in your scripts because, well, 2017 and the world is still split between py2 and py3, This is the one I think is overspecifying. I don't see a really *good* reason for not just saying /usr/bin/env python. What would you want to happen if you said /usr/bin/env python3 if you had Python 2 on your PATH? The only reasonable answer I can see is "give an error", so why not just put if sys.version_info < (3,0): raise RuntimeError("Needs python 3") at the top of your script? Add to this the fact that I don't even know how you'd check if a python interpreter that's on PATH is Python 2 or 3 without executing it (and the overhead of running it an extra time to query its version is unacceptable) and I still don't see the justification. > - just look at my %path% before doing anything else. It could be that the first interpreter you find there will just match the requirement from the shebang (that is, because on occasion I just know what I'm doing, and I've just activated a matching venv, you see). If so, just give me that Python and I will be ok; > - otherwise, my bad: feel free to resume any other search strategy you find appropriate, and I will humbly accept whatever interpreter you may fetch, even a php one. > I think this would be just reasonable enough. What I'm missing here? You're missing the fact that it's not possible to tell by inspection the version of a Python interpreter. On Unix, the executable name includes the version, so it's easy. If Python on Windows changed to ship python3.exe and python37.exe alongside python.exe, then it might be worth revisiting this discussion, but not as things stand (IMO). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 17:41:57 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 06 Feb 2017 22:41:57 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486420917.23.0.756328202655.issue28686@psf.upfronthosting.co.za> Steve Dower added the comment: > If Python on Windows changed to ship python3.exe and python37.exe alongside python.exe, then it might be worth revisiting this discussion Agreed, though if we started including versioned executables wouldn't that resolve this issue naturally? (As in, we'd search for python3.exe and find it?) FWIW, I'm not a huge fan of including versioned executables - I would much rather include versioned *launchers*, so we can put them all in the one directory and avoid cluttering the search path (i.e. rename "py.exe" to "python.exe", "python2.exe" and "python3.exe" and have it check its own name before searching). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 17:52:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 22:52:45 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486421565.85.0.88855188216.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, benchmark results don't seem good. There is probably a performance bug somewhere. I should investigate further to analyze these results. M aybe combined with the issue #29465, results will be better. haypo at speed-python$ python3 -m perf compare_to ~/benchmarks/2017-02-06_07-15-default-e06af4027546.json fastcall-no-keywords_ref_e06af4027546.json -G --min-speed=5 Slower (19): - unpickle_list: 6.36 us +- 0.11 us -> 8.08 us +- 0.14 us: 1.27x slower (+27%) - pickle_list: 7.53 us +- 0.41 us -> 8.62 us +- 0.49 us: 1.14x slower (+14%) - crypto_pyaes: 199 ms +- 2 ms -> 226 ms +- 2 ms: 1.13x slower (+13%) - pickle: 22.1 us +- 0.3 us -> 24.9 us +- 0.3 us: 1.12x slower (+12%) - nbody: 233 ms +- 2 ms -> 260 ms +- 2 ms: 1.12x slower (+12%) - xml_etree_iterparse: 179 ms +- 4 ms -> 198 ms +- 5 ms: 1.11x slower (+11%) - telco: 14.7 ms +- 0.3 ms -> 16.3 ms +- 0.5 ms: 1.11x slower (+11%) - pickle_dict: 56.6 us +- 4.3 us -> 62.7 us +- 4.7 us: 1.11x slower (+11%) - pidigits: 291 ms +- 1 ms -> 319 ms +- 1 ms: 1.10x slower (+10%) - scimark_fft: 662 ms +- 10 ms -> 717 ms +- 8 ms: 1.08x slower (+8%) - scimark_monte_carlo: 207 ms +- 4 ms -> 224 ms +- 6 ms: 1.08x slower (+8%) - regex_v8: 43.7 ms +- 0.6 ms -> 47.0 ms +- 0.3 ms: 1.08x slower (+8%) - float: 238 ms +- 3 ms -> 254 ms +- 4 ms: 1.07x slower (+7%) - xml_etree_parse: 242 ms +- 5 ms -> 257 ms +- 9 ms: 1.06x slower (+6%) - raytrace: 1.04 sec +- 0.01 sec -> 1.11 sec +- 0.01 sec: 1.06x slower (+6%) - unpickle: 30.0 us +- 0.3 us -> 31.8 us +- 0.3 us: 1.06x slower (+6%) - go: 493 ms +- 7 ms -> 520 ms +- 6 ms: 1.05x slower (+5%) - scimark_sparse_mat_mult: 8.24 ms +- 0.14 ms -> 8.69 ms +- 0.14 ms: 1.05x slower (+5%) - chaos: 234 ms +- 2 ms -> 246 ms +- 4 ms: 1.05x slower (+5%) Faster (2): - chameleon: 21.9 ms +- 0.2 ms -> 20.7 ms +- 0.3 ms: 1.06x faster (-5%) - sympy_expand: 949 ms +- 12 ms -> 899 ms +- 11 ms: 1.06x faster (-5%) Benchmark hidden because not significant (43): (...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 17:53:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 22:53:33 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <20170206225330.96359.41527.77510C62@psf.io> Roundup Robot added the comment: New changeset 4463e311f5bd by Steve Dower in branch '3.6': Issue #28164: Improves test on Windows 7 https://hg.python.org/cpython/rev/4463e311f5bd New changeset 8132bcc1522d by Steve Dower in branch 'default': Issue #28164: Improves test on Windows 7 https://hg.python.org/cpython/rev/8132bcc1522d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 17:54:02 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 06 Feb 2017 22:54:02 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486421642.93.0.931092352552.issue28164@psf.upfronthosting.co.za> Steve Dower added the comment: That test looks good for me, and I verified it on both Win7 and Win10. (Hopefully we don't have any Win8.1 edge cases in here...) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 18:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 23:00:26 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486422026.82.0.771201667133.issue28164@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 'master': Issue #28164: Improves test on Windows 7 https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b New changeset dc5c4bc90770d6a5875666434cf797c77eb3dcad by Steve Dower in branch 'master': Issue #28164: Improves test on Windows 7 https://github.com/python/cpython/commit/dc5c4bc90770d6a5875666434cf797c77eb3dcad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 18:00:30 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Feb 2017 23:00:30 +0000 Subject: [issue28164] _PyIO_get_console_type fails for various paths In-Reply-To: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za> Message-ID: <1486422030.41.0.615881009026.issue28164@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch '3.6': Issue #28164: Improves test on Windows 7 https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 18:59:48 2017 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Feb 2017 23:59:48 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486425588.31.0.138912787082.issue28686@psf.upfronthosting.co.za> Paul Moore added the comment: I agree, I don't particularly want versioned executables. I'm not sure I see much point to even having versioned launchers - "py -2" and "py -3" seem fine to me if needed. The only use cases I can see are: 1. Use the Python executable that's first on PATH: "py" 2. Use the specific system installation of Python X[.Y]: "py -X[.Y]" For shebang usage: 1. Use the Python executable that's first on PATH: "#!/usr/bin/env python" 2. Use the specific system installation of Python X[.Y]: "#!/usr/bin/pythonX[.Y]" 3. Use a specific interpreter: "#!" The Unix ability to have 2 different versions of Python on PATH and select which you use based on executable name doesn't exist on Windows, and so there's no equivalent of the Unix "#!/usr/bin/env pythonX[.Y]" If you want your script to fail under certain conditions - whether it's that the interpreter is a version you don't support, or something else, then test for that case and fail with an error. Checking runtime conditions doesn't need to be handled by the shebang. The only change I'd consider reasonable here would be a doc change to explain the behaviour a bit more clearly. I might try to put something together if I have the time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 19:55:03 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 07 Feb 2017 00:55:03 +0000 Subject: [issue29467] Allow return mismatch to be caught by function In-Reply-To: <1486415491.45.0.543077011727.issue29467@psf.upfronthosting.co.za> Message-ID: <1486428903.87.0.808852385461.issue29467@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks for the suggestion. However, I don't think it's possible or desirable for python to implement this. There are two problems: 1) the internals of python would have to be drastically changed to support this, and 2) you'd need different syntax to support this. For item 2, consider: def f(): try: return some_other_function() except: return 1,2 You can't distinguish between your proposed type mis-match exception and some_other_function() raising a TypeError. I suppose you could invent another exception type, but you'll always have a similar problem. A larger problem is that this behavior would be confusing to both newcomers and existing programmers, it adds nothing that can't currently be done, and it would be a source of subtle bugs. If you really want to explore this, I suggest working out a more complete example and bringing it up on the python-ideas mailing list. You'll want to include code that currently exists that would be made simpler with your proposal. If you can find any such code in the standard library, that would be a bonus. Thanks again. ---------- nosy: +eric.smith resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 20:05:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 01:05:56 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486429556.71.0.707768672789.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: pyobject_fastcall-2.patch: More complete changes. Sorry, the patch also contains unrelated refactoring! It's a more advanced implementation which tries to reduce the depth of the C backtrace. For example, _PyObject_FastCall() is now inlined manually in _PyObject_FastCallDict(). PyObject_Call() is also rewritten. If the overall approach is validated, I will rewriten the patch differently to limit changes, or push some changes in multiple commits. Results of testcapi_stacksize.patch + stack_overflow_28870-sp.py (from issue #28870). Reference: haypo at smithers$ ../default-ref/python stack_overflow_28870-sp.py test_python_call: 8586 calls before crash, stack: 976 bytes/call test_python_getitem: 9188 calls before crash, stack: 912 bytes/call test_python_iterator: 7936 calls before crash, stack: 1056 bytes/call => total: 25710 calls, 2944 bytes Patch: haypo at smithers$ ./python stack_overflow_28870-sp.py test_python_call: 9883 calls before crash, stack: 848 bytes/call (-128 B) test_python_getitem: 10476 calls before crash, stack: 800 bytes/call (- 112 B) test_python_iterator: 8878 calls before crash, stack: 944 bytes/call (- 112 B) => total: 29237 calls (+3616), 2592 bytes (- 352 B) ---------- Added file: http://bugs.python.org/file46553/pyobject_fastcall-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 20:12:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 01:12:06 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486429926.41.0.728088629689.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot to rebase my local git branch: patch version 2 contains unrelated changes. Please see instead the path version 3 which was rebased. ---------- Added file: http://bugs.python.org/file46554/pyobject_fastcall-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 21:47:24 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 07 Feb 2017 02:47:24 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field In-Reply-To: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> Message-ID: <1486435644.45.0.526106972111.issue29466@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 22:04:16 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Feb 2017 03:04:16 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> Message-ID: <1486436656.04.0.750599432139.issue29449@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 22:14:05 2017 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 07 Feb 2017 03:14:05 +0000 Subject: [issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls Message-ID: <1486437245.45.0.651838453816.issue29468@psf.upfronthosting.co.za> New submission from Joe Jevnik: In zipfile.py only OSError is checked to see if seek fails: ``` def _EndRecData64(fpin, offset, endrec): """ Read the ZIP64 end-of-archive records and use that to update endrec """ try: fpin.seek(offset - sizeEndCentDir64Locator, 2) except OSError: # If the seek fails, the file is not large enough to contain a ZIP64 # end-of-archive record, so just return the end record we were given. return endrec ``` I belive that this should also catch ValueError so that other file-like objects may be passed to ZipFile. The particular case I ran into was passing an mmap object: ``` """ $ python p.py sys.version_info(major=3, minor=6, micro=0, releaselevel='final', serial=0) [] Traceback (most recent call last): File "p.py", line 34, in with mmap_shared_raw_zipfile(f.name) as zf: File "/usr/lib64/python3.6/contextlib.py", line 82, in __enter__ return next(self.gen) File "p.py", line 23, in mmap_shared_raw_zipfile ZipFile(mm) as zf: File "/usr/lib64/python3.6/zipfile.py", line 1100, in __init__ self._RealGetContents() File "/usr/lib64/python3.6/zipfile.py", line 1163, in _RealGetContents endrec = _EndRecData(fp) File "/usr/lib64/python3.6/zipfile.py", line 264, in _EndRecData return _EndRecData64(fpin, -sizeEndCentDir, endrec) File "/usr/lib64/python3.6/zipfile.py", line 196, in _EndRecData64 fpin.seek(offset - sizeEndCentDir64Locator, 2) ValueError: seek out of range """ from contextlib import contextmanager import mmap import sys from tempfile import NamedTemporaryFile from zipfile import ZipFile print(sys.version_info) @contextmanager def mmap_shared_raw_zipfile(path): """Open a zipfile with mmap shared so the data can be shared in multiple processes. Parameters ---------- path : str The path the zipfile to open. Notes ----- The context manager returns a :class:`zipfile.ZipFile` on enter. """ with open(path) as f, \ mmap.mmap(f.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ) as mm, \ ZipFile(mm) as zf: yield zf with NamedTemporaryFile() as f: ZipFile(f, mode='w').close() print(ZipFile(f.name).infolist()) with NamedTemporaryFile() as f: ZipFile(f, mode='w').close() with mmap_shared_raw_zipfile(f.name) as zf: print(zf.infolist()) ``` ---------- components: Library (Lib) messages: 287185 nosy: llllllllll priority: normal severity: normal status: open title: zipfile should catch ValueError as well as OSError to detect bad seek calls versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:02:39 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 04:02:39 +0000 Subject: [issue29469] AST-level Constant folding Message-ID: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> New submission from INADA Naoki: spin off of #11549. This patch uses code generator to traverse AST. ---------- files: ast-constant-folding.patch keywords: patch messages: 287186 nosy: inada.naoki priority: normal severity: normal status: open title: AST-level Constant folding versions: Python 3.7 Added file: http://bugs.python.org/file46555/ast-constant-folding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:02:52 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 04:02:52 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1486440172.04.0.00572317513141.issue29469@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- dependencies: +Change docstring to attribute from first statement. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:05:55 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 04:05:55 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1486440355.65.0.991160057849.issue11549@psf.upfronthosting.co.za> INADA Naoki added the comment: I submit new issues: * #29463 for AST change (change docstring from first statement to attribute). * #29469 for constant folding Note that this issue contains more peephole -> AST optimization changes. But I want to start these two patch to ease review and discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:19:03 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 04:19:03 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <20170207041900.96018.23768.9DF61DF0@psf.io> Roundup Robot added the comment: New changeset df62e833eeb1 by Mariatta Wijaya in branch '3.5': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://hg.python.org/cpython/rev/df62e833eeb1 New changeset c3d779f96b20 by Mariatta Wijaya in branch '3.6': Issue #29371: merge with 3.5 https://hg.python.org/cpython/rev/c3d779f96b20 New changeset e376d2bfde9b by Mariatta Wijaya in branch 'default': Issue #29371: merge with 3.6 https://hg.python.org/cpython/rev/e376d2bfde9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:30:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 04:30:23 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <20170207043020.8248.87225.467A4FB8@psf.io> Roundup Robot added the comment: New changeset 3fd198b80f29 by Mariatta Wijaya in branch '2.7': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://hg.python.org/cpython/rev/3fd198b80f29 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:32:00 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 07 Feb 2017 04:32:00 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486441920.47.0.643107848489.issue29371@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Marco, Jim, and Raymond :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:59:50 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Feb 2017 04:59:50 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486443590.83.0.639633099408.issue26355@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Thanks Nick, I can work on the similar patch for Python 2.7. I'll wait for the migration to GitHub which IIRC should be soon. Side question, is there some metrics (like google analytics) to know how much traffic there is on older Python docs and if it's worth patching ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 00:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 05:00:26 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486443626.38.0.198877989109.issue29371@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in branch '3.5': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 00:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 05:00:28 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486443628.44.0.896965496727.issue29371@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in branch 'master': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4 New changeset 141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 by Mariatta Wijaya in branch 'master': Issue #29371: merge with 3.5 https://github.com/python/cpython/commit/141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 New changeset bcc59e6131af582620c2db32e19d0a064d891a59 by Mariatta Wijaya in branch 'master': Issue #29371: merge with 3.6 https://github.com/python/cpython/commit/bcc59e6131af582620c2db32e19d0a064d891a59 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 00:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 05:00:31 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486443631.37.0.636672905527.issue29371@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 2b20a37791e3cc4536db1f99fc85ffb6e20134ab by Mariatta Wijaya in branch '2.7': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://github.com/python/cpython/commit/2b20a37791e3cc4536db1f99fc85ffb6e20134ab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 00:00:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 05:00:35 +0000 Subject: [issue29371] Typo in doctest documentation In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za> Message-ID: <1486443635.23.0.0163233895085.issue29371@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in branch '3.6': Issue #29371: Clarify bitwise OR operation in doctest option flags. https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4 New changeset 141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 by Mariatta Wijaya in branch '3.6': Issue #29371: merge with 3.5 https://github.com/python/cpython/commit/141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 01:06:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 06:06:38 +0000 Subject: [issue29314] asyncio.async deprecation warning is missing stacklevel=2 In-Reply-To: <1484770067.77.0.974182324744.issue29314@psf.upfronthosting.co.za> Message-ID: <20170207060635.111010.91875.CB59D3FD@psf.io> Roundup Robot added the comment: New changeset 0f5161f865d7 by Mariatta Wijaya in branch '3.5': Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning https://hg.python.org/cpython/rev/0f5161f865d7 New changeset 6dbe9051cdec by Mariatta Wijaya in branch '3.6': Issue #29314: Merge with 3.5 https://hg.python.org/cpython/rev/6dbe9051cdec New changeset 9f16900bebaa by Mariatta Wijaya in branch 'default': Issue #29314: Merge with 3.6 https://hg.python.org/cpython/rev/9f16900bebaa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 01:08:08 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 07 Feb 2017 06:08:08 +0000 Subject: [issue29314] asyncio.async deprecation warning is missing stacklevel=2 In-Reply-To: <1484770067.77.0.974182324744.issue29314@psf.upfronthosting.co.za> Message-ID: <1486447688.76.0.97610836318.issue29314@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks all :) ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 01:22:31 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 07 Feb 2017 06:22:31 +0000 Subject: [issue29470] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 Message-ID: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): (Only 3.[56] tested) my application listens on an SSL wrapped port, accepts socket and gets an incoming set of messages. connection time frame is several seconds but due to bad Comcast service frequently we have outages which hang connections. almost every day python crashes as follows: Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 *** Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 *** Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in viola Feb 07 02:36:11 ranger.blue-labs.org python[11816]: ======= Backtrace: ========= Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(RSA_free+0x6f)[0x7f62a5d99a2f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(EVP_PKEY_free+0x4a)[0x7f62a5dcdcea] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(+0x163780)[0x7f62a5de5780] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x450)[0x7f62a5debf00] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x567)[0x7f62a5dec017] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_item_free+0x1fb)[0x7f62a5dec2fb] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate+0xc4)[0x7f62a4ee3d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate_chain_file+0x7f)[0x7f62a4ee490f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xe77d)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyCFunction_Call+0xe9)[0x7f62a8ac4be9] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x78a1)[0x7f62a8b3b941] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_CallFunctionObjArgs+0xc2)[0x7f62a8a7dec2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0x9c46)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl_parse_clienthello_tlsext+0x648)[0x7f62a4ec9838] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_get_client_hello+0x6fa)[0x7f62a4eadeca] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_accept+0x66f)[0x7f62a4eb27af] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xc3a9)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x843c)[0x7f62a8b3c4dc] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: ======= Backtrace: ========= Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(RSA_free+0x6f)[0x7f62a5d99a2f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(EVP_PKEY_free+0x4a)[0x7f62a5dcdcea] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(+0x163780)[0x7f62a5de5780] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x450)[0x7f62a5debf00] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x567)[0x7f62a5dec017] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x5d8e)[0x7f62a8b39e2e] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_item_free+0x1fb)[0x7f62a5dec2fb] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate+0xc4)[0x7f62a4ee3d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate_chain_file+0x7f)[0x7f62a4ee490f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xe77d)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyCFunction_Call+0xe9)[0x7f62a8ac4be9] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x78a1)[0x7f62a8b3b941] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_CallFunctionObjArgs+0xc2)[0x7f62a8a7dec2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0x9c46)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl_parse_clienthello_tlsext+0x648)[0x7f62a4ec9838] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_get_client_hello+0x6fa)[0x7f62a4eadeca] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_accept+0x66f)[0x7f62a4eb27af] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xc3a9)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x843c)[0x7f62a8b3c4dc] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x5d8e)[0x7f62a8b39e2e] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc5110)[0x7f62a8ada110] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc3475)[0x7f62a8ad8475] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x3d6b)[0x7f62a8b37e0b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x930c5)[0x7f62a8aa80c5] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0xee6)[0x7f62a8b34f86] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f62a8b33da7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1629a2)[0x7f62a8b779a2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpthread.so.0(+0x7454)[0x7f62a87ff454] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(clone+0x5f)[0x7f62a85427df] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc5110)[0x7f62a8ada110] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc3475)[0x7f62a8ad8475] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x3d6b)[0x7f62a8b37e0b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x930c5)[0x7f62a8aa80c5] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0xee6)[0x7f62a8b34f86] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f62a8b33da7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1629a2)[0x7f62a8b779a2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpthread.so.0(+0x7454)[0x7f62a87ff454] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(clone+0x5f)[0x7f62a85427df] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-797 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-798 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-794 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-796 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-795 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: cutils.cpython-35m-x86_64-linux-gnu.so (deleted) i've restarted this under valgrind to debug it. valgrind's startup of python 3.6 is depressingly filled with invalid read of size n, conditional jump/move on uninitialized value, use of uninitialized value; mostly in libpython3.6m. ---------- assignee: christian.heimes components: SSL messages: 287198 nosy: David Ford (FirefighterBlu3), christian.heimes priority: normal severity: normal status: open title: Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 01:32:28 2017 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 07 Feb 2017 06:32:28 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486449148.77.0.876359944599.issue29464@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks for asking. Cython doesn't use METH_FASTCALL yet, so this doesn't introduce any problems. Generally speaking, if Cython generated user code stops working with a new CPython version, we expect people to regenerate their code with the newest Cython version to fix it, so this kind of internal incompatibility is usually reparable by adapting Cython appropriately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 02:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 07:00:24 +0000 Subject: [issue29314] asyncio.async deprecation warning is missing stacklevel=2 In-Reply-To: <1484770067.77.0.974182324744.issue29314@psf.upfronthosting.co.za> Message-ID: <1486450824.65.0.568099323341.issue29314@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in branch 'master': Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5 New changeset 22fce50aa151160540326001ace1e0826f6323a1 by Mariatta Wijaya in branch 'master': Issue #29314: Merge with 3.5 https://github.com/python/cpython/commit/22fce50aa151160540326001ace1e0826f6323a1 New changeset 2ef05ee4f1c721732918c8839b0b3ac5f1c807a7 by Mariatta Wijaya in branch 'master': Issue #29314: Merge with 3.6 https://github.com/python/cpython/commit/2ef05ee4f1c721732918c8839b0b3ac5f1c807a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 02:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 07:00:27 +0000 Subject: [issue29314] asyncio.async deprecation warning is missing stacklevel=2 In-Reply-To: <1484770067.77.0.974182324744.issue29314@psf.upfronthosting.co.za> Message-ID: <1486450827.5.0.630382528546.issue29314@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in branch '3.6': Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5 New changeset 22fce50aa151160540326001ace1e0826f6323a1 by Mariatta Wijaya in branch '3.6': Issue #29314: Merge with 3.5 https://github.com/python/cpython/commit/22fce50aa151160540326001ace1e0826f6323a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 02:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 07:00:29 +0000 Subject: [issue29314] asyncio.async deprecation warning is missing stacklevel=2 In-Reply-To: <1484770067.77.0.974182324744.issue29314@psf.upfronthosting.co.za> Message-ID: <1486450829.18.0.940402209045.issue29314@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in branch '3.5': Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 02:36:10 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Feb 2017 07:36:10 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486452970.26.0.31256971561.issue26355@psf.upfronthosting.co.za> Berker Peksag added the comment: Patch looks good to me too, thanks! Just left a super minor comment on Rietveld. You might want to commit this to 3.5+ because we don't daily build 3.4 docs anymore: https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L30 I didn't see any links from 2.6 or older Python 2 versions in search results before so I don't have a strong opinion on backporting the patch to 2.7 (I probably wouldn't bother with Python 2 docs anymore :)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 02:49:54 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 07 Feb 2017 07:49:54 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1486453794.93.0.931388651967.issue29470@psf.upfronthosting.co.za> Changes by David Ford (FirefighterBlu3) : ---------- title: Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 -> [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:17:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 08:17:32 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486455452.07.0.141360074087.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Benchmarks result. Some are slower (code placement issue?), the faster benchmark are not really much faster. haypo at speed-python$ python3 -m perf compare_to /home/haypo/benchmarks/2017-02-06_07-15-default-e06af4027546.json pyobject_fastcall-3_ref_e06af4027546.json -G --min-speed=4 Slower (4): - scimark_lu: 352 ms +- 11 ms -> 374 ms +- 15 ms: 1.06x slower (+6%) - float: 238 ms +- 3 ms -> 251 ms +- 4 ms: 1.05x slower (+5%) - logging_silent: 558 ns +- 15 ns -> 585 ns +- 16 ns: 1.05x slower (+5%) - raytrace: 1.04 sec +- 0.01 sec -> 1.09 sec +- 0.01 sec: 1.05x slower (+5%) Faster (5): - nbody: 233 ms +- 2 ms -> 216 ms +- 2 ms: 1.08x faster (-7%) - pickle_dict: 56.6 us +- 4.3 us -> 52.9 us +- 2.2 us: 1.07x faster (-6%) - nqueens: 217 ms +- 2 ms -> 205 ms +- 2 ms: 1.06x faster (-6%) - unpickle_pure_python: 670 us +- 11 us -> 642 us +- 8 us: 1.04x faster (-4%) - scimark_sor: 405 ms +- 11 ms -> 389 ms +- 10 ms: 1.04x faster (-4%) Benchmark hidden because not significant (55): (...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:22:57 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 08:22:57 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <20170207082254.15965.54283.BD423A5F@psf.io> Roundup Robot added the comment: New changeset 514571268743 by Berker Peksag in branch '3.5': Issue #29441: Update examples to use async and await keywords in asyncio-task.rst https://hg.python.org/cpython/rev/514571268743 New changeset 975e03b0aea6 by Berker Peksag in branch '3.6': Issue #29441: Merge from 3.5 https://hg.python.org/cpython/rev/975e03b0aea6 New changeset ee074604bf0c by Berker Peksag in branch 'default': Issue #29441: Merge from 3.6 https://hg.python.org/cpython/rev/ee074604bf0c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:23:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Feb 2017 08:23:53 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486455833.71.0.661089964298.issue29441@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the reviews! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:28:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 08:28:44 +0000 Subject: [issue29463] Change docstring to attribute from first statement. In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486456124.75.0.681661426893.issue29463@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the change because (IMHO) it makes the code simpler, and becase it also changes the first line of code object. I reviewed the patch: need basic unit tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:29:16 2017 From: report at bugs.python.org (Alessandro Vesely) Date: Tue, 07 Feb 2017 08:29:16 +0000 Subject: [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() In-Reply-To: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> Message-ID: <1486456156.48.0.822772996746.issue29462@psf.upfronthosting.co.za> Alessandro Vesely added the comment: We can close this, then. Let's hope migration to Python3 isn't going to last forever... Thank you for your cooperation ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:30:38 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 08:30:38 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486456238.79.0.765778116954.issue29438@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file46556/29438-sharedkey-useafterfree-py36.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:40:04 2017 From: report at bugs.python.org (Marco Buttu) Date: Tue, 07 Feb 2017 08:40:04 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486456804.08.0.201030004789.issue22594@psf.upfronthosting.co.za> Marco Buttu added the comment: IMHO the reference proposed in the patch is too verbose. Adding details like what is supported and how to use some features I think is out of the scope of the reference. Moreover, if the regex module changes the features we are reporting in the reference, we'll have an outdated reference. In addition, as Brett Cannon pointed out in msg287159, the preferred way to mention a 3rd-party library should be by adding the reference at the top of the page, as in Doc/library/urllib.request.rst:19. I propose to just add a more concise reference, at the beginning of the page, like the following: .. seealso:: `regex `_, a third-party alternative regular expression module. ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 03:55:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 08:55:31 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1486457731.28.0.702396640425.issue29469@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggest you to look at my AST optimizer, especially the constant folding part: https://github.com/haypo/fatoptimizer/blob/master/fatoptimizer/const_fold.py And the unit tests, search for BaseConstantFoldingTests: https://github.com/haypo/fatoptimizer/blob/master/test_fatoptimizer.py#L1980 IHMO we must have a long test suite on this AST optimizer, because it's common that the AST changes in subtle ways, AST is complex and so we should prevent regressions. You may simply copy my unit tests. My optimizer implements more optimization: just remove unit tests on cases which you don't want to optimize. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 09:00:24 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486458024.67.0.332836508069.issue29441@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset dbfbdf9dce7889699e1eb7cc4644a911b16665ec by Berker Peksag in branch '3.6': Issue #29441: Update examples to use async and await keywords in asyncio-task.rst https://github.com/python/cpython/commit/dbfbdf9dce7889699e1eb7cc4644a911b16665ec New changeset f76fb14796715fc5abb5a2b68428b29063c3d48e by Berker Peksag in branch '3.6': Issue #29441: Merge from 3.5 https://github.com/python/cpython/commit/f76fb14796715fc5abb5a2b68428b29063c3d48e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:00:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 09:00:26 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486458026.56.0.61831974598.issue29441@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset dbfbdf9dce7889699e1eb7cc4644a911b16665ec by Berker Peksag in branch '3.5': Issue #29441: Update examples to use async and await keywords in asyncio-task.rst https://github.com/python/cpython/commit/dbfbdf9dce7889699e1eb7cc4644a911b16665ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:00:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Feb 2017 09:00:28 +0000 Subject: [issue29441] Update examples to use async and await keywords in asyncio-task.rst In-Reply-To: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> Message-ID: <1486458028.61.0.567297723983.issue29441@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset dbfbdf9dce7889699e1eb7cc4644a911b16665ec by Berker Peksag in branch 'master': Issue #29441: Update examples to use async and await keywords in asyncio-task.rst https://github.com/python/cpython/commit/dbfbdf9dce7889699e1eb7cc4644a911b16665ec New changeset f76fb14796715fc5abb5a2b68428b29063c3d48e by Berker Peksag in branch 'master': Issue #29441: Merge from 3.5 https://github.com/python/cpython/commit/f76fb14796715fc5abb5a2b68428b29063c3d48e New changeset 38c1fd9055ad58738643325a2c7682d76496f9ed by Berker Peksag in branch 'master': Issue #29441: Merge from 3.6 https://github.com/python/cpython/commit/38c1fd9055ad58738643325a2c7682d76496f9ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:01:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 09:01:57 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1486458117.72.0.601000722772.issue29469@psf.upfronthosting.co.za> STINNER Victor added the comment: With this change, the Python compiler doesn't emit ast.Num nor ast.Str, right? If we merge such change, we should prepare projects using AST. There is something like that in pip, but I failed to remind which one :-/ It should be easy: apply your patch, try to install something using pip and see the traceback ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:08:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 09:08:06 +0000 Subject: [issue29463] Change docstring to attribute from first statement. In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486458486.46.0.616158069357.issue29463@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I like this change. Added comments on Rietveld. Are changes in importlib.h only due to changing first line numbers? ---------- components: +Interpreter Core nosy: +benjamin.peterson, georg.brandl, serhiy.storchaka stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:08:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 09:08:59 +0000 Subject: [issue29471] AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines Message-ID: <1486458539.58.0.744778606798.issue29471@psf.upfronthosting.co.za> New submission from STINNER Victor: Currently, symtable_visit_expr() has browse into the AST tree to look up yield, yield from or await to check if a function is a generator or a coroutine. If we choose to start to work on AST optimizers, I would suggest to add an attribute to ast.FunctionDef to announce if a function is a generator or a coroutine. Currently, the peephole optimizer is unable to remove the deadcode, because otherwise the function is no more detected as a generator: def generator(): if 0: yield # "hack" to get a generator pass By the way, it would be nice to add a keyword similar to "async def" to be able to explicitly "document" generators as generators, and avoid the "if 0: yield" hack, but that's a different topic ;-) I feel less confortable to modify the Python language. ---------- components: Interpreter Core messages: 287216 nosy: haypo, inada.naoki, yselivanov priority: normal severity: normal status: open title: AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:09:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 09:09:18 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1486458558.81.0.247436476875.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the issue #29471: "AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:10:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 09:10:57 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1486458657.52.0.138600942046.issue29469@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, serhiy.storchaka, yselivanov stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:32:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 09:32:32 +0000 Subject: [issue29425] File-altering aspects of pathlib should return new pathlib objects In-Reply-To: <1486080253.05.0.537199940287.issue29425@psf.upfronthosting.co.za> Message-ID: <1486459952.41.0.273205321236.issue29425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Path.rename() is simple wrapper around os.rename() and returns the result of os.rename(). If os.rename() became returning something useful, this change will made impossible to return it from Path.rename(). Why not create destination Path object explicitly? bar_var = pathlib.PosixPath('bar') foo_var = pathlib.PosixPath('foo') bar_var.rename(foo_var) Note, that in 3.6 you can also write os.rename(bar_var, foo_var) ---------- nosy: +pitrou, serhiy.storchaka versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:33:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 09:33:55 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1486460035.71.0.373729782207.issue29453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't know. David, Raymond, what are your thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:47:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 09:47:15 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1486460835.11.0.457732217883.issue29470@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.6 got a new PYTHONMALLOC env var which should help you ;-) Please try to get the Python traceback on the crash and use Python builtin memory debugger: PYTHONMALLOC=debug python3 -X faulthandler ... > i've restarted this under valgrind to debug it. valgrind's startup of python 3.6 is depressingly filled with invalid read of size n, (...) Python memory allocator pymalloc causes false alarms. You can disable pymalloc to use Valgrind using: PYTHONMALLOC=malloc valgrind python3 ... ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:53:51 2017 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Tue, 07 Feb 2017 09:53:51 +0000 Subject: [issue29471] AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines In-Reply-To: <1486458539.58.0.744778606798.issue29471@psf.upfronthosting.co.za> Message-ID: <1486461231.76.0.600388507821.issue29471@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: I remember the message from Guido, long time ago when the syntax of generators was discussed. He said he has a hunch that new keyword will not be necessary, that the presence of yield will be enough. It'd be interesting to see if he has changed his mind, or he has some other excuse about async being fundamentally different. :-) ---------- nosy: +veky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:59:30 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Feb 2017 09:59:30 +0000 Subject: [issue29256] Windows select() errors out when given no fds to select on, which breaks SelectSelector In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za> Message-ID: <1486461570.53.0.91940542807.issue29256@psf.upfronthosting.co.za> Berker Peksag added the comment: See http://bugs.python.org/issue25680#msg255116 for Guido's comment on platform differences. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 05:12:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 10:12:40 +0000 Subject: [issue29256] Windows select() errors out when given no fds to select on, which breaks SelectSelector In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za> Message-ID: <1486462360.39.0.128265998973.issue29256@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 05:14:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 10:14:44 +0000 Subject: [issue29256] Windows select() errors out when given no fds to select on, which breaks SelectSelector In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za> Message-ID: <1486462484.46.0.892702090031.issue29256@psf.upfronthosting.co.za> STINNER Victor added the comment: > 2) Modify the select.select() wrapper so that it behaves consistently on all operating systems, by special-casing this situation on Windows. Please don't do that. In Python, we have a long tradition of trying to provide thin wrappers to OS functions: os and select modules are good example. To abstract the OS, there are higher level modules like: os=>shutil and select=>selectors. About the Windows issue: I don't know what is the best fix (if any). The minimum change is to document Windows's special case in Python doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 05:16:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 10:16:13 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486462573.35.0.333532267911.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, pyobject_fastcall-3.patch contains a performance bug :-p PyObject_Call() "unpacks" the tuple and then recreates a new tuple to call functions in for functions other than Python and C functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 05:48:22 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 07 Feb 2017 10:48:22 +0000 Subject: [issue29256] Windows select() errors out when given no fds to select on, which breaks SelectSelector In-Reply-To: <1484264538.85.0.902649207203.issue29256@psf.upfronthosting.co.za> Message-ID: <1486464502.52.0.00131985038855.issue29256@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > Please don't do that. In Python, we have a long tradition of trying to provide thin wrappers to OS functions: os and select modules are good example. I don't find this argument terribly convincing... Python also has a long history of papering over small issues when it can be done in a simple and tasteful way. select.select already overrides the Windows default for the maximum number of FDs, and the PEP 475 retry logic is definitely a non-trivial modification to the raw OS select semantics. But I don't think it matters terribly much either, so long as we all agree that the SelectSelector behavior is definitely a bug :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:00:15 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Feb 2017 11:00:15 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486465215.84.0.666997241854.issue26355@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I've marked 2.7 and 3.5+ as the minimal set of versions to get the change via the CPython source repo. However, looking at the results of https://www.google.com/search?q=python+httplib and https://www.google.com/search?q=python+http+client I think it's going to be worth backfilling the old branches as well - having multiple different versions of the 3.x documentation showing up in search results isn't helpful to anyone. ---------- versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:32:27 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 11:32:27 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1486467147.92.0.0470122601054.issue29469@psf.upfronthosting.co.za> INADA Naoki added the comment: Do you mean https://github.com/pypa/pip/blob/403e398330c8e841e4633aceda859430f5f7b913/pip/_vendor/distlib/markers.py ? This doesn't affect, maybe. Constant folding is executed right before producing bytecode. It doesn't affect to PyCF_ONLY_AST. BTW, how do you feel asdl_ct.py? I feel it's too much only for constant folding, but it is too less for other advanced optimizations. Actually, original patch in #11549 implements other optimizations ported from peephole in compile.c. And most tough part of updating this patch is resolve conflict with this commit. https://github.com/python/cpython/commit/9cea398e237d4d75c6012e23a33d01b17f5dffcc I'll try to remove asdl_ct.py and ast_opt.ct in next version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:35:35 2017 From: report at bugs.python.org (Guillaume Boudreau) Date: Tue, 07 Feb 2017 11:35:35 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1486467335.03.0.432056063379.issue24363@psf.upfronthosting.co.za> Guillaume Boudreau added the comment: Any chance this could get reviewed and merged soon? I got hit by a similar issue (see #29445) where the server, which I don't control, sends me invalid HTTP headers, and the prevents all the headers that follow it to not be parsed. The latest attached patch fixed the issue for me. Thanks. ---------- nosy: +gboudreau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:45:32 2017 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 07 Feb 2017 11:45:32 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486467932.25.0.612284891914.issue22594@psf.upfronthosting.co.za> Matthew Barnett added the comment: I agree with Marco that it shouldn't be too verbose. I'd like to suggest that it says that it's compatible (i.e. has the same API), but with additional features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:57:14 2017 From: report at bugs.python.org (Maurice van der Pot) Date: Tue, 07 Feb 2017 11:57:14 +0000 Subject: [issue29472] subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux Message-ID: <1486468634.65.0.790221754194.issue29472@psf.upfronthosting.co.za> New submission from Maurice van der Pot: This only happens when: - timeout is small enough - at least one stream is redirected to a PIPE When I know for certain that a subprocess has already terminated and I call communicate to retrieve its results with a timeout of 0 (or other small enough value), communicate will always return TimeoutExpired. The cause is that the check on timeout is done before the ready file descriptors are checked: https://hg.python.org/cpython/file/tip/Lib/subprocess.py#l1484. With a small enough timeout, communicate will never check the file descriptors for EOF. >From a user perspective I would expect to be able to use communicate(timeout=0) to get the output for a process that I know has already terminated or to poll without blocking. Is this the intended behaviour of communicate or is it a bug? To me this behaviour is surprising. ---------- components: Library (Lib) messages: 287230 nosy: Griffon26 priority: normal severity: normal status: open title: subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:58:21 2017 From: report at bugs.python.org (Maurice van der Pot) Date: Tue, 07 Feb 2017 11:58:21 +0000 Subject: [issue29472] subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux In-Reply-To: <1486468634.65.0.790221754194.issue29472@psf.upfronthosting.co.za> Message-ID: <1486468701.42.0.335074583054.issue29472@psf.upfronthosting.co.za> Changes by Maurice van der Pot : Added file: http://bugs.python.org/file46557/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 07:23:43 2017 From: report at bugs.python.org (Kaeptm Blaubaer) Date: Tue, 07 Feb 2017 12:23:43 +0000 Subject: [issue27727] Update Tools/freeze to use .vcxproj files In-Reply-To: <1470839867.79.0.0217135468923.issue27727@psf.upfronthosting.co.za> Message-ID: <1486470223.75.0.621066966384.issue27727@psf.upfronthosting.co.za> Changes by Kaeptm Blaubaer : ---------- type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 07:23:49 2017 From: report at bugs.python.org (Kaeptm Blaubaer) Date: Tue, 07 Feb 2017 12:23:49 +0000 Subject: [issue27727] Update Tools/freeze to use .vcxproj files In-Reply-To: <1470839867.79.0.0217135468923.issue27727@psf.upfronthosting.co.za> Message-ID: <1486470229.82.0.0974161429708.issue27727@psf.upfronthosting.co.za> Changes by Kaeptm Blaubaer : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 07:36:53 2017 From: report at bugs.python.org (spoorcc) Date: Tue, 07 Feb 2017 12:36:53 +0000 Subject: [issue29472] subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux In-Reply-To: <1486468634.65.0.790221754194.issue29472@psf.upfronthosting.co.za> Message-ID: <1486471013.48.0.554224517679.issue29472@psf.upfronthosting.co.za> Changes by spoorcc : ---------- nosy: +spoorcc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 08:06:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 13:06:40 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486472800.4.0.137390519374.issue29464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There was a bug in previous patch. The signature of generated by Argument Clinic functions was not changed. Updated patch fixes this bug and also fixes the use of fast call in deque methods. ---------- Added file: http://bugs.python.org/file46558/fastcall-no-keywords-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 08:10:26 2017 From: report at bugs.python.org (Joel Uckelman) Date: Tue, 07 Feb 2017 13:10:26 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1486473026.54.0.716921390809.issue29412@psf.upfronthosting.co.za> Joel Uckelman added the comment: I'm working on a patch now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 09:02:42 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 07 Feb 2017 14:02:42 +0000 Subject: [issue29439] _decimal on Android requires linking with libm In-Reply-To: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> Message-ID: <1486476162.8.0.158364015004.issue29439@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Actually my device is 6.0. Seems there's nothing interesting between API 23 and 24 on android-changes-for-ndk-developers.md :) Anyway, _decimal should not depend on the whether the python binary references to libm.so or not. Instead, _decimal should explicitly have an explicit DT_NEEDED entry to libm.so if it uses symbols from libm. > Strange that on other systems the compilers don't complain (usually they do). I guess on most system python is built with --enable-shared, so _decimal.so has an entry to libpython3.7m.so, and the latter references libm.so. If a linker supports recursive search, it can find the symbol. For future references, here's the partial output of logcat when I run python with `LD_DEBUG=3 python3.7m` and import _decimal: 02-07 19:43:25.697 10266 10266 linker D DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in python3.7m (from global group) 02-07 19:43:25.697 10266 10266 linker I SEARCH log10 in python3.7m at 0x55634f3000 h=735a40(elf) 452 02-07 19:43:25.697 10266 10266 linker I NOT FOUND log10 in python3.7m at 0x55634f3000 735a40 452 02-07 19:43:25.698 10266 10266 linker D DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /system/vendor/lib64/libNimsWrap.so (from global group) 02-07 19:43:25.698 10266 10266 linker I SEARCH log10 in /system/vendor/lib64/libNimsWrap.so at 0x7f7c5fb000 (gnu) 02-07 19:43:25.698 10266 10266 linker I NOT FOUND log10 in /system/vendor/lib64/libNimsWrap.so at 0x7f7c5fb000 02-07 19:43:25.698 10266 10266 linker D DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so (from local group) 02-07 19:43:25.698 10266 10266 linker I SEARCH log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so at 0x7f7c157000 h=735a40(elf) 49 02-07 19:43:25.698 10266 10266 linker I NOT FOUND log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so at 0x7f7c157000 735a40 49 02-07 19:43:25.698 10266 10266 linker D DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in libdl.so (from local group) 02-07 19:43:25.698 10266 10266 linker I SEARCH log10 in libdl.so at 0x0 h=735a40(elf) 0 02-07 19:43:25.698 10266 10266 linker I NOT FOUND log10 in libdl.so at 0x0 735a40 0 02-07 19:43:25.698 10266 10266 linker D DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /system/lib64/libc.so (from local group) 02-07 19:43:25.698 10266 10266 linker I SEARCH log10 in /system/lib64/libc.so at 0x7f7c4f6000 (gnu) 02-07 19:43:25.698 10266 10266 linker I NOT FOUND log10 in /system/lib64/libc.so at 0x7f7c4f6000 02-07 19:43:25.698 10266 10266 linker D DEBUG: cannot locate symbol "log10" referenced by "/data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so"... And BioniC's linker only checks HASH table of ELF: https://android.googlesource.com/platform/bionic/+/master/linker/linker_soinfo.cpp#277, so log10 is not found in python3.7m > This is misleading Maybe it is. I mean "I didn't write a patch for _decimal at issue21668 as _decimal didn't build then" > Perhaps test_decimal should fail for CPython if _decimal can't be imported. I create a simple script to ensure all installed dynamic modules can be imported: https://github.com/yan12125/python3-android/blob/master/devscripts/import_all.py. It may be worth to transform it into a proper unittest and put it into Lib/test/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 09:46:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 14:46:05 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486478765.19.0.794418100386.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I fixed the PyObject_Call() bug, and tried a new approach to help the compiler for code placement: I moved all "call" functions into a new Objects/call.c file. It should help the compiler to inline more code, and I move functions which call themself closer: _PyObject_FastCall(), _PyCFunction_FastCall() and _PyFunction_FastCall() are now very close in the same file for example. Not only the stack usage is better, but the performance seems also better: see benchmark results below. Again, if you like the _PyObject_FastCall() idea (to reduce the stack consumption), I will split my big patch into smaller patches to have a "smoother" hg/git history. Benchmark results on speed-python, CPython compiled with LTO+PGO: haypo at speed-python$ python3 -m perf compare_to /home/haypo/benchmarks/2017-02-06_07-15-default-e06af4027546.json pyobject_fastcall-4_ref_e06af4027546.json -G --min-speed=4 Faster (11): - sympy_expand: 949 ms +- 12 ms -> 878 ms +- 7 ms: 1.08x faster (-8%) - chameleon: 21.9 ms +- 0.2 ms -> 20.5 ms +- 0.3 ms: 1.07x faster (-7%) - sympy_str: 425 ms +- 5 ms -> 399 ms +- 5 ms: 1.07x faster (-6%) - sympy_integrate: 40.8 ms +- 0.3 ms -> 38.3 ms +- 0.4 ms: 1.06x faster (-6%) - sympy_sum: 192 ms +- 6 ms -> 181 ms +- 7 ms: 1.06x faster (-6%) - scimark_lu: 352 ms +- 11 ms -> 332 ms +- 13 ms: 1.06x faster (-6%) - xml_etree_generate: 208 ms +- 2 ms -> 197 ms +- 3 ms: 1.05x faster (-5%) - nbody: 233 ms +- 2 ms -> 222 ms +- 3 ms: 1.05x faster (-5%) - telco: 14.7 ms +- 0.3 ms -> 14.0 ms +- 0.3 ms: 1.05x faster (-5%) - scimark_fft: 662 ms +- 10 ms -> 633 ms +- 8 ms: 1.05x faster (-4%) - genshi_text: 71.0 ms +- 0.8 ms -> 68.3 ms +- 0.7 ms: 1.04x faster (-4%) Benchmark hidden because not significant (53): (...) ---------- Added file: http://bugs.python.org/file46559/pyobject_fastcall-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:04:37 2017 From: report at bugs.python.org (Vladimir Feinberg) Date: Tue, 07 Feb 2017 15:04:37 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1486479877.95.0.879386766196.issue19675@psf.upfronthosting.co.za> Vladimir Feinberg added the comment: I'm still hitting this issue in Python 3.6.0 :: Anaconda 4.3.0 (64-bit). Is there a reason this patch has been ignored? This is on CentOS release 6.5 ---------- nosy: +Vladimir Feinberg versions: +Python 3.6 -Python 2.7, Python 3.3 Added file: http://bugs.python.org/file46560/trace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:05:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 15:05:00 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486479900.64.0.461659535263.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, with pyobject_fastcall-4.patch, the stack usage of test_python_iterator is even better. The reference is 1056 bytes/call, pyobject_fastcall-2.patch was 944 bytes/call. haypo at smithers$ ./python ../default/stack_overflow_28870-sp.py test_python_call: 9883 calls before crash, stack: 848 bytes/call test_python_getitem: 10476 calls before crash, stack: 800 bytes/call test_python_iterator: 9189 calls before crash, stack: 912 bytes/call => total: 29548 calls, 2560 bytes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:12:16 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Feb 2017 15:12:16 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1486480336.65.0.524636881738.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, I'm going to try to get to this this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:15:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 15:15:04 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486480504.22.0.659153839926.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, so I looked again at your change: fastcall-no-keywords-2.patch LGTM, I like the idea! Since your patch is huge, I expect that it will be a pain to rebase it. I suggest you to push it as soon as possible, to avoid conflicts. I will rework my issue #29465 patch once this issue is done. According to the number of modified functions and files, not accepting keyword arguments is very common, and so it is annoying to have to call _PyArg_NoStackKeywords() in each function. Avoiding the "PyObject *kwnames" can also reduces the stack consumption per call, especially in long call stacks. At least my assumption that almost no function will accept only positional arguments is plain wrong :-) In practice, it's more the opposite! I checked quickly fastcall-no-keywords-2.patch stack usage and performance. It seems non significant, but I'm not surprised, it isn't really the purpose of the change. IMHO the purpose of the change is more to simplify the code, avoid to duplicate _PyArg_NoStackKeywords() everywhere, and only check keyword arguments at one place. For stack consumption and performances, I got good results on my issue #29465 which adds a new _PyObject_FastCall() function. IMHO this function fits well with your new METH_FASTCALL (no keyword argument)! If we combine both changes, we can get something very good ;-) @Stefan Behnel: Thank you for you reply. So the backward compatibility was a fake issue, and we are free to modify METH_FASTCALL. Anyway, *if* someone uses METH_FASTCALL, IMHO it will be easy to update his/her code and add #ifdef on the Python version if needed. Again, as Serhiy wrote, METH_FASTCALL is out of the stable ABI, so we are safe on our warranties. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:21:16 2017 From: report at bugs.python.org (=?utf-8?b?0JLQsNC00LjQvCDQmtCw0YDQsA==?=) Date: Tue, 07 Feb 2017 15:21:16 +0000 Subject: [issue29473] subprocces check_output Message-ID: <1486480876.24.0.160507485938.issue29473@psf.upfronthosting.co.za> New submission from ????? ????: check_output(['command']) Can't be decoded as it was in 3.5 check_output(['command']).decode('utf-8') returns UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 2: invalid start byte error. ---------- components: Windows messages: 287239 nosy: paul.moore, steve.dower, tim.golden, zach.ware, ????? ???? priority: normal severity: normal status: open title: subprocces check_output versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:34:42 2017 From: report at bugs.python.org (Marco Buttu) Date: Tue, 07 Feb 2017 15:34:42 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486481682.4.0.290991950071.issue22594@psf.upfronthosting.co.za> Marco Buttu added the comment: Looking at the regex module and documentation, it is not clear to me whether its API behaves exactly as the re API. In addition, being a third-party module, things can change in the future. To be defensive, IMO it is better to write as in the Ezio comment (in the review): "mostly compatible API". I propose a shorter patch, that adds the reference at the beginning of the page (right after the module introcution). ---------- Added file: http://bugs.python.org/file46561/regex_reference.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:35:35 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Feb 2017 15:35:35 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1486481735.19.0.497750460552.issue19675@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:59:18 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 07 Feb 2017 15:59:18 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs Message-ID: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> New submission from Mariatta Wijaya: https://docs.python.org/3/library/weakref.html?highlight=weakref#weakref.WeakValueDictionary There are grammatical errors in the sentence: These method have the same issues as the and keyrefs() method of WeakKeyDictionary objects. Reported by Arthur Goldberg in https://mail.python.org/pipermail/docs/2017-February/029957.html ---------- assignee: docs at python components: Documentation keywords: easy messages: 287241 nosy: Mariatta, docs at python priority: normal severity: normal status: open title: Grammatical errors in weakref.WeakValueDictionary docs versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:04:35 2017 From: report at bugs.python.org (Joel Uckelman) Date: Tue, 07 Feb 2017 16:04:35 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1486483475.05.0.920702518027.issue29412@psf.upfronthosting.co.za> Joel Uckelman added the comment: Here's a patch, complete with tests. If the value is all CFWS, then get_cfws(value)[1], which is what's left after the CFWS is extracted, is the empty string---which is why value[0] throws in this case. ---------- keywords: +patch Added file: http://bugs.python.org/file46562/29412.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:05:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 16:05:11 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486483511.14.0.490664408112.issue29474@psf.upfronthosting.co.za> STINNER Victor added the comment: Would you mind to propose a patch? Thanks in advance. Note: the sentence is also wrong in Python 2.7 doc, no? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:07:55 2017 From: report at bugs.python.org (Riccardo Polignieri) Date: Tue, 07 Feb 2017 16:07:55 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486483675.08.0.17317605212.issue28686@psf.upfronthosting.co.za> Riccardo Polignieri added the comment: Paul: > it's not possible to tell by inspection the version of a Python interpreter. True, but it's an implementation detail. Couldn't be solved? Versioned interpreters a la Linux, of course, or maybe how about including some kind of manifest file? Steve: > including versioned executables wouldn't that resolve this issue naturally? Definitely. Paul: > 1. Use the Python executable that's first on PATH: "py" Except, that's currently *almost never* true when I'm inside a venv! (For this to be true, I must give up on versioned shebangs). Now, if only 'py' could *always* look at the PATH *only*, ignoring shebangs - well this would be at least consistent behavior. Now, the absolute worst scenario here is when you have a prompt like "(myenv) $>" screaming to your face that you are inside a venv, and you go "py foo.py" expecting the venv interpreter to execute foo.py, because you are inside a venv, right? But wait!, foo.py was actually written by some Linux hacker, therefore *versioned* shebang, therefore 'py' fetches the wrong (system) Python, therefore no dependencies found, therefore crash. How I'm supposed to solve this? Paul: > The only change I'd consider reasonable here would be a doc change Thanks, it would really help, because I'm afraid I can't make it work for me. Most of all, I would really appreciate some sort of "best practice" suggestion on how to put together 'py', venvs and shebang. At the moment, I'm afraid my provisional policy is as follows: - when outside a venv (almost never) it's ok to 'py'; - when inside a venv (almost always) go 'python' the old way, because 'py' is unreliable here, *unless* you manually check the shebang of your scripts before you execute them. Which practically means - almost never use 'py'. Is this the correct way to go? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:15:56 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 07 Feb 2017 16:15:56 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486484156.96.0.102292234315.issue29474@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: You're right, Victor :) The wording in 2.7 is a little bit different, but should be fixed too. In 2.7: These method have the same issues as the iterkeyrefs() and keyrefs() methods of WeakKeyDictionary objects. Assigning this to myself. ---------- assignee: docs at python -> Mariatta nosy: +rhettinger versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:16:35 2017 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 07 Feb 2017 16:16:35 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486484195.37.0.974801324781.issue22594@psf.upfronthosting.co.za> Matthew Barnett added the comment: With the VERSION0 flag (the default behaviour), it should behave the same as the re module, and that's not going to change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:19:18 2017 From: report at bugs.python.org (Paul Moore) Date: Tue, 07 Feb 2017 16:19:18 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486484358.43.0.990126875847.issue28686@psf.upfronthosting.co.za> Paul Moore added the comment: > - when inside a venv (almost always) go 'python' the old way, because 'py' is unreliable here, *unless* you manually check the shebang of your scripts before you execute them. No. When inside a venv: - If you want to use the interactive interpreter, use 'py'. - If you want to execute a script, use a shebang of #!/usr/bin/env python and then use `py myscript.py` You should use /usr/bin/python[X[.Y]] shebangs specifically when you want to use the system Python, and bypass venvs. So that's typically for scripts you've installed in your PATH, not for working scripts in your project. You should never use versioned executable names in shebangs with /usr/bin/env. Your issues seem to come from an insistence on using versioned interpreter names in /usr/bin/env shebangs, which does not work as you expect. (How it actually works is IMO not very helpful, but not easily fixable without shipping versioned executables, which is an entirely different debate which I don't intend to get into here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 11:46:43 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 07 Feb 2017 16:46:43 +0000 Subject: [issue29473] subprocces check_output In-Reply-To: <1486480876.24.0.160507485938.issue29473@psf.upfronthosting.co.za> Message-ID: <1486486003.17.0.456350580165.issue29473@psf.upfronthosting.co.za> Steve Dower added the comment: What's your actual command? And what output is it producing? Without those, we've got no hope of guessing what is going on here. Nothing in subprocess should have changed because of my PEPs, other than decoding bytes passed as arguments (which IIRC wasn't possible before anyway, and we may have left it that way). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:02:52 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Feb 2017 18:02:52 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486490572.02.0.072343638654.issue26355@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : Removed file: http://bugs.python.org/file46426/cannonical-doc-for-3.4plus.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:04:39 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Feb 2017 18:04:39 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486490679.79.0.457137360345.issue26355@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Updated patch to take comments into account (added space before /> for consistency). I'm still unfamiliar with hg so let me know if I did anything wrong. ---------- Added file: http://bugs.python.org/file46563/cannonical-doc-for-3.4plus.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:21:29 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Feb 2017 18:21:29 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486491689.37.0.0106426101091.issue26355@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : Added file: http://bugs.python.org/file46564/cannonical-doc-for-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:24:22 2017 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Feb 2017 18:24:22 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486491862.29.0.709885930525.issue22594@psf.upfronthosting.co.za> Brett Cannon added the comment: How about "a mostly compatible API with more thorough Unicode support"? That focuses on the VERSION1 API which is a differentiator for regex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:34:32 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 07 Feb 2017 18:34:32 +0000 Subject: [issue29351] absolute imports for logging In-Reply-To: <1485177903.18.0.43823292649.issue29351@psf.upfronthosting.co.za> Message-ID: <1486492472.5.0.222660654827.issue29351@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:35:03 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 07 Feb 2017 18:35:03 +0000 Subject: [issue29372] RotatingFileHandler rotates empty logfile if it emits a large string In-Reply-To: <1485360224.38.0.947637323441.issue29372@psf.upfronthosting.co.za> Message-ID: <1486492503.33.0.641161617614.issue29372@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:36:53 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Feb 2017 18:36:53 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486492613.46.0.759218022491.issue26355@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : Added file: http://bugs.python.org/file46565/cannonical-doc-for-2.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 13:46:38 2017 From: report at bugs.python.org (Ben Longbons) Date: Tue, 07 Feb 2017 18:46:38 +0000 Subject: [issue19240] iglob should try to use `readdir` In-Reply-To: <1381628578.0.0.047697770755.issue19240@psf.upfronthosting.co.za> Message-ID: <1486493198.88.0.211209844965.issue19240@psf.upfronthosting.co.za> Ben Longbons added the comment: This is a duplicate of bug 25596, which is now fixed. ---------- nosy: +o11c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 14:04:49 2017 From: report at bugs.python.org (Walter Szeliga) Date: Tue, 07 Feb 2017 19:04:49 +0000 Subject: [issue29425] File-altering aspects of pathlib should return new pathlib objects In-Reply-To: <1486080253.05.0.537199940287.issue29425@psf.upfronthosting.co.za> Message-ID: <1486494289.89.0.725061651268.issue29425@psf.upfronthosting.co.za> Walter Szeliga added the comment: If Path.rename() were made to be slightly more than a wrapper around os.rename(), then any future changes to the return value of os.rename() could be taken into consideration in the return value of Path.rename(). I don't see how anything would become impossible then. Creating the destination Path object explicitly is my solution right now. Since it had become such a pattern in my code, I figured it could be delegated up to the level of the Path object and make for cleaner looking code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 14:05:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 19:05:40 +0000 Subject: [issue19240] iglob should try to use `readdir` In-Reply-To: <1381628578.0.0.047697770755.issue19240@psf.upfronthosting.co.za> Message-ID: <1486494340.48.0.537343407042.issue19240@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Use scandir() to speed up the glob module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 14:23:30 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 19:23:30 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486495410.47.0.908334735073.issue29464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The major part of the patch is generated by Argument Clinic. It is not a pain to rebase it. I prefer to delay pushing the patch until we prove its usefulness, because the cost of this change is not zero. Is it a stopper for issue29465? ---------- assignee: -> serhiy.storchaka priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 14:31:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 19:31:17 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486495877.89.0.337883087198.issue29465@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Awesome! This looks fantastic! I need to check the patch very carefully to be sure that we haven't missed something important. Isn't the Python directory more appropriate place for call.c? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 14:37:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 19:37:32 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486496252.17.0.43832732723.issue29438@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 15:00:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Feb 2017 20:00:51 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486497651.65.0.250704881719.issue29438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyDict_SetItem() can trigger destructor which first call _PyObjectDict_SetItem() which change CACHED_KEYS(tp) and then call PyDict_SetItem() which call dictresize(). At the end it may be possible that cached != ((PyDictObject *)dict)->ma_keys and cached != CACHED_KEYS(tp) and CACHED_KEYS(tp) != ((PyDictObject *)dict)->ma_keys. Wouldn't be better to just update the cached variable after calling PyDict_SetItem()? if (was_shared && (cached = CACHED_KEYS(tp)) != NULL && cached != ((PyDictObject *)dict)->ma_keys) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 16:26:16 2017 From: report at bugs.python.org (Ben Longbons) Date: Tue, 07 Feb 2017 21:26:16 +0000 Subject: [issue29475] option to not follow symlinks when globbing Message-ID: <1486502775.77.0.404935971295.issue29475@psf.upfronthosting.co.za> New submission from Ben Longbons: Background: I have a data hierarchy with a lot of "sibling" symlinked directories/files. I want to glob only the non-symlink files, because it's a *huge* performance increase. Before `os.scandir`, I was using a local copy of `glob.py` and calling `os.path.islink` every time, which was faster for *my* use case, but unacceptable for upstreaming. With `os.scandir`, my new patch should be acceptable. The patch includes tests. Current discussion points: * Am I making the right decision to still accept symlinks for fully-literal components (in glob0)? It doesn't apply to my use-case, and I imagine some people might want to handle that case separately. * Are my tests sufficient? I just copied and modified the existing symlink tests. * Should my `flags` TODO be implemented *before* this patch? IMO it would be clearer after, even if it makes the diffs longer. Future discussion points (don't derail): * Should my `flags` TODO be implemented internally (this would significantly shrink any future patches)? (I can work on this) * Should `flags` also be exposed externally? * What additional `flags` might be useful? (my list: GLOB_ERR, GLOB_MARK, ~GLOB_NOSORT, ~GLOB_NOESCAPE, GLOB_PERIOD, GLOB_BRACE, GLOB_TILDE_CHECK, GLOB_ONLYDIR (+ equivalent for files - also, why doesn't `os.scandir` have accessors for the other types without doing an unnecessary stat?)) * Is there a bitwise enum (or equivalently, enum set) in the standard library so `flags` can get sane reprs? (I've implemented this before, but imagine it would be overwhelmed with bikeshedding if it doesn't exist yet) * Should `pathlib` really be implementing globbing on its own? That makes it hard to ensure feature parity. Perhaps the `glob` module needs some additional APIs? (I don't want to work on `pathlib` itself) ---------- components: Library (Lib) files: python-glob-symlink.diff keywords: patch messages: 287256 nosy: o11c priority: normal severity: normal status: open title: option to not follow symlinks when globbing type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file46566/python-glob-symlink.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 16:49:25 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 21:49:25 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486495877.89.0.337883087198.issue29465@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Serhiy Storchaka added the comment: > Isn't the Python directory more appropriate place for call.c? I moved code from other .c files in Objects/, so for me it seems more natural to add the code in Objects/ as well. It seems like most of the code in Python/ is not "aware" of types defined in Objects/. But I don't have a strong opinion on the right directory. Objects/call.c is 1500 lines long. IMHO the code became big enough to justify to move it to a new file ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:07:26 2017 From: report at bugs.python.org (Earl Maier) Date: Tue, 07 Feb 2017 22:07:26 +0000 Subject: [issue29232] Quiet Install In-Reply-To: <1484083752.73.0.652797539276.issue29232@psf.upfronthosting.co.za> Message-ID: <1486505246.04.0.387584740193.issue29232@psf.upfronthosting.co.za> Earl Maier added the comment: Update. I have been able to reproduce the issue/pin point the problem. The all user flag on the installer doesn't install under all users. I install as an admin (under a different user) but python doesn't install for the current user (user). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:11:42 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 22:11:42 +0000 Subject: [issue29464] Specialize FASTCALL for functions with positional-only parameters In-Reply-To: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> Message-ID: <1486505502.68.0.181813241063.issue29464@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "I prefer to delay pushing the patch until we prove its usefulness, because the cost of this change is not zero. Is it a stopper for issue29465?" Ok. No, it's not a blocker for my issue #29465. About usefulness, I'm curious of the performance impact on this patch on top of the issue #29465. I tried to run a benchmark, but my tooling only works well with a single patch, not with two patches, and one based on the other. Moreover, our patches are in conflict. So it seems like the issue #29465 makes Python faster and uses less stack memory, I suggest to first focus on that one, and then rebase your patch on top of that. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:16:02 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 07 Feb 2017 22:16:02 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1486505762.77.0.619268725347.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: does the builtin memory debugger handle things well such as when involving external libraries like ssl/libcrypto? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:42:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 22:42:44 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486507364.36.0.535614769835.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: pyobject_fastcall-4.patch combines a lot of changes. I wrote it to experiment _PyObject_FastCall(). I will rewrite these changes as a patch serie with smaller changes. The design of PyObject_FastCall*() is to be short and simple. Changes: * Add _PyObject_FastCall(), _PyFunction_FastCall(), _PyCFunction_FastCall(): similar to the _PyObject_FastCallKeywords() but without keyword arguments. Without keyword arguments, the checks on keyword arguments can be removed, and it allows to reduce the stack usage: one less parameter to C functions. * Move the slow path out of _PyObject_FastCallDict() and _PyObject_FastCallKeywords() in a new subfunction which is tagged with _Py_NO_INLINE to reduce the stack consumption of _PyObject_FastCallDict() and _PyObject_FastCallKeywords() in their fast paths, which are the most code paths. * Move all "call" functions into a new Objects/call.c function. This change should help code placement to enhance the usage of the CPU caches (especially the CPU L1 instruction cache). In my long experience with benchmarking last year, I notice huge performance differences caused by code placement. See my blog post: https://haypo.github.io/analysis-python-performance-issue.html Sadly, _Py_HOT_FUNCTION didn't fix the issue completely. * _PyObject_FastCallDict() and _PyObject_FastCallKeywords() "call" _PyObject_FastCall(). In fact, _PyObject_FastCall() is inlined manually in these functions, against, to minimize the stack usage. Similar change in _PyCFunction_FastCallDict() and PyCFunction_Call(). * Since the slow path is moved to a subfunction, I removed _Py_NO_INLINE from _PyStack_AsTuple() to allow the compiler to inline it if it wants to ;-) Since the stack usage is better with the patch, it seems like this strange has no negative impact on the stack usage. * Optimize PyMethodDescr_Type (call _PyMethodDescr_FastCallKeywords()) in _PyObject_FastCallKeywords() * I moved Py_EnterRecursiveCall() closer to the final function call, to simplify error handling. It would be nice to fix the issue #29306 before :-/ * I had to copy/paste the null_error() function from Objects/abstract.c. I don't think that it's worth it to add a _PyErr_NullError() function shared by abstract.c and call.c. Compilers are even able to merge duplicated functions ;-) * A few other changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:51:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 22:51:09 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1486507869.97.0.282459696266.issue29470@psf.upfronthosting.co.za> STINNER Victor added the comment: David Ford: "does the builtin memory debugger handle things well such as when involving external libraries like ssl/libcrypto?" Nope, see: http://bugs.python.org/issue18227#msg191610 Please try what I suggested. Buffer overflows may not crash immediatly, but PYTHONMALLOC=debug should help to detect some bugs in memory blocks allocated by Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 17:53:36 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 07 Feb 2017 22:53:36 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1486508016.32.0.869252904692.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: yes, it's running now, hasn't crashed yet ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 18:26:36 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Tue, 07 Feb 2017 23:26:36 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1486509996.34.0.136116271587.issue19217@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi all, What do we do with this ticket? Patch were provided, People have agreed (I think). So what's missing to close it (or pass to the next step)? It's going to be a year that a high priority ticket has no update and I would like to accelerate it if I can :). Let me know what I can do. Regards, Eric Lafontaine ---------- nosy: +Eric Lafontaine _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 19:02:46 2017 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 Feb 2017 00:02:46 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1486512166.25.0.74657052853.issue19217@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 19:40:41 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Wed, 08 Feb 2017 00:40:41 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486514441.04.0.909139698314.issue16011@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi, For user-defined class, it's up to the class to do the right implementation in my opinion. It's true the description is wrong though. x in y means that x exist inside of y (so that the execution of y.__contain__(x) is executed successfully and (I guess) doesn't return None,False or 0). I'll modify the doc to be : For user-defined classes which define the __contains__() method, x in y is false if y.__contains__(x) is returning either None,False or 0. Otherwise, x in y return true. Regards, Eric Lafontaine ---------- nosy: +Eric Lafontaine _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 20:09:23 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 01:09:23 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486516163.4.0.0380278242786.issue16011@psf.upfronthosting.co.za> R. David Murray added the comment: Eric: that is not precise enough, I'm afraid :) See msg171093 for the correct documentation update. Specifically, in returns True if __contains__ returns a true value, and False otherwise (not the difference in case, it matters). There are more things than just None, False, and 0 that are false in Python. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 20:25:05 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Wed, 08 Feb 2017 01:25:05 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486517105.06.0.812064615771.issue16011@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi all, Here are the test I've made to understand the behavior : class Foo_42(object): def __contains__(self,item): return 42 class Foo_neg(object): def __contains__(self,item): return -42 class Foo_None(object): def __contains__(self,item): return class Foo_false(object): def __contains__(self,item): return False class Foo_true(object): def __contains__(self,item): return True for foo in [Foo_false(),Foo_None(),Foo_neg(),Foo_true(),Foo_42()]: print("3 in foo:" + str(3 in foo)) print("foo.__contains__(3)" + str(foo.__contains__(3))) which output this : 3 in foo:False foo.__contains__(3)False 3 in foo:False foo.__contains__(3)None 3 in foo:True foo.__contains__(3)-42 3 in foo:True foo.__contains__(3)True 3 in foo:True foo.__contains__(3)42 So as long as __contains__ return False or None, the 'in' operator will be False. Otherwise true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 20:29:06 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Wed, 08 Feb 2017 01:29:06 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486517346.98.0.663407710543.issue16011@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi David, sorry for the delay on my part for providing how I was getting to that conclusion. I've also resurrected an old post as I want to start contributing more seriously :). As this is documentation only (not changing the code behavior), I didn't take a look at the implementation of "in". Could you enlighten me on what else would be considered "False" in this case? Regards, Eric Lafontaine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 20:34:45 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Wed, 08 Feb 2017 01:34:45 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486517685.55.0.986678037681.issue16011@psf.upfronthosting.co.za> Eric Lafontaine added the comment: oh, I've got what you meant! Proposed change : For user-defined classes which define the __contains__() method, the in operator will convert to False "x in y" if y.__contains__(x) return False, 0 or None. Otherwise, the in operator will return True for any other value being returned by y.__contains__(x). Would that make more sense? Regards, Eric Lafontaine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 21:10:39 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 02:10:39 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486519839.55.0.751174767562.issue16011@psf.upfronthosting.co.za> R. David Murray added the comment: >>> bool(()) False >>> bool([]) False >>> bool('') False What you want to say is that 'in' coerces the result returned by __contains__ to a boolean value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 21:20:48 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Wed, 08 Feb 2017 02:20:48 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1486519839.55.0.751174767562.issue16011@psf.upfronthosting.co.za> Message-ID: Eric Lafontaine added the comment: (first time trying to reply through email) thanks for the example and you are right : class Foo_emptylist(object): def __contains__(self,item): return [] class Foo_emptydict(object): def __contains__(self,item): return {} class Foo_emptystring(object): def __contains__(self,item): return '' for foo in [Foo_false(),Foo_None(),Foo_emptylist(),Foo_emptydict(),Foo_emptystring(),Foo_neg(),Foo_true(),Foo_42()]: print("3 in foo:" + str(3 in foo)) print("foo.__contains__(3)" + str(foo.__contains__(3))) 3 in foo:False foo.__contains__(3)False 3 in foo:False foo.__contains__(3)None 3 in foo:False foo.__contains__(3)[] 3 in foo:False foo.__contains__(3){} 3 in foo:False foo.__contains__(3) 3 in foo:True foo.__contains__(3)-42 3 in foo:True foo.__contains__(3)True 3 in foo:True foo.__contains__(3)42 So the proposition should be this then? For user-defined classes which define a __contains__() method, the in operator will apply bool() on the __contains__() method. In other words, "x in y" is equivalent to "bool(y.__contains__(x))" and will return False if bool(y.__contains__(x)) is equivalent to false. ?ric Lafontaine | Membre du Projet VUE, Groupe Contr?le G?nie ?lectrique, 54?me promotion UdeS | ?tudiant en maitrise TI ? l'ETS VAS OPS chez Bell Mobility ? Nous voulons proposer une alternative de transport en pr?sentant un v?hicule ?lectrique sp?cifiquement con?u pour les d?placements urbains. ? 2017-02-07 21:10 GMT-05:00 R. David Murray : > > R. David Murray added the comment: > > >>> bool(()) > False > >>> bool([]) > False > >>> bool('') > False > > What you want to say is that 'in' coerces the result returned by > __contains__ to a boolean value. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 21:59:29 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 02:59:29 +0000 Subject: [issue29463] Change docstring to attribute from first statement. In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486522769.47.0.040326509431.issue29463@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file46567/ast-docstring-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 22:24:34 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Feb 2017 03:24:34 +0000 Subject: [issue29476] Simplify set_add_entry() Message-ID: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Dummy entries created by deletions are currently handled in two places. The code in set_add_entry() tracks a freeslot to allow dummy slots to be reused when new elements are inserted. The dummies are also eliminated during resizing. The freeslot checks are made in the inner-loop of set_add_entry() and will only eliminate a few of the dummies (ones that happen to be in a slot that we want to use again). In contrast, the resize routine eliminates 100% of the dummy entries -- this is where most dummies get reclaimed. This is a preliminary draft of an idea to only use resizing for dummy reclamation. It proposes eliminating the freeslot reuse step in set_add_entry(). One advantage is that the patch nicely simplifies the code in set_add_entry and makes its inner-loop tighter (eliminating one memory access out of the two on each iteration). With the advent of linear probing and the 60% set load factor, set resizing has become very cheap. One issue with the current design is the while a few dummies get reclaimed earlier, others are left alive longer, causing more collisions during lookups. The reuse of a few dummies defers the resizing step that would actually clear out all of the dummies. Another thought is that the proposal gives a better separation of concerns. Insertion focuses on adding entries without making inner loop checks for an uncommon case (the relevant note in dictobject.c says this is uncommon by a factor of hundreds). The patch leaves the dummy cleanup to the fast, efficient resizing step. Some areas for exploration: * We know that the benefit to set_add_entry() will reduce the cost of building a set (which is the common case). It simply does less work by using less code overall and by having less code in the inner loop (see the disassembly below (1) to see that we're now down to one memory access per iteration). That said, it would be nice to quantify whether this is a small improvement or a big one (I expect the answer will be different for CLang vs GCC vs MSC, for 32-bit builds versus 64-builds, and for ARM versus x86, etc). * It would also be nice see if there is an observable small benefit or small detriment to the uncommon case of building a set followed by cycling back and forth between removing elements and adding new elements. In any case, the simplification of the code in set_add_entry() will be nice and it would be good to have a separation of concerns with only set_resize being responsible for clearing out dummies in a single high-speed pass. (1) Inner-loop for the new set_add_entry() featuring only one memory access per iteration: L383: cmpq %r9, %rbx ; entry < start + LINEAR_PROBES je L406 L388: addq $16, %rbx ; entry++ movq 8(%rbx), %rax ; load entry->hash from memory testq %rax, %rax ; entry->hash == 0 jne L382 ; until zero found skip next test cmpq $0, (%rbx) ; entry->key == NULL je L374 ; return entry L382: cmpq %rax, %r15 ; entry->hash == hash jne L383 ; loop back <... process to equality test > ---------- assignee: rhettinger components: Interpreter Core files: set_no_dummy_reuse.diff keywords: patch messages: 287272 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Simplify set_add_entry() versions: Python 3.7 Added file: http://bugs.python.org/file46568/set_no_dummy_reuse.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 22:36:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 03:36:06 +0000 Subject: [issue29463] Change docstring to attribute from first statement. In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486524966.94.0.936776734201.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: lnotab is changed too. - 0,0,0,115,12,0,0,0,8,4,4,2,8,8,8,12, - 8,25,8,13,114,18,0,0,0,99,0,0,0,0,0,0, + 0,0,0,115,10,0,0,0,12,6,8,8,8,12,8,25, + 8,13,114,18,0,0,0,99,0,0,0,0,0,0,0,0, 115 is header for bytes type. next 4 bytes is it's length (little endian, 12->10 bytes) and everything after that is slided by 2 bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 23:14:06 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 08 Feb 2017 04:14:06 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486527246.6.0.588055001754.issue29438@psf.upfronthosting.co.za> Xiang Zhang added the comment: > if (was_shared && (cached = CACHED_KEYS(tp)) != NULL && cached != ((PyDictObject *)dict)->ma_keys) +1 on this and I think the deletion should also use if ((cached = CACHED_KEYS(tp) ?= NULL) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 23:18:19 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 04:18:19 +0000 Subject: [issue29463] Change docstring to attribute from first statement. In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486527499.65.0.158669635151.issue29463@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file46569/ast-docstring-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 23:20:49 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 04:20:49 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486527649.44.0.738899740961.issue29463@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- title: Change docstring to attribute from first statement. -> Add `docstring` attribute to AST nodes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:04:57 2017 From: report at bugs.python.org (Tim Peters) Date: Wed, 08 Feb 2017 05:04:57 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> Message-ID: <1486530297.71.0.57515923468.issue29449@psf.upfronthosting.co.za> Tim Peters added the comment: I can't judge a use case for a thread gimmick in the absence of wholly specified examples. There are too many possible subtleties. Indeed, if I'd do anything with Event.clear() it would be to remove it - I've seen too much code that suffers subtle race bugs when trying to reset an event. The one thing it's clearly good for is announcing a one-time global state change, for which it's sufficient, efficient, clear, and hard to get wrong. Can you use a Barrier instead? The Barrier design allows reuse with no special care, Barrier.wait() already returns a little integer unique to each thread, and the Barrier constructor even allows a function to be passed in to be executed by (exactly) one of the threads when the Barrier is complete. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:05:01 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 05:05:01 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486530301.52.0.97649418421.issue29474@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Attached is the patch to fix the grammatical errors for versions 3.5+ ---------- keywords: +patch Added file: http://bugs.python.org/file46570/issue29474py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:06:13 2017 From: report at bugs.python.org (Ammar Askar) Date: Wed, 08 Feb 2017 05:06:13 +0000 Subject: [issue29326] Blank lines in ._pth file are not ignored In-Reply-To: <1484844872.11.0.819349056222.issue29326@psf.upfronthosting.co.za> Message-ID: <1486530373.8.0.334320152503.issue29326@psf.upfronthosting.co.za> Changes by Ammar Askar : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:06:48 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 05:06:48 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486530408.02.0.522152237425.issue29474@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: And here is the patch that fixes the issue for python 2.7. ---------- Added file: http://bugs.python.org/file46571/issue29474py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:07:18 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 05:07:18 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486530438.86.0.00677727940462.issue29474@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:12:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 05:12:44 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486530764.75.0.545089650095.issue29476@psf.upfronthosting.co.za> INADA Naoki added the comment: I like this idea. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 00:25:32 2017 From: report at bugs.python.org (Ethan Furman) Date: Wed, 08 Feb 2017 05:25:32 +0000 Subject: [issue29475] option to not follow symlinks when globbing In-Reply-To: <1486502775.77.0.404935971295.issue29475@psf.upfronthosting.co.za> Message-ID: <1486531532.53.0.812827771702.issue29475@psf.upfronthosting.co.za> Ethan Furman added the comment: Before talking about the patch, have you signed the Contributer License Agreement yet? The issue tracker isn't showing that you have. Check out https://www.python.org/psf/contrib/contrib-form/ to do so. --- The `symlinks` flag: can you give some glob examples showing when, and when not, symlinks will be matched when the symlinks param is False? A bit flags enum: There is now an IntFlag Enum type which implements bit flags. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 01:20:58 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 06:20:58 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486534858.96.0.686082023397.issue29438@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file46572/29438-sharedkey-useafterfree-py36-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 01:26:18 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 08 Feb 2017 06:26:18 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486535178.21.0.583144040329.issue29438@psf.upfronthosting.co.za> Xiang Zhang added the comment: I left one review about the comment on Rietvied last patch. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 02:22:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 07:22:40 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486538560.19.0.275927170649.issue29438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please write tests Inada? It would be nice to test also the case that fails with 29438-sharedkey-useafterfree-py36.patch. Actually I don't know if this is easy to reproduce, it was just my guessing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 02:41:35 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 07:41:35 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486539695.06.0.661812335564.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: to: Serhiy I can reproduce the issue by 29438-minimum.py, on Python 3.7 with pydebug. But since this issue is "use after free", it may and may not crash. It's up to how freed memory block is used from another part of Python. Deterministic test which doesn't tied specific python version is difficult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 03:08:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 08:08:59 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486541339.72.0.951975112992.issue29463@psf.upfronthosting.co.za> STINNER Victor added the comment: def func(): "doc" + "string" Currently (Python 2.7-3.6), func.__doc__ is None. I suggest to add an unit test for this corner case, even if the result is going to change in a near future. We need to "specify" the expected behaviour, and make sure that we get the same result if optimizations are enabled or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 03:36:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 08:36:47 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1486543007.08.0.0781818131557.issue19217@psf.upfronthosting.co.za> STINNER Victor added the comment: unittest_unified_diff.patch: Rebased patch for the default branch. My patch updates also unit tests. The patch changes the test output. If we decide to apply the patch, I propose to only apply it to the default branch (Python 3.7). The bug report is about a test which fails. I'm not sure that it's a real blocker issue that Python is slow when a test fails. At least, it should be fast when a test pass. I mean that I like the current output, I'm not sure about the new output. Example with attached unified_diff.py. Before: @@@@@@@@@@@@@@@@@ F ====================================================================== FAIL: test_x (__main__.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "unified_diff.py", line 5, in test_x self.assertEqual([], [None]) AssertionError: Lists differ: [] != [None] Second list contains 1 additional elements. First extra element 0: None - [] + [None] ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) @@@@@@@@@@@@@@@@@ With the patch: @@@@@@@@@@@@@@@@@ haypo at selma$ ./python unified_diff.py F ====================================================================== FAIL: test_x (__main__.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "unified_diff.py", line 5, in test_x self.assertEqual([], [None]) AssertionError: Lists differ: [] != [None] Second list contains 1 additional elements. First extra element 0: None --- +++ @@ -1 +1 @@ -[] +[None] ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) @@@@@@@@@@@@@@@@@ The patch adds the following header which can be suprising: @@@@@@@@@@@@@@@@@ --- +++ @@ -1 +1 @@ @@@@@@@@@@@@@@@@@ Maybe we should pass a "file name" to unified_diff() to get something like: @@@@@@@@@@@@@@@@@ --- expected +++ got @@ -1 +1 @@ @@@@@@@@@@@@@@@@@ ---------- Added file: http://bugs.python.org/file46573/unittest_unified_diff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 03:36:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 08:36:59 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1486543019.07.0.672089830266.issue19217@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file46574/unified_diff.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 03:42:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 08:42:35 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486543355.47.0.808074932138.issue29438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Okay, if there is no way to test this with certainty, tests may be omitted. Why res == 0 is added? If PyDict_SetItem() triggers recursive calling of _PyObjectDict_SetItem() which calls PyDict_SetItem() it may be possible that the first PyDict_SetItem() is failed while the dict is changed by the second PyDict_SetItem() and CACHED_KEYS(tp) becomes outdated. ---------- assignee: -> inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 03:55:08 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 08:55:08 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486544108.07.0.017956021725.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: > Why res == 0 is added? If PyDict_SetItem() triggers recursive calling of _PyObjectDict_SetItem() which calls PyDict_SetItem() it may be possible that the first PyDict_SetItem() is failed while the dict is changed by the second PyDict_SetItem() and CACHED_KEYS(tp) becomes outdated. To avoid hiding error raised in PyDict_SetItem(). But it seems I was too nervous. The error will be hidden only when make_keys_shared() raise exception. I'll remove the check. BTW, how about -py35.patch? It is minimum patch to avoid "use after free". It skip CACHED_KEYS(tp) = NULL entirely. But I think I can apply same patch to Python 3.5 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:00:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 09:00:10 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486544410.16.0.854051512559.issue29463@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Support adding tests. Tests should cover all cases: module, class, function, coroutine and check also the first line number. What is the value of co_firstlineno if the function doesn't have any statements? def f(): '''docstring''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:03:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 09:03:04 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486544584.04.0.87012656309.issue29438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think same patch should be applied to Python 3.5 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:05:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 09:05:50 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486544750.94.0.110795352701.issue29438@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Mark.Shannon, benjamin.peterson, rhettinger, tim.peters versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:08:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 09:08:12 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486544892.3.0.51824922707.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: Oh, I misunderstood something. patched Python 3.7 and system's Python 3.5 shows same output for code below. I'll check what is actually changed. inada-n at x250 ~/w/p/ast-docstring> cat -n x.py 1 """module docstring""" 2 3 def func(): 4 """func docstring""" 5 6 def func2(): 7 """func docstring""" 8 1+1 9 10 print(func.__code__.co_firstlineno) 11 print(func.__code__.co_lnotab) 12 print(func2.__code__.co_firstlineno) 13 print(func2.__code__.co_lnotab) inada-n at x250 ~/w/p/ast-docstring> ./python x.py 3 b'' 6 b'\x00\x02' inada-n at x250 ~/w/p/ast-docstring> /usr/bin/python3 x.py 3 b'' 6 b'\x00\x02' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:14:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 09:14:00 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486545240.91.0.864902274649.issue29476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sets often are used in following pattern: def recurse(obj): if subobj not in proceeding: proceeding.add(obj) for subobj in links(obj): recurse(subobj) proceeding.discard(obj) In this case items are added and removed in LIFO order. How this change affects this case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:30:21 2017 From: report at bugs.python.org (Malthe Borch) Date: Wed, 08 Feb 2017 09:30:21 +0000 Subject: [issue29477] Lambda with complex arguments is ctx STORE Message-ID: <1486546221.26.0.696081579931.issue29477@psf.upfronthosting.co.za> New submission from Malthe Borch: Normally, lambda arguments (positional or keyword-based) are ctx PARAM, since they're parameters. But complex (packed) arguments are ctx STORE. This is a problem for AST transformation tools that can't reliably detect the name context. ---------- components: Interpreter Core messages: 287291 nosy: malthe priority: normal severity: normal status: open title: Lambda with complex arguments is ctx STORE type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:33:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 09:33:48 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486544892.3.0.51824922707.issue29463@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2017-02-08 10:08 GMT+01:00 INADA Naoki : > 6 def func2(): > 7 """func docstring""" > 8 1+1 1+1 is replaced with 2 and lone integer literals are removed by the peephole optimizer. See also the issue #26204. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:35:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 09:35:53 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486546553.58.0.0724240384842.issue29463@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I spoke too fast :-) "1+1" is not removed. "1+1" is replaced with "2" by the peephole optimizer, whereas the compiler ignoring constants comes before the peephole optimizer. One more time, it would be better to implement constant folding at the AST level ;-) $ python3 Python 3.5.2 (default, Sep 14 2016, 11:28:32) >>> def func(): ... "docstring" ... 1+1 ... >>> import dis >>> dis.dis(func) 3 0 LOAD_CONST 3 (2) 3 POP_TOP 4 LOAD_CONST 2 (None) 7 RETURN_VALUE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:49:35 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 08 Feb 2017 09:49:35 +0000 Subject: [issue12741] Add function similar to shutil.move that does not overwrite In-Reply-To: <1313152865.62.0.69696851164.issue12741@psf.upfronthosting.co.za> Message-ID: <1486547375.07.0.221333836493.issue12741@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- versions: +Python 3.7 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:49:57 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 08 Feb 2017 09:49:57 +0000 Subject: [issue12741] Add function similar to shutil.move that does not overwrite In-Reply-To: <1313152865.62.0.69696851164.issue12741@psf.upfronthosting.co.za> Message-ID: <1486547397.35.0.780661728189.issue12741@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:10:45 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Feb 2017 10:10:45 +0000 Subject: [issue29478] email.policy.Compat32(max_line_length=None) not as documented Message-ID: <1486548645.73.0.926739197467.issue29478@psf.upfronthosting.co.za> New submission from Martin Panter: By default, the email package turns single-line header fields into multi-line ones to try and limit the length of each line. The documentation says that setting the policy?s max_line_length attribute to None should prevent line wrapping. But this does not work: >>> from email.policy import Compat32 >>> from email.message import Message >>> from email.generator import Generator >>> from sys import stdout >>> p = Compat32(max_line_length=None) >>> m = Message(p) >>> m["Field"] = "x" * 100 >>> Generator(stdout).flatten(m) # Field is split across two lines Field: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>> A workaround is to specify zero instead: >>> p = Compat32(max_line_length=0) >>> Generator(stdout, policy=p).flatten(m) # All on one line Field: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Quickly looking at the code, Compat32._fold() passes max_line_length straight to Header.encode(), which is documented as using None as a placeholder for its real default value of 76. So I think the solution would be to add a special case in _fold() to call encode(maxlinelen=0) if max_line_length is None. ---------- components: email messages: 287294 nosy: barry, martin.panter, r.david.murray priority: normal severity: normal status: open title: email.policy.Compat32(max_line_length=None) not as documented type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:19:00 2017 From: report at bugs.python.org (song1st) Date: Wed, 08 Feb 2017 10:19:00 +0000 Subject: [issue29479] httplib: could not skip "ACCEPT-ENCODING" header Message-ID: <1486549140.01.0.111970837226.issue29479@psf.upfronthosting.co.za> New submission from song1st: When I tried to skip "ACCEPT-ENCODING" of header, I found the behavior was not right. I think the issue is the following two "if" in _send_request of httplib. def _send_request(self, method, url, body, headers): # Honor explicitly requested Host: and Accept-Encoding: headers. header_names = dict.fromkeys([k.lower() for k in headers]) skips = {} if 'host' in header_names: skips['skip_host'] = 1 if 'accept-encoding' in header_names: skips['skip_accept_encoding'] = 1 ---------- components: Library (Lib) messages: 287295 nosy: song1st priority: normal severity: normal status: open title: httplib: could not skip "ACCEPT-ENCODING" header type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:51:29 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Feb 2017 10:51:29 +0000 Subject: [issue29479] httplib: could not skip "ACCEPT-ENCODING" header In-Reply-To: <1486549140.01.0.111970837226.issue29479@psf.upfronthosting.co.za> Message-ID: <1486551089.01.0.00952106254091.issue29479@psf.upfronthosting.co.za> Martin Panter added the comment: Please explain what the wrong behaviour that you see is, and what you expect the right behaviour should be. That code is intended to either keep any user-supplied Accept-Encoding header field, or send ?Accept-Encoding: identity? if the field is not supplied. If you are looking for a way to avoid adding this field entirely, see the lower level putrequest() and related methods. This is documented behaviour: . ---------- nosy: +martin.panter stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:57:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 10:57:31 +0000 Subject: [issue26204] compiler: ignore constants used as statements (don't emit LOAD_CONST+POP_TOP) In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za> Message-ID: <1486551451.24.0.917427336477.issue26204@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the thread was in February 2016: https://mail.python.org/pipermail/python-dev/2016-February/143163.html "[Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:08:29 2017 From: report at bugs.python.org (song1st) Date: Wed, 08 Feb 2017 11:08:29 +0000 Subject: [issue29479] httplib: could not skip "ACCEPT-ENCODING" header In-Reply-To: <1486549140.01.0.111970837226.issue29479@psf.upfronthosting.co.za> Message-ID: <1486552109.65.0.488554925189.issue29479@psf.upfronthosting.co.za> song1st added the comment: Sorry, I thought I misunderstood the meaning. I want no "ACCEPT-ENCODING" even "ACCEPT-ENCODING: identity". I tried to modify the code from if 'accept-encoding' in header_names: to if not 'accept-encoding' in header_names: The http request will be no "ACCEPT-ENCODING". This is what I want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:16:23 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 08 Feb 2017 11:16:23 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486552583.93.0.869462425507.issue22594@psf.upfronthosting.co.za> Marco Buttu added the comment: > With the VERSION0 flag (the default behaviour), it should > behave the same as the re module, and that's not going to change. Thanks for the clarification Matthew. However, the default version will change, as the regex PyPI page points out: "In the short term this will be VERSION0, but in the longer term it will be VERSION1." I propose a patch that integrates the Brett suggestion. ---------- Added file: http://bugs.python.org/file46575/regex_reference.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:25:18 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Feb 2017 11:25:18 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <20170208112514.96094.62278.2EA9CBAC@psf.io> Roundup Robot added the comment: New changeset 88ed9d9eabc1 by Victor Stinner in branch 'default': Issue #29306: Fix usage of Py_EnterRecursiveCall() https://hg.python.org/cpython/rev/88ed9d9eabc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:30:36 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 08 Feb 2017 11:30:36 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486553436.96.0.799909804973.issue29474@psf.upfronthosting.co.za> Marco Buttu added the comment: The second patch LGTM. In the first one there is a typo (see review). ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:30:42 2017 From: report at bugs.python.org (Edward Ned Harvey) Date: Wed, 08 Feb 2017 11:30:42 +0000 Subject: [issue29480] Mac OSX Installer SSL Roots Message-ID: <1486553442.34.0.041490536597.issue29480@psf.upfronthosting.co.za> New submission from Edward Ned Harvey: I would like to suggest that the OSX installer automatically run "Install Certificates.command", or display a prompt to users saying "Run Now" during installation. Having the readme is helpful - but only after you google for 20 minutes, because of an exception you encountered. Of course nobody reads the readme during install. "I've installed python a thousand times before, I know what I'm doing." There are so many things that require SSL, and it's reasonably assumed to be functional by default. ---------- components: Installation messages: 287302 nosy: rahvee priority: normal severity: normal status: open title: Mac OSX Installer SSL Roots type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:38:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 11:38:33 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486553913.68.0.145594069242.issue29306@psf.upfronthosting.co.za> STINNER Victor added the comment: I still need to backport fixes to Python 3.6, maybe even Python 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:55:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 11:55:09 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field In-Reply-To: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> Message-ID: <1486554909.42.0.680609972535.issue29466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: True. Attributes __context__, __cause__ and __traceback__ are not pickled. The traceback objects are even not pickleable. What is worse, some other non-special attributes are lost during pickling. For example name and path attributes of ImportError. >>> try: import foo ... except Exception as ex: exc = ex ... >>> exc.name 'foo' >>> exc.__reduce__() (, ("No module named 'foo'",), {}) Or the value attribute of StopIteration if it was not passed to the constructor. >>> exc = StopIteration() >>> exc.value = 42 >>> exc.__reduce__() (, (), {}) ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:00:25 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Feb 2017 12:00:25 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486555225.66.0.747963315724.issue29306@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 65d24ff4bbd3320acadb58a5e4d944c84536cb2c by Victor Stinner in branch 'master': Issue #29306: Fix usage of Py_EnterRecursiveCall() https://github.com/python/cpython/commit/65d24ff4bbd3320acadb58a5e4d944c84536cb2c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:08:18 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 12:08:18 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1486555698.42.0.93138696432.issue16011@psf.upfronthosting.co.za> R. David Murray added the comment: You've got the right idea, but you are repeating yourself. Keep it as short as possible while still conveying the correct information. "coerce to boolean" is better than "apply bool", because the code may not in fact be using the bool function to do it. Your "equivalent to" phrase would be OK as an alternative, but you only need to show the equivalence, no need to also explain it in words. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:08:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 12:08:31 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486555711.35.0.735503317991.issue29306@psf.upfronthosting.co.za> STINNER Victor added the comment: I needed this fix to work on issue #29465. I expected that my patch was reviewed, but woops, it wasn't the case and I missed a refleak. Hopefully, the refleak is now fixed! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:08:42 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Feb 2017 12:08:42 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <20170208120838.128178.49661.F21EF0DA@psf.io> Roundup Robot added the comment: New changeset 37705f89c72b by Victor Stinner in branch 'default': Fix refleaks if Py_EnterRecursiveCall() fails https://hg.python.org/cpython/rev/37705f89c72b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:13:15 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 12:13:15 +0000 Subject: [issue29477] Lambda with complex arguments is ctx STORE In-Reply-To: <1486546221.26.0.696081579931.issue29477@psf.upfronthosting.co.za> Message-ID: <1486555995.5.0.975783973197.issue29477@psf.upfronthosting.co.za> R. David Murray added the comment: I presume this is a 2.7 only issue. I'm pretty sure the 2.7 AST isn't going to get changed in 2.7 at this point. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:15:00 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 12:15:00 +0000 Subject: [issue29478] email.policy.Compat32(max_line_length=None) not as documented In-Reply-To: <1486548645.73.0.926739197467.issue29478@psf.upfronthosting.co.za> Message-ID: <1486556100.11.0.203672789736.issue29478@psf.upfronthosting.co.za> R. David Murray added the comment: That sounds reasonable to me. Clearly there is a missing test :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:27:20 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 12:27:20 +0000 Subject: [issue29480] Mac OSX Installer SSL Roots In-Reply-To: <1486553442.34.0.041490536597.issue29480@psf.upfronthosting.co.za> Message-ID: <1486556840.45.0.724463388939.issue29480@psf.upfronthosting.co.za> R. David Murray added the comment: I thought there was an open issue for using the Apple cert mechanisms natively, but I can't find it. Adding the OSX people to nosy. ---------- components: +macOS nosy: +ned.deily, r.david.murray, ronaldoussoren versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:41:20 2017 From: report at bugs.python.org (Martin Teichmann) Date: Wed, 08 Feb 2017 12:41:20 +0000 Subject: [issue29432] wait_for(gather(...)) logs weird error message In-Reply-To: <1486121124.44.0.178086142975.issue29432@psf.upfronthosting.co.za> Message-ID: <1486557680.97.0.00266351572205.issue29432@psf.upfronthosting.co.za> Martin Teichmann added the comment: I added a solution to this problem. I just silence the bad error message by overwriting _GatheringFuture.__del__ to do nothing. This may have undesired side effects, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:53:06 2017 From: report at bugs.python.org (Guy Arad) Date: Wed, 08 Feb 2017 12:53:06 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque Message-ID: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> New submission from Guy Arad: See: - https://docs.python.org/3.6/library/typing.html#typing.Deque - https://docs.python.org/3.5/library/typing.html#typing.Deque `typing.Deque` is expected to be included in 3.6.1: https://docs.python.org/3/whatsnew/changelog.html#python-3-6-1-release-candidate-1 Please remove or specify the version in which it's going to be included. ---------- assignee: docs at python components: Documentation messages: 287313 nosy: Guy Arad, docs at python priority: normal severity: normal status: open title: 3.6.0 doc describes 3.6.1 feature - typing.Deque versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 08:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Feb 2017 13:00:22 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486558822.73.0.462889043728.issue29306@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 1101819ba99afcb4d1b6495d49b17bdd0acfe761 by Victor Stinner in branch 'master': Fix refleaks if Py_EnterRecursiveCall() fails https://github.com/python/cpython/commit/1101819ba99afcb4d1b6495d49b17bdd0acfe761 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:02:40 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Feb 2017 14:02:40 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1486562560.88.0.268386385867.issue29481@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:09:10 2017 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 08 Feb 2017 14:09:10 +0000 Subject: [issue1353344] python.desktop Message-ID: <1486562950.78.0.510640648021.issue1353344@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:20:28 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 08 Feb 2017 14:20:28 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486563628.3.0.530787930627.issue28686@psf.upfronthosting.co.za> Eryk Sun added the comment: > it's not possible to tell by inspection the version of a Python > interpreter. If getting the version of python[w].exe is ever required, it should be simple for 3.5+, for which python[w].exe has standard file version information with the product version (i.e. GetFileVersionInfo, etc). For older versions you could walk the EXE's import directory, looking for a dependency on pythonXY.dll. First map the executable as data via CreateFileW, CreateFileMapping, and MapViewOfFile. Next get pointers to the IMAGE_NT_HEADERS and the first IMAGE_IMPORT_DESCRIPTOR via ImageNtHeader and ImageDirectoryEntryToData. Finally, walk the array of import descriptors (while the "Characteristics" field isn't 0) to get the "Name" of each DLL dependency. It's a relative address that can be converted to a char pointer via ImageRvaToVa. Using relative addresses allows this to work if a 32-bit application is inspecting a 64-bit image and vice versa. That said, it's far simpler to just support versioned executable names (e.g. python3.exe, python3.6.exe, python3.6-32.exe, pythonw3.exe, pythonw3.6.exe, pythonw3.6-32.exe). Even if we don't install links/copies with these names, I don't see the harm in allowing the launcher to look for them. Users can create the links manually; I've seen people on SO that do this. I'm uploading a patch that implements this for "env" shebangs. ---------- keywords: +patch Added file: http://bugs.python.org/file46576/issue_28686_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:37:44 2017 From: report at bugs.python.org (xGblankGx) Date: Wed, 08 Feb 2017 14:37:44 +0000 Subject: [issue29482] AddressSanitizer: attempting double-free on 0x60b000007050 Message-ID: <1486564663.6.0.319136441437.issue29482@psf.upfronthosting.co.za> New submission from xGblankGx: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff7116418 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 Description: Heap error Short description: HeapError (10/22) Hash: fb83ab1a4cc8eeff85970c4e8a40accc.0c71313476b72a94b16ca488bd78a548 Exploitability Classification: EXPLOITABLE Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable. Other tags: AbortSignal (20/22) ASAN: ...E================================================================= ==18791==ERROR: AddressSanitizer: attempting double-free on 0x60b000007050 in thread T0: #0 0x4d24f0 in __interceptor_cfree.localalias.0 asan_malloc_linux.cc.o:? #1 0x4d24f0 in ?? ??:0 #2 0x7f1f02ff8e3f in ffi_call_unix64 ??:? #3 0x7f1f02ff8e3f in ?? ??:0 #4 0x7f1f02ff88aa in ffi_call ??:? #5 0x7f1f02ff88aa in ?? ??:0 #6 0x7f1f03226311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #7 0x7f1f03226311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #8 0x7f1f03226311 in ?? ??:0 #9 0x7f1f03215199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #10 0x7f1f03215199 in ?? ??:0 #11 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #12 0x5745f0 in ?? ??:0 #13 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #14 0x7a7429 in ?? ??:0 #15 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #16 0x7995cc in ?? ??:0 #17 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #18 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #19 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #20 0x7ab4cb in ?? ??:0 #21 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #22 0x7a76f2 in ?? ??:0 #23 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #24 0x7995cc in ?? ??:0 #25 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #26 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #27 0x7a9847 in ?? ??:0 #28 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #29 0x7ac2ea in ?? ??:0 #30 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #31 0x574668 in ?? ??:0 #32 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #33 0x5749fa in ?? ??:0 #34 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #35 0x573e9b in ?? ??:0 #36 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #37 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #38 0x793369 in ?? ??:0 #39 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #40 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #41 0x7a9847 in ?? ??:0 #42 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #43 0x7ac2ea in ?? ??:0 #44 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #45 0x574668 in ?? ??:0 #46 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #47 0x5749fa in ?? ??:0 #48 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #49 0x573e9b in ?? ??:0 #50 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #51 0x66efe4 in ?? ??:0 #52 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #53 0x5745f0 in ?? ??:0 #54 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #55 0x7a7429 in ?? ??:0 #56 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #57 0x7995cc in ?? ??:0 #58 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #59 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #60 0x7a9847 in ?? ??:0 #61 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #62 0x7ac2ea in ?? ??:0 #63 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #64 0x574668 in ?? ??:0 #65 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #66 0x5749fa in ?? ??:0 #67 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #68 0x573e9b in ?? ??:0 #69 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #70 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #71 0x793369 in ?? ??:0 #72 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #73 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #74 0x7a9847 in ?? ??:0 #75 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #76 0x7ac2ea in ?? ??:0 #77 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #78 0x574668 in ?? ??:0 #79 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #80 0x5749fa in ?? ??:0 #81 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #82 0x573e9b in ?? ??:0 #83 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #84 0x66efe4 in ?? ??:0 #85 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #86 0x5745f0 in ?? ??:0 #87 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #88 0x7a7429 in ?? ??:0 #89 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #90 0x7995cc in ?? ??:0 #91 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #92 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #93 0x7a9847 in ?? ??:0 #94 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #95 0x7ac2ea in ?? ??:0 #96 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #97 0x574668 in ?? ??:0 #98 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #99 0x5749fa in ?? ??:0 #100 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #101 0x573e9b in ?? ??:0 #102 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #103 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #104 0x793369 in ?? ??:0 #105 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #106 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #107 0x7a9847 in ?? ??:0 #108 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #109 0x7ac2ea in ?? ??:0 #110 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #111 0x574668 in ?? ??:0 #112 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #113 0x5749fa in ?? ??:0 #114 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #115 0x573e9b in ?? ??:0 #116 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #117 0x66efe4 in ?? ??:0 #118 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #119 0x5745f0 in ?? ??:0 #120 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #121 0x7a7429 in ?? ??:0 #122 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #123 0x7995cc in ?? ??:0 #124 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #125 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #126 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #127 0x7ab4cb in ?? ??:0 #128 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #129 0x7a76f2 in ?? ??:0 #130 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #131 0x7995cc in ?? ??:0 #132 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #133 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #134 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #135 0x7ab4cb in ?? ??:0 #136 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #137 0x7a76f2 in ?? ??:0 #138 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #139 0x7995cc in ?? ??:0 #140 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #141 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #142 0x7a9847 in ?? ??:0 #143 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #144 0x7ac2ea in ?? ??:0 #145 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #146 0x574668 in ?? ??:0 #147 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #148 0x5749fa in ?? ??:0 #149 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #150 0x573e9b in ?? ??:0 #151 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #152 0x6713f8 in ?? ??:0 #153 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #154 0x666d8d in ?? ??:0 #155 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #156 0x5745f0 in ?? ??:0 #157 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #158 0x7a7429 in ?? ??:0 #159 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #160 0x7995cc in ?? ??:0 #161 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #162 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #163 0x7a9847 in ?? ??:0 #164 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #165 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #166 0x78e0df in ?? ??:0 #167 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #168 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #169 0x5142f5 in ?? ??:0 #170 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #171 0x512afa in ?? ??:0 #172 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #173 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #174 0x53eefd in ?? ??:0 #175 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #176 0x503d16 in ?? ??:0 #177 0x7f1f06ea582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #178 0x7f1f06ea582f in ?? ??:0 #179 0x432548 in _start ??:? #180 0x432548 in ?? ??:0 0x60b000007050 is located 0 bytes inside of 108-byte region [0x60b000007050,0x60b0000070bc) freed by thread T0 here: #0 0x4d24f0 in __interceptor_cfree.localalias.0 asan_malloc_linux.cc.o:? #1 0x4d24f0 in ?? ??:0 #2 0x7f1f02ff8e3f in ffi_call_unix64 ??:? #3 0x7f1f02ff8e3f in ?? ??:0 #2 0x7ffc11a5271f () previously allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f1effe039bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7f1effe039bc in ?? ??:0 #2 0x7ffc11a5271f () SUMMARY: AddressSanitizer: double-free (/home/test/check/PythonASAN/python+0x4d24f0) ==18791==ABORTING ---------- components: Interpreter Core files: asan_malloc messages: 287316 nosy: xgblankgx priority: normal severity: normal status: open title: AddressSanitizer: attempting double-free on 0x60b000007050 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46577/asan_malloc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:40:30 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:40:30 +0000 Subject: [issue29483] AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 Message-ID: <1486564829.78.0.80987262722.issue29483@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: ASAN: ================================================================= ==17856==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 at pc 0x0000004bc3ad bp 0x7ffe8a4e7d10 sp 0x7ffe8a4e74c0 READ of size 11 at 0x60200000e731 thread T0 #0 0x4bc3ac in __asan_memcpy ??:? #1 0x4bc3ac in ?? ??:0 #2 0x58bbb7 in PyBytes_FromStringAndSize /home/test/check/PythonASAN/Objects/bytesobject.c:123 #3 0x58bbb7 in ?? ??:0 #4 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #5 0x79987c in ?? ??:0 #6 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #8 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #9 0x7ab4cb in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7f7d85d5e82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7f7d85d5e82f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 0x60200000e731 is located 0 bytes to the right of 1-byte region [0x60200000e730,0x60200000e731) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f7d81f8c964 in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 2) #3 0x7f7d81f8c964 in ?? ??:0 #2 0x7ffe8a4e797f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x4bc3ac) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[01]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17856==ABORTING ---------- components: Interpreter Core files: bytesobject_c_123 messages: 287317 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46578/bytesobject_c_123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:41:42 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:41:42 +0000 Subject: [issue29484] AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 Message-ID: <1486564902.18.0.325996539342.issue29484@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. PyBytes_FromStringAndSize (str=0xa76000 , size=1) at Objects/bytesobject.c:108 108 (op = characters[*str & UCHAR_MAX]) != NULL) Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 4b7ecbff5972b39c26f6e0cf37443391.86c50dffa4bdc3a046d693db2d45a01e Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ================================================================= ==18067==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 at pc 0x00000058bc2b bp 0x7ffe3c2965d0 sp 0x7ffe3c2965c8 READ of size 1 at 0x60200000e738 thread T0 #0 0x58bc2a in PyBytes_FromStringAndSize /home/test/check/PythonASAN/Objects/bytesobject.c:108 #1 0x58bc2a in ?? ??:0 #2 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #3 0x5745f0 in ?? ??:0 #4 0x677108 in slot_sq_item /home/test/check/PythonASAN/Objects/typeobject.c:5876 #5 0x677108 in ?? ??:0 #6 0x5d9714 in iter_iternext /home/test/check/PythonASAN/Objects/iterobject.c:63 #7 0x5d9714 in ?? ??:0 #8 0x571fe3 in PyIter_Next /home/test/check/PythonASAN/Objects/abstract.c:3146 #9 0x571fe3 in PySequence_Tuple /home/test/check/PythonASAN/Objects/abstract.c:1797 #10 0x571fe3 in ?? ??:0 #11 0x7ff6988bd4cf in converters_from_argtypes /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2165 #12 0x7ff6988bd4cf in ?? ??:0 #13 0x7ff6988be677 in PyCFuncPtr_set_argtypes /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3036 #14 0x7ff6988be677 in ?? ??:0 #15 0x63b1e7 in _PyObject_GenericSetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1152 #16 0x63b1e7 in ?? ??:0 #17 0x639d52 in PyObject_SetAttr /home/test/check/PythonASAN/Objects/object.c:932 #18 0x639d52 in ?? ??:0 #19 0x79ad9e in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2249 #20 0x79ad9e in ?? ??:0 #21 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #23 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #24 0x7ab4cb in ?? ??:0 #25 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #26 0x7a76f2 in ?? ??:0 #27 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #28 0x7995cc in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #41 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #42 0x793369 in ?? ??:0 #43 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #44 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #45 0x7a9847 in ?? ??:0 #46 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #47 0x7ac2ea in ?? ??:0 #48 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #49 0x574668 in ?? ??:0 #50 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #51 0x5749fa in ?? ??:0 #52 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #53 0x573e9b in ?? ??:0 #54 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #55 0x66efe4 in ?? ??:0 #56 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #57 0x5745f0 in ?? ??:0 #58 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #59 0x7a7429 in ?? ??:0 #60 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #61 0x7995cc in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #74 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #75 0x793369 in ?? ??:0 #76 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #77 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #78 0x7a9847 in ?? ??:0 #79 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #80 0x7ac2ea in ?? ??:0 #81 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #82 0x574668 in ?? ??:0 #83 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #84 0x5749fa in ?? ??:0 #85 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #86 0x573e9b in ?? ??:0 #87 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #88 0x66efe4 in ?? ??:0 #89 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #90 0x5745f0 in ?? ??:0 #91 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #92 0x7a7429 in ?? ??:0 #93 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #94 0x7995cc in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #107 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #108 0x793369 in ?? ??:0 #109 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #110 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #111 0x7a9847 in ?? ??:0 #112 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #113 0x7ac2ea in ?? ??:0 #114 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #115 0x574668 in ?? ??:0 #116 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #117 0x5749fa in ?? ??:0 #118 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #119 0x573e9b in ?? ??:0 #120 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #121 0x66efe4 in ?? ??:0 #122 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #123 0x5745f0 in ?? ??:0 #124 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #125 0x7a7429 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #138 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #139 0x7ab4cb in ?? ??:0 #140 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #141 0x7a76f2 in ?? ??:0 #142 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #143 0x7995cc in ?? ??:0 #144 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #145 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #146 0x7a9847 in ?? ??:0 #147 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #148 0x7ac2ea in ?? ??:0 #149 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #150 0x574668 in ?? ??:0 #151 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #152 0x5749fa in ?? ??:0 #153 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #154 0x573e9b in ?? ??:0 #155 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #156 0x6713f8 in ?? ??:0 #157 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #158 0x666d8d in ?? ??:0 #159 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #160 0x5745f0 in ?? ??:0 #161 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #162 0x7a7429 in ?? ??:0 #163 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #164 0x7995cc in ?? ??:0 #165 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #166 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #167 0x7a9847 in ?? ??:0 #168 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #169 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #170 0x78e0df in ?? ??:0 #171 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #172 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #173 0x5142f5 in ?? ??:0 #174 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #175 0x512afa in ?? ??:0 #176 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #177 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #178 0x53eefd in ?? ??:0 #179 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #180 0x503d16 in ?? ??:0 #181 0x7ff69c1fc82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #182 0x7ff69c1fc82f in ?? ??:0 #183 0x432548 in _start ??:? #184 0x432548 in ?? ??:0 0x60200000e738 is located 0 bytes to the right of 8-byte region [0x60200000e730,0x60200000e738) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7ff6984359bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7ff6984359bc in ?? ??:0 #2 0x7ffe3c29661f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x58bc2a) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa 00[fa]fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18067==ABORTING ---------- components: Interpreter Core files: bytobj_108 messages: 287318 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 versions: Python 3.6 Added file: http://bugs.python.org/file46579/bytobj_108 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:42:58 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:42:58 +0000 Subject: [issue29485] AddressSanitizer: SEGV on unknown address 0x7fab556df550 Message-ID: <1486564978.33.0.577417713514.issue29485@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. z_get (ptr=0x7ffff5bba5d8, size=8) at /home/test/check/PythonGDB/Modules/_ctypes/cfield.c:1336 1336 if (*(void **)ptr) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 3930661c9a0f4c1f31bb4f2341bca47f.d4e21449248c6102834e8b566f6b2ac9 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18885==ERROR: AddressSanitizer: SEGV on unknown address 0x7fab556df550 (pc 0x7fab558d0cd1 bp 0x7fab5a4b0b90 sp 0x7ffc9cbcc220 T0) #0 0x7fab558d0cd0 in z_get /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:1336 #1 0x7fab558d0cd0 in ?? ??:0 #2 0x63ac07 in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1060 #3 0x63ac07 in ?? ??:0 #4 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #5 0x7966cc in ?? ??:0 #6 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #8 0x7a9847 in ?? ??:0 #9 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #10 0x7ab648 in ?? ??:0 #11 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #12 0x7a76f2 in ?? ??:0 #13 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #14 0x7995cc in ?? ??:0 #15 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #16 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #17 0x7a9847 in ?? ??:0 #18 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #19 0x7ac2ea in ?? ??:0 #20 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #21 0x574668 in ?? ??:0 #22 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #23 0x5749fa in ?? ??:0 #24 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #25 0x573e9b in ?? ??:0 #26 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #27 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #28 0x793369 in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #41 0x66efe4 in ?? ??:0 #42 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #43 0x5745f0 in ?? ??:0 #44 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #45 0x7a7429 in ?? ??:0 #46 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #47 0x7995cc in ?? ??:0 #48 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #49 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #50 0x7a9847 in ?? ??:0 #51 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #52 0x7ac2ea in ?? ??:0 #53 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #54 0x574668 in ?? ??:0 #55 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #56 0x5749fa in ?? ??:0 #57 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #58 0x573e9b in ?? ??:0 #59 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #60 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #61 0x793369 in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #74 0x66efe4 in ?? ??:0 #75 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #76 0x5745f0 in ?? ??:0 #77 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #78 0x7a7429 in ?? ??:0 #79 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #80 0x7995cc in ?? ??:0 #81 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #82 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #83 0x7a9847 in ?? ??:0 #84 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #85 0x7ac2ea in ?? ??:0 #86 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #87 0x574668 in ?? ??:0 #88 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #89 0x5749fa in ?? ??:0 #90 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #91 0x573e9b in ?? ??:0 #92 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #93 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #94 0x793369 in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #107 0x66efe4 in ?? ??:0 #108 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #109 0x5745f0 in ?? ??:0 #110 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #111 0x7a7429 in ?? ??:0 #112 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #113 0x7995cc in ?? ??:0 #114 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #115 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #116 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #117 0x7ab4cb in ?? ??:0 #118 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #119 0x7a76f2 in ?? ??:0 #120 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #121 0x7995cc in ?? ??:0 #122 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #123 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #124 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #125 0x7ab4cb in ?? ??:0 #126 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #127 0x7a76f2 in ?? ??:0 #128 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #129 0x7995cc in ?? ??:0 #130 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #131 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #132 0x7a9847 in ?? ??:0 #133 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #134 0x7ac2ea in ?? ??:0 #135 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #136 0x574668 in ?? ??:0 #137 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #138 0x5749fa in ?? ??:0 #139 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #140 0x573e9b in ?? ??:0 #141 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #142 0x6713f8 in ?? ??:0 #143 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #144 0x666d8d in ?? ??:0 #145 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #146 0x5745f0 in ?? ??:0 #147 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #148 0x7a7429 in ?? ??:0 #149 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #150 0x7995cc in ?? ??:0 #151 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #152 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #153 0x7a9847 in ?? ??:0 #154 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #155 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #156 0x78e0df in ?? ??:0 #157 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #158 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #159 0x5142f5 in ?? ??:0 #160 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #161 0x512afa in ?? ??:0 #162 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #163 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #164 0x53eefd in ?? ??:0 #165 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #166 0x503d16 in ?? ??:0 #167 0x7fab5921b82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #168 0x7fab5921b82f in ?? ??:0 #169 0x432548 in _start ??:? #170 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x36cd0) ==18885==ABORTING ---------- components: Interpreter Core files: cfield_1336 messages: 287319 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7fab556df550 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46580/cfield_1336 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:44:02 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:44:02 +0000 Subject: [issue29486] AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 Message-ID: <1486565042.15.0.952325483441.issue29486@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x00007ffff63a6dfe in i_set (ptr=0x8007f5b3f5e8, value=, size=4) at /home/test/check/PythonGDB/Modules/_ctypes/cfield.c:650 650 x = SET(int, x, val, size); Description: Access violation Short description: AccessViolation (21/22) Hash: 0e6533f2dc6ec45bf8aced4adaa8169a.5ae343e4a8ceeca018e7fc78f552033e Exploitability Classification: UNKNOWN Explanation: The target crashed due to an access violation but there is not enough additional information available to determine exploitability. ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18660==ERROR: AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 (pc 0x7f0ef90f6e68 bp 0x619000035c98 sp 0x7ffe7b44e2e0 T0) #0 0x7f0ef90f6e67 in i_set /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:651 #1 0x7f0ef90f6e67 in ?? ??:0 #2 0x7f0ef90da8ea in PyCData_set /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2916 #3 0x7f0ef90da8ea in ?? ??:0 #4 0x7f0ef90f5470 in PyCField_set /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:216 #5 0x7f0ef90f5470 in ?? ??:0 #6 0x63b1e7 in _PyObject_GenericSetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1152 #7 0x63b1e7 in ?? ??:0 #8 0x639d52 in PyObject_SetAttr /home/test/check/PythonASAN/Objects/object.c:932 #9 0x639d52 in ?? ??:0 #10 0x79ad9e in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2249 #11 0x79ad9e in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #16 0x7ab648 in ?? ??:0 #17 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #18 0x7a76f2 in ?? ??:0 #19 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #20 0x7995cc in ?? ??:0 #21 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #23 0x7a9847 in ?? ??:0 #24 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #25 0x7ac2ea in ?? ??:0 #26 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #27 0x574668 in ?? ??:0 #28 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #29 0x5749fa in ?? ??:0 #30 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #31 0x573e9b in ?? ??:0 #32 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #33 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #34 0x793369 in ?? ??:0 #35 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #36 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #37 0x7a9847 in ?? ??:0 #38 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #39 0x7ac2ea in ?? ??:0 #40 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #41 0x574668 in ?? ??:0 #42 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #43 0x5749fa in ?? ??:0 #44 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #45 0x573e9b in ?? ??:0 #46 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #47 0x66efe4 in ?? ??:0 #48 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #49 0x5745f0 in ?? ??:0 #50 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #51 0x7a7429 in ?? ??:0 #52 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #53 0x7995cc in ?? ??:0 #54 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #55 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #56 0x7a9847 in ?? ??:0 #57 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #58 0x7ac2ea in ?? ??:0 #59 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #60 0x574668 in ?? ??:0 #61 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #62 0x5749fa in ?? ??:0 #63 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #64 0x573e9b in ?? ??:0 #65 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #66 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #67 0x793369 in ?? ??:0 #68 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #69 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #70 0x7a9847 in ?? ??:0 #71 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #72 0x7ac2ea in ?? ??:0 #73 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #74 0x574668 in ?? ??:0 #75 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #76 0x5749fa in ?? ??:0 #77 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #78 0x573e9b in ?? ??:0 #79 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #80 0x66efe4 in ?? ??:0 #81 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #82 0x5745f0 in ?? ??:0 #83 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #84 0x7a7429 in ?? ??:0 #85 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #86 0x7995cc in ?? ??:0 #87 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #88 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #89 0x7a9847 in ?? ??:0 #90 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #91 0x7ac2ea in ?? ??:0 #92 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #93 0x574668 in ?? ??:0 #94 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #95 0x5749fa in ?? ??:0 #96 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #97 0x573e9b in ?? ??:0 #98 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #99 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #100 0x793369 in ?? ??:0 #101 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #102 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #103 0x7a9847 in ?? ??:0 #104 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #105 0x7ac2ea in ?? ??:0 #106 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #107 0x574668 in ?? ??:0 #108 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #109 0x5749fa in ?? ??:0 #110 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #111 0x573e9b in ?? ??:0 #112 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #113 0x66efe4 in ?? ??:0 #114 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #115 0x5745f0 in ?? ??:0 #116 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #117 0x7a7429 in ?? ??:0 #118 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #119 0x7995cc in ?? ??:0 #120 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #121 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #122 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #123 0x7ab4cb in ?? ??:0 #124 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #125 0x7a76f2 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #138 0x7a9847 in ?? ??:0 #139 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #140 0x7ac2ea in ?? ??:0 #141 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #142 0x574668 in ?? ??:0 #143 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #144 0x5749fa in ?? ??:0 #145 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #146 0x573e9b in ?? ??:0 #147 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #148 0x6713f8 in ?? ??:0 #149 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #150 0x666d8d in ?? ??:0 #151 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #152 0x5745f0 in ?? ??:0 #153 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #154 0x7a7429 in ?? ??:0 #155 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #156 0x7995cc in ?? ??:0 #157 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #158 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #159 0x7a9847 in ?? ??:0 #160 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #161 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #162 0x78e0df in ?? ??:0 #163 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #164 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #165 0x5142f5 in ?? ??:0 #166 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #167 0x512afa in ?? ??:0 #168 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #169 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #170 0x53eefd in ?? ??:0 #171 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #172 0x503d16 in ?? ??:0 #173 0x7f0efc49282f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #174 0x7f0efc49282f in ?? ??:0 #175 0x432548 in _start ??:? #176 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x34e67) ==18660==ABORTING ---------- components: Interpreter Core files: cfield_651 messages: 287320 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46581/cfield_651 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:44:49 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:44:49 +0000 Subject: [issue29487] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 Message-ID: <1486565088.06.0.199584603629.issue29487@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19362) exited with code 01] ASAN: ================================================================= ==18038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 at pc 0x7fbe64d4ef87 bp 0x7ffdd65d7190 sp 0x7ffdd65d7188 READ of size 4 at 0x60200000e734 thread T0 #0 0x7fbe64d4ef86 in i_get /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:675 #1 0x7fbe64d4ef86 in ?? ??:0 #2 0x7fbe64d40dca in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5026 (discriminator 1) #3 0x7fbe64d40dca in ?? ??:0 #4 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #5 0x79987c in ?? ??:0 #6 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #8 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #9 0x7ab4cb in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7fbe686a582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7fbe686a582f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 0x60200000e734 is located 0 bytes to the right of 4-byte region [0x60200000e730,0x60200000e734) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7fbe648cc9bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7fbe648cc9bc in ?? ??:0 #2 0x7ffdd65d6e3f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x34f86) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[04]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18038==ABORTING ---------- components: Interpreter Core files: cfield_675 messages: 287321 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46582/cfield_675 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:45:38 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:45:38 +0000 Subject: [issue29488] AddressSanitizer: SEGV on unknown address 0x0001a5525c1b Message-ID: <1486565137.31.0.431748723797.issue29488@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff639c455 in PyCData_clear (self=0x7ffff5b3f510) at /home/test/check/PythonGDB/Modules/_ctypes/_ctypes.c:2497 2497 Py_CLEAR(self->b_objects); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 8dc538f2a05876e51d4aacf57c47935b.6a0f7d54d57adbe0b04a497a3ee9c96c Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18570==ERROR: AddressSanitizer: SEGV on unknown address 0x0001a5525c1b (pc 0x7f922b0d9c62 bp 0x7f922b0d9c20 sp 0x7ffc440acf10 T0) #0 0x7f922b0d9c61 in PyCData_clear /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2497 (discriminator 3) #1 0x7f922b0d9c61 in PyCData_dealloc /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2509 (discriminator 3) #2 0x7f922b0d9c61 in ?? ??:0 #3 0x65d51a in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1222 #4 0x65d51a in ?? ??:0 #5 0x60fb27 in free_keys_object /home/test/check/PythonASAN/Objects/dictobject.c:561 (discriminator 5) #6 0x60fb27 in ?? ??:0 #7 0x6163fa in dict_dealloc /home/test/check/PythonASAN/Objects/dictobject.c:1933 (discriminator 1) #8 0x6163fa in ?? ??:0 #9 0x7f922b0d9ca8 in PyCData_clear /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2497 (discriminator 5) #10 0x7f922b0d9ca8 in PyCData_dealloc /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2509 (discriminator 5) #11 0x7f922b0d9ca8 in ?? ??:0 #12 0x65d51a in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1222 #13 0x65d51a in ?? ??:0 #14 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #15 0x5d10da in ?? ??:0 #16 0x7a98ca in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4130 (discriminator 3) #17 0x7a98ca in ?? ??:0 #18 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #19 0x7ab648 in ?? ??:0 #20 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #21 0x7a76f2 in ?? ??:0 #22 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #23 0x7995cc in ?? ??:0 #24 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #25 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #26 0x7a9847 in ?? ??:0 #27 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #28 0x7ac2ea in ?? ??:0 #29 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #30 0x574668 in ?? ??:0 #31 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #32 0x5749fa in ?? ??:0 #33 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #34 0x573e9b in ?? ??:0 #35 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #36 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #37 0x793369 in ?? ??:0 #38 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #39 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #40 0x7a9847 in ?? ??:0 #41 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #42 0x7ac2ea in ?? ??:0 #43 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #44 0x574668 in ?? ??:0 #45 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #46 0x5749fa in ?? ??:0 #47 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #48 0x573e9b in ?? ??:0 #49 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #50 0x66efe4 in ?? ??:0 #51 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #52 0x5745f0 in ?? ??:0 #53 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #54 0x7a7429 in ?? ??:0 #55 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #56 0x7995cc in ?? ??:0 #57 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #58 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #59 0x7a9847 in ?? ??:0 #60 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #61 0x7ac2ea in ?? ??:0 #62 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #63 0x574668 in ?? ??:0 #64 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #65 0x5749fa in ?? ??:0 #66 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #67 0x573e9b in ?? ??:0 #68 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #69 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #70 0x793369 in ?? ??:0 #71 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #72 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #73 0x7a9847 in ?? ??:0 #74 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #75 0x7ac2ea in ?? ??:0 #76 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #77 0x574668 in ?? ??:0 #78 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #79 0x5749fa in ?? ??:0 #80 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #81 0x573e9b in ?? ??:0 #82 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #83 0x66efe4 in ?? ??:0 #84 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #85 0x5745f0 in ?? ??:0 #86 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #87 0x7a7429 in ?? ??:0 #88 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #89 0x7995cc in ?? ??:0 #90 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #91 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #92 0x7a9847 in ?? ??:0 #93 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #94 0x7ac2ea in ?? ??:0 #95 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #96 0x574668 in ?? ??:0 #97 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #98 0x5749fa in ?? ??:0 #99 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #100 0x573e9b in ?? ??:0 #101 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #102 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #103 0x793369 in ?? ??:0 #104 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #105 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #106 0x7a9847 in ?? ??:0 #107 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #108 0x7ac2ea in ?? ??:0 #109 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #110 0x574668 in ?? ??:0 #111 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #112 0x5749fa in ?? ??:0 #113 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #114 0x573e9b in ?? ??:0 #115 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #116 0x66efe4 in ?? ??:0 #117 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #118 0x5745f0 in ?? ??:0 #119 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #120 0x7a7429 in ?? ??:0 #121 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #122 0x7995cc in ?? ??:0 #123 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #124 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #125 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #126 0x7ab4cb in ?? ??:0 #127 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #128 0x7a76f2 in ?? ??:0 #129 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #130 0x7995cc in ?? ??:0 #131 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #132 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #133 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #134 0x7ab4cb in ?? ??:0 #135 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #136 0x7a76f2 in ?? ??:0 #137 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #138 0x7995cc in ?? ??:0 #139 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #140 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #141 0x7a9847 in ?? ??:0 #142 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #143 0x7ac2ea in ?? ??:0 #144 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #145 0x574668 in ?? ??:0 #146 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #147 0x5749fa in ?? ??:0 #148 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #149 0x573e9b in ?? ??:0 #150 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #151 0x6713f8 in ?? ??:0 #152 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #153 0x666d8d in ?? ??:0 #154 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #155 0x5745f0 in ?? ??:0 #156 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #157 0x7a7429 in ?? ??:0 #158 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #159 0x7995cc in ?? ??:0 #160 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #161 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #162 0x7a9847 in ?? ??:0 #163 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #164 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #165 0x78e0df in ?? ??:0 #166 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #167 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #168 0x5142f5 in ?? ??:0 #169 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #170 0x512afa in ?? ??:0 #171 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #172 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #173 0x53eefd in ?? ??:0 #174 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #175 0x503d16 in ?? ??:0 #176 0x7f922e50882f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #177 0x7f922e50882f in ?? ??:0 #178 0x432548 in _start ??:? #179 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x17c61) ==18570==ABORTING ---------- components: Interpreter Core files: ctypes_2497 messages: 287322 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0001a5525c1b type: security versions: Python 3.6 Added file: http://bugs.python.org/file46583/ctypes_2497 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:46:24 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:46:24 +0000 Subject: [issue29489] AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 Message-ID: <1486565184.6.0.709487123747.issue29489@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5d87282 in Pointer_item (index=32767, myself=0x7ffff5b3b620) at /home/test/check/PythonGDB/Modules/_ctypes/_ctypes.c:4748 4748 if (*(void **)self->b_ptr == NULL) { Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 6d733dd19a93baf3031238df7085b89d.f931e2f4bcacefcb07769ddcf0b1360f Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18357==ERROR: AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 (pc 0x7f4a36e40562 bp 0x7ffc8c278530 sp 0x7ffc8c278060 T0) #0 0x7f4a36e40561 in Pointer_item /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:4748 #1 0x7f4a36e40561 in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #6 0x7a9847 in ?? ??:0 #7 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #8 0x7ab648 in ?? ??:0 #9 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #10 0x7a76f2 in ?? ??:0 #11 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #12 0x7995cc in ?? ??:0 #13 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #14 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #15 0x7a9847 in ?? ??:0 #16 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #17 0x7ac2ea in ?? ??:0 #18 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #19 0x574668 in ?? ??:0 #20 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #21 0x5749fa in ?? ??:0 #22 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #23 0x573e9b in ?? ??:0 #24 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #25 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #26 0x793369 in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #39 0x66efe4 in ?? ??:0 #40 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #41 0x5745f0 in ?? ??:0 #42 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #43 0x7a7429 in ?? ??:0 #44 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #45 0x7995cc in ?? ??:0 #46 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #47 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #48 0x7a9847 in ?? ??:0 #49 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #50 0x7ac2ea in ?? ??:0 #51 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #52 0x574668 in ?? ??:0 #53 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #54 0x5749fa in ?? ??:0 #55 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #56 0x573e9b in ?? ??:0 #57 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #58 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #59 0x793369 in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #72 0x66efe4 in ?? ??:0 #73 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #74 0x5745f0 in ?? ??:0 #75 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #76 0x7a7429 in ?? ??:0 #77 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #78 0x7995cc in ?? ??:0 #79 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #80 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #81 0x7a9847 in ?? ??:0 #82 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #83 0x7ac2ea in ?? ??:0 #84 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #85 0x574668 in ?? ??:0 #86 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #87 0x5749fa in ?? ??:0 #88 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #89 0x573e9b in ?? ??:0 #90 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #91 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #92 0x793369 in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #105 0x66efe4 in ?? ??:0 #106 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #107 0x5745f0 in ?? ??:0 #108 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #109 0x7a7429 in ?? ??:0 #110 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #111 0x7995cc in ?? ??:0 #112 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #113 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #114 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #115 0x7ab4cb in ?? ??:0 #116 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #117 0x7a76f2 in ?? ??:0 #118 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #119 0x7995cc in ?? ??:0 #120 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #121 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #122 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #123 0x7ab4cb in ?? ??:0 #124 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #125 0x7a76f2 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #130 0x7a9847 in ?? ??:0 #131 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #132 0x7ac2ea in ?? ??:0 #133 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #134 0x574668 in ?? ??:0 #135 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #136 0x5749fa in ?? ??:0 #137 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #138 0x573e9b in ?? ??:0 #139 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #140 0x6713f8 in ?? ??:0 #141 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #142 0x666d8d in ?? ??:0 #143 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #144 0x5745f0 in ?? ??:0 #145 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #146 0x7a7429 in ?? ??:0 #147 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #148 0x7995cc in ?? ??:0 #149 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #150 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #151 0x7a9847 in ?? ??:0 #152 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #153 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #154 0x78e0df in ?? ??:0 #155 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #156 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #157 0x5142f5 in ?? ??:0 #158 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #159 0x512afa in ?? ??:0 #160 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #161 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #162 0x53eefd in ?? ??:0 #163 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #164 0x503d16 in ?? ??:0 #165 0x7f4a3a79082f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #166 0x7f4a3a79082f in ?? ??:0 #167 0x432548 in _start ??:? #168 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x26561) ==18357==ABORTING ---------- components: Interpreter Core files: ctypes_4748 messages: 287323 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46584/ctypes_4748 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:46:55 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:46:55 +0000 Subject: [issue29485] AddressSanitizer: SEGV on unknown address 0x7fab556df550 In-Reply-To: <1486564978.33.0.577417713514.issue29485@psf.upfronthosting.co.za> Message-ID: <1486565215.49.0.00787749482547.issue29485@psf.upfronthosting.co.za> St?phane Wirtel added the comment: See #issue29486 ---------- nosy: +matrixise resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:47:25 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:47:25 +0000 Subject: [issue29483] AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 In-Reply-To: <1486564829.78.0.80987262722.issue29483@psf.upfronthosting.co.za> Message-ID: <1486565245.42.0.761369383723.issue29483@psf.upfronthosting.co.za> Christian Heimes added the comment: _ctypes_test is an internal test helper module. It's not designed to be used outside of tests. The module contains quick and dirty C code for tests. Any bug in _ctypes_test is not a security bug. Feel free to contribute better code, though. ---------- components: +Tests -Interpreter Core nosy: +christian.heimes priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:47:36 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:47:36 +0000 Subject: [issue29490] AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f Message-ID: <1486565256.82.0.439128753451.issue29490@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19391) exited with code 01] ASAN: ================================================================= ==17908==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f at pc 0x7f191d68154b bp 0x7ffd5c1c7e60 sp 0x7ffd5c1c7e58 READ of size 1 at 0x60200000e72f thread T0 #0 0x7f191d68154a in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:4992 #1 0x7f191d68154a in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f1920fba82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f1920fba82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 0x60200000e72f is located 1 bytes to the left of 2-byte region [0x60200000e730,0x60200000e732) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f191d1f5964 in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 2) #3 0x7f191d1f5964 in ?? ??:0 #2 0x7ffd5c1c7aff () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x2754a) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa[fa]02 fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17908==ABORTING ---------- components: Interpreter Core files: ctypes_4992 messages: 287326 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f type: security versions: Python 3.6 Added file: http://bugs.python.org/file46585/ctypes_4992 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:48:14 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:48:14 +0000 Subject: [issue29491] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 Message-ID: <1486565293.5.0.613764150228.issue29491@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19397) exited with code 01] ASAN: ================================================================= ==17935==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 at pc 0x7f6e87941564 bp 0x7fff533392c0 sp 0x7fff533392b8 READ of size 4 at 0x60200000e734 thread T0 #0 0x7f6e87941563 in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5013 #1 0x7f6e87941563 in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f6e8b28d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f6e8b28d82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 0x60200000e734 is located 0 bytes to the right of 4-byte region [0x60200000e730,0x60200000e734) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f6e874cc9bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7f6e874cc9bc in ?? ??:0 #2 0x7fff53338f5f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x27563) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[04]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17935==ABORTING ---------- components: Interpreter Core files: ctypes_5013 messages: 287327 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 versions: Python 3.6 Added file: http://bugs.python.org/file46586/ctypes_5013 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:48:54 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:48:54 +0000 Subject: [issue29491] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565293.5.0.613764150228.issue29491@psf.upfronthosting.co.za> Message-ID: <1486565334.17.0.613791542139.issue29491@psf.upfronthosting.co.za> Changes by BeginVuln : ---------- type: -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:49:05 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:49:05 +0000 Subject: [issue29484] AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 In-Reply-To: <1486564902.18.0.325996539342.issue29484@psf.upfronthosting.co.za> Message-ID: <1486565345.79.0.445400645542.issue29484@psf.upfronthosting.co.za> Christian Heimes added the comment: _ctypes_test is an internal test helper module. It's not designed to be used outside of tests. The module contains quick and dirty C code for tests. Any bug in _ctypes_test is not a security bug. Feel free to contribute better code, though. ---------- components: +Tests -Interpreter Core nosy: +christian.heimes priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:49:50 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:49:50 +0000 Subject: [issue29492] AddressSanitizer: SEGV on unknown address 0x0000a0013639 Message-ID: <1486565390.59.0.464737357011.issue29492@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000049b304 in dict_dealloc (mp=0x7ffff5b44510) at Objects/dictobject.c:1925 1925 Py_XDECREF(values[i]); Description: Access violation during branch instruction Short description: BranchAv (4/22) Hash: 88d6a4b120e0fabdcb9b56178f8ef166.2c4f31b17f90f974f2ff23d3286fcbbd Exploitability Classification: EXPLOITABLE Explanation: The target crashed on a branch instruction, which may indicate that the control flow is tainted. Other tags: DestAv (8/22), AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18235==ERROR: AddressSanitizer: SEGV on unknown address 0x0000a0013639 (pc 0x00000061637c bp 0x7efd09781be8 sp 0x7ffe3da51c50 T0) #0 0x61637b in dict_dealloc /home/test/check/PythonASAN/Objects/dictobject.c:1925 (discriminator 5) #1 0x61637b in ?? ??:0 #2 0x65d3b9 in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1207 (discriminator 3) #3 0x65d3b9 in ?? ??:0 #4 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #5 0x5d10da in ?? ??:0 #6 0x7a98ca in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4130 (discriminator 3) #7 0x7a98ca in ?? ??:0 #8 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #9 0x7ab648 in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7efd0d28782f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7efd0d28782f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x61637b) ==18235==ABORTING ---------- components: Interpreter Core files: dicobj_1925 messages: 287329 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0000a0013639 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46587/dicobj_1925 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:50:45 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:50:45 +0000 Subject: [issue29493] AddressSanitizer: SEGV on unknown address 0x000cffff800d Message-ID: <1486565445.54.0.388710643733.issue29493@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000043d563 in PyObject_GC_UnTrack (op=0x7ffff3810400) at Modules/gcmodule.c:1699 1699 _PyObject_GC_UNTRACK(op); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: a30125899c34aa234161214a7afc7066.d78488ccad0508b81b411140385e7113 Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: EsFASAN:DEADLYSIGNAL ================================================================= ==18094==ERROR: AddressSanitizer: SEGV on unknown address 0x000cffff800d (pc 0x000000543039 bp 0x0fec572c0c81 sp 0x7ffc421b9cf0 T0) #0 0x543038 in PyObject_GC_UnTrack /home/test/check/PythonASAN/Modules/gcmodule.c:1699 (discriminator 4) #1 0x543038 in ?? ??:0 #2 0x65ca2f in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1133 #3 0x65ca2f in ?? ??:0 #4 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #5 0x5d10da in ?? ??:0 #6 0x5304c4 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:55 (discriminator 5) #7 0x5304c4 in ?? ??:0 #8 0x530456 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:54 (discriminator 5) #9 0x530456 in ?? ??:0 #10 0x530456 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:54 (discriminator 5) #11 0x530456 in ?? ??:0 #12 0x5b3b49 in BaseException_clear /home/test/check/PythonASAN/Objects/exceptions.c:76 (discriminator 5) #13 0x5b3b49 in ?? ??:0 #14 0x5b3742 in BaseException_dealloc /home/test/check/PythonASAN/Objects/exceptions.c:86 #15 0x5b3742 in ?? ??:0 #16 0x656df9 in tupledealloc /home/test/check/PythonASAN/Objects/tupleobject.c:243 (discriminator 5) #17 0x656df9 in ?? ??:0 #18 0x656df9 in tupledealloc /home/test/check/PythonASAN/Objects/tupleobject.c:243 (discriminator 5) #19 0x656df9 in ?? ??:0 #20 0x5e5c19 in list_clear /home/test/check/PythonASAN/Objects/listobject.c:562 (discriminator 5) #21 0x5e5c19 in listclear /home/test/check/PythonASAN/Objects/listobject.c:763 (discriminator 5) #22 0x5e5c19 in ?? ??:0 #23 0x632208 in _PyCFunction_FastCallDict /home/test/check/PythonASAN/Objects/methodobject.c:192 #24 0x632208 in ?? ??:0 #25 0x7a7751 in call_function /home/test/check/PythonASAN/Python/ceval.c:4788 (discriminator 17) #26 0x7a7751 in ?? ??:0 #27 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #28 0x7995cc in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #41 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #42 0x793369 in ?? ??:0 #43 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #44 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #45 0x7a9847 in ?? ??:0 #46 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #47 0x7ac2ea in ?? ??:0 #48 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #49 0x574668 in ?? ??:0 #50 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #51 0x5749fa in ?? ??:0 #52 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #53 0x573e9b in ?? ??:0 #54 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #55 0x66efe4 in ?? ??:0 #56 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #57 0x5745f0 in ?? ??:0 #58 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #59 0x7a7429 in ?? ??:0 #60 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #61 0x7995cc in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #74 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #75 0x793369 in ?? ??:0 #76 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #77 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #78 0x7a9847 in ?? ??:0 #79 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #80 0x7ac2ea in ?? ??:0 #81 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #82 0x574668 in ?? ??:0 #83 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #84 0x5749fa in ?? ??:0 #85 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #86 0x573e9b in ?? ??:0 #87 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #88 0x66efe4 in ?? ??:0 #89 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #90 0x5745f0 in ?? ??:0 #91 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #92 0x7a7429 in ?? ??:0 #93 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #94 0x7995cc in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #107 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #108 0x793369 in ?? ??:0 #109 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #110 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #111 0x7a9847 in ?? ??:0 #112 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #113 0x7ac2ea in ?? ??:0 #114 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #115 0x574668 in ?? ??:0 #116 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #117 0x5749fa in ?? ??:0 #118 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #119 0x573e9b in ?? ??:0 #120 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #121 0x66efe4 in ?? ??:0 #122 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #123 0x5745f0 in ?? ??:0 #124 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #125 0x7a7429 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #138 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #139 0x7ab4cb in ?? ??:0 #140 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #141 0x7a76f2 in ?? ??:0 #142 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #143 0x7995cc in ?? ??:0 #144 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #145 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #146 0x7a9847 in ?? ??:0 #147 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #148 0x7ac2ea in ?? ??:0 #149 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #150 0x574668 in ?? ??:0 #151 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #152 0x5749fa in ?? ??:0 #153 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #154 0x573e9b in ?? ??:0 #155 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #156 0x6713f8 in ?? ??:0 #157 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #158 0x666d8d in ?? ??:0 #159 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #160 0x5745f0 in ?? ??:0 #161 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #162 0x7a7429 in ?? ??:0 #163 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #164 0x7995cc in ?? ??:0 #165 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #166 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #167 0x7a9847 in ?? ??:0 #168 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #169 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #170 0x78e0df in ?? ??:0 #171 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #172 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #173 0x5142f5 in ?? ??:0 #174 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #175 0x512afa in ?? ??:0 #176 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #177 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #178 0x53eefd in ?? ??:0 #179 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #180 0x503d16 in ?? ??:0 #181 0x7f62bf5d482f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #182 0x7f62bf5d482f in ?? ??:0 #183 0x432548 in _start ??:? #184 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x543038) ==18094==ABORTING ---------- components: Interpreter Core files: gcmodule_1699 messages: 287330 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000cffff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46588/gcmodule_1699 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:51:44 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:51:44 +0000 Subject: [issue29494] AddressSanitizer: SEGV on unknown address 0x00009fff8001 Message-ID: <1486565504.05.0.501881320896.issue29494@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. visit_decref (op=0x100000000, data=0x0) at Modules/gcmodule.c:374 374 if (PyObject_IS_GC(op)) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 5ae0cf182ca6c91339ba4d86e35281e3.974794321b75f348830f6ff316f662f4 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18468==ERROR: AddressSanitizer: SEGV on unknown address 0x00009fff8001 (pc 0x000000544b5f bp 0x7ffeeb051e90 sp 0x7ffeeb051c30 T0) #0 0x544b5e in visit_decref /home/test/check/PythonASAN/Modules/gcmodule.c:374 #1 0x544b5e in ?? ??:0 #2 0x5d7035 in func_traverse /home/test/check/PythonASAN/Objects/funcobject.c:558 (discriminator 8) #3 0x5d7035 in ?? ??:0 #4 0x540ca1 in subtract_refs /home/test/check/PythonASAN/Modules/gcmodule.c:399 #5 0x540ca1 in collect /home/test/check/PythonASAN/Modules/gcmodule.c:956 #6 0x540ca1 in ?? ??:0 #7 0x5406ed in collect_with_callback /home/test/check/PythonASAN/Modules/gcmodule.c:1128 #8 0x5406ed in PyGC_Collect /home/test/check/PythonASAN/Modules/gcmodule.c:1592 #9 0x5406ed in _PyGC_CollectIfEnabled /home/test/check/PythonASAN/Modules/gcmodule.c:1605 #10 0x5406ed in ?? ??:0 #11 0x50d31a in Py_FinalizeEx /home/test/check/PythonASAN/Python/pylifecycle.c:603 #12 0x50d31a in ?? ??:0 #13 0x50e127 in Py_Exit /home/test/check/PythonASAN/Python/pylifecycle.c:1537 #14 0x50e127 in ?? ??:0 #15 0x51537b in handle_system_exit /home/test/check/PythonASAN/Python/pythonrun.c:602 #16 0x51537b in ?? ??:0 #17 0x5146b0 in PyErr_PrintEx /home/test/check/PythonASAN/Python/pythonrun.c:612 #18 0x5146b0 in ?? ??:0 #19 0x512c87 in PyErr_Print /home/test/check/PythonASAN/Python/pythonrun.c:508 #20 0x512c87 in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:401 #21 0x512c87 in ?? ??:0 #22 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #23 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #24 0x53eefd in ?? ??:0 #25 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #26 0x503d16 in ?? ??:0 #27 0x7fcae111d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #28 0x7fcae111d82f in ?? ??:0 #29 0x432548 in _start ??:? #30 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x544b5e) ==18468==ABORTING ---------- components: Interpreter Core files: gcmodule_374 messages: 287331 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x00009fff8001 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46589/gcmodule_374 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:51:53 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:51:53 +0000 Subject: [issue29492] AddressSanitizer: SEGV on unknown address 0x0000a0013639 In-Reply-To: <1486565390.59.0.464737357011.issue29492@psf.upfronthosting.co.za> Message-ID: <1486565513.07.0.713841322676.issue29492@psf.upfronthosting.co.za> Christian Heimes added the comment: Please stop flooding the bug tracker with automated messages. All your 'exploits' are using ctypes. ctypes code is not memory safe and can easily trigger all sorts of bugs and crashes. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:52:36 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Feb 2017 14:52:36 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486565556.36.0.242311298341.issue29476@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > How this change affects this case? I would expect to see a tiny net benefit. The set.add() would be microscopically faster (because of less work finding and going back to a free slot). The set.discard() would do the same work (locating a value and marking it as a dummy). The resize step would run at the same speed (it just skips over dummies and reinserts only active values). The resize would run a little earlier (because we're not reusing a small proportion of the dummy entries) but it would clean out 100% of the dummies, making the table more sparse sooner. > Sets often are used in following pattern Not really. This is one use pattern out of many and is one of the least common. The two dominant use cases for sets are uniquification (deduping) and fast membership testing. The third most common case is data analysis using fast set-to-set operations (union, intersection, and difference). Then comes cases with individual element membership tests followed by an individual element set.add (i.e. the "if x not in seen: {seen.add(x); work_on(x);}" case). Dead last are the affected cases that the bounce around with a mix of set.add() and set.discard() or set.remove(). The comment in dictobject.c suggests that the latter case is uncommon by a factor of hundreds. Hence, I think work should be taken out of the inner loop for the common cases and instead deferred to the high-speed resize step which cleans out 100% of the dummy entries all at once. The common cases all benefit (none of those have dummies, so there is no reason at all to check for dummies in set_add_entry). The uncommon case (the mix of individual adds and discards) is about neutral or slightly positive (as explained above). I've tried to think of a case that would be negatively affected and all I can think of is repeatedly adding and removing exactly the *same* element or small group of elements. In that case, the freeslot would be reused 100% of the time and the would never need a resize. I've not seen such a case and if I had, I would still care about the common cases more. Also, I like the simplification of set_add_entry() and the separation of concerns (dummy reclamation occurs in exactly one place and that one place eliminates 100% of the dummies in a single pass). FWIW, there is a loose analogy between this idea and the trade-off between reference counting and GC. Reference counting reuses memory quicker than waiting for GC to reclaim memory in one pass later, but it entails encumbering all of the setting and deleting code. GC-only systems make the rest of the code much cleaner and faster, but they have to wait to reclaim memory all at once. Where the analogy fails though is that use of reuse of dummies in sets is by far the least common case, that early freeslot checks only recapture a small fraction of the deletions (only the ones that happen to have exactly the same hash slot), and that early freeslot checks are completely wasted in all of the common cases (which typically have no dummies at all). ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:53:08 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:53:08 +0000 Subject: [issue29495] AddressSanitizer: SEGV on unknown address 0x02007ea947c3 Message-ID: <1486565587.91.0.875598249655.issue29495@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 Description: Access violation near NULL on source operand Short description: SourceAvNearNull (16/22) Hash: 524fc888253e60855a72647740103ec8.0dd959fe8965dda124a3c8d6b55807e3 Exploitability Classification: PROBABLY_NOT_EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation, which may mean the application crashed on a simple NULL dereference to data structure that has no immediate effect on control of the processor. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18706==ERROR: AddressSanitizer: SEGV on unknown address 0x02007ea947c3 (pc 0x00000044ffe7 bp 0x7fffaa71f040 sp 0x7fffaa71e7e0 T0) #0 0x44ffe6 in __interceptor_strlen.part.45 asan_interceptors.cc.o:? #1 0x44ffe6 in ?? ??:0 #2 0x7f2309ccc95b in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 1) #3 0x7f2309ccc95b in ?? ??:0 #4 0x7f2309f17e3f in ffi_call_unix64 ??:? #5 0x7f2309f17e3f in ?? ??:0 #6 0x7f2309f178aa in ffi_call ??:? #7 0x7f2309f178aa in ?? ??:0 #8 0x7f230a145311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7f230a145311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7f230a145311 in ?? ??:0 #11 0x7f230a134199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7f230a134199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #21 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #22 0x7ab4cb in ?? ??:0 #23 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #24 0x7a76f2 in ?? ??:0 #25 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #26 0x7995cc in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #39 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #40 0x793369 in ?? ??:0 #41 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #42 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #43 0x7a9847 in ?? ??:0 #44 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #45 0x7ac2ea in ?? ??:0 #46 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #47 0x574668 in ?? ??:0 #48 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #49 0x5749fa in ?? ??:0 #50 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #51 0x573e9b in ?? ??:0 #52 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #53 0x66efe4 in ?? ??:0 #54 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #55 0x5745f0 in ?? ??:0 #56 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #57 0x7a7429 in ?? ??:0 #58 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #59 0x7995cc in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #72 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #73 0x793369 in ?? ??:0 #74 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #75 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #76 0x7a9847 in ?? ??:0 #77 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #78 0x7ac2ea in ?? ??:0 #79 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #80 0x574668 in ?? ??:0 #81 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #82 0x5749fa in ?? ??:0 #83 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #84 0x573e9b in ?? ??:0 #85 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #86 0x66efe4 in ?? ??:0 #87 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #88 0x5745f0 in ?? ??:0 #89 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #90 0x7a7429 in ?? ??:0 #91 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #92 0x7995cc in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #105 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #106 0x793369 in ?? ??:0 #107 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #108 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #109 0x7a9847 in ?? ??:0 #110 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #111 0x7ac2ea in ?? ??:0 #112 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #113 0x574668 in ?? ??:0 #114 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #115 0x5749fa in ?? ??:0 #116 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #117 0x573e9b in ?? ??:0 #118 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #119 0x66efe4 in ?? ??:0 #120 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #121 0x5745f0 in ?? ??:0 #122 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #123 0x7a7429 in ?? ??:0 #124 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #125 0x7995cc in ?? ??:0 #126 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #127 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #128 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #129 0x7ab4cb in ?? ??:0 #130 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #131 0x7a76f2 in ?? ??:0 #132 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #133 0x7995cc in ?? ??:0 #134 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #135 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #136 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #137 0x7ab4cb in ?? ??:0 #138 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #139 0x7a76f2 in ?? ??:0 #140 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #141 0x7995cc in ?? ??:0 #142 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #143 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #144 0x7a9847 in ?? ??:0 #145 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #146 0x7ac2ea in ?? ??:0 #147 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #148 0x574668 in ?? ??:0 #149 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #150 0x5749fa in ?? ??:0 #151 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #152 0x573e9b in ?? ??:0 #153 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #154 0x6713f8 in ?? ??:0 #155 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #156 0x666d8d in ?? ??:0 #157 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #158 0x5745f0 in ?? ??:0 #159 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #160 0x7a7429 in ?? ??:0 #161 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #162 0x7995cc in ?? ??:0 #163 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #164 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #165 0x7a9847 in ?? ??:0 #166 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #167 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #168 0x78e0df in ?? ??:0 #169 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #170 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #171 0x5142f5 in ?? ??:0 #172 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #173 0x512afa in ?? ??:0 #174 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #175 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #176 0x53eefd in ?? ??:0 #177 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #178 0x503d16 in ?? ??:0 #179 0x7f230da9b82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #180 0x7f230da9b82f in ?? ??:0 #181 0x432548 in _start ??:? #182 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x44ffe6) ==18706==ABORTING ---------- components: Interpreter Core files: inter messages: 287334 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x02007ea947c3 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46590/inter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:53:50 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:53:50 +0000 Subject: [issue29496] AddressSanitizer: SEGV on unknown address 0x01ffe96de071 Message-ID: <1486565630.26.0.23581787911.issue29496@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19429) exited with code 01] ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18136==ERROR: AddressSanitizer: SEGV on unknown address 0x01ffe96de071 (pc 0x0000005e9305 bp 0x7ffc234b3300 sp 0x7ffc234b3240 T0) #0 0x5e9304 in PyLong_AsLongAndOverflow /home/test/check/PythonASAN/Objects/longobject.c:408 #1 0x5e9304 in ?? ??:0 #2 0x5e9658 in PyLong_AsLong /home/test/check/PythonASAN/Objects/longobject.c:474 (discriminator 1) #3 0x5e9658 in ?? ??:0 #4 0x7fda5a8bfe3f in ffi_call_unix64 ??:? #5 0x7fda5a8bfe3f in ?? ??:0 #6 0x7fda5a8bf8aa in ffi_call ??:? #7 0x7fda5a8bf8aa in ?? ??:0 #8 0x7fda5aaed311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7fda5aaed311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7fda5aaed311 in ?? ??:0 #11 0x7fda5aadc199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7fda5aadc199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #21 0x7a9847 in ?? ??:0 #22 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #23 0x78e15d in ?? ??:0 #24 0x784f1a in builtin___build_class__ /home/test/check/PythonASAN/Python/bltinmodule.c:170 #25 0x784f1a in ?? ??:0 #26 0x631f93 in _PyCFunction_FastCallDict /home/test/check/PythonASAN/Objects/methodobject.c:231 #27 0x631f93 in ?? ??:0 #28 0x7a7751 in call_function /home/test/check/PythonASAN/Python/ceval.c:4788 (discriminator 17) #29 0x7a7751 in ?? ??:0 #30 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #31 0x7995cc in ?? ??:0 #32 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #33 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #34 0x7a9847 in ?? ??:0 #35 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #36 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #37 0x78e0df in ?? ??:0 #38 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #39 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #40 0x5142f5 in ?? ??:0 #41 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #42 0x512afa in ?? ??:0 #43 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #44 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #45 0x53eefd in ?? ??:0 #46 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #47 0x503d16 in ?? ??:0 #48 0x7fda5deaf82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #49 0x7fda5deaf82f in ?? ??:0 #50 0x432548 in _start ??:? #51 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x5e9304) ==18136==ABORTING ---------- components: Interpreter Core files: longobj_408 messages: 287335 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x01ffe96de071 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46591/longobj_408 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:54:34 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:54:34 +0000 Subject: [issue29482] AddressSanitizer: attempting double-free on 0x60b000007050 In-Reply-To: <1486564663.6.0.319136441437.issue29482@psf.upfronthosting.co.za> Message-ID: <1486565674.3.0.345866103323.issue29482@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:54:38 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:54:38 +0000 Subject: [issue29486] AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 In-Reply-To: <1486565042.15.0.952325483441.issue29486@psf.upfronthosting.co.za> Message-ID: <1486565678.51.0.0472803099172.issue29486@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:54:39 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:54:39 +0000 Subject: [issue29497] AddressSanitizer: SEGV on unknown address 0x000000000008 Message-ID: <1486565679.01.0.635065355996.issue29497@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff7116418 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 Description: Heap error Short description: HeapError (10/22) Hash: 2aa3ac417e1aa62c7fe1524ebca9f7a3.8d7f0ad1f2db61942ed3977c83757030 Exploitability Classification: EXPLOITABLE Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable. Other tags: AbortSignal (20/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18277==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f65f421d380 bp 0x7f65f4560b20 sp 0x7ffe10375320 T0) #0 0x7f65f421d37f in _int_free /build/glibc-GKVZIf/glibc-2.23/malloc/malloc.c:4057 #1 0x7f65f421d37f in ?? ??:0 #2 0x7f65f4220abb in __GI___libc_free /build/glibc-GKVZIf/glibc-2.23/malloc/malloc.c:2969 (discriminator 4) #3 0x7f65f4220abb in ?? ??:0 #4 0x7f65f0640e3f in ffi_call_unix64 ??:? #5 0x7f65f0640e3f in ?? ??:0 #6 0x7f65f06408aa in ffi_call ??:? #7 0x7f65f06408aa in ?? ??:0 #8 0x7f65f0885311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7f65f0885311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7f65f0885311 in ?? ??:0 #11 0x7f65f0874199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7f65f0874199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #21 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #22 0x7ab4cb in ?? ??:0 #23 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #24 0x7a76f2 in ?? ??:0 #25 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #26 0x7995cc in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #39 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #40 0x793369 in ?? ??:0 #41 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #42 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #43 0x7a9847 in ?? ??:0 #44 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #45 0x7ac2ea in ?? ??:0 #46 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #47 0x574668 in ?? ??:0 #48 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #49 0x5749fa in ?? ??:0 #50 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #51 0x573e9b in ?? ??:0 #52 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #53 0x66efe4 in ?? ??:0 #54 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #55 0x5745f0 in ?? ??:0 #56 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #57 0x7a7429 in ?? ??:0 #58 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #59 0x7995cc in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #72 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #73 0x793369 in ?? ??:0 #74 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #75 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #76 0x7a9847 in ?? ??:0 #77 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #78 0x7ac2ea in ?? ??:0 #79 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #80 0x574668 in ?? ??:0 #81 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #82 0x5749fa in ?? ??:0 #83 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #84 0x573e9b in ?? ??:0 #85 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #86 0x66efe4 in ?? ??:0 #87 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #88 0x5745f0 in ?? ??:0 #89 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #90 0x7a7429 in ?? ??:0 #91 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #92 0x7995cc in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #105 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #106 0x793369 in ?? ??:0 #107 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #108 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #109 0x7a9847 in ?? ??:0 #110 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #111 0x7ac2ea in ?? ??:0 #112 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #113 0x574668 in ?? ??:0 #114 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #115 0x5749fa in ?? ??:0 #116 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #117 0x573e9b in ?? ??:0 #118 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #119 0x66efe4 in ?? ??:0 #120 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #121 0x5745f0 in ?? ??:0 #122 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #123 0x7a7429 in ?? ??:0 #124 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #125 0x7995cc in ?? ??:0 #126 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #127 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #128 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #129 0x7ab4cb in ?? ??:0 #130 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #131 0x7a76f2 in ?? ??:0 #132 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #133 0x7995cc in ?? ??:0 #134 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #135 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #136 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #137 0x7ab4cb in ?? ??:0 #138 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #139 0x7a76f2 in ?? ??:0 #140 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #141 0x7995cc in ?? ??:0 #142 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #143 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #144 0x7a9847 in ?? ??:0 #145 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #146 0x7ac2ea in ?? ??:0 #147 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #148 0x574668 in ?? ??:0 #149 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #150 0x5749fa in ?? ??:0 #151 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #152 0x573e9b in ?? ??:0 #153 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #154 0x6713f8 in ?? ??:0 #155 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #156 0x666d8d in ?? ??:0 #157 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #158 0x5745f0 in ?? ??:0 #159 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #160 0x7a7429 in ?? ??:0 #161 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #162 0x7995cc in ?? ??:0 #163 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #164 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #165 0x7a9847 in ?? ??:0 #166 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #167 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #168 0x78e0df in ?? ??:0 #169 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #170 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #171 0x5142f5 in ?? ??:0 #172 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #173 0x512afa in ?? ??:0 #174 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #175 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #176 0x53eefd in ?? ??:0 #177 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #178 0x503d16 in ?? ??:0 #179 0x7f65f41bd82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #180 0x7f65f41bd82f in ?? ??:0 #181 0x432548 in _start ??:? #182 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x8037f) ==18277==ABORTING ---------- components: Interpreter Core files: malloc_4057 messages: 287336 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000000000008 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46592/malloc_4057 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:54:45 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:54:45 +0000 Subject: [issue29487] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565088.06.0.199584603629.issue29487@psf.upfronthosting.co.za> Message-ID: <1486565685.05.0.948251471258.issue29487@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:22 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:55:22 +0000 Subject: [issue29498] AddressSanitizer: SEGV on unknown address 0x0005ffff800d Message-ID: <1486565722.07.0.443557463109.issue29498@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _PyObject_GenericGetAttrWithDict (dict=0x2c0000006f, name=0x7ffff7eed3b0, obj=0x7ffff628ebf8) at Objects/object.c:1088 1088 Py_INCREF(dict); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 5fba3f64e0a5cd874121e05187de0b92.c7630c31a2ff26cdc6fb85881fa40252 Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: EsEASAN:DEADLYSIGNAL ================================================================= ==18600==ERROR: AddressSanitizer: SEGV on unknown address 0x0005ffff800d (pc 0x00000063acfe bp 0x7f86cde063b0 sp 0x7fffa5d9ea90 T0) #0 0x63acfd in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1088 #1 0x63acfd in ?? ??:0 #2 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #3 0x7966cc in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f86ccc5d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f86ccc5d82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x63acfd) ==18600==ABORTING ---------- components: Interpreter Core files: obj_1088 messages: 287337 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0005ffff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46593/obj_1088 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:26 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:55:26 +0000 Subject: [issue29488] AddressSanitizer: SEGV on unknown address 0x0001a5525c1b In-Reply-To: <1486565137.31.0.431748723797.issue29488@psf.upfronthosting.co.za> Message-ID: <1486565726.11.0.430678357658.issue29488@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:34 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:55:34 +0000 Subject: [issue29489] AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 In-Reply-To: <1486565184.6.0.709487123747.issue29489@psf.upfronthosting.co.za> Message-ID: <1486565734.4.0.185416800837.issue29489@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:44 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:55:44 +0000 Subject: [issue29483] AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 In-Reply-To: <1486564829.78.0.80987262722.issue29483@psf.upfronthosting.co.za> Message-ID: <1486565744.13.0.48689147015.issue29483@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:52 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:55:52 +0000 Subject: [issue29490] AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f In-Reply-To: <1486565256.82.0.439128753451.issue29490@psf.upfronthosting.co.za> Message-ID: <1486565752.29.0.46690211125.issue29490@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:00 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:00 +0000 Subject: [issue29491] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565293.5.0.613764150228.issue29491@psf.upfronthosting.co.za> Message-ID: <1486565760.82.0.998273833974.issue29491@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:09 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:09 +0000 Subject: [issue29484] AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 In-Reply-To: <1486564902.18.0.325996539342.issue29484@psf.upfronthosting.co.za> Message-ID: <1486565769.6.0.50889315493.issue29484@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:17 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:17 +0000 Subject: [issue29493] AddressSanitizer: SEGV on unknown address 0x000cffff800d In-Reply-To: <1486565445.54.0.388710643733.issue29493@psf.upfronthosting.co.za> Message-ID: <1486565777.53.0.904642984109.issue29493@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:20 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:56:20 +0000 Subject: [issue29499] AddressSanitizer: SEGV on unknown address 0x000ebfff800d Message-ID: <1486565778.73.0.558630262267.issue29499@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _PyObject_Alloc (ctx=0x0, elsize=136, nelem=1, use_calloc=0) at Objects/obmalloc.c:1258 1258 if ((pool->freeblock = *(block **)bp) != NULL) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 931f1ff7977aaf47bb64eec6d074074f.3e2cbb794853bcf6a077da4bfa99ade4 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: EsEASAN:DEADLYSIGNAL ================================================================= ==18115==ERROR: AddressSanitizer: SEGV on unknown address 0x000ebfff800d (pc 0x0000005082ed bp 0x00720000006f sp 0x7fffe2536f60 T0) #0 0x5082ec in _PyObject_Alloc /home/test/check/PythonASAN/Objects/obmalloc.c:1258 #1 0x5082ec in ?? ??:0 #2 0x54318c in _PyObject_GC_Alloc /home/test/check/PythonASAN/Modules/gcmodule.c:1714 #3 0x54318c in ?? ??:0 #4 0x543391 in _PyObject_GC_Malloc /home/test/check/PythonASAN/Modules/gcmodule.c:1736 #5 0x543391 in _PyObject_GC_New /home/test/check/PythonASAN/Modules/gcmodule.c:1748 #6 0x543391 in ?? ??:0 #7 0x5d5516 in PyFunction_NewWithQualName /home/test/check/PythonASAN/Objects/funcobject.c:21 #8 0x5d5516 in ?? ??:0 #9 0x796ecf in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3373 #10 0x796ecf in ?? ??:0 #11 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #12 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #13 0x7a9847 in ?? ??:0 #14 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #15 0x7ab648 in ?? ??:0 #16 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #17 0x7a76f2 in ?? ??:0 #18 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #19 0x7995cc in ?? ??:0 #20 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #21 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #22 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #23 0x7ab4cb in ?? ??:0 #24 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #25 0x7a76f2 in ?? ??:0 #26 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #27 0x7995cc in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #32 0x7ab648 in ?? ??:0 #33 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #34 0x7a76f2 in ?? ??:0 #35 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #36 0x7995cc in ?? ??:0 #37 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #38 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #39 0x7a9847 in ?? ??:0 #40 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #41 0x7ab648 in ?? ??:0 #42 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #43 0x7a76f2 in ?? ??:0 #44 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #45 0x7995cc in ?? ??:0 #46 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #47 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #48 0x7a9847 in ?? ??:0 #49 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #50 0x7ab648 in ?? ??:0 #51 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #52 0x7a76f2 in ?? ??:0 #53 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #54 0x7995cc in ?? ??:0 #55 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #56 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #57 0x7a9847 in ?? ??:0 #58 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #59 0x78e15d in ?? ??:0 #60 0x5d6d7d in function_call /home/test/check/PythonASAN/Objects/funcobject.c:604 #61 0x5d6d7d in ?? ??:0 #62 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #63 0x573e9b in ?? ??:0 #64 0x92ce4e in property_descr_get /home/test/check/PythonASAN/Objects/descrobject.c:1384 #65 0x92ce4e in ?? ??:0 #66 0x63ac07 in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1060 #67 0x63ac07 in ?? ??:0 #68 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #69 0x7966cc in ?? ??:0 #70 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #71 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #72 0x7a9847 in ?? ??:0 #73 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #74 0x7ab648 in ?? ??:0 #75 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #76 0x7a76f2 in ?? ??:0 #77 0x792b47 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3291 #78 0x792b47 in ?? ??:0 #79 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #80 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #81 0x7a9847 in ?? ??:0 #82 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #83 0x7ac2ea in ?? ??:0 #84 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #85 0x574668 in ?? ??:0 #86 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #87 0x5749fa in ?? ??:0 #88 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #89 0x573e9b in ?? ??:0 #90 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #91 0x6713f8 in ?? ??:0 #92 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #93 0x666d8d in ?? ??:0 #94 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #95 0x5745f0 in ?? ??:0 #96 0x574ff3 in _PyObject_FastCallKeywords /home/test/check/PythonASAN/Objects/abstract.c:2480 #97 0x574ff3 in ?? ??:0 #98 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #99 0x7a7429 in ?? ??:0 #100 0x792b47 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3291 #101 0x792b47 in ?? ??:0 #102 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #103 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #104 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #105 0x7ab4cb in ?? ??:0 #106 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #107 0x7a76f2 in ?? ??:0 #108 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #109 0x7995cc in ?? ??:0 #110 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #111 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #112 0x7a9847 in ?? ??:0 #113 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #114 0x78e15d in ?? ??:0 #115 0x5d6d7d in function_call /home/test/check/PythonASAN/Objects/funcobject.c:604 #116 0x5d6d7d in ?? ??:0 #117 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #118 0x573e9b in ?? ??:0 #119 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #120 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #121 0x793369 in ?? ??:0 #122 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #123 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #124 0x7a9847 in ?? ??:0 #125 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #126 0x7ab648 in ?? ??:0 #127 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #128 0x7a76f2 in ?? ??:0 #129 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #130 0x7995cc in ?? ??:0 #131 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #132 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #133 0x7a9847 in ?? ??:0 #134 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #135 0x7ab648 in ?? ??:0 #136 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #137 0x7a76f2 in ?? ??:0 #138 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #139 0x7995cc in ?? ??:0 #140 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #141 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #142 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #143 0x7ab4cb in ?? ??:0 #144 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #145 0x7a76f2 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #152 0x7ac2ea in ?? ??:0 #153 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #154 0x574668 in ?? ??:0 #155 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #156 0x5749fa in ?? ??:0 #157 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #158 0x573e9b in ?? ??:0 #159 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #160 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #161 0x793369 in ?? ??:0 #162 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #163 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #164 0x7a9847 in ?? ??:0 #165 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #166 0x7ac2ea in ?? ??:0 #167 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #168 0x574668 in ?? ??:0 #169 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #170 0x5749fa in ?? ??:0 #171 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #172 0x573e9b in ?? ??:0 #173 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #174 0x66efe4 in ?? ??:0 #175 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #176 0x5745f0 in ?? ??:0 #177 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #178 0x7a7429 in ?? ??:0 #179 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #180 0x7995cc in ?? ??:0 #181 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #182 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #183 0x7a9847 in ?? ??:0 #184 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #185 0x7ac2ea in ?? ??:0 #186 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #187 0x574668 in ?? ??:0 #188 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #189 0x5749fa in ?? ??:0 #190 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #191 0x573e9b in ?? ??:0 #192 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #193 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #194 0x793369 in ?? ??:0 #195 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #196 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #197 0x7a9847 in ?? ??:0 #198 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #199 0x7ac2ea in ?? ??:0 #200 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #201 0x574668 in ?? ??:0 #202 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #203 0x5749fa in ?? ??:0 #204 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #205 0x573e9b in ?? ??:0 #206 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #207 0x66efe4 in ?? ??:0 #208 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #209 0x5745f0 in ?? ??:0 #210 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #211 0x7a7429 in ?? ??:0 #212 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #213 0x7995cc in ?? ??:0 #214 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #215 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #216 0x7a9847 in ?? ??:0 #217 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #218 0x7ac2ea in ?? ??:0 #219 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #220 0x574668 in ?? ??:0 #221 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #222 0x5749fa in ?? ??:0 #223 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #224 0x573e9b in ?? ??:0 #225 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #226 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #227 0x793369 in ?? ??:0 #228 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #229 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #230 0x7a9847 in ?? ??:0 #231 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #232 0x7ac2ea in ?? ??:0 #233 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #234 0x574668 in ?? ??:0 #235 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #236 0x5749fa in ?? ??:0 #237 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #238 0x573e9b in ?? ??:0 #239 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #240 0x66efe4 in ?? ??:0 #241 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #242 0x5745f0 in ?? ??:0 #243 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #244 0x7a7429 in ?? ??:0 #245 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #246 0x7995cc in ?? ??:0 #247 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #248 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #249 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #250 0x7ab4cb in ?? ??:0 #251 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #252 0x7a76f2 in ?? ??:0 #253 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #254 0x7995cc in ?? ??:0 #255 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #256 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #257 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #258 0x7ab4cb in ?? ??:0 #259 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #260 0x7a76f2 in ?? ??:0 #261 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #262 0x7995cc in ?? ??:0 #263 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #264 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #265 0x7a9847 in ?? ??:0 #266 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #267 0x7ac2ea in ?? ??:0 #268 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #269 0x574668 in ?? ??:0 #270 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #271 0x5749fa in ?? ??:0 #272 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #273 0x573e9b in ?? ??:0 #274 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #275 0x6713f8 in ?? ??:0 #276 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #277 0x666d8d in ?? ??:0 #278 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #279 0x5745f0 in ?? ??:0 #280 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #281 0x7a7429 in ?? ??:0 #282 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #283 0x7995cc in ?? ??:0 #284 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #285 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #286 0x7a9847 in ?? ??:0 #287 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #288 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #289 0x78e0df in ?? ??:0 #290 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #291 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #292 0x5142f5 in ?? ??:0 #293 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #294 0x512afa in ?? ??:0 #295 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #296 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #297 0x53eefd in ?? ??:0 #298 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #299 0x503d16 in ?? ??:0 #300 0x7f8e75bb582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #301 0x7f8e75bb582f in ?? ??:0 #302 0x432548 in _start ??:? #303 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x5082ec) ==18115==ABORTING ---------- components: Interpreter Core files: obmalloc_1258 messages: 287338 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000ebfff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46594/obmalloc_1258 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:24 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:24 +0000 Subject: [issue29494] AddressSanitizer: SEGV on unknown address 0x00009fff8001 In-Reply-To: <1486565504.05.0.501881320896.issue29494@psf.upfronthosting.co.za> Message-ID: <1486565784.6.0.806946580972.issue29494@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:32 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:32 +0000 Subject: [issue29492] AddressSanitizer: SEGV on unknown address 0x0000a0013639 In-Reply-To: <1486565390.59.0.464737357011.issue29492@psf.upfronthosting.co.za> Message-ID: <1486565792.57.0.979766493888.issue29492@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:40 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:40 +0000 Subject: [issue29495] AddressSanitizer: SEGV on unknown address 0x02007ea947c3 In-Reply-To: <1486565587.91.0.875598249655.issue29495@psf.upfronthosting.co.za> Message-ID: <1486565800.52.0.245461551951.issue29495@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:47 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:47 +0000 Subject: [issue29496] AddressSanitizer: SEGV on unknown address 0x01ffe96de071 In-Reply-To: <1486565630.26.0.23581787911.issue29496@psf.upfronthosting.co.za> Message-ID: <1486565807.5.0.391468658404.issue29496@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:55 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:56:55 +0000 Subject: [issue29482] AddressSanitizer: attempting double-free on 0x60b000007050 In-Reply-To: <1486564663.6.0.319136441437.issue29482@psf.upfronthosting.co.za> Message-ID: <1486565815.24.0.392117348018.issue29482@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:56 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:56:56 +0000 Subject: [issue29484] AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 In-Reply-To: <1486564902.18.0.325996539342.issue29484@psf.upfronthosting.co.za> Message-ID: <1486565816.42.0.743034026081.issue29484@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:03 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:57:03 +0000 Subject: [issue29486] AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 In-Reply-To: <1486565042.15.0.952325483441.issue29486@psf.upfronthosting.co.za> Message-ID: <1486565823.54.0.55102059558.issue29486@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:03 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:57:03 +0000 Subject: [issue29491] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565293.5.0.613764150228.issue29491@psf.upfronthosting.co.za> Message-ID: <1486565823.54.0.0121379430567.issue29491@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:08 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:57:08 +0000 Subject: [issue29490] AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f In-Reply-To: <1486565256.82.0.439128753451.issue29490@psf.upfronthosting.co.za> Message-ID: <1486565828.45.0.920193940551.issue29490@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:10 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:57:10 +0000 Subject: [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 Message-ID: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19456) exited normally] ASAN: ================================================================= ==18010==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 at pc 0x000000830a11 bp 0x7fff6131b9b0 sp 0x7fff6131b9a8 READ of size 2 at 0x61600004a982 thread T0 #0 0x830a10 in find_op /home/test/check/PythonASAN/Python/peephole.c:101 (discriminator 1) #1 0x830a10 in PyCode_Optimize /home/test/check/PythonASAN/Python/peephole.c:712 (discriminator 1) #2 0x830a10 in ?? ??:0 #3 0x7ccf6c in makecode /home/test/check/PythonASAN/Python/compile.c:5249 #4 0x7ccf6c in assemble /home/test/check/PythonASAN/Python/compile.c:5367 #5 0x7ccf6c in ?? ??:0 #6 0x7d0a09 in compiler_function /home/test/check/PythonASAN/Python/compile.c:1886 #7 0x7d0a09 in ?? ??:0 #8 0x7b0923 in compiler_body /home/test/check/PythonASAN/Python/compile.c:1463 #9 0x7b0923 in ?? ??:0 #10 0x7ae107 in compiler_mod /home/test/check/PythonASAN/Python/compile.c:1483 #11 0x7ae107 in PyAST_CompileObject /home/test/check/PythonASAN/Python/compile.c:341 #12 0x7ae107 in ?? ??:0 #13 0x5142d8 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:977 #14 0x5142d8 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #15 0x5142d8 in ?? ??:0 #16 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #17 0x512afa in ?? ??:0 #18 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #19 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #20 0x53eefd in ?? ??:0 #21 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #22 0x503d16 in ?? ??:0 #23 0x7f5554ba782f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #24 0x7f5554ba782f in ?? ??:0 #25 0x432548 in _start ??:? #26 0x432548 in ?? ??:0 0x61600004a982 is located 0 bytes to the right of 514-byte region [0x61600004a780,0x61600004a982) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x508c35 in PyMem_RawMalloc /home/test/check/PythonASAN/Objects/obmalloc.c:386 #3 0x508c35 in _PyObject_Alloc /home/test/check/PythonASAN/Objects/obmalloc.c:1427 #4 0x508c35 in ?? ??:0 SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x830a10) Shadow bytes around the buggy address: 0x0c2c800014e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c800014f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2c80001530:[02]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c80001540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c80001550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18010==ABORTING ---------- components: Interpreter Core files: peephole_101 messages: 287339 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46595/peephole_101 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:11 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:57:11 +0000 Subject: [issue29497] AddressSanitizer: SEGV on unknown address 0x000000000008 In-Reply-To: <1486565679.01.0.635065355996.issue29497@psf.upfronthosting.co.za> Message-ID: <1486565831.27.0.424169898145.issue29497@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:17 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:57:17 +0000 Subject: [issue29483] AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 In-Reply-To: <1486564829.78.0.80987262722.issue29483@psf.upfronthosting.co.za> Message-ID: <1486565837.69.0.0559693070279.issue29483@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:23 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:57:23 +0000 Subject: [issue29487] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565088.06.0.199584603629.issue29487@psf.upfronthosting.co.za> Message-ID: <1486565843.08.0.738886034694.issue29487@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:25 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:57:25 +0000 Subject: [issue29489] AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 In-Reply-To: <1486565184.6.0.709487123747.issue29489@psf.upfronthosting.co.za> Message-ID: <1486565845.37.0.328347414996.issue29489@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:46 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:57:46 +0000 Subject: [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 In-Reply-To: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> Message-ID: <1486565866.62.0.70255645541.issue29500@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:55 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:57:55 +0000 Subject: [issue29501] AddressSanitizer: SEGV on unknown address 0x0000000028cb Message-ID: <1486565874.81.0.128719869317.issue29501@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 Description: Access violation near NULL on source operand Short description: SourceAvNearNull (16/22) Hash: 887855ab5f56908afba8d62b6a25a6db.02c83d5748e9f8196679750a04737f93 Exploitability Classification: PROBABLY_NOT_EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation, which may mean the application crashed on a simple NULL dereference to data structure that has no immediate effect on control of the processor. Other tags: AccessViolation (21/22) ASAN: sEASAN:DEADLYSIGNAL ================================================================= ==18621==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000028cb (pc 0x7f1572e57d16 bp 0x7ffeaf5703d0 sp 0x7ffeaf56fb68 T0) #0 0x7f1572e57d15 in strlen /build/glibc-GKVZIf/glibc-2.23/string/../sysdeps/x86_64/strlen.S:76 #1 0x7f1572e57d15 in ?? ??:0 #2 0x44ffac in __interceptor_strlen.part.45 asan_interceptors.cc.o:? #3 0x44ffac in ?? ??:0 #4 0x7f156c4cdf5c in string_at /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5226 #5 0x7f156c4cdf5c in ?? ??:0 #6 0x7f156c2ade3f in ffi_call_unix64 ??:? #7 0x7f156c2ade3f in ?? ??:0 #8 0x7f156c2ad8aa in ffi_call ??:? #9 0x7f156c2ad8aa in ?? ??:0 #10 0x7f156c4db311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #11 0x7f156c4db311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #12 0x7f156c4db311 in ?? ??:0 #13 0x7f156c4ca199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #14 0x7f156c4ca199 in ?? ??:0 #15 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #16 0x5745f0 in ?? ??:0 #17 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #18 0x7a7429 in ?? ??:0 #19 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #20 0x7995cc in ?? ??:0 #21 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #23 0x7a9847 in ?? ??:0 #24 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #25 0x7ab648 in ?? ??:0 #26 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #27 0x7a76f2 in ?? ??:0 #28 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #29 0x7995cc in ?? ??:0 #30 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #31 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #32 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #33 0x7ab4cb in ?? ??:0 #34 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #35 0x7a76f2 in ?? ??:0 #36 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #37 0x7995cc in ?? ??:0 #38 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #39 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #40 0x7a9847 in ?? ??:0 #41 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #42 0x7ac2ea in ?? ??:0 #43 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #44 0x574668 in ?? ??:0 #45 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #46 0x5749fa in ?? ??:0 #47 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #48 0x573e9b in ?? ??:0 #49 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #50 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #51 0x793369 in ?? ??:0 #52 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #53 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #54 0x7a9847 in ?? ??:0 #55 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #56 0x7ac2ea in ?? ??:0 #57 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #58 0x574668 in ?? ??:0 #59 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #60 0x5749fa in ?? ??:0 #61 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #62 0x573e9b in ?? ??:0 #63 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #64 0x66efe4 in ?? ??:0 #65 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #66 0x5745f0 in ?? ??:0 #67 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #68 0x7a7429 in ?? ??:0 #69 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #70 0x7995cc in ?? ??:0 #71 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #72 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #73 0x7a9847 in ?? ??:0 #74 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #75 0x7ac2ea in ?? ??:0 #76 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #77 0x574668 in ?? ??:0 #78 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #79 0x5749fa in ?? ??:0 #80 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #81 0x573e9b in ?? ??:0 #82 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #83 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #84 0x793369 in ?? ??:0 #85 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #86 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #87 0x7a9847 in ?? ??:0 #88 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #89 0x7ac2ea in ?? ??:0 #90 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #91 0x574668 in ?? ??:0 #92 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #93 0x5749fa in ?? ??:0 #94 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #95 0x573e9b in ?? ??:0 #96 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #97 0x66efe4 in ?? ??:0 #98 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #99 0x5745f0 in ?? ??:0 #100 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #101 0x7a7429 in ?? ??:0 #102 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #103 0x7995cc in ?? ??:0 #104 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #105 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #106 0x7a9847 in ?? ??:0 #107 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #108 0x7ac2ea in ?? ??:0 #109 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #110 0x574668 in ?? ??:0 #111 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #112 0x5749fa in ?? ??:0 #113 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #114 0x573e9b in ?? ??:0 #115 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #116 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #117 0x793369 in ?? ??:0 #118 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #119 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #120 0x7a9847 in ?? ??:0 #121 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #122 0x7ac2ea in ?? ??:0 #123 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #124 0x574668 in ?? ??:0 #125 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #126 0x5749fa in ?? ??:0 #127 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #128 0x573e9b in ?? ??:0 #129 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #130 0x66efe4 in ?? ??:0 #131 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #132 0x5745f0 in ?? ??:0 #133 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #134 0x7a7429 in ?? ??:0 #135 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #136 0x7995cc in ?? ??:0 #137 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #138 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #139 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #140 0x7ab4cb in ?? ??:0 #141 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #142 0x7a76f2 in ?? ??:0 #143 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #144 0x7995cc in ?? ??:0 #145 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #146 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #147 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #148 0x7ab4cb in ?? ??:0 #149 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #150 0x7a76f2 in ?? ??:0 #151 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #152 0x7995cc in ?? ??:0 #153 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #154 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #155 0x7a9847 in ?? ??:0 #156 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #157 0x7ac2ea in ?? ??:0 #158 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #159 0x574668 in ?? ??:0 #160 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #161 0x5749fa in ?? ??:0 #162 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #163 0x573e9b in ?? ??:0 #164 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #165 0x6713f8 in ?? ??:0 #166 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #167 0x666d8d in ?? ??:0 #168 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #169 0x5745f0 in ?? ??:0 #170 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #171 0x7a7429 in ?? ??:0 #172 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #173 0x7995cc in ?? ??:0 #174 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #175 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #176 0x7a9847 in ?? ??:0 #177 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #178 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #179 0x78e0df in ?? ??:0 #180 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #181 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #182 0x5142f5 in ?? ??:0 #183 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #184 0x512afa in ?? ??:0 #185 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #186 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #187 0x53eefd in ?? ??:0 #188 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #189 0x503d16 in ?? ??:0 #190 0x7f1572ded82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #191 0x7f1572ded82f in ?? ??:0 #192 0x432548 in _start ??:? #193 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x8ad15) ==18621==ABORTING ---------- components: Interpreter Core files: strlen_76 messages: 287340 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0000000028cb type: security versions: Python 3.6 Added file: http://bugs.python.org/file46596/strlen_76 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:58:03 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:58:03 +0000 Subject: [issue29499] AddressSanitizer: SEGV on unknown address 0x000ebfff800d In-Reply-To: <1486565778.73.0.558630262267.issue29499@psf.upfronthosting.co.za> Message-ID: <1486565883.69.0.0166537785786.issue29499@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:58:04 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:58:04 +0000 Subject: [issue29487] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 In-Reply-To: <1486565088.06.0.199584603629.issue29487@psf.upfronthosting.co.za> Message-ID: <1486565884.84.0.161932236464.issue29487@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:58:10 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:58:10 +0000 Subject: [issue29498] AddressSanitizer: SEGV on unknown address 0x0005ffff800d In-Reply-To: <1486565722.07.0.443557463109.issue29498@psf.upfronthosting.co.za> Message-ID: <1486565890.71.0.790187027463.issue29498@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:58:38 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Feb 2017 14:58:38 +0000 Subject: [issue29501] AddressSanitizer: SEGV on unknown address 0x0000000028cb In-Reply-To: <1486565874.81.0.128719869317.issue29501@psf.upfronthosting.co.za> Message-ID: <1486565918.55.0.818454472897.issue29501@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules -Interpreter Core priority: normal -> low type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:58:42 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:58:42 +0000 Subject: [issue29497] AddressSanitizer: SEGV on unknown address 0x000000000008 In-Reply-To: <1486565679.01.0.635065355996.issue29497@psf.upfronthosting.co.za> Message-ID: <1486565922.72.0.135119986765.issue29497@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:02 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:02 +0000 Subject: [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 In-Reply-To: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> Message-ID: <1486565942.64.0.788018656225.issue29500@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:07 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:07 +0000 Subject: [issue29486] AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 In-Reply-To: <1486565042.15.0.952325483441.issue29486@psf.upfronthosting.co.za> Message-ID: <1486565947.25.0.226611812374.issue29486@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:12 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:12 +0000 Subject: [issue29482] AddressSanitizer: attempting double-free on 0x60b000007050 In-Reply-To: <1486564663.6.0.319136441437.issue29482@psf.upfronthosting.co.za> Message-ID: <1486565952.09.0.608040100394.issue29482@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:17 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:17 +0000 Subject: [issue29496] AddressSanitizer: SEGV on unknown address 0x01ffe96de071 In-Reply-To: <1486565630.26.0.23581787911.issue29496@psf.upfronthosting.co.za> Message-ID: <1486565957.38.0.856078930112.issue29496@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:21 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 14:59:21 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486565961.63.0.664914673837.issue29474@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for reviewing, Marco :) Updated the patch. ---------- Added file: http://bugs.python.org/file46597/issue29474py3-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:24 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:24 +0000 Subject: [issue29495] AddressSanitizer: SEGV on unknown address 0x02007ea947c3 In-Reply-To: <1486565587.91.0.875598249655.issue29495@psf.upfronthosting.co.za> Message-ID: <1486565964.44.0.0583775658654.issue29495@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:30 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:30 +0000 Subject: [issue29492] AddressSanitizer: SEGV on unknown address 0x0000a0013639 In-Reply-To: <1486565390.59.0.464737357011.issue29492@psf.upfronthosting.co.za> Message-ID: <1486565970.88.0.138474082986.issue29492@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:42 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:42 +0000 Subject: [issue29494] AddressSanitizer: SEGV on unknown address 0x00009fff8001 In-Reply-To: <1486565504.05.0.501881320896.issue29494@psf.upfronthosting.co.za> Message-ID: <1486565982.89.0.750831808157.issue29494@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:59:56 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 14:59:56 +0000 Subject: [issue29499] AddressSanitizer: SEGV on unknown address 0x000ebfff800d In-Reply-To: <1486565778.73.0.558630262267.issue29499@psf.upfronthosting.co.za> Message-ID: <1486565996.93.0.203350783149.issue29499@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:00:01 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:00:01 +0000 Subject: [issue29493] AddressSanitizer: SEGV on unknown address 0x000cffff800d In-Reply-To: <1486565445.54.0.388710643733.issue29493@psf.upfronthosting.co.za> Message-ID: <1486566001.2.0.0905526542077.issue29493@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:00:06 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:00:06 +0000 Subject: [issue29488] AddressSanitizer: SEGV on unknown address 0x0001a5525c1b In-Reply-To: <1486565137.31.0.431748723797.issue29488@psf.upfronthosting.co.za> Message-ID: <1486566006.42.0.77376763334.issue29488@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:00:22 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:00:22 +0000 Subject: [issue29498] AddressSanitizer: SEGV on unknown address 0x0005ffff800d In-Reply-To: <1486565722.07.0.443557463109.issue29498@psf.upfronthosting.co.za> Message-ID: <1486566022.06.0.645624448612.issue29498@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:00:34 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:00:34 +0000 Subject: [issue29501] AddressSanitizer: SEGV on unknown address 0x0000000028cb In-Reply-To: <1486565874.81.0.128719869317.issue29501@psf.upfronthosting.co.za> Message-ID: <1486566034.65.0.403034994046.issue29501@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:17:29 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 08 Feb 2017 15:17:29 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486567049.37.0.787497787585.issue29474@psf.upfronthosting.co.za> Marco Buttu added the comment: Thanks Mariatta, now it is OK to me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:39:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 15:39:38 +0000 Subject: [issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro? Message-ID: <1486568378.9.0.904847418882.issue29502@psf.upfronthosting.co.za> New submission from STINNER Victor: call_function() and do_call_core() functions of Python/ceval.c use C_TRACE() macro to call the profiler, but PyObject_Call() and similar functions like _PyObject_FastCallKeywords() don't. Is it a bug or a deliberate choice for performance? Since PyObject_Call() and similar functions have now fast paths, I don't think that it's still needed to have these fast paths in ceval.c too. But I kept fast paths in ceval.c because of C_TRACE(). ---------- components: Interpreter Core messages: 287343 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro? type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:41:51 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:41:51 +0000 Subject: [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 In-Reply-To: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> Message-ID: <1486568511.06.0.312932663761.issue29500@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:42:32 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 08 Feb 2017 15:42:32 +0000 Subject: [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 In-Reply-To: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> Message-ID: <1486568552.49.0.905838459418.issue29500@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:53:16 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 15:53:16 +0000 Subject: [issue29503] Make embedded-Python detectable Message-ID: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> New submission from Andi Bergmeier: While it is nice to have embeddable Python for Windows, currently there seems to be no way of distinguishing it from a "normal" Python, which reacts quite differently to its Environment. Would like to support Embeddable Python (and ._pth), but really first need a way of identifying whether it is embeddable or not. ---------- components: Windows messages: 287344 nosy: Andi Bergmeier, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make embedded-Python detectable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:03:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 16:03:26 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486569806.16.0.103540022494.issue29476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For the worst case the drawback is significant: $ ./python -m perf timeit -s "s = set('a%s' % i for i in range(100))" -- "s.add('test'); s.discard('test')" Unpatched: Median +- std dev: 861 ns +- 82 ns Patched: Median +- std dev: 2.81 us +- 0.18 us How large the benefit in the best case? I can't get any significant difference. $ ./python -m perf timeit -s "a = ['a%s' % i for i in range(1000)]" -- "set(a)" Unpatched: Median +- std dev: 130 us +- 6 us Patched: Median +- std dev: 127 us +- 8 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:04:57 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Feb 2017 16:04:57 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486569897.52.0.814613380302.issue29476@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, can you post your recurse() code with some sample data so that we can run some timings and get a sense of the effect on the extreme case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:07:23 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Feb 2017 16:07:23 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486570043.7.0.976370736653.issue29503@psf.upfronthosting.co.za> R. David Murray added the comment: Why should a library behave differently if the python using it is embedded in an application? Can you explain your use case in more detail? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:08:24 2017 From: report at bugs.python.org (Paul Moore) Date: Wed, 08 Feb 2017 16:08:24 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486570104.7.0.323328142493.issue29503@psf.upfronthosting.co.za> Paul Moore added the comment: The embedded distribution is meant to be for just that - embedded applications. I'm not quite sure what you mean by support it, or when you would write code that needed to know it was being run from an embedded application. Can you clarify precisely why you need to be able to get at this information? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:17:19 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 16:17:19 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486570639.93.0.359843891905.issue29503@psf.upfronthosting.co.za> Andi Bergmeier added the comment: I would like to ship Python hermetically with Bazel (embedding it). For that the Python embedded seems perfect. A problem arises since currently Bazel is controlling the search path of Python via setting PYTHONPATH (which actually worked with Python 3.5.2-embedded for non prefixed paths). Now I do not know whether there is any other way of modifying sys.path when calling python.exe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:19:12 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 16:19:12 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486570752.91.0.22560263586.issue29503@psf.upfronthosting.co.za> Andi Bergmeier added the comment: As a result either a, have a way to modify sys.path and add support for embeddable b, have no way to modify sys.path and fail very soon should someone try to use Bazel with a Python embeddable. Either way the minimum is to have a way to detect which variant it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:20:39 2017 From: report at bugs.python.org (Paul Moore) Date: Wed, 08 Feb 2017 16:20:39 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486570839.4.0.888610522606.issue29503@psf.upfronthosting.co.za> Paul Moore added the comment: With the embedded distribution, you should probably be calling the Python API rather than running python.exe. And if you do it that way, you can set sys.path via the API before calling user code. Alternatively, you can set up a site.py within your copy of the embedded distribution to configure the PATH you want. Or you can just modify the _pth file that's in the embedded distribution. That's pretty much what it's for... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 11:27:59 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 16:27:59 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486571279.47.0.329713249773.issue29503@psf.upfronthosting.co.za> Andi Bergmeier added the comment: Using the Python API would of course be the preferred way to go. Sadly that also means that you at minimum have a full compiler and that IMO seems overkill when you only want to build a Python package or a Python test (from the end-user point of view). The ._pth would be perfect if I could place it alongside the .py script I want to execute. BTW: Can you please remove PYTHONPATH from the help message and so forth for the embeddable variant. Can be misleading. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:01:31 2017 From: report at bugs.python.org (Paul Moore) Date: Wed, 08 Feb 2017 17:01:31 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486573291.76.0.81002440069.issue29503@psf.upfronthosting.co.za> Paul Moore added the comment: I'm still not clear what you're doing here - why does it matter where you have the _pth file? Could you explain how your application directory is laid out, and what is the main executable for the application? I'm assuming it's a Windows executable, myapp.exe, but the fact that you seem to be implying taht you don't have a C compiler makes me wonder if that's the case. You could also explain (in the light of the above details) precisely what directories you want to add to sys.path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:08:45 2017 From: report at bugs.python.org (Riccardo Polignieri) Date: Wed, 08 Feb 2017 17:08:45 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486573725.19.0.423823956619.issue28686@psf.upfronthosting.co.za> Riccardo Polignieri added the comment: Paul: > When inside a venv: - If you want to execute a script, use a shebang of #!/usr/bin/env python and then use `py myscript.py` Yes, I'm totally on board with this - that is, as far as I run my own scripts. I just wonder, what if one day I pip install someone else's work, and then bang!, 'py' is just working differently now, for a non-local reason, and without alerting me. It's true that all major libraries use the "right" kind of shebang these days... Still, I find it a bit disturbing nevertheless. But thanks for the clarifications, anyways - now 'py' expected behavior is much more clear to me. Eryk: > it's far simpler to just support versioned executable names Keeping my fingers crossed about this. > Even if we don't install links/copies with these names, I don't see the harm in allowing the launcher to look for them. Users can create the links manually True, but It would allow for yet another possible source of confusion I'm afraid. No, if py were to look for versioned executables, then versioned executable should be supplied imo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:20:57 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 17:20:57 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486574457.26.0.848193836649.issue29503@psf.upfronthosting.co.za> Andi Bergmeier added the comment: Gladly. So imagine you have the following files: - foobar - pyfoo - foo.py - src - test - bar.py Since Bazel is a build system, you declare (in directory foobar): py_library( name = "foo", # abstract name imports = ".", srcs = ["pyfoo/foo.py"], # Which source files are in that library ) py_test( name = "bartest", srcs = ["pyfoo/src/test/bar.py"], # The test script deps = ["foo"], # "Will import foo" -> import of foo's parent directory is added when executing test ) Bazel does not ship with a specific Python version. So you (the user) start Bazel and provide it with a path to a Python on your system. This means that the Python version MAY be different on every execution of Bazel. Then you can use Bazel to execute the bartest. Bazel will create a temporary directory (as a bit of sandboxing) and copy all declared files (+ directories) into it. Bazel will execute the provided Python binary and try set PYTHONPATH so that a import foo does work (notice the imports declaration above). This is the part where I think a ._pth alongside the script would be beneficial, because for every test invocation the paths will be different. And multiple tests may be executed in parallel (so a "global" ._pth does not cut it). Using a ._pth one could get around setting an environment variable. Now to simplify deployment I want to put an embeddable Python alongside Bazel and always tell it to use this one. With Embeddable, the only way I have to modify sys.path is to execute Python with -c or write an intermediate script. Both can then modify sys.path and then load bar.py. Obviously this is not as nice as having a direct command-line switch or ._pth mechanism available. I hope I explained enough. If not - don't hesitate to ask. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:29:23 2017 From: report at bugs.python.org (Mike Gilbert) Date: Wed, 08 Feb 2017 17:29:23 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 Message-ID: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> New submission from Mike Gilbert: When compiling python-3.6.0 with -march=bdver2, the blake2 module fails to build. In file included from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-round.h:70:0, from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:40, from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/blake2s_impl.c:32: /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:29:4: error: expected identifier or '(' before 'return' return _mm_blendv_epi8(t0, s1, mask); ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:30:1: error: expected identifier or '(' before '}' token }*/ ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:30:3: error: expected identifier or '(' before '/' token }*/ ^ In file included from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/blake2s_impl.c:32:0: /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c: In function 'blake2s_init0': /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:167:38: error: 'blake2s_IV' undeclared (first use in this function) for( i = 0; i < 8; ++i ) S->h[i] = blake2s_IV[i]; ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:167:38: note: each undeclared identifier is reported only once for each function it appears in /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c: In function 'PyBlake2_blake2s_init_param': /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:176:44: error: 'blake2s_IV' undeclared (first use in this function) const uint8_t * v = ( const uint8_t * )( blake2s_IV ); ^ ---------- components: Extension Modules files: build.log messages: 287356 nosy: floppymaster priority: normal severity: normal status: open title: blake2: compile error with -march=bdver2 versions: Python 3.6 Added file: http://bugs.python.org/file46598/build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:30:00 2017 From: report at bugs.python.org (Mike Gilbert) Date: Wed, 08 Feb 2017 17:30:00 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 In-Reply-To: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> Message-ID: <1486575000.93.0.12308446766.issue29504@psf.upfronthosting.co.za> Mike Gilbert added the comment: Downstream bug report: https://bugs.gentoo.org/show_bug.cgi?id=608586 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:33:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 17:33:47 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486575227.53.0.288648040887.issue29465@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- pull_requests: +25 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:35:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 17:35:47 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486575347.45.0.630308704176.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: I splitted my big patch into smaller changes, see my pull request: https://github.com/python/cpython/pull/74 If you prefer Rietveld ([Review] button), I also attached the squashed change: pyobject_fastcall-5.patch. ---------- Added file: http://bugs.python.org/file46599/pyobject_fastcall-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:36:08 2017 From: report at bugs.python.org (Paul Moore) Date: Wed, 08 Feb 2017 17:36:08 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486575368.48.0.939064410909.issue29503@psf.upfronthosting.co.za> Paul Moore added the comment: OK, well I certainly wouldn't bother supporting users trying to provide the path to an embedded distribution of Python. That's not what the distribution is for, and as the author of Bazel you'd be perfectly OK (IMO) to say you don't support that. If you want to supply an embedded distribution with Bazel, and deploy it with the application, that's fine - in that case you can modify the _pth file when you copy the distribution to deploy it. If you want to share the embeddable distribution that is installed with Bazel among multiple user scripts that get deployed, then I'd suggest deploying a wrapper script with the user's code. That wrapper could set sys.path then run the user's script (using the stdlib runpy module, maybe). You mention that option, but say it's "not as nice as having a direct command-line switch" - but while that may be true (I disagree, but it's a matter of opinion) surely the fact that there *is* no such command line switch makes that consideration irrelevant? Also, I'm not sure how your original question (how you can distinguish an embeddable distribution from a normal one) would help here anyway. FWIW, if you really had to, you could do that by looking to see if there was a _pth file in os.listdir(sys.prefix)). That would be a plausible heuristic, but certainly not something I'd recommend as a robust solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:38:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 17:38:08 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486575488.49.0.865727203419.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Crap, pyobject_fastcall-5.patch was not rebased correctly :-/ Please see pyobject_fastcall-6.patch instead. ---------- Added file: http://bugs.python.org/file46600/pyobject_fastcall-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:57:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Feb 2017 17:57:26 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486576646.18.0.053550140202.issue29476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't have good real-world example. Actually dict is used more often than set in such cases. I agree with your arguments Raymond, in particular about your ranging of cases. But even if the bad case is hundreds times more rare than the good case, the total effect can be negative if the negative effect of the bad case is hundreds times larger that the positive effect of the good case. I checked timing just to be sure and was unpleasantly surprised that the negative effect is so large. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 14:55:25 2017 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 08 Feb 2017 19:55:25 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486583725.77.0.950171738659.issue22594@psf.upfronthosting.co.za> Matthew Barnett added the comment: Ah, well, if it hasn't changed after this many years, it never will. Expect one or two changes to the text. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 15:54:21 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Feb 2017 20:54:21 +0000 Subject: [issue29505] Submit the re, json, & csv modules to oss-fuzz testing Message-ID: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za> New submission from Gregory P. Smith: For reference, read https://github.com/google/oss-fuzz. We should investigate creating fuzz targets for the Python re module (_sre.c) at a minimum. There are probably other good targets as well such as _json.c and _csv.c. pickle and marshal are not intended to be secure so ignore those. ---------- messages: 287363 nosy: gregory.p.smith priority: normal severity: normal stage: test needed status: open title: Submit the re, json, & csv modules to oss-fuzz testing type: security versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 16:06:22 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 21:06:22 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486587982.07.0.661756668929.issue29476@psf.upfronthosting.co.za> INADA Naoki added the comment: I think it violates O(1). "s.add(x); s.discard(x);" loop creates dummy chain. Average chain length is determined by size of the set. So it is O(len(s)) rather than amortized O(1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 16:36:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 21:36:34 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486589794.83.0.627287858984.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: This patch affects firstlineno and lnotab of module and class, but not functions. module: - at 0x7f053a8f8b70, file "Lib/importlib/_bootstrap.py", line 8> + at 0x7fdefbf10340, file "Lib/importlib/_bootstrap.py", line 25> filename Lib/importlib/_bootstrap.py -firstlineno: 8 +firstlineno: 25 -lnotab: b'\x04\x11\x04\x02\x08\x08\x08\x07\x04\x02\x04\x03\x10\x04\x0eD\x0e\x15\x0e\x13\x08\x13\x08\x13\x08\x0b\x0e\x08\x08\x0b\x08\x0c\x08\x10\x08$\x0e\x1b\x0ee\x10\x1a\x06\x03\n-\x0e<\x08\x11\x08\x11\x08\x19\x08\x1d\x08\x17\x08\x10\x0eI\x0eM\x0e\r\x08\t\x08\t\n/\x08\x14\x04\x01\x08\x02\x08\x1b\x08\x06\n\x19\x08\x1f\x08\x1b\x12#\x08\x07\x08/' - 8 0 LOAD_CONST 0 ('Core implementation of import.\n\nThis module is NOT meant to be directly imported! It has been designed such\nthat it can be bootstrapped into Python as the implementation of import. As\nsuch it requires the injection of specific modules and attributes in order to\nwork. One should use importlib as the public-facing version of this module.\n\n') +lnotab: b'\x04\x00\x04\x02\x08\x08\x08\x07\x04\x02\x04\x03\x10\x04\x0eD\x0e\x15\x0e\x13\x08\x13\x08\x13\x08\x0b\x0e\x08\x08\x0b\x08\x0c\x08\x10\x08$\x0e\x1b\x0ee\x10\x1a\x06\x03\n-\x0e<\x08\x11\x08\x11\x08\x19\x08\x1d\x08\x17\x08\x10\x0eI\x0eM\x0e\r\x08\t\x08\t\n/\x08\x14\x04\x01\x08\x02\x08\x1b\x08\x06\n\x19\x08\x1f\x08\x1b\x12#\x08\x07\x08/' + 25 0 LOAD_CONST 0 ('Core implementation of import.\n\nThis module is NOT meant to be directly imported! It has been designed such\nthat it can be bootstrapped into Python as the implementation of import. As\nsuch it requires the injection of specific modules and attributes in order to\nwork. One should use importlib as the public-facing version of this module.\n\n') 2 STORE_NAME 0 (__doc__) - - 25 4 LOAD_CONST 1 (None) + 4 LOAD_CONST 1 (None) 6 STORE_GLOBAL 1 (_bootstrap_external) class: - + filename Lib/importlib/_bootstrap.py firstlineno: 51 -lnotab: b'\x08\x04\x04\x02\x08\x08\x08\x0c\x08\x19\x08\r' +lnotab: b'\x0c\x06\x08\x08\x08\x0c\x08\x19\x08\r' 51 0 LOAD_NAME 0 (__name__) 2 STORE_NAME 1 (__module__) 4 LOAD_CONST 0 ('_ModuleLock') 6 STORE_NAME 2 (__qualname__) - - 55 8 LOAD_CONST 1 ('A recursive lock implementation which is able to detect deadlocks\n (e.g. thread 1 trying to take locks A then B, and thread 2 trying to\n take locks B then A).\n ') + 8 LOAD_CONST 1 ('A recursive lock implementation which is able to detect deadlocks\n (e.g. thread 1 trying to take locks A then B, and thread 2 trying to\n take locks B then A).\n ') 10 STORE_NAME 3 (__doc__) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 16:56:37 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 08 Feb 2017 21:56:37 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486590997.5.0.115897733605.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: So what's new entry may be: +* ``Module``, ``FunctionDef``, ``AsyncFunctionDef``, and + ``ClassDef`` AST nodes now have a new ``docstring`` attribute. + The first statement in their body is not considered as a docstring anymore. + This affects ``co_firstlineno`` and ``co_lnotab`` attribute of code object + for module and class. + (Contributed by Eugene Toder and INADA Naoki in :issue:`29463`.) + ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 17:02:44 2017 From: report at bugs.python.org (Pedro) Date: Wed, 08 Feb 2017 22:02:44 +0000 Subject: [issue29506] Incorrect documentation for the copy module Message-ID: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> New submission from Pedro: The docs for the copy module contain a bullet that says the following: "Because deep copy copies everything it may copy too much, e.g., even administrative data structures that should be shared even between copies." There should be a "not" between "should" and "be shared." I think the second "even" can be dropped, too. ---------- assignee: docs at python components: Documentation messages: 287367 nosy: docs at python, pgacv2 priority: normal severity: normal status: open title: Incorrect documentation for the copy module versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 17:07:35 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 22:07:35 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486591655.12.0.21809046727.issue29506@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: -> needs patch versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 17:14:56 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 08 Feb 2017 22:14:56 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486592096.43.0.950699124495.issue29506@psf.upfronthosting.co.za> Zachary Ware added the comment: That line is correct, the point is that deep copy will duplicate even the things that you may *want* to be shared. See also #27416. I'm not sure what we can do to further clarify that line, but it is certainly easy to misread. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 17:21:32 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 08 Feb 2017 22:21:32 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486592492.53.0.635594338807.issue29506@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: How about ``` Because deep copy copies everything, it may copy too much, including the administrative data structures. ``` ? ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 18:30:20 2017 From: report at bugs.python.org (Piotr Dobrogost) Date: Wed, 08 Feb 2017 23:30:20 +0000 Subject: [issue26388] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True) In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za> Message-ID: <1486596620.45.0.283972127108.issue26388@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 18:44:33 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 08 Feb 2017 23:44:33 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1486597473.16.0.340469305487.issue28686@psf.upfronthosting.co.za> Eryk Sun added the comment: If the system doesn't have a "python3.exe" on PATH, then "env python3" will run a registered version, exactly like it currently does. IMO, this is slightly less confusing than the current behavior, which skips searching PATH in this case. We can take it a step further, however. If the launcher can't find the versioned name, then search for "python[w].exe" and determine its version using the approach I outlined above. If it doesn't match the required version, as always the launcher will default to running a registered version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 19:17:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 00:17:38 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple Message-ID: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> New submission from STINNER Victor: Subset of the (almost) rejected issue #29259 (tp_fastcall), attached patch adds _PyMethod_FastCall() and uses it in call_method() of typeobject.c. The change avoids the creation of a temporary tuple for Python functions and METH_FASTCALL C functions. Currently, call_method() calls method_call() which calls _PyObject_Call_Prepend(), and calling method_call() requires a tuple for positional arguments. Example of benchmark on __getitem__(): 1.3x faster (-22%). $ ./python -m perf timeit -s 'class C:' -s ' def __getitem__(self, index): return index' -s 'c=C()' 'c[0]' Median +- std dev: 130 ns +- 1 ns => 102 ns +- 1 ns See also the issue #29263 "Implement LOAD_METHOD/CALL_METHOD for C functions". ---------- components: Interpreter Core files: method_fastcall.patch keywords: patch messages: 287371 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Use FASTCALL in call_method() to avoid temporary tuple type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46601/method_fastcall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 19:19:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 00:19:54 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486599594.62.0.016320305361.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: Maybe PyObject_Call(), _PyObject_FastCallDict(), etc. can also be modified to get the following fast-path: + if (Py_TYPE(func) == &PyMethod_Type) { + result = _PyMethod_FastCall(func, args, nargs); + } But I don't know how common it is to get a PyMethod_Type object in these functions, nor the code of the additional if. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 20:03:06 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 01:03:06 +0000 Subject: [issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects In-Reply-To: <1484310274.99.0.832491900546.issue29259@psf.upfronthosting.co.za> Message-ID: <20170209010301.16582.98716.FAB352CB@psf.io> Roundup Robot added the comment: New changeset 31342913fb1e by Victor Stinner in branch 'default': Fix PyCFunction_Call() performance issue https://hg.python.org/cpython/rev/31342913fb1e ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 20:03:06 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 01:03:06 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <20170209010302.16582.57925.913931B5@psf.io> Roundup Robot added the comment: New changeset 31342913fb1e by Victor Stinner in branch 'default': Fix PyCFunction_Call() performance issue https://hg.python.org/cpython/rev/31342913fb1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 20:16:40 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 09 Feb 2017 01:16:40 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486603000.43.0.230100414432.issue29506@psf.upfronthosting.co.za> Steven D'Aprano added the comment: What about "administrative data structures" that should be copied? I think that "administrative data structures" is a red herring: there could be data that needs copying, and data that needs sharing and shouldn't be copied, independent of what the data is used for. "Because deepcopy copies everything it may copy too much, such as data which is intended to be shared between copies." ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 21:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 02:00:22 +0000 Subject: [issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects In-Reply-To: <1484310274.99.0.832491900546.issue29259@psf.upfronthosting.co.za> Message-ID: <1486605622.65.0.583022707441.issue29259@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset e9807e307f1f561a2dfe3e9f97a38444528dba86 by Victor Stinner in branch 'master': Fix PyCFunction_Call() performance issue https://github.com/python/cpython/commit/e9807e307f1f561a2dfe3e9f97a38444528dba86 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 21:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 02:00:23 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1486605623.22.0.105581461225.issue29465@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset e9807e307f1f561a2dfe3e9f97a38444528dba86 by Victor Stinner in branch 'master': Fix PyCFunction_Call() performance issue https://github.com/python/cpython/commit/e9807e307f1f561a2dfe3e9f97a38444528dba86 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 21:39:17 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 02:39:17 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486607957.01.0.150663353145.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: Now I doubt about this patch is really good. docstring of Module and Class generates two bytecode. So it's a real, executed statement. LOAD_CONST 0 ("docstring") STORE_NAME 0 ("__doc__") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 21:52:35 2017 From: report at bugs.python.org (Ma Lin) Date: Thu, 09 Feb 2017 02:52:35 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1486608755.77.0.2943793605.issue22594@psf.upfronthosting.co.za> Ma Lin added the comment: How about this? Is it too long? @Matthew Barnett, I'm animalize on your repository. .. seealso:: Third-party module `regex `_, is a substitute for re module, it offers some mainstream features which re module lacks (Atomic grouping, Possessive quantifiers, Variable-length lookbehind, Recursive matching). It also has further Unicode support, some advanced grammars appears in other regular expression engines, and many facilitations. ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 22:19:40 2017 From: report at bugs.python.org (Super Bo) Date: Thu, 09 Feb 2017 03:19:40 +0000 Subject: [issue23402] dynload_shlib does not close ldl handles when the interpreter is shut down In-Reply-To: <1423246900.58.0.18702391948.issue23402@psf.upfronthosting.co.za> Message-ID: <1486610380.35.0.215638514864.issue23402@psf.upfronthosting.co.za> Super Bo added the comment: I think dynload_unload_all() should be called in PyImport_Cleanup() function. ---------- nosy: +Super Bo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 22:22:05 2017 From: report at bugs.python.org (Michael Rieck) Date: Thu, 09 Feb 2017 03:22:05 +0000 Subject: [issue29508] Cannot install python-3.2.5 on Mac 10.11.6 Message-ID: <1486610525.23.0.51102827646.issue29508@psf.upfronthosting.co.za> New submission from Michael Rieck: python-3.2.5-macosx10.6.dmg starts installation on my Mac 10.11.6 but terminates at end with following message: The Installation Failed. The installer could not install the software because there was no software to install. I cold booted my computer, tried again, and got the same results. ---------- components: Installation messages: 287381 nosy: rieck priority: normal severity: normal status: open title: Cannot install python-3.2.5 on Mac 10.11.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 23:51:21 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 04:51:21 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486615881.18.0.799106397296.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Marco: > To have a wide view, usually it is a good idea to start from the beginning: > > https://groups.google.com/forum/#!msg/comp.lang.python/DfzH5Nrt05E/Yyd3s7fPVxwJ Thank you, that is a very interesting thread. Clearly the creator of doctests, Tim Peters, is a well-regarded person in the Python world. On the other hand, I was surprised to see some of the examples used in the present-day documentation in Tim's original 1999 message. I find it remarkable that in 18 years since then, no rewrite or editing has replaced those examples with better ones. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 01:08:34 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Feb 2017 06:08:34 +0000 Subject: [issue29508] Cannot install python-3.2.5 on Mac 10.11.6 In-Reply-To: <1486610525.23.0.51102827646.issue29508@psf.upfronthosting.co.za> Message-ID: <1486620514.24.0.277590773621.issue29508@psf.upfronthosting.co.za> Zachary Ware added the comment: Python 3.2 is out of support, so unfortunately there's nothing we can do to help here. I would recommend using Python 3.6 as it is the latest version, but if you absolutely need 3.2 for some reason your best bet is probably to build it yourself. It is a fairly straightforward procedure, and a guide to get started can be found in the CPython devguide. ---------- nosy: +zach.ware resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 01:33:18 2017 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Feb 2017 06:33:18 +0000 Subject: [issue29508] Cannot install python-3.2.5 on Mac 10.11.6 In-Reply-To: <1486610525.23.0.51102827646.issue29508@psf.upfronthosting.co.za> Message-ID: <1486621998.43.0.168275150992.issue29508@psf.upfronthosting.co.za> Ned Deily added the comment: The python.org macOS installers provided on .dmg files for older releases used a legacy installer package format that is no longer supported by the OS X Installer app on the most recent maxOS releases. The newer .pkg format installer files should be OK. As Zach notes, 3.2.5 in very out-of-date and its use should be avoided now. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 02:40:51 2017 From: report at bugs.python.org (Zsolt Endreffy) Date: Thu, 09 Feb 2017 07:40:51 +0000 Subject: [issue26873] xmlrpclib raises when trying to convert an int to string when unicode is available In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za> Message-ID: <1486626051.04.0.287717931028.issue26873@psf.upfronthosting.co.za> Zsolt Endreffy added the comment: I think this patch breaks compatibility between python 2.7 versions. Our rpc server has 2.7.10 Python version, and sends back tuples as responses (first value is a boolean, second is a string). If we connect with a computer, which has 2.7.11 or earlier Python, then it is working flawlessly. When we connect with Python 2.7.12 or later, then it sends this error: ResponseError: ResponseError("unknown tag u'tuple'",) As far as I understand, the xmlrpclib should be able to marshal through tuples. ---------- nosy: +Zsolt Endreffy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 02:48:43 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 07:48:43 +0000 Subject: [issue29509] redundant interning in PyObject_GetAttrString Message-ID: <1486626523.7.0.635584720165.issue29509@psf.upfronthosting.co.za> New submission from INADA Naoki: PyObject_GetAttrString creates temporary unicode object and intern it. It totally redundant. ---------- files: getattrstring-nointern.patch keywords: patch messages: 287386 nosy: inada.naoki priority: normal severity: normal stage: patch review status: open title: redundant interning in PyObject_GetAttrString type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46602/getattrstring-nointern.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:08:09 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 08:08:09 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486627689.83.0.840872451138.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: Maybe, we can skip Method object entirely using _PyObject_GetMethod(). Currently it is used only in LOAD_METHOD. But PyObject_CallMethod(), _PyObject_CallMethodId(), PyObject_CallMethodObjArgs(), _PyObject_CallMethodIdObjArgs() can use it too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:24:53 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 08:24:53 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE Message-ID: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: The Eclipse IDE, and its relatives pydev and LiClipse, store settings in the root of a repository. It would be nice for the master .gitignore file to ignore these files, so that individual developers don't have to do this. I am preparing a GitHub Pull Request that fixes this issue. It is a matter of adding 4 lines to the top-level .gitignore file. ---------- messages: 287388 nosy: JDLH priority: normal severity: normal status: open title: gitignore settings files for Eclipse IDE versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:27:52 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 08:27:52 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486628872.16.0.637430432389.issue29510@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: A fix is in GitHub cpython PR #75. ---------- pull_requests: +26 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:38:05 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 08:38:05 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486629485.11.0.157676938546.issue29510@psf.upfronthosting.co.za> Changes by Jim DeLaHunt : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:46:15 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Thu, 09 Feb 2017 08:46:15 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486629975.44.0.983183623747.issue29503@psf.upfronthosting.co.za> Andi Bergmeier added the comment: I am not the primary contributor to Bazel, so the decision to support embeddable Python is not mine to make. That said, it seems to me like embeddable Python is a perfect fit if you want to have a hermetic Python installation. And I AM actually the person advocating for support for embeddable Python :). We should discuss whether we use -c or a wrapper script. The latter might be the better option on the long run for other reasons, too. My original question stems from the desire to only use e.g. a wrapper script for embeddable for the near future. Reason being that it is not yet as well tested as the PYTHONPATH approach. So would be hesitant to switch from PYTHONPATH to wrapper script for all variants. Also I am not sure yet, the wrapper script is an option for all cases. Thanks for the input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:48:52 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 08:48:52 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486630132.32.0.412012219382.issue29510@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I'm now looking at cpython as retrieved from Mercurial by Eclipse. It appears to be concerned by the presence of .project which is also an Eclipse settings file. It might be reasonable to extend the scope of this issue to include telling Mercurial to ignore settings files. My pull request does not do this, because I haven't yet learned the right Mercurial action. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:53:35 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 08:53:35 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486630415.67.0.39729824332.issue29510@psf.upfronthosting.co.za> INADA Naoki added the comment: We'll move to github soon. So no need for caring hgignore. While there is `.vscode` in gitignore already, I'm not fan of adding hundreds of IDE specific rule to gitignore. Why don't you use gitignore_global? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 04:10:37 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 09:10:37 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486631437.88.0.783370804721.issue29510@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: gitignore_global is a great idea. I had not heard of it before. But here it is: https://help.github.com/articles/ignoring-files/ . This instruction also has a link to a gist with a lot of helpful global ignores. I understand your reluctance to add entries for every IDE. Maybe a better solution would be to add something to the devguide about excluding IDE settings files, with a link to the Github instructions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 04:17:00 2017 From: report at bugs.python.org (George Shuklin) Date: Thu, 09 Feb 2017 09:17:00 +0000 Subject: [issue29511] Add 'find' as build-in method for lists Message-ID: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> New submission from George Shuklin: I found that Python provides 'find()' and 'in' methods for strings, but lacking same functionality for lists. Because strings and lists are very similar, it's reasonable to expect same function available for both. Here long and rather ugly hack list on stackoverflow about 'reinventing the wheel': http://stackoverflow.com/questions/16579085/python-verifying-if-one-list-is-a-subset-of-the-other There are short few proposals, each of them imperfect: 1. Use sets intersection. This looses count and order 2. Use collections.Count. This looses order 3. all(x in two for x in one) - looses order Propsal: adds a normal 'find' method which will behave the same way as find for strings. It should perform normal __cmp__ call on each element, or, may be, asking for optional lambda to perform comparison of elements. ---------- components: Interpreter Core messages: 287394 nosy: george-shuklin priority: normal severity: normal status: open title: Add 'find' as build-in method for lists type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 04:26:23 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Feb 2017 09:26:23 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486632383.76.0.74241753221.issue29510@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report and for the patch, Jim! I agree with Inada. global_gitignore is a better way to achieve this. > Maybe a better solution would be to add something to the devguide about > excluding IDE settings files, with a link to the Github instructions. Our goal is to only cover CPython specific topics in devguide. There a lot of things that can be mentioned in devguide, but it would be hard to maintain all these information and keep devguide short at same time :) ---------- nosy: +berker.peksag resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 04:46:41 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 09:46:41 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486633601.69.0.899336302036.issue29510@psf.upfronthosting.co.za> INADA Naoki added the comment: I agree with Berker. But some git/github tips are very useful for CPython core developers while they aren't CPython specific. And some of them are not in beginner's guide. I think it's worth enough to add link to such tips. * Use gitignore_global to ignore IDE/Editor specific files: https://help.github.com/articles/ignoring-files/ * Checkout pull request without adding remote: https://help.github.com/articles/checking-out-pull-requests-locally/ * Readable patch by git diff --indent-heuristic (git 2.11+) or --compact-heuristic (git 2.9+). * Creating lightweight working tree by git-new-workdir (like `hg share`): https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 05:25:20 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 09 Feb 2017 10:25:20 +0000 Subject: [issue29511] Add 'find' as build-in method for lists In-Reply-To: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> Message-ID: <1486635920.42.0.65383819012.issue29511@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Only 3.7 can receive new functionality. Here is a pure Python implementation of a subsequence test: https://code.activestate.com/recipes/577850-search-sequences-for-sub-sequence/ It appears to be reasonably popular on Activestate: it has about 7000 views, but a score of only 1. Take of that what you will. I interpret it as meaning it is of moderate but not great interest to people. ---------- nosy: +steven.daprano versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 05:27:50 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 09 Feb 2017 10:27:50 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486636070.4.0.541303322256.issue29506@psf.upfronthosting.co.za> Marco Buttu added the comment: +1 for the Steven's suggestion ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 05:30:22 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 10:30:22 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486636222.15.0.662812384033.issue29476@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 05:37:31 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 10:37:31 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486636651.74.0.36822030916.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: > But PyObject_CallMethod(), _PyObject_CallMethodId(), PyObject_CallMethodObjArgs(), _PyObject_CallMethodIdObjArgs() can use it too. CallMethod[Id]ObjArgs() can use it easily. But format support is not so easy. ---------- Added file: http://bugs.python.org/file46603/callmethod.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 05:38:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 10:38:14 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486636694.08.0.833122771297.issue29476@psf.upfronthosting.co.za> STINNER Victor added the comment: I vote -1 on set_no_dummy_reuse.diff since it doesn't show any significant speedup (3 ns on 130 ns with a std dev of 8 ns is not something significant), and makes the set type 2x slower on some corner cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:00:56 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 11:00:56 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486638056.52.0.830304638474.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: callmethod.patch: + ../python.default -m perf compare_to default.json patched2.json -G --min-speed=1 Slower (5): - logging_silent: 717 ns +- 9 ns -> 737 ns +- 8 ns: 1.03x slower (+3%) - fannkuch: 1.04 sec +- 0.01 sec -> 1.06 sec +- 0.02 sec: 1.02x slower (+2%) - call_method: 14.5 ms +- 0.1 ms -> 14.7 ms +- 0.1 ms: 1.02x slower (+2%) - call_method_slots: 14.3 ms +- 0.3 ms -> 14.6 ms +- 0.1 ms: 1.02x slower (+2%) - scimark_sparse_mat_mult: 8.66 ms +- 0.21 ms -> 8.76 ms +- 0.25 ms: 1.01x slower (+1%) Faster (17): - scimark_lu: 433 ms +- 28 ms -> 410 ms +- 24 ms: 1.06x faster (-5%) - unpickle: 32.9 us +- 0.2 us -> 31.7 us +- 0.3 us: 1.04x faster (-4%) - sqlite_synth: 10.0 us +- 0.2 us -> 9.77 us +- 0.24 us: 1.03x faster (-3%) - telco: 21.1 ms +- 0.7 ms -> 20.6 ms +- 0.4 ms: 1.03x faster (-2%) - unpickle_list: 8.22 us +- 0.18 us -> 8.02 us +- 0.17 us: 1.03x faster (-2%) - json_dumps: 30.3 ms +- 0.8 ms -> 29.6 ms +- 0.4 ms: 1.02x faster (-2%) - nbody: 245 ms +- 6 ms -> 240 ms +- 5 ms: 1.02x faster (-2%) - meteor_contest: 207 ms +- 2 ms -> 203 ms +- 2 ms: 1.02x faster (-2%) - scimark_fft: 738 ms +- 14 ms -> 727 ms +- 17 ms: 1.02x faster (-2%) - pickle_pure_python: 1.27 ms +- 0.02 ms -> 1.25 ms +- 0.02 ms: 1.01x faster (-1%) - django_template: 401 ms +- 4 ms -> 395 ms +- 5 ms: 1.01x faster (-1%) - sqlalchemy_declarative: 317 ms +- 3 ms -> 313 ms +- 4 ms: 1.01x faster (-1%) - json_loads: 64.2 us +- 1.0 us -> 63.4 us +- 1.0 us: 1.01x faster (-1%) - nqueens: 270 ms +- 2 ms -> 267 ms +- 2 ms: 1.01x faster (-1%) - crypto_pyaes: 234 ms +- 1 ms -> 231 ms +- 3 ms: 1.01x faster (-1%) - chaos: 300 ms +- 2 ms -> 297 ms +- 4 ms: 1.01x faster (-1%) - sympy_expand: 1.01 sec +- 0.01 sec -> 1.00 sec +- 0.01 sec: 1.01x faster (-1%) Benchmark hidden because not significant (42) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:05:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 11:05:29 +0000 Subject: [issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro? In-Reply-To: <1486568378.9.0.904847418882.issue29502@psf.upfronthosting.co.za> Message-ID: <1486638329.14.0.865772005559.issue29502@psf.upfronthosting.co.za> STINNER Victor added the comment: Output of attached profiler_c_code.py example: --- haypo at selma$ ./python profiler_c_code.py (, 'call', None) (, 'return', 'h') (, 'call', None) (, 'return', 'e') (, 'call', None) (, 'return', 'l') (, 'call', None) (, 'return', 'l') (, 'call', None) (, 'return', 'o') (, 'c_call', ) --- Except of sys.setprofile(), the profiler doesn't see any C calls! list() and map() are simply "hidden". So tools like coverage miss a lot of C call? Again, is it a compromise between performance and correctness, or just a regular bug? ---------- Added file: http://bugs.python.org/file46604/profiler_c_code.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:08:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 11:08:33 +0000 Subject: [issue29400] Add instruction level tracing via sys.settrace In-Reply-To: <1485886852.16.0.854514177291.issue29400@psf.upfronthosting.co.za> Message-ID: <1486638513.29.0.72350815435.issue29400@psf.upfronthosting.co.za> STINNER Victor added the comment: See aslo issue #29502: "Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro?" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:29:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 11:29:47 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486639787.16.0.724413484562.issue29306@psf.upfronthosting.co.za> STINNER Victor added the comment: enter_recursive_call_36.patch: Patch for Python 3.6. * Add Py_EnterRecursiveCall() into C functions * Don't call C functions inside a Py_EnterRecursiveCall() block in PyObject_Call() ---------- Added file: http://bugs.python.org/file46605/enter_recursive_call_36.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:46:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 11:46:03 +0000 Subject: [issue29512] regrtest refleak: implement bisection feature Message-ID: <1486640763.77.0.630012847727.issue29512@psf.upfronthosting.co.za> New submission from STINNER Victor: It would be great to be able to list which methods cause a reference leak. Example right now on the 3.6 branch: ---- $ ./python -m test -R 3:3 test_os Run tests sequentially 0:00:00 [1/1] test_os beginning 6 repetitions 123456 ...... test_os leaked [124, 124, 124] references, sum=372 test_os leaked [114, 114, 114] memory blocks, sum=342 test_os failed in 32 sec 1 test failed: test_os Total duration: 32 sec Tests result: FAILURE ---- Which methods caused the refleak? Is it possible to list test methods of a test file using unittest? ---------- components: Tests messages: 287405 nosy: haypo priority: normal severity: normal status: open title: regrtest refleak: implement bisection feature type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:49:27 2017 From: report at bugs.python.org (Sascha Silbe) Date: Thu, 09 Feb 2017 11:49:27 +0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1486640967.02.0.131865337053.issue1025395@psf.upfronthosting.co.za> Changes by Sascha Silbe : ---------- nosy: +sascha_silbe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:59:34 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Feb 2017 11:59:34 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 In-Reply-To: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> Message-ID: <1486641574.85.0.117923848477.issue29504@psf.upfronthosting.co.za> Christian Heimes added the comment: It's a bug in Blake2's reference implementation with nested C++ comments (/* /* */ */). https://github.com/BLAKE2/BLAKE2/commit/259e61dedee5383eac1a90db6ef88f9ccdcf6002#diff-ac1a341ec0ed38dc5d219572f4282287 fixed the bug. For Python 3.6.1 I'm going to update Python's copy of blake2. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:01:08 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Feb 2017 12:01:08 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 In-Reply-To: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> Message-ID: <1486641668.84.0.67369303809.issue29504@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't have time to fix the issue right away. Python's copy of blake2 needs some manual massaging and tweaking. ---------- assignee: -> christian.heimes nosy: +ned.deily priority: normal -> release blocker stage: -> needs patch type: -> compile error versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:01:58 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Feb 2017 12:01:58 +0000 Subject: [issue29480] Mac OSX Installer SSL Roots In-Reply-To: <1486553442.34.0.041490536597.issue29480@psf.upfronthosting.co.za> Message-ID: <1486641718.93.0.837952859139.issue29480@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:06:56 2017 From: report at bugs.python.org (Antti Haapala) Date: Thu, 09 Feb 2017 12:06:56 +0000 Subject: [issue11726] clarify that linecache only works on files that can be decoded successfully In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za> Message-ID: <1486642016.2.0.0596575821708.issue11726@psf.upfronthosting.co.za> Antti Haapala added the comment: Every now and then there are new questions and answers regarding the use of `linecache` module on Stack Overflow for doing random access to text files, even though the documentation states that it is meant for Python source code files. One problem is that the title still states: "11.9. linecache ? Random access to text lines"; the title should really be changed to "Random access to Python source code lines" so that the title wouldn't imply that this is a general-purpose random access library for text files. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:09:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:09:14 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) Message-ID: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> New submission from STINNER Victor: The following code leaks one reference on Python 3.6: def test_attributes(self): d = dict((entry.name, entry) for entry in os.scandir('.')) Or try the command: ./python -m test -R 3:3 test_os -v -m test_attributes ---------- components: Library (Lib) messages: 287409 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: os.scandir(str) reference leak (test_os refleak) type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:20:19 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 12:20:19 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486642819.72.0.852650408175.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm sorry, callmethod.patch is tuned other place, and causing SEGV. method_fastcall2.patch is tuning same function (call_method() in typeobject.c), and uses trick to bypass temporary method object (same to _PyObject_GetMethod()). $ ./python -m perf timeit --compare-to `pwd`/python.default -s 'class C:' -s ' def __getitem__(self, index): return index' -s 'c=C()' 'c[0]' python.default: ..................... 155 ns +- 4 ns python: ..................... 111 ns +- 1 ns Median +- std dev: [python.default] 155 ns +- 4 ns -> [python] 111 ns +- 1 ns: 1.40x faster (-28%) ---------- Added file: http://bugs.python.org/file46606/method_fastcall2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:21:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:21:47 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486642907.05.0.794822027799.issue29306@psf.upfronthosting.co.za> STINNER Victor added the comment: check_recursion_depth.py: script using Python functions and C function (functools.partial) to check the recursion depth. Example with Python 3.6: haypo at selma$ ./python check_recursion_depth.py # unpatched got: 148, expected: 100 haypo at selma$ ./python check_recursion_depth.py # patched got: 100, expected: 100 Maybe we need "proxies" in _testcapi for each kind of function, a function taking a callback and calling this function. Function types: * C function, METH_NOARGS * C function, METH_O * C function, METH_VARRGS * C function, METH_VARRGS | METH_KEYWORDS * C function, METH_FASTCALL * Python function * Maybe even most common C functions to call functions: PyObject_Call(), _PyObject_FastCallDict(), _PyObject_FastCallKeywords(), etc. ---------- Added file: http://bugs.python.org/file46607/check_recursion_depth.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:23:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:23:55 +0000 Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() in new FASTCALL functions In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za> Message-ID: <1486643035.02.0.0769460765033.issue29306@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested check_recursion_depth.py: Python 2.7, 3.5 and 3.6 have the bug. Python 3.7 is already fixed. ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:39:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:39:32 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486643972.66.0.18395702205.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: > method_fastcall2.patch is tuning same function (call_method() in typeobject.c), and uses trick to bypass temporary method object (same to _PyObject_GetMethod()). Oh, great idea! That's why I put you in the nosy list ;-) You know better than me this area of the code. > Median +- std dev: [python.default] 155 ns +- 4 ns -> [python] 111 ns +- 1 ns: 1.40x faster (-28%) Wow, much better than my patch. Good job! Can we implement the same optimization in callmethod() of Objects/abstract.c? Maybe add a "is_method" argument to the static function _PyObject_CallFunctionVa(), to only enable the optimization for callmehod(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:40:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:40:55 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486644055.55.0.728605001471.issue29507@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:50:48 2017 From: report at bugs.python.org (Pedro) Date: Thu, 09 Feb 2017 12:50:48 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486644647.99.0.740249619509.issue29506@psf.upfronthosting.co.za> Pedro added the comment: "Because deepcopy copies everything it may copy too much, such as data which is intended to be shared (instead of duplicated) between copies." A bit more explicit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 08:30:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 13:30:42 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486647042.34.0.866228190749.issue29513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The owning of references in the path_t structure was changed in issue29034, but some code still directly manipulates reference counters of path_t fields. Proposed patch should fix the leak. ---------- keywords: +patch nosy: +xiang.zhang stage: -> patch review Added file: http://bugs.python.org/file46608/scandir-refleak-3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 08:48:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 13:48:44 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486648124.64.0.482699989917.issue29513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 3.7 doesn't leak, but contains outdated comment and code. ---------- versions: +Python 3.7 Added file: http://bugs.python.org/file46609/scandir-refleak-3.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 08:49:23 2017 From: report at bugs.python.org (desbma) Date: Thu, 09 Feb 2017 13:49:23 +0000 Subject: [issue29212] Python 3.6 logging thread name regression with concurrent.future threads In-Reply-To: <1483938963.09.0.315595404976.issue29212@psf.upfronthosting.co.za> Message-ID: <1486648163.62.0.449824478348.issue29212@psf.upfronthosting.co.za> desbma added the comment: Ping, so that this has a chance for the 3.6.1 release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 09:04:38 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 14:04:38 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486649078.09.0.127726748336.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: method_fastcall3.patch implement the trick in more general way. (I haven't ran test yet since it's midnight. I'll post result later.) ---------- Added file: http://bugs.python.org/file46610/method_fastcall3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 09:22:31 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 14:22:31 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486650151.38.0.32189870273.issue26355@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: docs at python -> ncoghlan stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 09:23:47 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 14:23:47 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486650227.16.0.285227091502.issue26355@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks good to me, so I'll apply these right now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 09:52:02 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 09 Feb 2017 14:52:02 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486651922.41.0.369703977142.issue29513@psf.upfronthosting.co.za> Xiang Zhang added the comment: 3.6 LGTM. 3.7 is technically right to me. But it looks to me AC shouldn't call path_cleanup in .c.h. It always do nothing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 09:57:55 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Feb 2017 14:57:55 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486652275.27.0.623830307965.issue29506@psf.upfronthosting.co.za> R. David Murray added the comment: I prefer Steven's formulation. The parenthetical is more distracting than clarifying, I think. I agree that 'administrative' is confusing and unnecessary. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:02:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 15:02:43 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486652563.4.0.0936472074534.issue29513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If PyObject_New(ScandirIterator, &ScandirIteratorType) fails the path should be cleaned up by Argument Clinic. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:03:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 15:03:09 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486652589.74.0.961293940158.issue29513@psf.upfronthosting.co.za> STINNER Victor added the comment: scandir-refleak-3.6.patch LGTM. The following removed Py_CLEAR() is just redundant, so it's ok to remove it. - Py_CLEAR(iterator->path.object); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:04:56 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 09 Feb 2017 15:04:56 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486652696.2.0.172320031407.issue29513@psf.upfronthosting.co.za> Xiang Zhang added the comment: > If PyObject_New(ScandirIterator, &ScandirIteratorType) fails the path should be cleaned up by Argument Clinic. Ohh yes. My stupid. Then both LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:09:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 15:09:19 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <20170209150914.96198.62156.4F2C6AF9@psf.io> Roundup Robot added the comment: New changeset c63b09833141 by Nick Coghlan in branch '3.5': Issue #26355: Specify canonical URLs in docs pages https://hg.python.org/cpython/rev/c63b09833141 New changeset 80970cf56048 by Nick Coghlan in branch '3.6': Merge issue #26355 fix from Python 3.5 https://hg.python.org/cpython/rev/80970cf56048 New changeset 26af402c291f by Nick Coghlan in branch 'default': Merge issue #26355 fix from 3.6 https://hg.python.org/cpython/rev/26af402c291f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:11:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 15:11:11 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486653071.53.0.0236332112373.issue29506@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Current documentation looks correct to me. What is the problem with it? Steven's formulation says about "deepcopy", but current documentation says about common issues of "deep copy" and describes how copy.deepcopy() solves them. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:24:03 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 09 Feb 2017 15:24:03 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1486653843.53.0.568577184445.issue29506@psf.upfronthosting.co.za> Marco Buttu added the comment: Serhiy is right about "deep copy" instead of "deepcopy", but IMO the Steven's proposal (with the "deep copy" correction) is much clearer than the current doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:30:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 15:30:10 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases Message-ID: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> New submission from Nick Coghlan: The magic number change in 3.5.3 broke the world when Fedora attempted to rebase from 3.5.2, but upstream CPython developers don't currently get an automated notification that it isn't permitted to change the magic number in a maintenance release - instead, the current approach relies on people "just knowing" not to do that, and we just saw the limitations of relying on the code review process to catch this particular problem. I think we can keep this from happening again by having an importlib test case that fails if sys.version_info.releaselevel is "candidate" or "final" and either: - no "expected magic number" is defined; or - the actual magic number in importlib.util.MAGIC_NUMBER doesn't match the expected one The comments on the new test case would then explain the policy and why it isn't OK to break pyc file compatibility in a maintenance release. We'd also propose an update to the release PEP warning release managers to expect this error as part of prepping the first release candidate, and that they should lock in the magic number for the release at that time. ---------- messages: 287428 nosy: barry, brett.cannon, doko, encukou, ncoghlan priority: normal severity: normal status: open title: Add a test case that prevents magic number changes in minor releases versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:35:59 2017 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 09 Feb 2017 15:35:59 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486654559.49.0.301153128956.issue29514@psf.upfronthosting.co.za> Petr Viktorin added the comment: For the record, the magic number was changed in issue27286 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:00:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 16:00:34 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486656034.44.0.393621425.issue26355@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a47e20b636d2a5559e5831c6805df3cba1ddb2a1 by Nick Coghlan in branch 'master': Issue #26355: Specify canonical URLs in docs pages https://github.com/python/cpython/commit/a47e20b636d2a5559e5831c6805df3cba1ddb2a1 New changeset 37150972faf660571a3ae7076a623087c06b8791 by Nick Coghlan in branch 'master': Merge issue #26355 fix from Python 3.5 https://github.com/python/cpython/commit/37150972faf660571a3ae7076a623087c06b8791 New changeset d267bc695eaf9422668daedb9e44442696e01fe7 by Nick Coghlan in branch 'master': Merge issue #26355 fix from 3.6 https://github.com/python/cpython/commit/d267bc695eaf9422668daedb9e44442696e01fe7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:00:37 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 16:00:37 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486656037.4.0.0340820928002.issue26355@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a47e20b636d2a5559e5831c6805df3cba1ddb2a1 by Nick Coghlan in branch '3.5': Issue #26355: Specify canonical URLs in docs pages https://github.com/python/cpython/commit/a47e20b636d2a5559e5831c6805df3cba1ddb2a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:00:51 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 16:00:51 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <20170209160040.8335.85376.C23C35CC@psf.io> Roundup Robot added the comment: New changeset b07d454e45a2 by Nick Coghlan in branch '2.7': Issue #26355: Specify canonical URLs in docs pages https://hg.python.org/cpython/rev/b07d454e45a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:07:27 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 16:07:27 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486656447.68.0.862246799411.issue26355@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I'm marking this as closed, since it's as resolved as we can make it through a *CPython* change. Since the old branches aren't autobuilt anymore, adding a canonical URL reference to them would presumably be a matter of running a script over the built docs. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:22:07 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 09 Feb 2017 16:22:07 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486657327.45.0.243712223162.issue29476@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The problem with posting an idea here on the tracker while it is still in the research phase is that it will be prematurely downvoted without have fully thought it through. What I'm working on now is that opposite question. Was it ever worthwhile to add this optimization in the first place? In particular, does it strongly preference a single case over normal cases to no real benefit? Suppose we found a line code in the calendar module that tested for one special case. Is it March 3, 1978, and if so used a precomputed result, but for all other dates would compute normally. The right thing to do would be to remove that code, but then one commenter would say, "it makes that one case many times slower" when in fact it brings that case into line with the other normal cases. And another respondent would say "removing the almost never used special case provides too small of an improvement to the rest of the cases". The group would then arrive at the collective incorrect conclusion that yes it is a great idea to keep a special case for March 3, 1978. The test bench I'm working on now is examining whether a repeated add/discard of the same element in an otherwise mostly full table is like the calendar module scenario described above. In particular, I want to know whether applying the patch makes the new performance for that case about the same as other typical cases of add/discard. Here are some thoughts using timings. How you time, what you time, and where you time it matter a great deal when evaluating whether to keep code that is deep in the set insertion logic. In a complex function that is already having register spills, different compilers may have very different results (i.e. eliminating the freeslot lookup may allow another important variable to use a register rather than spilling and reloading on every iteration). We can also expect different results on 32-bit vs 64-bit builds (the former having many fewer registers to work with) and on ARM vs x86 (with the latter having greater instruction level parallelism that lets you get away with having blocks of useless code running in parallel with the important code). The test dataset matters as well. If set insertion timings are dominated by hashing or equality tests, then all improvements to the probing logic with look insignificant. Likewise, if the dataset has few hash collisions, then the affected code doesn't get run at all, leading to the false conclusion that simplifying the code doesn't have any benefit. For a timing that properly isolates and exercises the affected code, we should expect some measurable (and likely non-trivial) benefit. The GCC-6 x86_64 disassembly gives us reason to expect a favorable result because the new inner loop has a third fewer instructions, two fewer compare/jumps, and half the number of memory accesses (because the freeslot is being reloaded from the stack on every iteration). Also, there hasn't been any exploration of the potential indirect benefits in cases that I expect to be far more common. In those cases where we're going to have to resize anyway, is it better to do work to have partial early reclamation of dummies and defer resizing, or is it better to avoid the work for early reclamation so we can resize sooner and eliminate all of the dummies. I don't know the answer to this question yet, but it is far more important and usual than a contrived case of repeatedly adding and discarding the exact same element but never hitting a resize. On the other hand, perhaps the early dummy reclamation is worth it. I don't know the answer yet and was hoping that you all would help me find out. Downvoting of the basis of two quick and dirty timings on a single machine, single compiler, and single dataset isn't helpful. I've already put a lot of time in looking at these issues and still don't know the right thing to do. So, if other commenters have only put a few minutes into thinking about about it and have already drawn a conclusion, then their conclusions are suspect. IMO, there are still open research questions: Is early freeslot reclamation worth it or does it have a net negative benefit in all but the most exotic and unlikely cases? Without the existing optimization, would the exotic case perform about the same as other cases, or is the exotic case catastrophically worse than the others so that it warrants special handing even to the detriment of the other cases? ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:24:10 2017 From: report at bugs.python.org (Jyotirmoy Bhattacharya) Date: Thu, 09 Feb 2017 16:24:10 +0000 Subject: [issue29449] clear() should return prior state in threading.Event In-Reply-To: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> Message-ID: <1486657450.83.0.959758286846.issue29449@psf.upfronthosting.co.za> Jyotirmoy Bhattacharya added the comment: Thanks for the comments above. I'm going to rethink my design. Closing this bug. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:27:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 16:27:28 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486657648.75.0.292401823657.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: method_fastcall4.patch: Based on method_fastcall3.patch, I just added call_unbound() and call_unbound_noarg() helper functions to factorize code. I also modified mro_invoke() to be able to remove lookup_method(). I confirm the speedup with attached bench.py: Median +- std dev: [ref] 121 ns +- 5 ns -> [patch] 82.8 ns +- 1.0 ns: 1.46x faster (-31%) ---------- Added file: http://bugs.python.org/file46611/method_fastcall4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 11:27:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 16:27:39 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486657659.09.0.324349467126.issue29507@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file46612/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 17:00:23 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486659623.78.0.265861604561.issue26355@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset e8455e7137b9bd63d4c0183558161dba6ea00d32 by Nick Coghlan in branch '2.7': Issue #26355: Specify canonical URLs in docs pages https://github.com/python/cpython/commit/e8455e7137b9bd63d4c0183558161dba6ea00d32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:17:50 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 09 Feb 2017 17:17:50 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1486660670.99.0.0996760115543.issue29503@psf.upfronthosting.co.za> Steve Dower added the comment: You can also use the nuget packages (search on nuget.org for Python). These are intended to be used is scripted standalone setups, such as CI systems. I've been using them as part of most of my build systems recently. They support distutils and pip (not venv in the current version, but that's coming). You can directly download the nuget.exe tool from https://aka.ms/nugetclidl (e.g. as part of a script). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:38:23 2017 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Feb 2017 17:38:23 +0000 Subject: [issue29505] Submit the re, json, & csv modules to oss-fuzz testing In-Reply-To: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za> Message-ID: <1486661903.51.0.308608230339.issue29505@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon, christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:44:02 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 17:44:02 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486662242.53.0.846760231417.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: method_fastcall4.patch looks clean enough, and performance benefit seems nice. I don't know current test suite covers unusual special methods. Maybe, we can extend test_class to cover !unbound (e.g. @classmethod) case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:50:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 17:50:57 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486662657.03.0.606680302556.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: method_fastcall4.patch benchmark results. It's not the first time that I notice that fannkuch and nbody benchmarks become slower. I guess that it's effect of changing code placement because of unrelated change in the C code. Results don't seem significant on such macro benchmarks (may be random performance changes due to code placement). IMHO the change is worth it! "1.46x faster (-31%)" on a microbenchmark is significant and the change is small. $ python3 -m perf compare_to /home/haypo/benchmarks/2017-02-08_15-49-default-f507545ad22a.json method_fastcall4_ref_f507545ad22a.json -G --min-speed=5 Slower (2): - fannkuch: 900 ms +- 20 ms -> 994 ms +- 10 ms: 1.10x slower (+10%) - nbody: 215 ms +- 3 ms -> 228 ms +- 4 ms: 1.06x slower (+6%) Faster (3): - scimark_lu: 357 ms +- 23 ms -> 298 ms +- 8 ms: 1.19x faster (-16%) - scimark_sor: 400 ms +- 11 ms -> 355 ms +- 12 ms: 1.12x faster (-11%) - raytrace: 1.05 sec +- 0.01 sec -> 984 ms +- 15 ms: 1.07x faster (-6%) Benchmark hidden because not significant (59): (...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:55:09 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 09 Feb 2017 17:55:09 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486662909.74.0.553564001237.issue26355@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > OK, I'm marking this as closed, since it's as resolved as we can make it through a *CPython* change. Thanks you Nick, I appreciate the time you took to do that. ANd thank you Berker for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:58:02 2017 From: report at bugs.python.org (Maximilian Hils) Date: Thu, 09 Feb 2017 17:58:02 +0000 Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za> Message-ID: <1486663082.73.0.058716399414.issue6926@psf.upfronthosting.co.za> Maximilian Hils added the comment: This still seems to be an issue with the offical Python 3.6 builds on Windows 10: Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 >>> import socket >>> socket.IPPROTO_IPV6 Traceback (most recent call last): File "", line 1, in AttributeError: module 'socket' has no attribute 'IPPROTO_IPV6' ---------- nosy: +mhils _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 12:59:41 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Feb 2017 17:59:41 +0000 Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za> Message-ID: <1486663181.09.0.730434505402.issue6926@psf.upfronthosting.co.za> Christian Heimes added the comment: The constants are defined on Linux. That means Windows does not define the constants and therefore the socket module can't export them. This ticket is closed. If you still think it's a bug, please open a new ticket and reference this ticket. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:03:25 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 18:03:25 +0000 Subject: [issue1353344] python.desktop Message-ID: <1486663405.49.0.622737944832.issue1353344@psf.upfronthosting.co.za> Nick Coghlan added the comment: >From a downstream redistributor point of view, the key pieces it would be handy to consolidate upstream are the desktop file itself (with all the translations) and the preferred icon. It wouldn't really help much to have it integrated into "make install" since most redistributors split out tkinter and IDLE packages from the base installation anyway. However, as Terry says, before the change can be accepted, those files need to be combined into an actual patch that: - adds the desktop file and the icon to the Misc directory - updates Misc/README to describe the new files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:04:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 18:04:21 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486663461.52.0.543056609963.issue26355@psf.upfronthosting.co.za> Nick Coghlan added the comment: Matthias - thanks for figuring out how to turn my "we should do this" idea into a change we've actually made :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:07:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 18:07:38 +0000 Subject: [issue29034] Fix memory leak and use-after-free in path_converter In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za> Message-ID: <20170209180734.16444.38392.C426D3BD@psf.io> Roundup Robot added the comment: New changeset 4e3a16bdadae by Serhiy Storchaka in branch '3.6': Issue #29513: Fixed a reference leak in os.scandir() added in issue #29034. https://hg.python.org/cpython/rev/4e3a16bdadae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:07:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 18:07:38 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <20170209180734.16444.36473.EDBF0F6F@psf.io> Roundup Robot added the comment: New changeset 4e3a16bdadae by Serhiy Storchaka in branch '3.6': Issue #29513: Fixed a reference leak in os.scandir() added in issue #29034. https://hg.python.org/cpython/rev/4e3a16bdadae New changeset a3f8c5d172b4 by Serhiy Storchaka in branch 'default': Issue #29513: Fix outdated comment and remove redundand code is os.scandir(). https://hg.python.org/cpython/rev/a3f8c5d172b4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:07:45 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 09 Feb 2017 18:07:45 +0000 Subject: [issue26355] Emit major version based canonical URLs for docs In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za> Message-ID: <1486663665.08.0.691340180102.issue26355@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > turn my "we should do this" idea into a change we've actually made :) Looking forward to being able to do this more on GitHub as I am more familiar with git. Good luck for the transition, I'm pretty sure there will be some hard time in the next few weeks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:08:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 18:08:13 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486663693.51.0.314586399685.issue29513@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:27:42 2017 From: report at bugs.python.org (Maximilian Hils) Date: Thu, 09 Feb 2017 18:27:42 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows Message-ID: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> New submission from Maximilian Hils: The latest Windows builds for Python 3.5.3/3.6.0 do not export socket.IPPROTO_IPV6, even though e.g. socket.IPV6_V6ONLY is exported. This seems to be wrong to me as IPV6_V6ONLY requires the corresponding socket option level IPPROTO_IPV6 to be actually useful. The same issue at least also applies to IPPROTO_IPV4. christian.heimes mentioned that this is intended behaviour in https://bugs.python.org/issue6926 as Windows would not define the constants. Now I am all but an expert on this, but it seems to me that IPPROTO_IPV6 is defined in Windows: https://msdn.microsoft.com/en-us/library/windows/hardware/ff543746(v=vs.85).aspx. Apologies if I'm missing something here. Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 >>> import socket; socket.IPPROTO_IPV6 Traceback (most recent call last): File "", line 1, in AttributeError: module 'socket' has no attribute 'IPPROTO_IPV6' As a workaround, IPPROTO_IPV6 can be substituted with the hardcoded constant 41. ---------- components: Windows messages: 287449 nosy: christian.heimes, mhils, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:31:04 2017 From: report at bugs.python.org (Cornelius Diekmann) Date: Thu, 09 Feb 2017 18:31:04 +0000 Subject: [issue29070] Integration tests for pty.spawn on Linux and all other platforms In-Reply-To: <1482684225.17.0.467768789806.issue29070@psf.upfronthosting.co.za> Message-ID: <1486665064.57.0.0396349671021.issue29070@psf.upfronthosting.co.za> Cornelius Diekmann added the comment: Uploaded a new version of the patch. Changelog of this patch (compared to v3): * Fixed reliability issue of existing pty tests. * pty.fork() should now also work on systems without os.forkpty(). Added code to test this backup path of pty.fork(). * Reverted my flawed changes to pty.py (broken pipe). * All new tests which produce output in the pty.spawn()ed child have the terminal in a well-defined state w.r.t. termios. * Subtle renaming: PtyTest is now PtyBasicTest. The reason is to execute it before the integration tests. All tests are independent and the order is irrelevant, but if something fails on a platform, it is easier to debug if we run the unit tests before we go to the integration tests. * Improved, cleaned, documented, and restructured test code. Thank you Xavier and Martin for your very helpful feedback :-) I also added some small comments in the code review tool. ---------- Added file: http://bugs.python.org/file46613/pty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 14:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 19:00:22 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> Message-ID: <1486666822.3.0.659929247352.issue29513@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset be85fd4ef41979dbe68262938da12328fb6cfb8c by Serhiy Storchaka in branch '3.6': Issue #29513: Fixed a reference leak in os.scandir() added in issue #29034. https://github.com/python/cpython/commit/be85fd4ef41979dbe68262938da12328fb6cfb8c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 14:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 19:00:22 +0000 Subject: [issue29034] Fix memory leak and use-after-free in path_converter In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za> Message-ID: <1486666822.4.0.568444063599.issue29034@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset be85fd4ef41979dbe68262938da12328fb6cfb8c by Serhiy Storchaka in branch '3.6': Issue #29513: Fixed a reference leak in os.scandir() added in issue #29034. https://github.com/python/cpython/commit/be85fd4ef41979dbe68262938da12328fb6cfb8c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 15:45:30 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 09 Feb 2017 20:45:30 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486673130.27.0.652773008764.issue29507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 Though this is a rather large and impactful patch, I think it is a great idea. It will be one of the highest payoff applications of FASTCALL, broadly benefitting a lot of code. Let's be sure to be extra careful with this one because it is touching central parts of the language, so any errors or subtle behavior changes will be felt by a lot of code, some of which is sure to hit the rare corner cases and to rely on implementation details. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:11:14 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 21:11:14 +0000 Subject: [issue29510] gitignore settings files for Eclipse IDE In-Reply-To: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> Message-ID: <1486674674.44.0.798515490523.issue29510@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I have set up a global gitignore, and it works for me. % git config --global core.excludesfile ~/.gitignore_global (Amusingly, I had _already- set a global gitignore, but I had forgotten it existed, and it didn't ignore these IDE files.) I agree that we should not put IDE entries in the CPython .gitignore. I also think it's a good idea to add the points Inada mentions in the developer doc somewhere. That should include the Git global ignore idea. I see Berker's point that the Devguide shouldn't get too big, but it also shouldn't leave out useful information. There's a balance to strike. I think that's the topic of a different issue, however. I'll open that when I get back to this. In the meantime, if someone searches the issue database for "gitignore", they will find this discussion. That's helpful. Thank you both for your responses, Inada and Berker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:12:34 2017 From: report at bugs.python.org (Darko Poljak) Date: Thu, 09 Feb 2017 21:12:34 +0000 Subject: [issue29516] shutil.copytree(symlinks=True) fails when copying symlinks cross-device and there is no alternative Message-ID: <1486674754.67.0.62017119203.issue29516@psf.upfronthosting.co.za> New submission from Darko Poljak: shutil.copytree() always calls copystat() for symlinks. Copying symlink to another volume fails if some attributes cannot be set. And there is no alternative to bypass this as it can be done for files and directories using copy_function. By default copy_function equals copy2() which calls copystat(). There is also copy() available which calls copymode(). >From the copytree() source code one can see that for symlink copystat() is called in any case: if os.path.islink(srcname): linkto = os.readlink(srcname) if symlinks: # We can't just leave it to `copy_function` because legacy # code with a custom `copy_function` may rely on copytree # doing the right thing. os.symlink(linkto, dstname) copystat(srcname, dstname, follow_symlinks=not symlinks) An example is running inside a docker container with a zfs based volume mounted at /root/.cdist. Root filesytem with /tmp is also on zfs based container root-volume. And copying files with shutil.move which in this case uses copytree results in the following error: Traceback (most recent call last): File "/appenv/lib/python3.5/shutil.py", line 538, in move os.rename(src, real_dst) OSError: [Errno 18] Cross-device link: '/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data' -> '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/appenv/bin/cdist", line 94, in commandline() File "/appenv/bin/cdist", line 66, in commandline args.func(args) File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 157, in commandline args, parallel=False) File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 227, in onehost c.run() File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 255, in run self.local.save_cache() File "/appenv/lib/python3.5/site-packages/cdist/exec/local.py", line 265, in save_cache shutil.move(self.base_path, destination) File "/appenv/lib/python3.5/shutil.py", line 549, in move symlinks=True) File "/appenv/lib/python3.5/shutil.py", line 353, in copytree raise Error(errors) shutil.Error: [('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/network', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/network', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/network'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/os', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/machine', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/init-system', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/init-system', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/init-system'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/interfaces', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/interfaces', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/interfaces'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/os_version', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os_version', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os_version'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/cpu_cores', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/cpu_cores', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/cpu_cores'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/lsb_description', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_description', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_description'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/machine_type', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine_type', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine_type'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/efi', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/efi', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/efi'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/lsb_id', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_id', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_id'"), ... Using copy_function=copy instead of default copy2 does not solve the problem since for symlinks copytree() always uses copystat(). Concrete example which mimics copytree() code for symlink: (appenv) ~ # rm /root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog (appenv) ~ # python Python 3.5.2 (default, Dec 20 2016, 17:58:45) [GCC 5.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> src='/tmp/tmpoiwfrgvk/936a8745479046ce91a00ee3013fc9b8/data/conf/type/__hpc_syslog' >>> dst='/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog' >>> linkto = os.readlink(src) >>> os.symlink(linkto, dst) >>> os.stat(dst) os.stat_result(st_mode=16877, st_ino=955, st_dev=71, st_nlink=4, st_uid=65534, st_gid=65534, st_size=8, st_atime=1486540058, st_mtime=1485953153, st_ctime=1485953153) >>> import shutil >>> shutil.copystat(src, dst, follow_symlinks=False) Traceback (most recent call last): File "", line 1, in File "/appenv/lib/python3.5/shutil.py", line 197, in copystat lookup("chmod")(dst, mode, follow_symlinks=follow) OSError: [Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog' >>> ---------- components: Library (Lib) messages: 287455 nosy: poljakowski priority: normal severity: normal status: open title: shutil.copytree(symlinks=True) fails when copying symlinks cross-device and there is no alternative type: crash versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:16:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 21:16:00 +0000 Subject: [issue29513] os.scandir(str) reference leak (test_os refleak) In-Reply-To: <1486666822.3.0.659929247352.issue29513@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thanks for the quick fix Serhiy! I was working on patch and I like to check for refleaks. Sadly, it wasn't noticed before. At least my test was pass :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:16:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Feb 2017 21:16:50 +0000 Subject: [issue29476] Simplify set_add_entry() In-Reply-To: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> Message-ID: <1486675010.06.0.760545109322.issue29476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't downvote, no. I am just unsure. I don't have enough information to say that the net benefit is positive neither that it is negative. In the face of hesitance the status quo wins. But it looks to me that in dominant cases set_add_entry() is used with a set that doesn't contain dummies. What do you think about specializing set_add_entry() for this case? set_add_entry() could be optimized for most common cases (creating and set-to-set operations), but still not be degrading in worst cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:19:24 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 21:19:24 +0000 Subject: [issue29034] Fix memory leak and use-after-free in path_converter In-Reply-To: <1486666822.4.0.568444063599.issue29034@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Does the latest commit fixes a regression introduced by the first fix? Too bad that we missed the refleak in an issue fixing a memory leak :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:41:25 2017 From: report at bugs.python.org (DAVID ALEJANDRO Pineda) Date: Thu, 09 Feb 2017 21:41:25 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... Message-ID: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> New submission from DAVID ALEJANDRO Pineda: Hello. I'm working in a real time data collector project. I'm using asyncio and multiprocessing (run_in_executor). In python 3.5 worked fine but in python 3.6 not, gave to me this error: "Traceback (most recent call last): File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 241, in _feed obj = _ForkingPickler.dumps(obj) File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) AttributeError: Can't pickle local object 'WeakSet.__init__.._remove' " I tracked and the problem is when i run some method in run_in_executor with the functools.partial. Before this version the system works fine. The main file is local.py (to run with local administration using a socket) And the engine is in engine.py The project (in development): https://gitlab.com/pineiden/collector ---------- components: asyncio files: code_with_bug.png messages: 287459 nosy: DAVID ALEJANDRO Pineda, gvanrossum, yselivanov priority: normal severity: normal status: open title: "Can't pickle local object" when uses functools.partial with method and args... type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46614/code_with_bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 17:00:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 22:00:33 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <20170209220030.53274.19585.01899564@psf.io> Roundup Robot added the comment: New changeset 7b8df4a5d81d by Victor Stinner in branch 'default': Optimize slots: avoid temporary PyMethodObject https://hg.python.org/cpython/rev/7b8df4a5d81d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 17:14:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 22:14:32 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486678472.84.0.763920145268.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: Raymond Hettinger: "+1 Though this is a rather large and impactful patch, I think it is a great idea. It will be one of the highest payoff applications of FASTCALL, broadly benefitting a lot of code." In my experience, avoiding temporary tuple to pass positional arguments provides a speedup to up 30% faster in the best case. Here it's 1.5x faster because the optimization also avoids the creation of temporary PyMethodObject. "Let's be sure to be extra careful with this one because it is touching central parts of the language, so any errors or subtle behavior changes will be felt by a lot of code, some of which is sure to hit the rare corner cases and to rely on implementation details." I reviewed Naoki's patch carefully, but in fact it isn't as big as I expected. In Python 3.6, call_method() calls tp_descr_get of PyFunction_Type which creates PyMethodObject. The tp_call of PyMethodObject calls the function with self, nothing crazy. The patch removes a lot of steps and (IMHO) makes the code simpler than before (when calling Python methods). I'm not saying that such change is bugfree-proof :-) But we are far from Python 3.7 final, so it's the right time to push such large optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 17:22:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 22:22:20 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486678940.9.0.937384597814.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: Naoki: "method_fastcall4.patch looks clean enough, and performance benefit seems nice." Ok, I pushed the patch with minor changes: * replace "variants:" with "Variants:" * rename lookup_maybe_unbound() to lookup_maybe_method() * rename lookup_method_unbound() to lookup_method() "I don't know current test suite covers unusual special methods." What do you mean by "unusual special methods"? "Maybe, we can extend test_class to cover !unbound (e.g. @classmethod) case." It's hard to test all cases, since they are a lot of function types in Python, and each slot (wrapper in typeobject.c) has its own C implementation. But yeah, in general more tests don't harm :-) Since the patch here optimizes the most common case, a regular method implemented in Python, I didn't add a specific test with the change. This case is already very well tested, like everything in the stdlib, no? -- I tried to imagine how we could avoid temporary method objects in more cases like Python class methods (using @classmethod), but I don't think that it's worth it. It would require more complex code for a less common case. Or do someone see other common cases which would benefit of a similar optimization? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 17:25:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Feb 2017 22:25:00 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486679100.15.0.46021010153.issue29507@psf.upfronthosting.co.za> Yury Selivanov added the comment: patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 17:51:18 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 22:51:18 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <20170209225115.53274.98012.5FE2AF09@psf.io> Roundup Robot added the comment: New changeset be663c9a9e24 by Victor Stinner in branch 'default': Issue #29507: Update test_exceptions https://hg.python.org/cpython/rev/be663c9a9e24 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:12:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 23:12:03 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486681923.21.0.616763457637.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I was too lazy to run the full test suite, I only ran a subset and I was bitten by buildbots :-) test_unraisable() of test_exceptions fails. IHMO the BrokenRepr subtest on this test function is really implementation specific. To fix buildbots, I removed the BrokenRepr unit test, but kept the other cases on test_unraisable(): change be663c9a9e24. See my commit message for the full rationale. In fact, the patch changed the error message logged when a destructor fails. Example: --- class Obj: def __del__(self): raise Exception("broken del") def __repr__(self): return "" obj = Obj() del obj --- Before, contains "": --- Exception ignored in: > Traceback (most recent call last): File "x.py", line 3, in __del__ raise Exception("broken del") Exception: broken del --- After, "" is gone: --- Exception ignored in: Traceback (most recent call last): File "x.py", line 3, in __del__ raise Exception("broken del") Exception: broken del --- There is an advantage. The error message is now better when repr(obj) fails. Example: --- class Obj: def __del__(self): raise Exception("broken del") def __repr__(self): raise Excepiton("broken repr") obj = Obj() del obj --- Before, raw "" with no information on the type: --- Exception ignored in: Traceback (most recent call last): File "x.py", line 3, in __del__ raise Exception("broken del") Exception: broken del --- After, the error message includes the type: --- Exception ignored in: Traceback (most recent call last): File "x.py", line 3, in __del__ raise Exception("broken del") Exception: broken del --- Technically, slot_tp_finalize() can call lookup_maybe() to get a bound method if the unbound method failed. The question is if it's worth it? In general, I dislike calling too much code to log an exception, since it's likely to raise a new exception. It's exactly the case here: logging an exception raises a new exception (in repr())! Simpler option: revert the change in slot_tp_finalize() and document that's it's deliberate to get a bound method to get a better error message. The question is a tradeoff between performance and correctness. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:14:18 2017 From: report at bugs.python.org (Maximilian Hils) Date: Thu, 09 Feb 2017 23:14:18 +0000 Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za> Message-ID: <1486682058.17.0.276186474319.issue6926@psf.upfronthosting.co.za> Maximilian Hils added the comment: Thanks for the insanely quick feedback. I still think this is a bug, so I filed https://bugs.python.org/issue29515 with additional details. Let's continue there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:18:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 23:18:31 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486682311.2.0.0531575927284.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: I checked typeobject.c: there is a single case where we use the result of lookup_maybe_method()/lookup_method() for something else than calling the unbound method: slot_tp_finalize() calls PyErr_WriteUnraisable(del), the case discussed in my previous message which caused test_exceptions failure (now fixed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:27:27 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 23:27:27 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486682847.18.0.521564174046.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks for finishing my draft patch, Victor. callmetohd2.patch is same trick for PyObject_CallMethod* APIs in abstract.c. It fixes segv in callmethod.patch. And APIs receiving format string can do same trick when format is empty too. As I grepping "PyObject_CallMethod", there are many format=NULL callers. ---------- Added file: http://bugs.python.org/file46615/callmethod2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:41:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Feb 2017 23:41:40 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <20170209234136.61992.58017.E6348D97@psf.io> Roundup Robot added the comment: New changeset e5cd74868dfc by Victor Stinner in branch 'default': Issue #29507: Fix _PyObject_CallFunctionVa() https://hg.python.org/cpython/rev/e5cd74868dfc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 18:50:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 23:50:16 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486684216.09.0.492045050526.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: callmethod2.patch: I like that change on object_vacall(), I'm not sure about the change on PyObject_CallMethod*() only for empty format string. I suggest to split your patch into two parts, and first focus on object_vacall(). Do you have a benchmark for this one? Note: I doesn't like the name I chose for object_vacall(). If we modify it, I would suggest to rename it objet_call_vargs() instead. Anyway, before pushing anything more, I would like to take a decision on the repr()/test_exceptions issue. What do you think Naoki? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 19:00:20 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 00:00:20 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486684820.68.0.0130728708015.issue29507@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d by Victor Stinner in branch 'master': Issue #29507: Fix _PyObject_CallFunctionVa() https://github.com/python/cpython/commit/b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 20:15:52 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Feb 2017 01:15:52 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... In-Reply-To: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> Message-ID: <1486689351.98.0.952519914727.issue29517@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 21:01:49 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 10 Feb 2017 02:01:49 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1486692109.44.0.154024209339.issue29515@psf.upfronthosting.co.za> Eryk Sun added the comment: The macro is defined but not defined. If I insert the following line before the #ifdef check: #define IPPROTO_IPV6 IPPROTO_IPV6 then the constant gets added: >>> import _socket >>> _socket.IPPROTO_IPV6 41 The same applies to IPPROTO_IPV4 and probably others. ---------- nosy: +eryksun versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 21:47:38 2017 From: report at bugs.python.org (Justin McNiel) Date: Fri, 10 Feb 2017 02:47:38 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) Message-ID: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> New submission from Justin McNiel: All for loops are refusing to break (Python 2.7.13) on win32 - only on execution of '.py' file an example would be:" for x in range(5): #Line 1 of main.py print x #Line 2 of main.py " and the resulting error would be:" File "pathToFile\main.py", line 1, in for x in range(5): IndexError: array index out of range " I also have 32-bit python 3.6 installed, but the default for opening '.py' files is python 2.7 This error happens on custom made generators too, but never in the interactive shell. ---------- components: Windows files: pythonError.png messages: 287473 nosy: Justin McNiel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 'for' loop not automatically breaking (index error on line of loop header) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file46616/pythonError.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 22:05:07 2017 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 10 Feb 2017 03:05:07 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) In-Reply-To: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> Message-ID: <1486695907.87.0.851563367754.issue29518@psf.upfronthosting.co.za> Josh Rosenberg added the comment: You're going to need to actually provide the source file here. This makes no sense as is. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 23:35:06 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Feb 2017 04:35:06 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing Message-ID: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> New submission from ?ukasz Langa: Antoine, #28427 introduces a regression. When used with multiprocessing, the WeakValueDictionary in `multiprocessing.util._afterfork_registry` causes the `remove()` to be invoked during `atexit` and then `sys.meta_path` is None, lots of things is None, including the global `_remove_dead_weakref`. In effect, I'm getting spew like this: Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable When debugged, this 'NoneType' is `_remove_dead_weakref` (weakref.py:117). I'm working on a smaller repro, unfortunately this happens as part of a rather large multiprocessing app so this might take a while. Just wanted to let you know, maybe you'll know right away what the problem is. ---------- assignee: pitrou components: Library (Lib) keywords: 3.5regression, 3.6regression messages: 287475 nosy: lukasz.langa, pitrou priority: normal severity: normal status: open title: weakref spewing exceptions during finalization when combined with multiprocessing type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 00:12:07 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 10 Feb 2017 05:12:07 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486703527.42.0.187684934981.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: > I'm not sure about the change on PyObject_CallMethod*() only for empty format string. There are many place using _PyObject_CallMethodId() to call method without args. Maybe, we should recommend to use _PyObject_CallMethodIdObjArgs() when no arguments, and replace all caller in cpython? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 02:25:57 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 10 Feb 2017 07:25:57 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1486711557.34.0.305401002345.issue29515@psf.upfronthosting.co.za> Eryk Sun added the comment: Unless someone has a better (more automated) way to handle the Winsock IPPROTO enum, I suggest we either special-case the individual tests for MS_WINDOWS when we know that Winsock defines the value; or just define macros for the values in the enum: #ifdef MS_WINDOWS /* Macros based on the IPPROTO enum. */ #define IPPROTO_ICMP IPPROTO_ICMP #define IPPROTO_IGMP IPPROTO_IGMP #define IPPROTO_GGP IPPROTO_GGP #define IPPROTO_TCP IPPROTO_TCP #define IPPROTO_PUP IPPROTO_PUP #define IPPROTO_UDP IPPROTO_UDP #define IPPROTO_IDP IPPROTO_IDP #define IPPROTO_ND IPPROTO_ND #define IPPROTO_RAW IPPROTO_RAW #define IPPROTO_MAX IPPROTO_MAX #if (_WIN32_WINNT >= 0x0501) #define IPPROTO_HOPOPTS IPPROTO_HOPOPTS #define IPPROTO_IPV4 IPPROTO_IPV4 #define IPPROTO_IPV6 IPPROTO_IPV6 #define IPPROTO_ROUTING IPPROTO_ROUTING #define IPPROTO_FRAGMENT IPPROTO_FRAGMENT #define IPPROTO_ESP IPPROTO_ESP #define IPPROTO_AH IPPROTO_AH #define IPPROTO_ICMPV6 IPPROTO_ICMPV6 #define IPPROTO_NONE IPPROTO_NONE #define IPPROTO_DSTOPTS IPPROTO_DSTOPTS #define IPPROTO_ICLFXBM IPPROTO_ICLFXBM #endif /* (_WIN32_WINNT >= 0x0501) */ #if (_WIN32_WINNT >= 0x0600) #define IPPROTO_ST IPPROTO_ST #define IPPROTO_CBT IPPROTO_CBT #define IPPROTO_EGP IPPROTO_EGP #define IPPROTO_IGP IPPROTO_IGP #define IPPROTO_RDP IPPROTO_RDP #define IPPROTO_PIM IPPROTO_PIM #define IPPROTO_PGM IPPROTO_PGM #define IPPROTO_L2TP IPPROTO_L2TP #define IPPROTO_SCTP IPPROTO_SCTP #endif /* (_WIN32_WINNT >= 0x0600) */ #endif /* MS_WINDOWS */ or call PyModule_AddIntConstant(m, "IPPROTO_ICMP", IPPROTO_ICMP) and so on for each enum value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 02:29:46 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 07:29:46 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template Message-ID: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I build the documentation on the current CPython code, there is a deprecation warning on the console. ===== (beginning of output) % make html sphinx-build -b html -d build/doctrees -D latex_elements.papersize= . build/html Running Sphinx v1.5.2 ...[omitted irrelevant output]... generating indices... genindex py-modindex writing additional pages... download index WARNING: Now base template defindex.html is deprecated. search opensearch copying images... [100%] faq/python-video-icon.png ...[omitted irrelevant output]... build succeeded, 1 warning. Build finished. The HTML pages are in build/html. ===== (end of output) This is observed when building documentation from branch master, commit b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d . The build command is "cd Doc; make html". There are other warnings in the output, and I'm dealing with them in a different issue (number to follow). They are easier to fix than this one. Diagnosis: Sphinx config file Doc/conf.py:72 invokes the building of template 'indexcontent.html'. Doc/tools/templates/indexcontent.html:1 contains Sphinx directive `{% extends "defindex.html" %}`. This invokes file sphinx/sphinx/themes/basic/defindex.html [See https://github.com/sphinx-doc/sphinx/blob/8ecd7ff08249739bbc6d900527fe9306592456ab/sphinx/themes/basic/defindex.html ]. Sure enough, it issues a deprecation warning. {{ warn('Now base template defindex.html is deprecated.') }} There's a story behind this file. Sphinx issue 2986 (https://github.com/sphinx-doc/sphinx/issues/2986) says that this is a very old file, from about the 0.2 version of Sphinx. It wasn't HTML 5 compatible, so they declared it obsolete and threw it out. Well, that lasted only about two weeks. It became apparent that not only Python's docs, but thousands of other projects, seem to rely on it. So, defindex.html was restored, but with the deprecation warning. Then, on 1. January 2017, Sphinx deleted defindex.html again. (See https://github.com/sphinx-doc/sphinx/commit/45d3f2e8b279efa9d42068d4109cd97eb3f2d899 ). I can only imagine that, once this change makes it into the public release of Sphinx, Python's documentation, and that of thousands of projects, will break again. So, it seems like a good idea to proactively remove the dependence on this Sphinx file, before that new Sphinx release comes out. Options: 1. Copy the Sphinx defindex.html file into our source tree, and keep using it. Plus points: it's simple and easy. Minus points: the Sphinx licence terms may not permit this. And, it is not HTML5 compatible, which we might care about. 2. Identify the template which Sphinx intends as a successor to defindex.html, and switch to using that. I've done a bit of searching, and couldn't find out which template that might be. 3. Reimplement our Doc/tools/templates/indexcontent.html to rely on supported Sphinx template, and replace whatever intermediate content we were using from defindex.html with freshly-written code. I don't have a solution in mind for this issue. I just want to get it in the bug list, so we know about it. ---------- assignee: docs at python components: Documentation messages: 287478 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Documentation uses deprecated "defindex.html" Sphinx template type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 02:36:31 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Feb 2017 07:36:31 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486712191.67.0.55971781502.issue29519@psf.upfronthosting.co.za> ?ukasz Langa added the comment: I have a pretty minimal repro. You'll have to download both `mod1.py` and `mod2.py` and execute `python3.6 mod1.py`. You'll see: Exception ignored in: .remove at 0x7fcb56b09400> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable I can reproduce this both on CentOS 7 and macOS Sierra. I don't quite understand what makes this particular combination of instructions in the modules trigger the problem, I'd appreciate some explanation. AFAICT any additional simplification to the two modules makes it stop producing the spew. Note: the spew doesn't happen with 3.6.0, only with master because it's directly caused by the missing global after the change in #28427. ---------- Added file: http://bugs.python.org/file46617/mod1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 02:36:41 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Feb 2017 07:36:41 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486712201.9.0.0545911844938.issue29519@psf.upfronthosting.co.za> Changes by ?ukasz Langa : Added file: http://bugs.python.org/file46618/mod2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:14:19 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 08:14:19 +0000 Subject: [issue29521] Minor warning messages when compiling documentation Message-ID: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I build the documentation on the current CPython code, there are various error and warning messages on the console. Here's what my build output looks like. I've marked the messages I'm concerned about with a numbered >>0>> prefix. ===== (beginning of output) % make html sphinx-build -b html -d build/doctrees -D latex_paper_size= . build/html Running Sphinx v1.5.2 loading pickled environment... done >>1>> WARNING: latex_preamble is deprecated. Use latex_elements['preamble'] instead. >>2>> WARNING: latex_paper_size is deprecated. Use latex_elements['papersize'] instead. building [mo]: targets for 0 po files that are out of date building [html]: targets for 466 source files that are out of date updating environment: 0 added, 1 changed, 0 removed reading sources... [100%] whatsnew/changelog >>3>> ../../Misc/NEWS:659: WARNING: Inline emphasis start-string without end-string. >>4>> ../../Misc/NEWS:659: WARNING: Inline emphasis start-string without end-string. looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done writing output... [100%] whatsnew/index >>5>> /Users/jdlh/workspace/cpython_github/Doc/faq/windows.rst:303: WARNING: unknown option: -t generating indices... genindex py-modindex writing additional pages... download index >>6>> WARNING: Now base template defindex.html is deprecated. search opensearch copying images... [100%] using/win_installer.png copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 6 warnings. Build finished. The HTML pages are in build/html. ===== (end of output) This is observed when building documentation from branch master, commit b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d . The build command is "cd Doc; make html". Warning >>6>> is the subject of http://bugs.python.org/issue29520 . It's harder to fix, and I won't address it here. The other five warnings are pretty easy to fix. Warnings >>1>>, >>2>> are Sphinx warnings about names used in Doc/conf.py , namely `latex_preamble` and `latex_paper_size`. There are straightforward changes to build a dict latex_elements{}, with keys 'preamble' and 'papersize'. It turns out that makefiles Doc/Makefile and Doc/make.bat also referred to `latex_paper_size`. Those references are rewritten as `latex_elements.papersize`, per Sphinx syntax for external names. Warnings >>3>>, >>4>> are Sphinx warnings about the text, in Misc/NEWS:661, ```is now of type "const char *" rather of "char *".``` Put a backslash in front of the '*', and the warning disappears. Warning >>5>> is a Sphinx warning about this text, in Doc/faq/windows.rst:303: If you suspect mixed tabs and spaces are causing problems in leading whitespace, run Python with the :option:`-t` switch or run ``Tools/Scripts/tabnanny.py`` to check a directory tree in batch mode. The notation :option:`-t` seems to need a corresponding ``.. cmdoption:: -t `` entry, perhaps in the same file. There is no such entry. It turns out that the -t option has no function in Python 3.6, maybe in all of 3.x. Python swallows the option but does nothing. Thus, instead of trying to make the reference to '-t' work, I decided to cut the whole phrase. This paragraph now reads, If you suspect mixed tabs and spaces are causing problems in leading whitespace, run ``Tools/Scripts/tabnanny.py`` to check a directory tree in batch mode. I am making a Pull Request with these fixes. I will shortly link to it from here. ---------- assignee: docs at python components: Documentation messages: 287480 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Minor warning messages when compiling documentation type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:19:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 10 Feb 2017 08:19:54 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486714793.99.0.825509504395.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: performance benefit is small. https://gist.github.com/methane/32fe57cd4aaac1c5c37f75cbbfbe7562 ---------- Added file: http://bugs.python.org/file46619/callmethod3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:20:41 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 08:20:41 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <20170210082038.125603.22144.CE410D3A@psf.io> Roundup Robot added the comment: New changeset 2cb530243943 by ?ukasz Langa in branch '3.5': Fix #29519: weakref spewing exceptions during interp finalization https://hg.python.org/cpython/rev/2cb530243943 New changeset c5267272e66a by ?ukasz Langa in branch '3.6': Merge 3.5 (fix #29519) https://hg.python.org/cpython/rev/c5267272e66a New changeset e91ec62da088 by ?ukasz Langa in branch 'default': Merge 3.6 (fix #29519) https://hg.python.org/cpython/rev/e91ec62da088 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:22:49 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Feb 2017 08:22:49 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486714969.37.0.394014691789.issue29519@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Given that the weakref behavior during shutdown with the repro was identical in 3.6.0, as well as in 3.5.2 and earlier, I patched this by binding the name to a local, therefore making it usable also during finalization. ---------- assignee: pitrou -> lukasz.langa resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:48:09 2017 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Feb 2017 08:48:09 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486716489.89.0.453117860742.issue29521@psf.upfronthosting.co.za> Martin Panter added the comment: Jim, regarding Doc/faq/windows.rst, this warning lead me to open Issue 29387. We already have discussed a patch for that, and I think it is ready to commit (when it gets to the top of my list, if nobody else beats me to it). Regarding Misc/NEWS, I think I was going to use ``backticks`` as quotes (Slightly more palatable than backslashes; this file is meant to be readable as plain text as well.) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:48:28 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 08:48:28 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1486716508.67.0.326934409809.issue29520@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: The other warnings in the "make html" output are the subject of http://bugs.python.org/issue29521 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:50:10 2017 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Feb 2017 08:50:10 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486716610.12.0.00461737791956.issue29521@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +Tabs vs spaces FAQ out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:55:23 2017 From: report at bugs.python.org (nico) Date: Fri, 10 Feb 2017 08:55:23 +0000 Subject: [issue29522] PyLong_AsDouble Behaviour is Weird Message-ID: <1486716923.02.0.912981013362.issue29522@psf.upfronthosting.co.za> New submission from nico: I'm using the pre-installed version of Python 2.7.12 on Ubuntu 16.04. Pretty straight forward error the following code: PyObject * intobj = PyInt_FromLong(10); double d1 = (double)PyLong_AsLong(intobj); double d2 = PyLong_AsDouble(intobj); printf("Should be the same: %f vs %f", d1, d2); Does not display the same number for both double since `PyLong_AsDouble` raises the error, SystemError: ../Objects/longobject.c:2336: bad argument to internal function and returns -1.0 instead of 10.0. ---------- components: Build messages: 287486 nosy: nico priority: normal severity: normal status: open title: PyLong_AsDouble Behaviour is Weird versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:00:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 09:00:24 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486717224.36.0.125325218392.issue29519@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6c961c5a5396ef125dbbc47c060272a5d12c1646 by ?ukasz Langa in branch 'master': Fix #29519: weakref spewing exceptions during interp finalization https://github.com/python/cpython/commit/6c961c5a5396ef125dbbc47c060272a5d12c1646 New changeset 39279a07e8fc7bc14dcb948d970c12dbbf65ff40 by ?ukasz Langa in branch 'master': Merge 3.5 (fix #29519) https://github.com/python/cpython/commit/39279a07e8fc7bc14dcb948d970c12dbbf65ff40 New changeset 8d6fcedf53048ff53cde91f7a55c1583456fa15e by ?ukasz Langa in branch 'master': Merge 3.6 (fix #29519) https://github.com/python/cpython/commit/8d6fcedf53048ff53cde91f7a55c1583456fa15e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:00:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 09:00:27 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486717227.34.0.496993356886.issue29519@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6c961c5a5396ef125dbbc47c060272a5d12c1646 by ?ukasz Langa in branch '3.5': Fix #29519: weakref spewing exceptions during interp finalization https://github.com/python/cpython/commit/6c961c5a5396ef125dbbc47c060272a5d12c1646 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 09:00:29 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1486717229.44.0.766021641292.issue29519@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 6c961c5a5396ef125dbbc47c060272a5d12c1646 by ?ukasz Langa in branch '3.6': Fix #29519: weakref spewing exceptions during interp finalization https://github.com/python/cpython/commit/6c961c5a5396ef125dbbc47c060272a5d12c1646 New changeset 39279a07e8fc7bc14dcb948d970c12dbbf65ff40 by ?ukasz Langa in branch '3.6': Merge 3.5 (fix #29519) https://github.com/python/cpython/commit/39279a07e8fc7bc14dcb948d970c12dbbf65ff40 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:00:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 09:00:45 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486717245.97.0.328292928336.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: >> I'm not sure about the change on PyObject_CallMethod*() only for empty format string. > > There are many place using _PyObject_CallMethodId() to call method without args. I'm more interested by an optimization PyObject_CallMethod*() for any number of arguments, as done in typeobject.c ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:09:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Feb 2017 09:09:15 +0000 Subject: [issue29522] PyLong_AsDouble Behaviour is Weird In-Reply-To: <1486716923.02.0.912981013362.issue29522@psf.upfronthosting.co.za> Message-ID: <1486717755.13.0.834655765512.issue29522@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is incorrect use of PyLong_AsDouble(). It should be used with a long object, but you use it with an int object. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:20:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 09:20:04 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486718404.33.0.995058692229.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: > performance benefit is small. > https://gist.github.com/methane/32fe57cd4aaac1c5c37f75cbbfbe7562 Are you using PGO+LTO compilation? Without PGO, the noise of code placement can be too high. In your "perf stat" comparisons, I see that "insn per cycle" is lower with the patch, which sounds like a code placement issue like a performance issue with the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:25:38 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 10 Feb 2017 09:25:38 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1486718737.99.0.359591867073.issue23404@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Just tried boot-flag.patch with https://github.com/python/cpython/commit/16e07881bd3867d471dd0a25c5117672b65c90ee. Doesn't work out-of-box: #./Programs/_freeze_importlib \ ./Lib/importlib/_bootstrap.py Python/importlib.h /bin/sh: line 1: ./Lib/importlib/_bootstrap.py: Permission denied make: *** [Makefile:749: Python/importlib.h] Error 126 My fix is: merge the two lines into a single one. See my attached patch. By the way, the BOOT hack is quite similar to GENERATED_COMMENT in introduced in issue27641. Maybe they can merge? My environment: * Arch Linux x86_64 * /bin/sh symlinks to bash, which is 4.4.12 * GNU Make 4.2.1 ---------- nosy: +Chi Hsuan Yen Added file: http://bugs.python.org/file46620/boot-flag.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:35:02 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 09:35:02 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <20170210093459.106871.49074.A8EA955A@psf.io> Roundup Robot added the comment: New changeset 383c0238b5b0 by Victor Stinner in branch '3.6': Fix datetime.fromtimestamp(): check bounds https://hg.python.org/cpython/rev/383c0238b5b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:36:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 09:36:06 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486719366.41.0.58508805569.issue29100@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed timestamp_limits-2.patch. Thanks for the bug report Jordon Phillips, thanks for the review Serhiy Storshaka. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:38:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 10 Feb 2017 09:38:15 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486719495.13.0.33028115516.issue29507@psf.upfronthosting.co.za> INADA Naoki added the comment: Yes, I used --enable-optimization this time. But my patch is not good for branch prediction of my CPU in this time. I'm willing Object/call.c solves such placement issue. BTW, since benefit of GetMethod is small, how about this? * Add _PyMethod_FastCallKeywords * Call it from _PyObject_FastCall* _PyObject_FastCall* can use FASTCALL C function and method (PyCFunction), and Python function (PyFunction). Python method (PyMethod) is last common callable PyObject_FastCall* can't use FASTCALL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:39:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 09:39:45 +0000 Subject: [issue27744] Add AF_ALG (Linux Kernel crypto) to socket module In-Reply-To: <1470997290.77.0.995104201782.issue27744@psf.upfronthosting.co.za> Message-ID: <1486719585.33.0.847835596.issue27744@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the status of this issue? test_aead_aes_gcm() fails on my Fedora 25 (Python: default branch). haypo at selma$ cat /etc/fedora-release Fedora release 25 (Twenty Five) haypo at selma$ uname -r 4.9.5-200.fc25.x86_64 test test_socket failed -- Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 556, in wrapper return func(*args, **kw) File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line 5515, in test_aead_aes_gcm res = op.recv(assoclen + len(plain) + taglen) OSError: [Errno 22] Invalid argument ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:42:54 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 09:42:54 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486719774.75.0.857480954557.issue29521@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Thanks, Martin, for your suggestions. In Misc/NEWS, I've respelled the ``char *`` as you suggested. In faq/windows.rst, I've used your wording from the discussion in http://bugs.python.org/issue29387 . Pull Request 76 https://github.com/python/cpython/pull/76 ready for review. ---------- pull_requests: +27 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 04:46:48 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 09:46:48 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486720008.91.0.164549007623.issue29387@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I just created Pull Request 76 https://github.com/python/cpython/pull/76 to address http://bugs.python.org/issue29521 . In faq/windows.rst, I've used your wording from the discussion in of this bug. I may have address this issue completely, in fact. I did not do the more careful "testing all versions patched" which Terry suggested. ---------- nosy: +JDLH _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 10:00:22 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486720822.11.0.244148016655.issue29100@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 5b804b2fb0eaa2bacb4afcfe4cfa85b31475e87f by Victor Stinner in branch '3.6': Fix datetime.fromtimestamp(): check bounds https://github.com/python/cpython/commit/5b804b2fb0eaa2bacb4afcfe4cfa85b31475e87f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:00:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 10:00:23 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486720823.96.0.859831535407.issue29100@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset 5b804b2fb0eaa2bacb4afcfe4cfa85b31475e87f by Victor Stinner in branch 'master': Fix datetime.fromtimestamp(): check bounds https://github.com/python/cpython/commit/5b804b2fb0eaa2bacb4afcfe4cfa85b31475e87f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:06:41 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 10 Feb 2017 10:06:41 +0000 Subject: [issue27744] Add AF_ALG (Linux Kernel crypto) to socket module In-Reply-To: <1470997290.77.0.995104201782.issue27744@psf.upfronthosting.co.za> Message-ID: <1486721201.53.0.625206674182.issue27744@psf.upfronthosting.co.za> Christian Heimes added the comment: I'll look into the matter and push a fix after the migration to github today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:08:26 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 10 Feb 2017 10:08:26 +0000 Subject: [issue27744] Add AF_ALG (Linux Kernel crypto) to socket module In-Reply-To: <1470997290.77.0.995104201782.issue27744@psf.upfronthosting.co.za> Message-ID: <1486721305.99.0.312962632354.issue27744@psf.upfronthosting.co.za> Christian Heimes added the comment: By the way problem with AES-GCM is tracked in https://bugs.python.org/issue29324 . It was caused in a Kernel API change. Jan has provided a fix. I need to find some spare time to dig into Kernel sources and verify the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:14:21 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 10 Feb 2017 10:14:21 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies Message-ID: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> New submission from Charalampos Stratakis: The latest versions of setuptools stopped bundling its dependencies and instead starting requiring them [0]. This seems to break virtualenvs as those dependencies are not bundled with python. In order to reproduce it, replace the setuptools-28.8.0-py2.py3-none-any.whl with setuptools-34.1.1-py2.py3-none-any.whl at Lib/ensurepip/_bundled/ and change _SETUPTOOLS_VERSION = "28.8.0" to _SETUPTOOLS_VERSION = "34.1.1" Then configure, make and make install: This message will appear first: Could not find a version that satisfies the requirement packaging>=16.8 (from setuptools) (from versions: ) No matching distribution found for packaging>=16.8 (from setuptools) Which is one of the new dependencies. Then: ./python3.7 -m test test_venv -v Where the EnsurePipTest will fail due to this assertion [1] at the do_test_with_pip test case with "No module named pip\n' != ''". One way to fix this would be to bundle the other wheels with python, not sure if that would be the ideal approach though. Attaching a patch for Lib/ensurepip/__init__.py. With this patch and adding the other wheels [2][3][4][5] at the _bundled directory fixes the issue. [0] https://github.com/pypa/setuptools/blob/master/CHANGES.rst#v3400 [1] https://github.com/python/cpython/blob/master/Lib/test/test_venv.py#L384 [2] https://pypi.python.org/pypi/six/1.10.0 [3] https://pypi.python.org/pypi/appdirs/1.4.0 [4] https://pypi.python.org/pypi/packaging/16.8 [5] https://pypi.python.org/pypi/pyparsing/2.1.10 ---------- components: Distutils, Library (Lib) files: bundle-setuptools-dependencies.patch keywords: patch messages: 287504 nosy: cstratak, dstufft, eric.araujo priority: normal severity: normal status: open title: latest setuptools breaks virtualenvs due to unbundling dependencies versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46621/bundle-setuptools-dependencies.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:27:00 2017 From: report at bugs.python.org (Marco Buttu) Date: Fri, 10 Feb 2017 10:27:00 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486722420.97.0.348314244004.issue29387@psf.upfronthosting.co.za> Marco Buttu added the comment: Thanks Jim. I tested thise exec() in Py2.7 and Py3 (3.5 - 3.7): exec("if True:\n" + " "*width + "1\n" + "\t2\n") * width == 0 raises a IndentationError both in Py2 and Py3 * width in range(1, 8) raises an IndentationError in Py2 and TabError in Py3 * width == 8 is OK in Py2, and raises a TabError in Python 3 * width > 8 is the same as width == 0 I think the most important case, is when width==4 or width==8, because they are the usual widths of the TAB. In these cases, the editor will show a "correct" level of indentation, but Python will raise an exception and a beginner user will not understand the reason. IMO is here that Lib/tabnanny.py really comes in handy. And in these cases (width== 4 or 8), Python 3 raises a TabError, but if we write in the doc that it raises an IndentationError, IMO the user perhaps will think there is an error in the doc, because IMO on the average he/she will not spot that TabError is a subclass of IndentationError. Thats why I think it is better to not specity the exeption type. Anyway, it is really a minor issue, and currently is also related to other issues, so there is no need to discuss to much for such a detail. Finally, the wording in the pull request is good enough for me :) Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:44:44 2017 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 10 Feb 2017 10:44:44 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1486723484.94.0.923283192113.issue27286@psf.upfronthosting.co.za> Mark Dickinson added the comment: It's difficult to track down which versions of Python 3.5.x the bytecode change is in because the Misc/NEWS entry has vanished, apparently in this merge commit: https://github.com/python/cpython/commit/aa0f9d8f26bbe63adcbce950aaadc844d996e7ac ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:45:51 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 10:45:51 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <20170210104548.106538.92141.63340781@psf.io> Roundup Robot added the comment: New changeset 1c6b87b07586 by Victor Stinner in branch '3.6': Fix test_datetime on system with 32-bit time_t https://hg.python.org/cpython/rev/1c6b87b07586 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:45:51 2017 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Feb 2017 10:45:51 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1486723551.51.0.697196952854.issue27286@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry about that! It's almost like manually updating Misc/NEWS is a bad design :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:50:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 10:50:09 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486723809.34.0.0723760498613.issue29324@psf.upfronthosting.co.za> STINNER Victor added the comment: I confirm that test_socket pass with test_socket_aead_kernel49.patch on my Fedora 25 (kernel 4.9.5-200.fc25.x86_64). I would be nice to fix test_socket which is currently broken ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:53:03 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 10 Feb 2017 10:53:03 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) In-Reply-To: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> Message-ID: <1486723983.47.0.595967105972.issue29518@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I agree with Josh: the exception you are giving doesn't seem possible with the code snippet shown. Please COPY AND PASTE (not a screen shot) the text of the entire traceback, starting with the line "Traceback..." I suspect that you may have shadowed the built-in range or len object with some custom object, but I could be completely wrong. But without more information, we cannot tell what is going on. It would be really useful if you could provide a minimal (short as possible) script that reproduces the problem. And please confirm that you can reproduce the problem in the regular CPython interpreter, without using any third-party IDEs. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:54:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 10:54:17 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486724057.68.0.964084840276.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: curses_temporaryfile.patch: Call tempfile.TemporaryFile in getwin() and putwin() to create the temporary file in a more portable and safer manner. The curses library requires a FILE* object, but TemporaryFile.close() must be called to remove the temporary file. So I chose to duplicate the file descriptor, so we can close fclose() and tmpfile.close(). I chose to modify the C rather rather than trying to implement a window class in Python, because the C window class is part of a "PyCurses_API", and many C functions instanciate the C class. ---------- Added file: http://bugs.python.org/file46622/curses_temporaryfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:58:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 10:58:13 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486724293.9.0.935199605891.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: curses_fix_window_class_name.patch: Fix the name of the C window class: "_curses.window", not "_curses.curses window" (with a space in the class name) !? The following example current displays : --- import curses w = curses.initscr() curses.endwin() print(type(w)) --- ---------- Added file: http://bugs.python.org/file46623/curses_fix_window_class_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:00:22 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 11:00:22 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486724422.88.0.947231691235.issue29100@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset a88f9614c672c3369cf03cdf51d012a42ae5665f by Victor Stinner in branch 'master': Fix test_datetime on system with 32-bit time_t https://github.com/python/cpython/commit/a88f9614c672c3369cf03cdf51d012a42ae5665f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:10:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Feb 2017 11:10:36 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486725036.32.0.201142173366.issue29176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Check that pickling/unpickling the windows object doesn't cause crash or undefined behaviour. Currently the pickling fails because the name of the class is not true name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:13:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 11:13:19 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1486725199.28.0.374099556962.issue27640@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm in favor of allowing to build a "subset" of Python. Not only it makes sense for embedded devices, but in many cases it's even not possible to do otherwise: "full" Python is too big for small devices. But I would prefer to see a public discussion on python-dev before going into this direction. The previous attempt failed because some core developers were opposed to support officially a "subset of Python". But since this previous discussion (two years ago? longer?), MicroPython became popular, and this implementation of Python has a small subset of the stdlib (but it supports asyncio ;-)) Maybe it's time for a new attempt :-) Oh, and the meanwhile we also made progress on the Android port, which is now an important platform. In short, I would like to official support Python subsets ;-) At least, add options for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:24:20 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 10 Feb 2017 11:24:20 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1486725860.5.0.440560153718.issue27640@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:32:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 11:32:33 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486726353.86.0.793827956511.issue20210@psf.upfronthosting.co.za> STINNER Victor added the comment: Antoine Pitrou: "That's not really the point. The question is why we should have to maintain this ourselves. It is easy for interested people to maintain their own forks, especially when *removing* stuff." It's painful to have to maintain downstream patches. Supporting this feature would make Python usable on more platforms. Marc-Andre Lemburg: "it is possible to compress Python down to just a few MBs: (...)" Right, that "a few MBs" can be too big on small devices, and it has a price on runtime performance, at least on the boot duration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:33:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 11:33:37 +0000 Subject: [issue29300] Modify the _struct module to use FASTCALL and Argument Clinic In-Reply-To: <1484670705.59.0.0193443230555.issue29300@psf.upfronthosting.co.za> Message-ID: <1486726417.67.0.539899428126.issue29300@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not aware of any pending issues, buildbots are happy, I'm happy, I close the issue :-) Don't hesitate to reopen it if I missed something. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:35:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Feb 2017 11:35:24 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486726524.16.0.16909492234.issue20210@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It's painful to have to maintain downstream patches. Supporting this feature would make Python usable on more platforms. Who volunteers to support it? It's a PITA to maintain the configure script and setup.py, and adding options only makes it more painful. This kind of niche features needs some dedicated maintainer so that other core developers don't have to bother with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:38:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 11:38:32 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <20170210113829.107056.17068.B6471025@psf.io> Roundup Robot added the comment: New changeset 1555e7776321 by Victor Stinner in branch '3.6': Fix test_datetime on Windows https://hg.python.org/cpython/rev/1555e7776321 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:46:06 2017 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Feb 2017 11:46:06 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486727166.86.0.176475104893.issue29523@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:46:42 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 10 Feb 2017 11:46:42 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486727202.86.0.607512538799.issue20210@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I'm still -1 on the approach taken by the OP, but +1 on Martin's approach of making such configurations more easily possible via Modules/Setup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:54:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 11:54:48 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486727688.91.0.646175854497.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "Check that pickling/unpickling the windows object doesn't cause crash or undefined behaviour. Currently the pickling fails because the name of the class is not true name." Ah, good idea. I tested with curses_fix_window_class_name.patch: window objects cannot be pickled. Hopefully! IMHO it doesn't make sense to serialize such "live" object. haypo at selma$ cat > x.py import curses w = curses.initscr() curses.endwin() print(type(w)) ^D haypo at selma$ ./python -i x.py >>> import pickle >>> pickle.dumps(w) Traceback (most recent call last): File "", line 1, in TypeError: can't pickle _curses.window objects ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 06:59:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 11:59:32 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486727972.26.0.126524804042.issue20210@psf.upfronthosting.co.za> STINNER Victor added the comment: Antoine Pitrou: " Who volunteers to support it? It's a PITA to maintain the configure script and setup.py, and adding options only makes it more painful. This kind of niche features needs some dedicated maintainer so that other core developers don't have to bother with it." Oh, I forgot to put more context in my previous comment. Xavier de Gaye opened the issue #27640 "add the '--disable-test-suite' option to configure". He is a core developer working on porting CPython to Android. Xavier is the requested dedicated maintainer ;-) ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:00:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 12:00:29 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486728029.15.0.131326719334.issue29100@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset be363764cad68ad7b608ceed837cc01c2c3b4efc by Victor Stinner in branch '3.6': Fix test_datetime on Windows https://github.com/python/cpython/commit/be363764cad68ad7b608ceed837cc01c2c3b4efc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:00:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 12:00:31 +0000 Subject: [issue29100] datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6 In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> Message-ID: <1486728031.08.0.808654475982.issue29100@psf.upfronthosting.co.za> Roundup Robot added the comment: New changeset be363764cad68ad7b608ceed837cc01c2c3b4efc by Victor Stinner in branch 'master': Fix test_datetime on Windows https://github.com/python/cpython/commit/be363764cad68ad7b608ceed837cc01c2c3b4efc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:00:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 12:00:51 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1486728051.82.0.865687069488.issue27640@psf.upfronthosting.co.za> STINNER Victor added the comment: > But I would prefer to see a public discussion on python-dev before going into this direction. Ah, the discussion restarted on the other issue: http://bugs.python.org/issue20210#msg287516 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:41:27 2017 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Feb 2017 12:41:27 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1486730487.38.0.21450335776.issue27286@psf.upfronthosting.co.za> Martin Panter added the comment: Diff showing what changed relative to the main 3.5 branch when merging in the 3.5.2 release: . There are four news entries deleted from the 3.5.2rc1 section. Ideally they should have been moved to the 3.5.3rc1 section instead, because they were added after 3.5.2rc1 was branched, but before the 3.5.3rc1 heading appeared. Also, there were some minor corrections of mine and Victor?s that were undone. And I would suggest to restrict merge commits to changes that are already in at least one of the branches being merged. The edit to ?byte-like? was not present in either of the branches being merged. In Git I think they call these changes ?evil merges?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:42:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 12:42:39 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file Message-ID: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> New submission from STINNER Victor: I propose to move functions to call objects into a new Objects/call.c file. It should easy maintainance since all moved functions are inter-dependent: it becomes easier to keep them consistent since they are in the same fle. I also have a small "hope" that moving "call" functions in the same file should help the compiler to produce more efficient code and that we will get a better "code placement". Closer functions should enhance the usage of the CPU instruction cache. I don't know exactly how to measure the effect of code placement. My plan is to push the change, and then watch speed.python.org timeline. Attached call.patch: * Add Objects/call.c file * Move all functions to call objects in a new Objects/call.c file. * Rename fast_function() to _PyFunction_FastCallKeywords(). * Copy null_error() from Objects/abstract.c * Inline type_error() in call.c to not have to copy it, it was only called once. * Export _PyEval_EvalCodeWithName() since it is now called from call.c. The change comes from the issue #29465. Copy of my msg287257 from this issue: --- Serhiy Storchaka added the comment: > Isn't the Python directory more appropriate place for call.c? I moved code from other .c files in Objects/, so for me it seems more natural to add the code in Objects/ as well. It seems like most of the code in Python/ is not "aware" of types defined in Objects/. But I don't have a strong opinion on the right directory. Objects/call.c is 1500 lines long. IMHO the code became big enough to justify to move it to a new file ;-) --- Once we have a call.c file, we may try other changes to enhance the code placement: * Add "#define PY_LOCAL_AGGRESSIVE" (only used by Visual Studio) * Tag functions with _Py_HOT_FUNCTION: see the issue #28618 for discussion on __attribute__((hot)). The last time I checked, it wasn't enough to fix all "code placement issues". * Reorder functions in call.c: I dislike this idea, IMHO it's too hard to guess ourself what is the best order, and it's likely to produce many commits for little benefit See also the issue #29465: "Add _PyObject_FastCall() to reduce stack consumption. ---------- components: Interpreter Core files: call.patch keywords: patch messages: 287527 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Move functions to call objects into a new Objects/call.c file versions: Python 3.7 Added file: http://bugs.python.org/file46624/call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:47:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 12:47:15 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486730835.07.0.449497148044.issue29524@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #29502 "Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro?": fixing this one should allow to remove fast-paths from ceval.c, since we now already have fast-paths in all "call" functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:54:21 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 12:54:21 +0000 Subject: [issue29507] Use FASTCALL in call_method() to avoid temporary tuple In-Reply-To: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> Message-ID: <1486731261.27.0.35744069313.issue29507@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm willing Object/call.c solves such placement issue. I also *hope* that a call.c file would *help* a little bit, but I'm not sure that it will fix *all* code placement issues. I created the issue #29524 with a patch creating Objects/call.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:10:47 2017 From: report at bugs.python.org (Matthis Thorade) Date: Fri, 10 Feb 2017 13:10:47 +0000 Subject: [issue3955] maybe doctest doesn't understand unicode_literals? In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za> Message-ID: <1486732247.82.0.60608806837.issue3955@psf.upfronthosting.co.za> Matthis Thorade added the comment: I found this bug when trying to write a doctest that passes on Python 3.5 and Python 2.7.9. The following adapted example passes on Python2, but fails on Python3: # -*- coding: utf-8 -*- from __future__ import unicode_literals def f(): """ >>> f() u'xyz' """ return "xyz" if __name__ == "__main__": import doctest doctest.testmod() I think a nice solution could be to add a new directive so that I can use the following def myUnic(): """ This is a small demo that just returns a string. >>> myUnic() u'abc' # doctest: +ALLOW_UNICODE """ return 'abc' I asked the same question here: http://stackoverflow.com/questions/42158733/unicode-literals-and-doctest-in-python-2-7-and-python-3-5 ---------- nosy: +Matthis Thorade _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:15:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Feb 2017 13:15:39 +0000 Subject: [issue29465] Add _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <20170210131536.62551.47201.BF1BDAC8@psf.io> Roundup Robot added the comment: New changeset f23fa1f7b68f by Victor Stinner in branch 'default': Issue #29465: Add Objects/call.c file https://hg.python.org/cpython/rev/f23fa1f7b68f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:28:11 2017 From: report at bugs.python.org (Frak N) Date: Fri, 10 Feb 2017 13:28:11 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) Message-ID: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> New submission from Frak N: I used to have an older version of python 2.7 that has worked for years. I just upgraded to 2.7.13 for Windows, 32 bit and now, I can't get the interpreter to run from the command line. It just returns to the DOS prompt. c:\Python27>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. c:\Python27>python PC: OS: Windows 7 - 64 bit (I am intentionally using the 32bit of python) Processor: AMD PhenomII 975 Processor. 3.6GHz RAM: 16GB ---------- components: Windows messages: 287532 nosy: Frak N, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 2.7.13 for Windows broken (from prompt) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:42:23 2017 From: report at bugs.python.org (Tim Golden) Date: Fri, 10 Feb 2017 13:42:23 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <3347e13a-d6f0-15fe-70a4-c3d82d01cc71@timgolden.me.uk> Tim Golden added the comment: Although I don't remember seeing a crash out as quick as this, common causes for this kind of thing are to do with environment variables pointing to still-existing or part-existing installations. Can you try: set PY from a command prompt, please, to see if any Python-related env vars are present. (Typically PYTHONHOME is the culprit) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:45:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Feb 2017 13:45:32 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486734332.47.0.67520091015.issue20210@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, thanks for clarifying! That eliminates my objection, if there's a tacit agreement that the functionality can be broken by mistake and it's the dedicated maintainer (Xavier or someone else)'s job to repair it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:47:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 13:47:56 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486734476.78.0.680116453519.issue29525@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:58:45 2017 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 10 Feb 2017 13:58:45 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486735125.46.0.492027847796.issue29523@psf.upfronthosting.co.za> Jason R. Coombs added the comment: This approach, bundling the necessary dependencies to install setuptools, seems like exactly the right thing to do, assuming that ensurepip should install setuptools at all, and I don't want to challenge that assumption here. Looking at the patch and ensurepip, I wonder if the patch is necessary at all. It looks to me like the `find_links` declaration should be sufficient to allow a `pip install setuptools` to succeed and install its dependencies as long as they're bundled. @cstratak, can you test a less aggressive approach that merely bumps the dependency on setuptools and bundles the dependencies? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:01:35 2017 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 10 Feb 2017 14:01:35 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486735295.25.0.338148058635.issue29523@psf.upfronthosting.co.za> Jason R. Coombs added the comment: For convenience, here's a link to the rendered changelog in the docs, which provides hyperlinks to the relevant issues [0]. [0] https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:07:25 2017 From: report at bugs.python.org (Matthias Klose) Date: Fri, 10 Feb 2017 14:07:25 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1486735645.59.0.379490833324.issue20210@psf.upfronthosting.co.za> Matthias Klose added the comment: I don't see the point of having an option to do that. Will patches for third party projects be submitted as well, to not install the test suite? Or will pip gain such a feature? Note that removing the test suite completely, you'll make the test suites of some third party packages useless in some cases (I had a few bug reports for the Ubuntu packaging when I removed the tests unconditionally), but probably you don't care about these either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:12:15 2017 From: report at bugs.python.org (Donald Stufft) Date: Fri, 10 Feb 2017 14:12:15 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486735935.78.0.56884206203.issue29523@psf.upfronthosting.co.za> Donald Stufft added the comment: I haven't updated the bundled copy of ensurepip yet because of this. Most likely the way this will get resolved is that the PEP 518 PR will land in pip and we will no longer require setuptools to be pre-installed at all and ensurepip will go to only bundling pip itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:13:56 2017 From: report at bugs.python.org (Hugo Prod'homme) Date: Fri, 10 Feb 2017 14:13:56 +0000 Subject: [issue29526] Documenting format() function Message-ID: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> New submission from Hugo Prod'homme: Hello python contributors, this is my first time on python.org and I am coming with a suggestion. The idea is to help people that have to format strings containing numbers of various kinds, I am from the scientific domain but this should help everybody anyway. In the past the strftime was the best way to format numbers in strings (truncating to some digits after point, setting to exponent notation, etc...). To remind the "strf language" one had to use the internet or a document such as this page : http://strftime.org/ Some idea was provided to add this indications in the python docs. http://bugs.python.org/issue9650 Now the format() function has appeared in the python __builtins__ and this is even more adequate to add help about the string formatting, because we can write the "Format Specification Mini-Language" directly inside the docstring of the format.__doc__ . See the paragraph named "7.1.3.1. Format Specification Mini-Language" in the following page : https://docs.python.org/2/library/string.html I emphasize, the interest of this is to allow the user to be reminded of the formatting options without opening another document than his(her) script, to avoid breaking the workflow. I am providing what I think is the minimal material that the docstring should contains within the attached file. I am not really familiar with docstring formatting according to PEP (436?) and someone should help getting this in the right way of writing. Furthermore, a specific syntax is needed within the string in addition to the format() arguments, this should be described. And the reminder about the mini-language should appear clearly as a reminder. These are two supplemental difficulties in comparison with an usual docstring. To anyone thinking something else should be added to the docstring; please add or say it. PS: I think I can start from the matplotlib.pyplot.plot.__doc__ as a template to complete the format.__doc__ but I have some work aside for now. ---------- files: format_docstring_v0.1.txt messages: 287539 nosy: hugo.prodhomme at gmx.fr priority: normal severity: normal status: open title: Documenting format() function type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46625/format_docstring_v0.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:36:58 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 10 Feb 2017 14:36:58 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486737418.78.0.884440921607.issue29525@psf.upfronthosting.co.za> Steve Dower added the comment: Readline is also a common culprit when it's crashing out at the interactive prompt. Try either uninstalling or upgrading any packages that may include a readline module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:43:15 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 10 Feb 2017 14:43:15 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1486737795.58.0.338314392596.issue29515@psf.upfronthosting.co.za> Steve Dower added the comment: We may just want to copy the values from the enum if there are different versions when they were introduced. But if that's not a problem, adding the MS_WINDOWS check is better than defining new macros. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:46:03 2017 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 10 Feb 2017 14:46:03 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486737963.61.0.950094351015.issue29526@psf.upfronthosting.co.za> Eric V. Smith added the comment: Since these codes don't apply to all types, you'll need some words saying what they do apply to. For example, None being the same as "g" is true for int, float, and Decimal; but None is "s" for strings. And, for example, none of the listed codes apply to datetime's. I'm +0 on this if we can get the wording right. ---------- nosy: +eric.smith versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:49:18 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 10 Feb 2017 14:49:18 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486738158.38.0.159113468701.issue29523@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: @jason.coombs Already tried to just bump the setuptools version and bundle the other wheels but the result is still the same ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:59:35 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Feb 2017 14:59:35 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486738775.17.0.428835926971.issue29526@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for wanting to help improve python. I'm not entirely clear on what you are proposing. I *think* you want to add something to the 'format' docstring? As Eric mentioned the 'mini language' depends on the datatype, so it is going to be hard to cram accurate information into a docstring, where the full context of the documentation explanation of how format interacts with data types is missing. We try to keep docstrings as short reminders. In that regard, the format docstring *is* perhaps a bit lacking :) A reminder of the BNF of the minilanguage would also be helpful if we could cram that in somehow. It may just be too complex a topic for a docstring, though. I'm also not clear why you are referring to strftime and numbers in the same sentence. strftime is for date formatting. I certainly don't think it is appropriate to try to jam that complex subtopic into the format docstring :) Maybe you meant 'printf', which % formatting followed fairly closely? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:04:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Feb 2017 15:04:19 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486739059.72.0.128352944654.issue29524@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I like the idea of moving all code related to calling objects in one one file. But this has a drawback. This breaks a history. This makes harder code exploration and merging. I would delay pushing this change until CPython repository be converted to Git. I heard Git better supports moving a code between files. And perhaps it might be easier to do this change by several commits -- separately moving a code from different files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:10:32 2017 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 10 Feb 2017 15:10:32 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486739432.64.0.392076714411.issue29523@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Aah, yes. I see now. Ensure_pip uses _PROJECTS for three purposes: for defining additional_projects, extracting those packages to the tmpdir, and for declaring the installation of those projects. Only that last declaration is unnecessary. This patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:19:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Feb 2017 15:19:58 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486739998.36.0.0857610721998.issue29526@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it would be worth to extend docstrings of __format__ methods of concrete types for including the description of type-specific format specifiers. But the docstring of format() shouldn't contain the description of format specifiers of all builtin types. Detailed documentation of format specification mini-language with tables and examples you can get by requesting the help for FORMATTING. "help('FORMATTING')" or "pydoc3 FORMATTING". It may be worth to add a reference to FORMATTING from the format() docstring. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:24:07 2017 From: report at bugs.python.org (Marco Buttu) Date: Fri, 10 Feb 2017 15:24:07 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486740247.97.0.56179205714.issue29526@psf.upfronthosting.co.za> Marco Buttu added the comment: > It may be worth to add a reference to FORMATTING from the > format() docstring. +1 :-) ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:34:02 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Feb 2017 15:34:02 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486740842.58.0.818820465461.issue29526@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: those are both great ideas. +1 from me too. Then we can even have the date formatting documented without cluttering up the main docstring, if we wish :) The format docstring should then also mention doing help on the __format__ method of concrete types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 10:43:55 2017 From: report at bugs.python.org (Hugo Prod'homme) Date: Fri, 10 Feb 2017 15:43:55 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486741435.14.0.577978436469.issue29526@psf.upfronthosting.co.za> Hugo Prod'homme added the comment: +1 : Adding the reference to help('FORMATTING') will indeed solve all the problems I was thinking about at first. -- I realized I was thinking only about a small part of the problem thanks to your answers. I wasn't even thinking about the dates and other types... So I agree applying my first idea will be a big mess. (... and yes I was referring to printf formatting) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 11:01:22 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 16:01:22 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486742482.19.0.180624243651.issue29514@psf.upfronthosting.co.za> Brett Cannon added the comment: Why shouldn't the magic number be bumped when a bug in the bytecode is fixed in a bugfix release? How did this break Fedora? Are you not shipping source code but only .pyc files? I view the whole point of having the magic number is to cover things like this, otherwise we might as well just embed the CPython version number in the file name and be done with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 11:59:18 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 10 Feb 2017 16:59:18 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486745958.0.0.0180146224736.issue29523@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Will send a pull request which includes the extra wheels. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 11:59:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Feb 2017 16:59:24 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486745964.0.0.186467108997.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: There are a couple of pieces to it: - first, there's the problem of breaking anyone that actually is doing pyc-only distribution, even though nothing in Fedora itself does that. While that aspect doesn't break Fedora per se, it does break Fedora's compatibility expectations for end user components, which maintenance updates shouldn't do - however, more importantly in this case, ordinary users don't have write access to the system site-packages directory, so the pyc files have to be pre-compiled when generating the system RPMs. While CPython falls back to the slow path of recompiling from source when those precompiled files are invalidated so nothing obviously breaks, it still generates a lot of SELinux warnings related to unauthorised write attempts to system-owned directories: https://bodhi.fedoraproject.org/updates/python3-3.5.3-1.fc25%20python3-docs-3.5.3-1.fc25#comment-559458 (Debian uses a similar pre-compilation trick for the same reasons, so I expect you'd also see comparable warnings under AppArmor if packages weren't rebuilt after a magic number change) This all means that CPython changing the magic number in a maintenance release ends up being akin to breaking the C ABI in a maintenance release - while it isn't quite as dire (since there's still the slow path fallback to recompiling from source), it does still invalidate all of the pyc files in the system RPMs until they're rebuilt against the new version. "Requires a mass rebuild of all the Python packages in the distro to get things working properly again" is again a major concern for what's nominally a low impact maintenance update. I realise those consequences aren't particularly obvious for non-distro developers, which is why I'd like to see the previous policy of "don't change the magic number in maintenance releases" captured as a test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:04:57 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 17:04:57 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486746297.34.0.0799563048505.issue29514@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, but how would you propose to fix broken bytecodes in a bugfix be fixed if you can't bump the magic number? And why aren't you regenerating the bytecode when updating Python or shipping the bytecode with the install (and I bet the answer is "RPM doesn't support it" and "it goes against packaging guidelines to include auto-generated files", but I thought I would ask :) . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:13:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 17:13:32 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486739059.72.0.128352944654.issue29524@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Serhiy Storchaka added the comment: > I would delay pushing this change until CPython repository be converted to Git. I heard Git better supports moving a code between files. And perhaps it might be easier to do this change by several commits -- separately moving a code from different files. Mercurial requires to use "hg cp file1.c file2.c" to keep file1 history in file2. Git doesn't care. It is "smarter" (more convenient?). It uses an heuristic to automatically detect when code is moved between files. The migration to GitHub is ongoing, we are no more able to push to Mercurial anyway :-D Any remark about call.c content itself? Does it look good to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:14:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 17:14:32 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: Message-ID: STINNER Victor added the comment: Oh, it's painful to have reviews and comments in two websites. Serhiy left a comment on the review in fact: "Should be added also in PCbuild/pythoncore.vcxproj.filters." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:35:55 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 10 Feb 2017 17:35:55 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1486748155.72.0.970371396149.issue29481@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:39:50 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Feb 2017 17:39:50 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486748389.99.0.187233748276.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: We *do* ship the bytecode in the built RPMs - the issue is that Python maintenance releases shouldn't be triggering rebuilds of thousands of system components (cf http://fedora.portingdb.xyz/ ) and potentially breaking otherwise working end user applications. As far as "What about bytecode generation bugs?" goes, then my answer would be to find a way to fix the bug for freshly generated bytecode, without forcing stale bytecode to be regenerated. That way folks that actually hit the original bug have a way of solving it (clear their bytecode cache), while we also don't forcibly break the world. That is, the problem with the resolution of issue 27836 wasn't fixing the bytecode generation when using double-star unpacking twice in a single function call - it was forcing the regeneration of *all* bytecode just because *some* bytecode would be broken if it used a particular new language feature. It's the equivalent of deliberately breaking the ABI for all extension modules just because we found a header bug affecting one particular function signature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:46:14 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Feb 2017 17:46:14 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486748774.45.0.579083173514.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that Fedora doesn't even rebuild all the extension modules when bumping CPython to a new maintenance release, let alone rebuilding and re-releasing all the pure Python ones. (RPM supports doing that just fine, but it would mean shipping thousands of updated binary artifacts instead of just one - the new CPython maintenance release) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:50:30 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Feb 2017 17:50:30 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486749030.39.0.0608327823621.issue29524@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is hard to make a review of changes of such kind. Common reviewing tools don't help with this. I would suggest you to make a series of commits that move a code from different files after migrating to Git. It may be easier to make a post-commit review. I said about Python/ because Object/ contains mainly implementations of concrete builtin types and Python/ contains some utility files (getargs.c, modsupport.c). But I think Objects/ is good place too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:53:00 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 10 Feb 2017 17:53:00 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486748774.45.0.579083173514.issue29514@psf.upfronthosting.co.za> Message-ID: <20170210125252.2b27cfa5@presto.wooz.org> Barry A. Warsaw added the comment: On Feb 10, 2017, at 05:46 PM, Nick Coghlan wrote: >Note that Fedora doesn't even rebuild all the extension modules when bumping >CPython to a new maintenance release, let alone rebuilding and re-releasing >all the pure Python ones. (RPM supports doing that just fine, but it would >mean shipping thousands of updated binary artifacts instead of just one - the >new CPython maintenance release) Debian/Ubuntu doesn't rebuild extension modules either. We don't ship .pyc files in binary packages, but instead build them at install time on the user's machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 12:56:15 2017 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 10 Feb 2017 17:56:15 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486749375.33.0.316659629358.issue29514@psf.upfronthosting.co.za> Petr Viktorin added the comment: > How would you propose to fix broken bytecodes in a bugfix be fixed if you can't bump the magic number? That would depend on the situation. I can imagine that if the bug is severe enough, the number could be bumped, after careful discussion, and with the change being advertised rather loudly. The test case that's proposed can be changed if it's indeed the best thing to do, but it should at the very least be mentioned in release notes. FWIW, I'm not convinced the bug here was severe enough. Practically no one is using the 3.5+ syntax in libraries: we checked to find that *zero* packages in Fedora are using the affected opcode. But that's moot now ? wider discussion on that should have happened before the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 13:01:36 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Feb 2017 18:01:36 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486749696.04.0.615213826959.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, interesting. The install-time generation case is even trickier, since you presumably can't force in-place regeneration of existing pyc files on systems that previously had 3.5.2 and upgraded to 3.5.3. When I last spoke to Peter about this yesterday, he was exploring the idea of a downstream-only patch to 3.5.3 that gave it the ability to load pyc files that used the 3.5.2 magic number (so it would *emit* files with the new magic number, but still allow use of pyc files with the old one). Assuming he can get that to work, then I guess it may be of interest to Debian & Ubuntu as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 13:12:10 2017 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 10 Feb 2017 18:12:10 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486750330.25.0.488383915967.issue29514@psf.upfronthosting.co.za> Petr Viktorin added the comment: According to issue27286, Ubuntu 16.04LTS has the fix and uses the new magic number. (And this is one reason undoing the change in CPython is out of the question.) The patch Nick mentioned is brewing at https://github.com/encukou/cpython/commit/magic-number-workaround . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 13:18:19 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 10 Feb 2017 18:18:19 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486750699.51.0.291446245666.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: Since Python 3.5's key sharing dict allows deletion, py35-2.patch is slightly different from py36-2.patch. Since dictresize won't happen in normal (no weakref/__del__ callback) deletion, I removed `CACHED_KEYS(tp) = NULL` entirely. ---------- Added file: http://bugs.python.org/file46626/29438-sharedkey-useafterfree-py35-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 13:19:32 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 10 Feb 2017 18:19:32 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486750772.49.0.781374289267.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: I'll send PR to github. Please continue there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 13:22:09 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Feb 2017 18:22:09 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1486750929.8.0.830352271223.issue29481@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The online docs are regenerated daily from the current repository, so the inclusion of typing.Deque in the doc is correct, given that it has been added to the module. IDLE aside, new features in bugfix releases are limited to provisional modules, such as typing. I believe this should get a 'New in 3.6.1' (or 3.5.?) note. Some installations include a local frozen copy of the docs. The frozen copy will not include the rare (and admittedly confusing) feature added for a future release. But it will also not include the much more common corrections and clarifications added since the release. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 14:20:34 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 10 Feb 2017 19:20:34 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486754434.7.0.0272227246738.issue29523@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Second version of the patch: Adjusted the test_ensurepip test cases to account for the new modules ---------- Added file: http://bugs.python.org/file46627/bundle-setuptools-dependencies2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 14:31:36 2017 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 Feb 2017 19:31:36 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) In-Reply-To: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> Message-ID: <1486755096.86.0.823492321622.issue29518@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 14:34:11 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Feb 2017 19:34:11 +0000 Subject: [issue29505] Submit the re, json, & csv modules to oss-fuzz testing In-Reply-To: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za> Message-ID: <1486755251.89.0.967335276802.issue29505@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It does not appear to me that targets have to be security critical, though that is certainly a good place to start. The Chrome tests found 100s of "security vulnerabilities and stability bugs". The important thing is that there be someone willing to receive and act on reports. Would 'make public after 90 days' ever be a problem? AFAIK, most Python security issues are already public here on the tracker from day 1. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 15:13:25 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Feb 2017 20:13:25 +0000 Subject: [issue29511] Add 'find' as build-in method for lists In-Reply-To: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> Message-ID: <1486757605.84.0.0297344388478.issue29511@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Lists, tuples, ranges, dicts, and other builtin collection objects already work with 'in'. >>> 1 in [1,2,3] True >>> 4 in range(9) True For historical reasons, stings have both 'find' and 'index'. The only difference is returning -1 (a C-ism) versus raising ValueError on failure. They are otherwise redundant. Lists, tuples, and ranges, and other builtin sequence objects already have 'index'. There is no need to repeat the redundancy of 'find'. >>> [1,2,3].index(2) 1 >>> [1,2,3].index(4) Traceback (most recent call last): File "", line 1, in [1,2,3].index(4) ValueError: 4 is not in list >>> range(9).index(4) 4 Strings are a special case of collection in that they 'contain' substrings rather than items of a different class. For this reason, 'in' and index/find are special-cased also work with contiguous substrings of length greater than 1. >>> 'ac' in 'abc' False >>> 'ab' in 'abc' True Extending this idea to 'subsequence in sequence' or sequence.index(subsequence) has been rejected. Note: __cmp__ does not exist in 3.x. Collection 'in' and sequence 'index' check object identity before equality to guarantee that an object in a collection (in the common sense of the term) is actually found even if it has a screwy definition of __eq__. >>> nan = float('nan') >>> nan == nan False >>> nan in [nan] True >>> float('nan') in [float('nan')] False >>> [nan].index(nan) 0 ---------- nosy: +terry.reedy resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 15:41:38 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Feb 2017 20:41:38 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1486759298.48.0.518484121364.issue29526@psf.upfronthosting.co.za> Terry J. Reedy added the comment: +1 of Serhiy's ideas. I was not aware that FORMATTING had been added. And this could be specifically helpful. >>> help(int.__format__) Help on method_descriptor: __format__(...) default object formatter ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 16:27:40 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 21:27:40 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486762060.59.0.875446104306.issue29521@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: My Pull Request was closed, because apparently https://github.com/python/cpython/ will not be the new GitHub repo for Python. The actual repo will open on 11. Feb, I'm told. I will repeat the PR there. Please stand by. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 17:57:09 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 10 Feb 2017 22:57:09 +0000 Subject: [issue29511] Add 'find' as build-in method for lists In-Reply-To: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> Message-ID: <1486767429.27.0.284508931837.issue29511@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Terry, I'm not sure if you've read this enhancement request correctly or not, because your reply when closing covers over a lot of detail which is not relevant to this feature request. > Extending this idea to 'subsequence in sequence' or sequence.index(subsequence) has been rejected. And so it should, as that is a major break with backwards compatibility, but that is not what this feature request is about. Including George's link, I count at least five questions on StackOverflow asking about this functionality: how to do subsequence tests in sequences apart from strings. That, and the interest in the recipes on ActiveState (here's another: http://code.activestate.com/recipes/117214/ ) indicate a reasonable level of interest in this feature. In Python today, there is no obvious, good, correct way to do this in the standard library, just a bunch of hacks and tricks which solve slightly different problems. Unless the very idea of subsequence matching has been rejected (which would surprise me greatly) I'm going to re-open this ticket. Any objections? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:49:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 23:49:33 +0000 Subject: [issue29527] Travis: doc job is broken Message-ID: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> New submission from STINNER Victor: I suggest to disable the job until it's fixed, just to fix Travis right now. This issue will track the bug to find a solution. https://travis-ci.org/python/cpython/jobs/200517775 $ make html SPHINXBUILD="./venv/bin/python3 -m sphinx" SPHINXOPTS="-nW -q -b linkcheck" ./venv/bin/python3 -m sphinx -b html -d build/doctrees -D latex_paper_size= -nW -q -b linkcheck . build/html Warning, treated as error: WARNING: latex_preamble is deprecated. Use latex_elements['preamble'] instead. make: *** [build] Error 1 ---------- components: Tests messages: 287573 nosy: haypo priority: normal severity: normal status: open title: Travis: doc job is broken versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:52:33 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:52:33 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486770753.1.0.774231723531.issue29527@psf.upfronthosting.co.za> Brett Cannon added the comment: What would it take to simply fix the docs? And we shouldn't disable the check entirely if fixing it is difficult, but instead just let warnings be warnings until we fix all warnings and then make them be errors again. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:58:09 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:58:09 +0000 Subject: [issue29528] Encrypt IRC channel details Message-ID: <1486771089.77.0.265289321985.issue29528@psf.upfronthosting.co.za> New submission from Brett Cannon: Donald pointed out on IRC we should encrypt a channel key for IRC so that it doesn't get flooded from people's forks. See https://docs.travis-ci.com/user/notifications#Channel-key for documentation on how to do this. ---------- messages: 287575 nosy: brett.cannon, dstufft, r.david.murray priority: high severity: normal status: open title: Encrypt IRC channel details _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:59:00 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:59:00 +0000 Subject: [issue29529] Backport Travis configuration Message-ID: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> New submission from Brett Cannon: Once the Travis config stabilizes then it should be backported to all active branches. ---------- assignee: brett.cannon messages: 287576 nosy: brett.cannon priority: normal severity: normal status: open title: Backport Travis configuration versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:59:18 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:59:18 +0000 Subject: [issue29528] Encrypt IRC channel details for Travis In-Reply-To: <1486771089.77.0.265289321985.issue29528@psf.upfronthosting.co.za> Message-ID: <1486771158.42.0.733017612801.issue29528@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Encrypt IRC channel details -> Encrypt IRC channel details for Travis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:59:24 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:59:24 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1486771164.4.0.259327733912.issue29529@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Encrypt IRC channel details for Travis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:17:56 2017 From: report at bugs.python.org (Frak N) Date: Sat, 11 Feb 2017 00:17:56 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486772276.71.0.990341348176.issue29525@psf.upfronthosting.co.za> Frak N added the comment: c:\Python27>SET PY Environment variable PY not defined I don't know anything about readline or how to find what uses it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:25:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 00:25:16 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486772716.97.0.759391416501.issue29525@psf.upfronthosting.co.za> STINNER Victor added the comment: To get more information during the Python initialization, you can try to run: python -X faulthandler -S -v * -X faulthandler: dump a traceback if python crashed (is it the case? I don't understand from the bug report) * -S disables the site module * -v enables verbose mode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:31:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 00:31:55 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486773115.41.0.679134338814.issue29527@psf.upfronthosting.co.za> STINNER Victor added the comment: > And we shouldn't disable the check entirely if fixing it is difficult, but instead just let warnings be warnings until we fix all warnings and then make them be errors again. Ok, I changed my change (I got the same proposal in the PR). So I removed -W option: https://github.com/python/cpython/commit/0d5f11061a873e9fb67ae59e46b3313e5ba22fc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:38:13 2017 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Feb 2017 00:38:13 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1486773493.68.0.643906571302.issue23404@psf.upfronthosting.co.za> Zachary Ware added the comment: I've disabled the Touch step on the buildbots until this is fixed. ---------- keywords: +buildbot nosy: +zach.ware priority: normal -> critical versions: +Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:47:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 00:47:37 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486774057.23.0.205014156775.issue29524@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- pull_requests: +28 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:47:38 2017 From: report at bugs.python.org (Justin McNiel) Date: Sat, 11 Feb 2017 00:47:38 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) In-Reply-To: <1486723983.47.0.595967105972.issue29518@psf.upfronthosting.co.za> Message-ID: Justin McNiel added the comment: While restarting didn't fix it, waiting for the next morning did, so I am afraid that that isn't possible, also, I have made tremendous changes to my code since then, but I would by happy to send you any bit of my code that you would like, it cold also be an issue with my computer, our IT department is very work heavy and doesn't always install the operating system properly (ie. not installing the driver for the touchpad) On Feb 10, 2017 4:53 AM, "Steven D'Aprano" wrote: > > Steven D'Aprano added the comment: > > I agree with Josh: the exception you are giving doesn't seem possible with > the code snippet shown. Please COPY AND PASTE (not a screen shot) the text > of the entire traceback, starting with the line "Traceback..." > > I suspect that you may have shadowed the built-in range or len object with > some custom object, but I could be completely wrong. But without more > information, we cannot tell what is going on. > > It would be really useful if you could provide a minimal (short as > possible) script that reproduces the problem. And please confirm that you > can reproduce the problem in the regular CPython interpreter, without using > any third-party IDEs. > > ---------- > nosy: +steven.daprano > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:47:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 00:47:45 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486774065.92.0.380594649594.issue29524@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file46624/call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 19:48:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 00:48:33 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486774113.02.0.103602746722.issue29524@psf.upfronthosting.co.za> STINNER Victor added the comment: We have moved to GitHub and mandatory reviews with Pull Requests. So I created the PR #12 and removed the patch attached to this issue to avoid confusion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:13:30 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sat, 11 Feb 2017 01:13:30 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486775610.39.0.009413827356.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I've drafted some fairly restricted changes to the doctest documentation page. They are in my Github branch, https://github.com/JDLH/cpython/tree/Issue29428_doctest_docs . The diffs are at https://github.com/JDLH/cpython/commit/223ef8f8a6d2fbec6db774912028abb4d2ff88b6 . There currently is no official Python github repot against which to make a pull request. In a few days, once it appears, I'll make a pull request. In the meantime, I can take review comments and improve it. If you are interested, please review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:35:38 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Feb 2017 01:35:38 +0000 Subject: [issue29511] Add 'find' as build-in method for lists In-Reply-To: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> Message-ID: <1486776938.37.0.817033618231.issue29511@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Without any test code (other than my examples) to illustrate the desired new functionality, I may have misunderstood. But I read the George's prose (but not the SO link) and everything I wrote is relevant to what I thought it said. The request appears to be for either what now exists (other than the name and failure signal) or what Guido has specifically rejected for non-strings. Reasons for rejecting subsequence matching: 1. Except for strings, practical use cases seem to be rare. 2. Enhancement could mask bugs. 3. General sequences with nesting (tuples and lists, but not range) have an ambiguity problem that strings do not. [1, 2, [1,2]].index([1,2]) currently returns 2, not 0, and this cannot change. Similarly, [1,2] in [1,2,3] should not change from False to True. Steven, without specific code examples, I do not understand what the 'this' is that you think is different from what you say was properly rejected, The request appears to be for extending the meaning of'in' and 'find/index' for non-strings. (See last sentence of opening post.) As you note, there are several related but different problems. http://code.activestate.com/recipes/117214/ gives Python code for Knuth-Morris-Pratt string matching. Python uses a C-coded version of either this or an alternative in (str/bytes/bytearray).(index/find) Both methods stop with the first match, but have a 'start' parameter if one wants repeated matches, and one can choose either start as position + 1 or position + len(pattern) to allow overlaps or not. Every presentation of KMP I have seen is as a string algorithm. In spite of the recipe title and argument name ('text'), the author claims that the Python code is generic. Since the recipe discussion only tested strings, I tried for i in KnuthMorrisPratt([1,2,3,4,5,1,2], [1,2]): print(i) and it prints 0 and 5, as claimed. Nice! Generic subsequence matching is easily possible. I believe the Python code could be rewritten in C with the Python C-API and remain generic. If this idea is not to be dropped, I think the next step should be a python-ideas post with a clear function definition and a possible API (which will elicit alternative proposals) that avoids the back compatibility problem, specific positive and negative test examples, and real-life use cases (which I hope might be included in the SO questions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:37:11 2017 From: report at bugs.python.org (Eric Snow) Date: Sat, 11 Feb 2017 01:37:11 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486777031.09.0.952857867061.issue29514@psf.upfronthosting.co.za> Eric Snow added the comment: This is strictly a problem for the system Python, right? In that case, can't the dist package clear __pycache__ under the system site-packages directory (and any other user-read-only dirs) during install of the updated Python? Is the concern that upgrading Python may force all .pyc files to be re-written (perhaps unnecessarily)? If so, I'm not clear on why it's okay between major versions but not minor ones. Frequency perhaps? Is the cost of re-compiling all .pyc files (which mostly won't happen all at the same time) significant enough to warrant changing the status quo, particularly since the magic number rarely changes in a minor release? As one (poor) alternative, we could require re-compiling a .pyc file only if it contains the affected bytecode(s). Granted, that would probably require associating every bytecode with a magic number. The required comparison would likely be more expensive than just re-compiling. :/ Another alternative would be to leverage sys.dont_write_bytecode somehow. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:38:41 2017 From: report at bugs.python.org (Ryan Gonzalez) Date: Sat, 11 Feb 2017 01:38:41 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486777121.69.0.317447962613.issue29527@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Trying to fix this in https://github.com/python/cpython/pull/9...but... Currently there are approx *pause for effect* 6,245 warnings! Out of those, around 6,243 are 'reference target not found' warnings, spanning over 290 files: /media/ryan/stuff/cpython/Doc/whatsnew/3.7.rst:121: WARNING: c:member reference target not found: doc /media/ryan/stuff/cpython/Doc/whatsnew/3.7.rst:121: WARNING: c:type reference target not found: PyGetSetDef /media/ryan/stuff/cpython/Doc/whatsnew/3.7.rst:121: WARNING: c:type reference target not found: wrapperbase /media/ryan/stuff/cpython/Doc/whatsnew/3.7.rst:157: WARNING: py:mod reference target not found: ntpath ../../Misc/NEWS:348: WARNING: py:data reference target not found: socket.TCP_CONGESTION ../../Misc/NEWS:348: WARNING: py:data reference target not found: socket.TCP_USER_TIMEOUT ../../Misc/NEWS:1005: WARNING: py:data reference target not found: socket.TCP_CONGESTION ../../Misc/NEWS:1005: WARNING: py:data reference target not found: socket.TCP_USER_TIMEOUT ../../Misc/NEWS:2718: WARNING: py:obj reference target not found: idlelib/*.py ../../Misc/NEWS:2718: WARNING: py:obj reference target not found: idle_test/test_*.py ../../Misc/NEWS:2837: WARNING: c:func reference target not found: malloc ../../Misc/NEWS:2883: WARNING: c:func reference target not found: PyObject_Malloc For some reason, I don't feel like fixing 6,200 warnings is really feasible (or at least for me), so would it be worth it to, in the mean time, disable this specific kind of warning, at least for the CI builds? ---------- nosy: +refi64 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:58:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 01:58:36 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) Message-ID: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> New submission from STINNER Victor: (*) I noticed test_sax and test_random failures on Windows since CPython moved to GitHub. These failures seem to be caused by newlines: see issue #27425. (*) "AMD64 Windows7 SP1 3.x" fails on the "git" step with: 'git' is not recognized as an internal or external command I contacted the slave owner, Jeremy, to ask him to install git. ---------- components: Tests keywords: buildbot messages: 287587 nosy: haypo priority: normal severity: normal status: open title: Windows buildbots broken by the migration to GitHub (meta issue) versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 21:14:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 02:14:45 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486779285.75.0.751679852689.issue29524@psf.upfronthosting.co.za> STINNER Victor added the comment: Benchmarks results. I don't know if the speedup is purely random, if I was just lucky, or if the change really makes Python faster... spectral_norm is a benchmark highly impacted by code placement. haypo at speed-python$ python3 -m perf compare_to /home/haypo/benchmarks/2017-02-10_00-20-default-e91ec62da088.json call_ref_e91ec62da088.json -G --min-speed=5 Slower (1): - spectral_norm: 242 ms +- 3 ms -> 282 ms +- 2 ms: 1.16x slower (+16%) Faster (15): - xml_etree_process: 193 ms +- 4 ms -> 173 ms +- 3 ms: 1.11x faster (-10%) - call_method: 12.4 ms +- 0.6 ms -> 11.3 ms +- 0.3 ms: 1.10x faster (-9%) - hexiom: 18.5 ms +- 0.2 ms -> 17.1 ms +- 0.1 ms: 1.09x faster (-8%) - sympy_expand: 940 ms +- 12 ms -> 866 ms +- 13 ms: 1.09x faster (-8%) - regex_effbot: 5.39 ms +- 0.09 ms -> 4.99 ms +- 0.06 ms: 1.08x faster (-7%) - chaos: 235 ms +- 2 ms -> 219 ms +- 2 ms: 1.07x faster (-7%) - unpickle_pure_python: 686 us +- 11 us -> 639 us +- 7 us: 1.07x faster (-7%) - chameleon: 22.6 ms +- 0.4 ms -> 21.0 ms +- 0.3 ms: 1.07x faster (-7%) - nqueens: 220 ms +- 2 ms -> 205 ms +- 3 ms: 1.07x faster (-7%) - telco: 15.0 ms +- 0.6 ms -> 14.0 ms +- 0.2 ms: 1.07x faster (-6%) - sympy_str: 423 ms +- 4 ms -> 399 ms +- 3 ms: 1.06x faster (-6%) - scimark_monte_carlo: 223 ms +- 9 ms -> 211 ms +- 8 ms: 1.06x faster (-6%) - xml_etree_generate: 223 ms +- 3 ms -> 210 ms +- 2 ms: 1.06x faster (-6%) - xml_etree_iterparse: 192 ms +- 3 ms -> 182 ms +- 4 ms: 1.05x faster (-5%) - sympy_sum: 191 ms +- 7 ms -> 181 ms +- 7 ms: 1.05x faster (-5%) Benchmark hidden because not significant (48): (...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 22:14:21 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 11 Feb 2017 03:14:21 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486782861.01.0.299447604944.issue29525@psf.upfronthosting.co.za> Eryk Sun added the comment: It doesn't appear to be a crash, but seems like the REPL is quitting because there's no input (e.g. like stdin is redirected to NUL). Echo %errorlevel%; it's probably 0. readline (pyreadline) is probably the culprit. Try the following shell commands to temporarily disable it: ren C:\Python27\Lib\site-packages\readline.py readline.py.bak del C:\Python27\Lib\site-packages\readline.pyc If it's not installed, then these commands will fail. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 22:15:55 2017 From: report at bugs.python.org (Roger Sachan) Date: Sat, 11 Feb 2017 03:15:55 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst Message-ID: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> New submission from Roger Sachan: I have simply updated the document and its references to README.rst (thanks to whoever formatted it). ---------- assignee: docs at python components: Documentation messages: 287590 nosy: Roger Sachan, docs at python priority: normal pull_requests: 29 severity: normal status: open title: Update Doc/README.txt to README.rst type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 22:32:45 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 11 Feb 2017 03:32:45 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1486783965.28.0.168083017264.issue29438@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +30 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 22:38:48 2017 From: report at bugs.python.org (Roger Sachan) Date: Sat, 11 Feb 2017 03:38:48 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst In-Reply-To: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> Message-ID: <1486784328.49.0.353944327297.issue29531@psf.upfronthosting.co.za> Changes by Roger Sachan : ---------- pull_requests: +31 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 23:05:00 2017 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Feb 2017 04:05:00 +0000 Subject: [issue29528] Encrypt IRC channel details for Travis In-Reply-To: <1486771089.77.0.265289321985.issue29528@psf.upfronthosting.co.za> Message-ID: <1486785900.22.0.0389387026881.issue29528@psf.upfronthosting.co.za> Zachary Ware added the comment: Fixed in PR13. ---------- nosy: +zach.ware pull_requests: +32 resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 00:03:32 2017 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Feb 2017 05:03:32 +0000 Subject: [issue27536] Convert readme to reStructuredText In-Reply-To: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> Message-ID: <1486789412.37.0.03001216028.issue27536@psf.upfronthosting.co.za> Zachary Ware added the comment: This has been done in PR2. Thank you for the patch anyway, Louis, and I'm sorry we didn't wind up using it! ---------- nosy: +haypo, zach.ware pull_requests: +33 resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 00:00:12 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Feb 2017 05:00:12 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486789212.36.0.0452212729624.issue28929@psf.upfronthosting.co.za> Brett Cannon added the comment: Now that we have migrated to GitHub and Mariatta is a core dev I'm assigning this to her. :) ---------- assignee: docs at python -> Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 02:20:01 2017 From: report at bugs.python.org (Naoyuki Kamo) Date: Sat, 11 Feb 2017 07:20:01 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 Message-ID: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> New submission from Naoyuki Kamo: The code: from functools import partial def f(a): print(a) d = {'a': 3} g = partial(f, **d) g() d['a'] = 5 g() On python2.7, gets 3 but on python3.5, gets 5 is it a bug? ---------- messages: 287594 nosy: naoyuki priority: normal severity: normal status: open title: functools.partial is not compatible between 2.7 and 3.5 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:26:31 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 11 Feb 2017 08:26:31 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1486801591.87.0.0666415808596.issue29532@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Confirmed that in Python 2.7 calling g() before and after modifying the dict prints 3 both times; calling g() before modifying the dict prints 3, then after modifying it prints 5. Python 3.3 behaves like 2.7, so this sounds like a regression in 3.5 or maybe 3.4. ---------- nosy: +steven.daprano versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:42:30 2017 From: report at bugs.python.org (Stuart Berg) Date: Sat, 11 Feb 2017 08:42:30 +0000 Subject: [issue28837] 2to3 does not wrap zip correctly In-Reply-To: <1480503898.29.0.0471565347052.issue28837@psf.upfronthosting.co.za> Message-ID: <1486802550.44.0.404643169473.issue28837@psf.upfronthosting.co.za> Stuart Berg added the comment: Patch submitted as github PR #24: https://github.com/python/cpython/pull/24 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:43:27 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:43:27 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows Message-ID: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> New submission from Julia Dolgova: I've found that urllib works sometimes slowly on windows with proxy. To reproduce the issue: on Windows: 1. Turn on the option "use proxy" in "browser settings" in "control panel". No real proxy needed. The problem will come out before addressing to proxy. Just don't pay attention to exception. 2. Make sure that the list of addresses for proxy bypass is not empty 3. Execute checklib.py with socket.py (attached here) in the same directory The result output could be: A (not a problem): Before call to _socket.gethostbyaddr("docs.python.org") After call to _socket.gethostbyaddr("docs.python.org") B (little problem): Before call to _socket.gethostbyaddr("docs.python.org") Exception in call to _socket.gethostbyaddr("docs.python.org") C (worse problem): Before call to _socket.gethostbyaddr("docs.python.org") (Delay) Exception in call to _socket.gethostbyaddr("docs.python.org") The result A,B or C depends on what DNS server you use, what url you pass into urllib2.urlopen(), and could differ at different time because dns is not a stable thing. However, no matter what result you have, this test shows that a hostname is passed into gethostbyaddr instead of IP as expected and described in MSDN. It should be changed to gethostbyname_ex here. test.py compare performance of gethostbyaddr and gethostbyname_ex. It sets different dns servers on the system and calls these functions with different hostnames passed into. Run on my computer shows that gethostbyname_ex is 3 times more productive and doesn't raise exceptions. ----------------------------- Attached files: checklib.py - just make a call to urllib2.urlopen("https://docs.python.org") socket.py - not a patched lib. Has debug lines near 141 line. Use it with checklib.py. test.py - compare performance of gethostbyaddr with gethostbyname_ex log.txt - result of test.py on my computer (Windows 8, 64 bit) socket.patch - socket.py patch ---------- components: Library (Lib), Windows files: checklib.py messages: 287597 nosy: juliadolgova, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: urllib2 works slowly with proxy on windows type: performance versions: Python 2.7 Added file: http://bugs.python.org/file46628/checklib.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:44:04 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:44:04 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1486802644.16.0.573811793036.issue29533@psf.upfronthosting.co.za> Changes by Julia Dolgova : Added file: http://bugs.python.org/file46629/socket.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:44:24 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:44:24 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1486802664.2.0.495204192142.issue29533@psf.upfronthosting.co.za> Changes by Julia Dolgova : Added file: http://bugs.python.org/file46630/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:44:34 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:44:34 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1486802674.07.0.646212365513.issue29533@psf.upfronthosting.co.za> Changes by Julia Dolgova : Added file: http://bugs.python.org/file46631/log.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:44:48 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:44:48 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1486802688.83.0.361295143964.issue29533@psf.upfronthosting.co.za> Changes by Julia Dolgova : ---------- keywords: +patch Added file: http://bugs.python.org/file46632/socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 05:10:19 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sat, 11 Feb 2017 10:10:19 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1486807819.5.0.0393465516215.issue19675@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 06:10:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 11:10:13 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1486811413.32.0.939411893822.issue29532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, this can be considered a bug. Following patch fixes it. ---------- components: +Library (Lib) keywords: +patch nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.7 -Python 3.4 Added file: http://bugs.python.org/file46633/partial-copy-kwargs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 06:18:56 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 Feb 2017 11:18:56 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486811936.14.0.332223597446.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Providing some additional background: - 3.5.3 was the *first time ever* in more than two decades that CPython changed the magic number in a maintenance release. It *wasn't* necessary to do so - it could have been left alone (as 3.5.0, 3.5.1, and 3.5.2 can read the revised bytecode just fine - no changes were made to ceval, only to the code generator). If the magic number had been left alone, recompilation would have been limited solely to folks with affected bytecode files, which is approximately zero people in practice (as anyone impacted by the problem would have been getting weird runtime behaviour and presumably found a way to work around it). - because the pyc caches for system packages on Linux are in system-owned directories, they're generated either at build time (Fedora et al) or install time (Debian et al) by the package that owns the corresponding source files and then installed with elevated privileges (e.g. "sudo dnf install python-requests"). These files *do not* belong to the CPython package, they belong to the individual Python modules that depend on CPython, so messing with them when installing a new version of CPython would be a significant breach of distro policies - as a result, removing CPython 3.5.3's ability to read pyc files generated by 3.5.0, 3.5.1 or 3.5.2 means that either the distros have to regenerate all of their Python dependent packages (to force recompilation of the affected bytecode files), or else patch the system Python so it can still read the old pyc files (which is the approach Peter is currently pursuing, since requiring a mass rebuild for a maintenance update is *also* against distro policy) Thus this request to take the previously unwritten de facto policy (which worked fine and clearly isn't a major limitation on CPython maintainability, since the one time it has been done in 20+ years didn't actually need to do it) and make it an explicit official policy that's enforced by the test suite. The reason that none of these concerns apply to Python feature releases is because those are only rolled out as part of distro version upgrades (e.g. the switch from 3.5 to 3.6 as the system Python is one of the upgrades going from F25 to F26), where both distro maintainers and distro users already expect to have to rebuild and reinstall almost everything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 06:23:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 11:23:39 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486812219.59.0.17011337042.issue29514@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 08:54:15 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 13:54:15 +0000 Subject: [issue29534] _decimal difference with _pydecimal Message-ID: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> New submission from Armin Rigo: A difference in behavior between _decimal and _pydecimal (it seems that _decimal is more consistent in this case): class X(Decimal): def __init__(self, a): print('__init__:', a) X.from_float(42.5) # __init__: Decimal('42.5') X.from_float(42) # with _pydecimal: __init__: 42 # with _decimal: __init__: Decimal('42') ---------- messages: 287600 nosy: arigo priority: normal severity: normal status: open title: _decimal difference with _pydecimal type: behavior versions: Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 09:45:00 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Feb 2017 14:45:00 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486824300.05.0.521093071467.issue29534@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +mark.dickinson, rhettinger, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:16:53 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 15:16:53 +0000 Subject: [issue29535] datetime hash is deterministic in some cases Message-ID: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> New submission from Armin Rigo: The documentation on the hash randomization says that date, time and datetime have a hash based on strings, that is therefore nondeterministic in several runs of Python. I may either be missing a caveat, or the actual implementation does not follow its promise in case a timezone is attached to the datetime or time object: ~/svn/python/3.7-debug/python -c "import datetime;print(hash(d atetime.datetime(2016,10,10,0,0,0,0,datetime.timezone(datetime.timedelta(0, 36000)))))" (this gives -6021186165085109055 all the time) ~/svn/python/3.7-debug/python -c "import datetime;print(hash(datetime.time(0,0,0,0, datetime.timezone(datetime.timedelta(0, 36000)))))" (this gives -3850122659820237607 all the time) ---------- messages: 287601 nosy: arigo priority: normal severity: normal status: open title: datetime hash is deterministic in some cases type: security versions: Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:25:54 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Feb 2017 15:25:54 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1486826754.48.0.281056235907.issue29535@psf.upfronthosting.co.za> Christian Heimes added the comment: Only the hash of str and bytes are randomized/ The types date, datetime and time are not subject to hash randomization. Same for int, float, bool and None. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:27:41 2017 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 11 Feb 2017 15:27:41 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486826861.03.0.533693703179.issue29530@psf.upfronthosting.co.za> Jeremy Kloth added the comment: After ensuring that Git is available to the buildbot service, the initial update fails due to the existing build directory containing the Mercurial checkout. After manually removing the contents of the build directories, the update task successfully completes. ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:27:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 15:27:53 +0000 Subject: [issue402227] make BUILD_MAP use it's argument Message-ID: <1486826873.18.0.065493234874.issue402227@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After all this change was implemented as a part of PEP 448 implementation (issue2292). But it was not documented and current documentation of the BUILD_MAP opcode doesn't match the implementation. See also issue26213. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:34:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 15:34:11 +0000 Subject: [issue26213] Document BUILD_*_UNPACK opcodes In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za> Message-ID: <1486827251.78.0.124709908959.issue26213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: At the same time the semantic of the BUILD_MAP opcode was changed. However the documentation was not updated and currently it doesn't match the implementation. This caused an issue in third-party projects that operate with bytecode. See also issue28810 for documenting bytecode changes in 3.6. ---------- priority: low -> high type: -> behavior versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:40:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 15:40:07 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1486827607.23.0.0444357756072.issue2292@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue26213 was opened for documenting bytecode changes. But 21 months and 3 releases after the code patch the documentation is still not updated. ---------- nosy: +larry, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:51:02 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 15:51:02 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1486828262.56.0.679765118456.issue29535@psf.upfronthosting.co.za> Armin Rigo added the comment: That's not what the docs say. E.g.: https://docs.python.org/3/reference/datamodel.html#object.__hash__ says By default, the __hash__() values of str, bytes and datetime objects are ?salted? with an unpredictable random value. Although they remain constant within an individual Python process, they are not predictable between repeated invocations of Python. Morever, this command really prints changing numbers: ~/svn/python/3.7-debug/python -c "import datetime;print(hash(d atetime.datetime(2016,10,10,0,0,0,0)))" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:05:28 2017 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 11 Feb 2017 16:05:28 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486829128.38.0.576708806783.issue29530@psf.upfronthosting.co.za> Jeremy Kloth added the comment: Tests are now failing due to end-of-line (?) differences. I did a quick reading of the devguide, but didn't see any mention of the settings to be used for Git on Windows wrt core.autocrlf. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:06:01 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Feb 2017 16:06:01 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1486829161.81.0.529505076768.issue29535@psf.upfronthosting.co.za> Christian Heimes added the comment: I only checked Python 2.7. For Python 3.x it's a bit more complicated: timedelta: PyObject_Hash(), always the same hash value date: _Py_HashBytes(), always a randomized hash value time: _Py_HashBytes() for offset = None, PyObject_Hash() for offset != 0 datetime: _Py_HashBytes() for offset = None, PyObject_Hash() for offset != 0 timezone: PyObject_Hash() (inherited from object) I don't know why the datetime module doesn't use hash randomization for datetime and time objects with an offset. MAL is the master of (date)time. He might know. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:06:10 2017 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Feb 2017 16:06:10 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486829170.59.0.905667360972.issue29530@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware priority: normal -> critical versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:07:35 2017 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Feb 2017 16:07:35 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486829255.59.0.772028656032.issue29530@psf.upfronthosting.co.za> Zachary Ware added the comment: We really need to be able to function regardless of the core.autocrlf setting. See #27425 for more about the EOL issues. ---------- dependencies: +Tests fail because of git's newline preferences on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:08:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 16:08:41 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1486829321.75.0.147473721585.issue29535@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +belopolsky versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:32:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 16:32:40 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486830760.04.0.790154543758.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My apologies for breaking the world. But I considered this bug as security issue. Unlikely, but not impossible. The BUILD_MAP_UNPACK_WITH_CALL opcode is rarely used, but if it is used, it can cause reading arbitrary memory and either crashing or even exposing the content of this memory in error message that can be leaked to remote user. This hole would be better to close early. I expected this change would be included in 3.5.2. The more robust solution would be to add the support of two magic numbers and check on loading whether the BUILD_MAP_UNPACK_WITH_CALL opcode is occurred in a precompiled file with old magic number. But this solution looked too excessive. It would be nice to design a mechanism for possible future bytecode fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 11:38:00 2017 From: report at bugs.python.org (Stefan Krah) Date: Sat, 11 Feb 2017 16:38:00 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486831080.74.0.888792946851.issue29534@psf.upfronthosting.co.za> Stefan Krah added the comment: I get the the same output, perhaps I misunderstand something here: >>> from _decimal import * >>> class X(Decimal): ... def __init__(self, a): ... print('__init__:', a) ... >>> X.from_float(42.5) __init__: 42.5 Decimal('42.5') >>> X.from_float(42) __init__: 42 Decimal('42') >>> >>> >>> from _pydecimal import * >>> class X(Decimal): ... def __init__(self, a): ... print('__init__:', a) ... >>> X.from_float(42.5) __init__: 42.5 Decimal('42.5') >>> X.from_float(42) __init__: 42 Decimal('42') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 12:14:11 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 11 Feb 2017 17:14:11 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486833251.41.0.837455634703.issue29324@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 12:18:10 2017 From: report at bugs.python.org (Roger Sachan) Date: Sat, 11 Feb 2017 17:18:10 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst In-Reply-To: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> Message-ID: <1486833490.46.0.80421771427.issue29531@psf.upfronthosting.co.za> Changes by Roger Sachan : ---------- pull_requests: -29 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 12:20:39 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 11 Feb 2017 17:20:39 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486833639.17.0.371495507256.issue29530@psf.upfronthosting.co.za> Steve Dower added the comment: My vote would be to make the tests not presume anything about line endings, to the point of converting test files on the fly to be sure. I'm mostly free today (in a different city with nothing to do), so if my hotel internet will let me SSH to github then I can work on this today. If people are around, I'll be on IRC too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 12:20:56 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 11 Feb 2017 17:20:56 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486833656.43.0.0519224306066.issue29324@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Confirmed that test_socket_aead_kernel49.patch fixes the problem for Ubuntu 17.04. It'll probably fix it for Debian Stretch too give its kernel version number, but I haven't tested that yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 12:35:47 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 11 Feb 2017 17:35:47 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1486834547.62.0.212963050625.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.3, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 13:06:29 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 18:06:29 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486836389.87.0.17507772846.issue29534@psf.upfronthosting.co.za> Armin Rigo added the comment: Sorry! It should be repr(a) inside the print. Here is the fixed version: class X(Decimal): def __init__(self, a): print('__init__:', repr(a)) X.from_float(42.5) # __init__: Decimal('42.5') X.from_float(42) # with _pydecimal: __init__: 42 # with _decimal: __init__: Decimal('42') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 13:08:14 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Feb 2017 18:08:14 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1486836494.0.0.109621284715.issue29324@psf.upfronthosting.co.za> Christian Heimes added the comment: Thx Barry, I'll try to find some time to verify the new Kernel API and commit the patch early next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 13:54:50 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Feb 2017 18:54:50 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486839290.1.0.779224394962.issue29527@psf.upfronthosting.co.za> Brett Cannon added the comment: It really depends on why the warnings are there. If it's a configuration issue with how Misc/NEWS is being built then that can be fixed to deal with a lot of warnings upfront. Otherwise we can also strip out the references from Misc/NEWS to deal with the warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 14:02:35 2017 From: report at bugs.python.org (12345 67890) Date: Sat, 11 Feb 2017 19:02:35 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previousline In-Reply-To: <1485039375.56.0.473197770315.issue29339@psf.upfronthosting.co.za> Message-ID: <1486839755.78.0.23422002442.issue29339@psf.upfronthosting.co.za> 12345 67890 added the comment: I guess the workflow has been fixed so that I can submit a PR! I wasn't expecting this so soon, but I will get around to this as soon as I have time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 14:21:34 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Feb 2017 19:21:34 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486840894.26.0.780730515517.issue29514@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so it sounds like Serhiy had good reason to do what he did. If we do add a test then I would argue that the message should be very clear that the magic number can change in a bugfix release but that it should be discussed with python-dev first so that downstream can be aware of the issue ahead of time (as Nick pointed out, it took a very special circumstance to make this come up and so chances are it shouldn't again, but institutional memory doesn't necessarily last 20 years either ;) . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 14:47:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 19:47:59 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486842479.89.0.35474242299.issue29463@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Therefore we loss the possibility to set a breakpoint on the docstring? It doesn't look a great lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 14:55:25 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Feb 2017 19:55:25 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486842925.32.0.862723320399.issue29530@psf.upfronthosting.co.za> R. David Murray added the comment: Some of the tests (notably email tests) are *testing* platform line endings. In tests that I rewrote I did my best to make the tests independent of the line endings of checked in files (that is, constructing the files-to-test in the test itself instead of checking them in), but I wouldn't be surprised if there were a few tests that weren't converted to that paradigm. (I haven't looked to see if there are any test.test_email.test_email failures, which is where they'd be.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 14:57:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 19:57:23 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486843043.33.0.315881249526.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please explain to me the comment from _bootstrap_external.py? # Starting with the adoption of PEP 3147 in Python 3.2, every bump in magic # number also includes a new "magic tag", i.e. a human readable string used # to represent the magic number in __pycache__ directories. When you change # the magic number, you must also set a new unique magic tag. Generally this # can be named after the Python major version of the magic number bump, but # it can really be anything, as long as it's different than anything else # that's come before. The tags are included in the following table, starting # with Python 3.2a0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 15:03:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 20:03:59 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486843439.91.0.543171762597.issue29530@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does Git support per-file settings like the svn:eol-style property in Subversion or .hgeol in Mercurial? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 15:22:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Feb 2017 20:22:33 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486844553.23.0.960228428481.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now I think that it would be safer to omit the function name in error message rather than fixing the compilation and bumping the magic number. Nick, if you want I could write a patch that fixes the possible security issue for .pyc files with old magic number. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 15:37:41 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 11 Feb 2017 20:37:41 +0000 Subject: [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) In-Reply-To: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> Message-ID: <1486845461.4.0.435804298782.issue29530@psf.upfronthosting.co.za> Steve Dower added the comment: > Does Git support per-file settings like the svn:eol-style property in Subversion or .hgeol in Mercurial? The .gitattributes file seems to be full of glob patterns, so I assume a full file path will?work. However, that doesn't help with tarballs. Fixing the tests is the best way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 16:27:48 2017 From: report at bugs.python.org (Sachin Kumar) Date: Sat, 11 Feb 2017 21:27:48 +0000 Subject: [issue29536] test_hashlib failure on Ubuntu 16.04 Message-ID: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> New submission from Sachin Kumar: When executing ./python -m test -v test_hashlib on Python 3.7, the test fails. This is the complete traceback: CPython 3.7.0a0 (default, Feb 8 2017, 03:10:42) [GCC 5.4.0 20160609] == Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian == hash algorithm: siphash24 64bit == cwd: /XXX/build/test_python_14437 == encodings: locale=UTF-8, FS=utf-8 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_hashlib test_algorithms_available (test.test_hashlib.HashLibTestCase) ... ok test_algorithms_guaranteed (test.test_hashlib.HashLibTestCase) ... ok test_blake2b (test.test_hashlib.HashLibTestCase) ... ok test_blake2b_vectors (test.test_hashlib.HashLibTestCase) ... ERROR test_blake2s (test.test_hashlib.HashLibTestCase) ... ok test_blake2s_vectors (test.test_hashlib.HashLibTestCase) ... ERROR test_blocksize_name (test.test_hashlib.HashLibTestCase) ... ok test_blocksize_name_blake2 (test.test_hashlib.HashLibTestCase) ... ok test_blocksize_name_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2b_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2b_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2s_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2s_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_huge (test.test_hashlib.HashLibTestCase) ... skipped 'not enough memory: 4.0G minimum needed' test_case_md5_uintmax (test.test_hashlib.HashLibTestCase) ... skipped 'not enough memory: 4.0G minimum needed' test_case_sha1_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_224_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_224_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_256_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_256_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_384_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_384_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_512_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_512_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha512_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_shake128_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_shake256_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_shake_128_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_shake_256_0 (test.test_hashlib.HashLibTestCase) ... ok test_extra_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_get_builtin_constructor (test.test_hashlib.HashLibTestCase) ... ok test_gil (test.test_hashlib.HashLibTestCase) ... ok test_hash_array (test.test_hashlib.HashLibTestCase) ... ok test_hexdigest (test.test_hashlib.HashLibTestCase) ... ok test_large_update (test.test_hashlib.HashLibTestCase) ... ok test_name_attribute (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode_blake2 (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_threaded_hashing (test.test_hashlib.HashLibTestCase) ... ok test_unknown_hash (test.test_hashlib.HashLibTestCase) ... ok test_pbkdf2_hmac_c (test.test_hashlib.KDFTests) ... ok test_pbkdf2_hmac_py (test.test_hashlib.KDFTests) ... ok test_scrypt (test.test_hashlib.KDFTests) ... skipped ' test requires OpenSSL > 1.1' ====================================================================== ERROR: test_blake2b_vectors (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 623, in test_blake2b_vectors for msg, key, md in read_vectors('blake2b'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_blake2s_vectors (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 648, in test_blake2s_vectors for msg, key, md in read_vectors('blake2s'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_224_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 659, in test_case_sha3_224_vector for msg, md in read_vectors('sha3_224'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_256_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 669, in test_case_sha3_256_vector for msg, md in read_vectors('sha3_256'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_384_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 680, in test_case_sha3_384_vector for msg, md in read_vectors('sha3_384'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_512_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 691, in test_case_sha3_512_vector for msg, md in read_vectors('sha3_512'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_shake128_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 703, in test_case_shake128_vector for msg, md in read_vectors('shake_128'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_shake256_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 715, in test_case_shake256_vector for msg, md in read_vectors('shake_256'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ---------------------------------------------------------------------- Ran 65 tests in 0.877s FAILED (errors=8, skipped=3) test test_hashlib failed test_hashlib failed 1 test failed: test_hashlib Total duration: 1 sec Tests result: FAILURE ---------- components: Tests messages: 287626 nosy: Sachin Kumar priority: normal severity: normal status: open title: test_hashlib failure on Ubuntu 16.04 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 18:38:11 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Feb 2017 23:38:11 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1486856291.53.0.787887449296.issue29529@psf.upfronthosting.co.za> Brett Cannon added the comment: https://github.com/python/core-workflow/issues/19 should be decided upon before backporting anything. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 19:40:00 2017 From: report at bugs.python.org (Joakim Soderlund) Date: Sun, 12 Feb 2017 00:40:00 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1486860000.36.0.0915873277971.issue28739@psf.upfronthosting.co.za> Joakim Soderlund added the comment: I got slightly confused here while playing around. Python 3.6.0 (default, Jan 31 2017, 11:39:39) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class Huacaya: ... f"""Huacaya!""" ... >>> class Suri: ... f"""{'Suri!'}""" ... >>> Huacaya.__doc__ is None False >>> Suri.__doc__ is None True At first I thought f-strings *did* work as docstrings since it worked just fine for the first class. But, the docstring suddenly vanished when putting an actual expression into it. ---------- nosy: +JockeTF _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 19:42:49 2017 From: report at bugs.python.org (Zachary Ware) Date: Sun, 12 Feb 2017 00:42:49 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486860169.26.0.0934946985734.issue29527@psf.upfronthosting.co.za> Zachary Ware added the comment: PR16 made the Travis build situation better, but we still have some warnings to look into. I thought we had a PR for that, but I can't seem to find it. ---------- nosy: +zach.ware pull_requests: +34 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 21:46:09 2017 From: report at bugs.python.org (Eric Appelt) Date: Sun, 12 Feb 2017 02:46:09 +0000 Subject: [issue29026] time.time() documentation should mention UTC timezone In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za> Message-ID: <1486867569.49.0.620202491333.issue29026@psf.upfronthosting.co.za> Eric Appelt added the comment: As we have moved to GitHub and mandatory reviews with Pull Requests, I have created a new patch in PR#34 which incorporates Victor's suggestions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 22:48:06 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 03:48:06 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486871286.35.0.95023639375.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 22:59:49 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 03:59:49 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486871989.04.0.504473850631.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +35 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:00:05 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:00:05 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486872005.62.0.893424149555.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +36 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:00:20 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:00:20 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486872020.45.0.23527908797.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +37 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:06:08 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:06:08 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486872368.5.0.162024577915.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +38 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:08:14 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:08:14 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486872494.0.0.0545039245614.issue29474@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +39 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:08:31 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:08:31 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486872511.28.0.743866155335.issue29474@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +40 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:08:41 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:08:41 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486872521.66.0.328532447959.issue29474@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +41 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:09:50 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:09:50 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486872590.19.0.550744955879.issue29474@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 23:13:07 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 04:13:07 +0000 Subject: [issue28941] Update the link to Source Code in Python Docs from hg to github In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za> Message-ID: <1486872787.92.0.575237072888.issue28941@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- assignee: docs at python -> Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 00:58:54 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sun, 12 Feb 2017 05:58:54 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486879134.97.0.942557395177.issue29521@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: It looks like commit e7ffb99f842ebff97cffa0fc90b18be4e5abecf2 to the new GitHub python/cpython repo, by Ryan Gonzalez, fixed the problems in Doc/conf.py, Doc/Makefile, and Misc/NEWS . It did not fix the problems in Doc/make.bat or Doc/faq/windows.rst . I'll make a new Pull Request on the new repo to fix these two parts. That commit was related to https://github.com/python/cpython/pull/9. http://bugs.python.org/issue29527 talks about over 6000 warnings in the doc build, maybe including some of these. Another PR appeared to have fixed many of the warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 01:41:25 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sun, 12 Feb 2017 06:41:25 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486881685.98.0.587256606511.issue29521@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I submitted a PR https://github.com/python/cpython/pull/41 to the new Github repo which finishes clearing the warnings in this bug report. I would appreciate review and committing. ---------- pull_requests: +43 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 01:45:29 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sun, 12 Feb 2017 06:45:29 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486881929.02.0.891213420145.issue29387@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: PR https://github.com/python/cpython/pull/41 to the new Github repo contains the following wording in Doc/faq/windows.rst: Python raises :exc:`IndentationError` or :exc:`TabError` if mixed tabs and spaces are causing problems in leading whitespace. You may also run the :mod:`tabnanny` module to check a directory tree in batch mode. This is parallel wording with the contents of Martin's patch. The PR may be enough to fix this issue. ---------- pull_requests: +44 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 02:22:50 2017 From: report at bugs.python.org (Jeff Allen) Date: Sun, 12 Feb 2017 07:22:50 +0000 Subject: [issue29463] Add `docstring` attribute to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486884170.82.0.906355677007.issue29463@psf.upfronthosting.co.za> Jeff Allen added the comment: Just terminology ... strictly speaking what you've done here is "add a *field* to the nodes Module, FunctionDef and ClassDef", rather than add an *attribute* -- that is, when one is consistent with the terms used in the ast module (https://docs.python.org/3/library/ast.html#node-classes) or Wang (https://docs.python.org/devguide/compiler.html#wang97). ---------- nosy: +jeff.allen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 03:02:30 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sun, 12 Feb 2017 08:02:30 +0000 Subject: [issue29428] Doctest documentation unclear about multi-line fixtures In-Reply-To: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> Message-ID: <1486886550.8.0.948865554883.issue29428@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Pull Request https://github.com/python/cpython/pull/45 submitted to new Github repo. I would appreciate a review. I attempted to balance all the different opinions in the discussion below: stay concise, but also improve the clarity. ---------- pull_requests: +45 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 04:03:11 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 12 Feb 2017 09:03:11 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486890191.58.0.169333892551.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks. I don't familiar with language frontend. I'll check NEWS entry. ---------- title: Add `docstring` attribute to AST nodes -> Add `docstring` field to AST nodes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 04:17:11 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 12 Feb 2017 09:17:11 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1486891031.69.0.47714811963.issue29463@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +46 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 09:28:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 14:28:54 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 Message-ID: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch is an alternative fix of issue27286 for Python 3.5. Rather than fixing the compiler and bumping the magic number it just avoids using incorrect value in eval loop. The patch can be useful for disro maintainers that don't want to recompile all .pyc files when update Python to 3.5.3. I think it would be the best way to fix issue27286. Now it can be combined with either reverting issue27286 changes or applying the workaround https://github.com/encukou/cpython/commit/magic-number-workaround . The patch makes the high byte of oparg be used only when it is unambiguous (equal to 1). In that case the error message contains a function name. Otherwise the error message doesn't contain a function name. This is small usability regression, but the BUILD_MAP_UNPACK_WITH_CALL opcode is very rarely used and shouldn't raise an exception in normal case. ---------- components: Interpreter Core messages: 287637 nosy: barry, encukou, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 09:29:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 14:29:23 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1486909763.91.0.750694006808.issue29537@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file46634/BUILD_MAP_UNPACK_WITH_CALL-no-function_location.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 10:48:31 2017 From: report at bugs.python.org (Martijn Pieters) Date: Sun, 12 Feb 2017 15:48:31 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1486914511.62.0.430944451538.issue28598@psf.upfronthosting.co.za> Martijn Pieters added the comment: I'm not sure if issues are linked automatically yet. I put the patch up as a pull request on GitHub: https://github.com/python/cpython/pull/51 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 11:13:34 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Feb 2017 16:13:34 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1486916014.1.0.92466834002.issue27122@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 89b1824e693419b20b6a9113e5293f1c1a78065f by GitHub in branch '3.6': bpo-27122: Fix comment to point to correct issue number (#48) https://github.com/python/cpython/commit/89b1824e693419b20b6a9113e5293f1c1a78065f ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 11:18:03 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Feb 2017 16:18:03 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1486916283.86.0.445954982575.issue27122@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset c6d2f498142c29ed62241ab6d89cb7b5e38f2fca by GitHub in branch '3.5': bpo-27122: Fix comment to point to correct issue number (#50) https://github.com/python/cpython/commit/c6d2f498142c29ed62241ab6d89cb7b5e38f2fca ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 11:24:13 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 16:24:13 +0000 Subject: [issue29474] Grammatical errors in weakref.WeakValueDictionary docs In-Reply-To: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> Message-ID: <1486916653.65.0.992130079492.issue29474@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, everyone :) The GitHub PRs have been merged. Closing this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 12:14:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 17:14:32 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1486919672.54.0.27541425124.issue28598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 12:42:24 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Feb 2017 17:42:24 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486921344.94.0.483523353541.issue29514@psf.upfronthosting.co.za> Brett Cannon added the comment: That comment is poorly worded. All that is really necessary is that the tag differ when you want to have a .pyc file exist side-by-side with another .pyc file. So far we have only changed it when releasing a new version of Python, but for instance Python 3.5.2 could have had a different tag and that would have prevented trying to overwrite any pre-existing .pyc files for 3.5.1 and instead create new ones. So the tag doesn't need to change for every new magic number, just when you don't want to overwrite .pyc files created by another version of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 13:35:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Feb 2017 18:35:44 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486924544.56.0.57764295767.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: I created https://github.com/python/cpython/pull/52 for curses_fix_window_class_name.patch. ---------- pull_requests: +47 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 13:42:21 2017 From: report at bugs.python.org (CJ Kucera) Date: Sun, 12 Feb 2017 18:42:21 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1486924941.48.0.37492621278.issue14044@psf.upfronthosting.co.za> CJ Kucera added the comment: I've just encountered this problem on Python 3.6, on a different URL. The difference being that it's not encountered with EVERY page load, though I'd say it happens with at least half: import urllib.request html = urllib.request.urlopen('http://www.basicinstructions.net/').read() print('Succeeded!') I realize that the root problem here may be an HTTP server doing something improper, but I've got no way of fixing someone else's webserver. It'd be really nice if there was a reasonable way of handling this in Python itself. As mentioned in the original report, other methods of retreiving this URL work without fail (curl/wget/etc). As it is, the only way for me to be sure of retreiving the entire page contents is by looping until I don't get an IncompleteRead, which is hardly ideal. ---------- nosy: +apocalyptech versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 13:46:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Feb 2017 18:46:31 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1486925191.48.0.514567499749.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the PR https://github.com/python/cpython/pull/53 for curses_temporaryfile.patch. ---------- pull_requests: +48 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 14:11:26 2017 From: report at bugs.python.org (Eric Appelt) Date: Sun, 12 Feb 2017 19:11:26 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486926686.87.0.117226892687.issue29514@psf.upfronthosting.co.za> Eric Appelt added the comment: I added PR #54 with a test as Nick describes for checking magic number changes and explaining to the developer the procedure to follow if this is required in a maintenance release. ---------- nosy: +Eric Appelt pull_requests: +49 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 14:54:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 19:54:12 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486929252.07.0.493912098919.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch looks overcomplicated to me. The test could be as simple as self.assertEqual(importlib.util.MAGIC_NUMBER, ...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:26:39 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 20:26:39 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1486931199.67.0.362939378571.issue19675@psf.upfronthosting.co.za> Camilla Montonen added the comment: I've reformatted Dustin Oprea's original patch to be compatible with git, applied it to master and executed _test_multiprocessing suite. All tests pass locally. ---------- Added file: http://bugs.python.org/file46635/bug19675git.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:30:05 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 20:30:05 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1486931405.77.0.471293357549.issue14119@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:33:20 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 20:33:20 +0000 Subject: [issue5001] Remove assertion-based checking in multiprocessing In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za> Message-ID: <1486931600.4.0.896207582.issue5001@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:36:24 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 20:36:24 +0000 Subject: [issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination In-Reply-To: <1421588019.18.0.707676170756.issue23267@psf.upfronthosting.co.za> Message-ID: <1486931784.04.0.210722018431.issue23267@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:37:34 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 20:37:34 +0000 Subject: [issue22281] ProcessPoolExecutor/ThreadPoolExecutor should provide introspection APIs In-Reply-To: <1409104603.02.0.0732918756664.issue22281@psf.upfronthosting.co.za> Message-ID: <1486931854.04.0.614209483027.issue22281@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:38:19 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Feb 2017 20:38:19 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1486931899.31.0.983371078045.issue29537@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Serhiy, I think that will work well downstream in combination with Petr's patch to accept both magic numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 15:59:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Feb 2017 20:59:46 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486933186.65.0.278111400132.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Eric! I've left some detailed comments on the PR, with the main one being to include the "expected" table directly in the test case so it doesn't require any changes to importlib itself. For Serhiy - thanks for the explanation of the potential security impact of the original bug, as well as the additional patch that resolves that aspect even for the invalid bytecode. As for as the complexity of the test case itself goes, the main cases we're interested in here are how it fails: - when an RM goes to make a candidate release, they may forget to record the now expected magic number for that release series and get prompted by the failing test case. We'd like them to be able to just copy the magic number from _bootstrap_external.py directly into the table of expected magic numbers - when someone attempts to bump the magic number in a maintenance release, we want the warning that that's a higher impact change than it may first appear (one we know how to deal with now, but still something we'd prefer to avoid if we possibly can) So I think it makes sense to have a relatively verbose test case, even though the core of it is a really simple check of a single value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 16:19:51 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 12 Feb 2017 21:19:51 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1486934391.76.0.172286070339.issue28929@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks all :) PRs have been merged on GitHub. Closing this. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 16:27:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 21:27:27 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486934847.24.0.205287328983.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the purpose of having a *table* of magic numbers? We need just one value. Different Python versions run different tests. And I don't think this test needs adding separate file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 16:40:30 2017 From: report at bugs.python.org (CJ Kucera) Date: Sun, 12 Feb 2017 21:40:30 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1486935630.33.0.982648866659.issue14044@psf.upfronthosting.co.za> CJ Kucera added the comment: Ah, well, actually I suppose I'll rescind that a bit - other pages about this bug around the internet had been claiming that the 'requests' module uses urllib in the backend and was subject to this bug as well, but after experimenting myself, it seems like if that IS the case, they're working around it somehow, because using requests makes this succeed 100% of the time. I probably should've tried that first! So anyway, there's a reasonable workaround, at least. Sorry for the bugspam! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 16:55:07 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Feb 2017 21:55:07 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486936507.9.0.746903002302.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think the table of expected magic numbers will be easier to maintain than a single value, as otherwise you either have to: - update it every time the magic number changes during the alpha/beta cycle (which would be a bad habit to encourage, since it runs counter to the purpose of the test) - change it to None for the alpha/beta cycle (to effectively disable the test) before setting it again at the next release candidate By contrast, the version table will typically be append only - the only time it will routinely require modification is for the first release candidate of a particular feature release, and the change will be to add a new entry for that release. I see it as being similar to why we have the full history of all the magic numbers in _bootstrap_external.py, even though we technically only need the latest one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 16:55:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Feb 2017 21:55:17 +0000 Subject: [issue29527] Travis: doc job is broken In-Reply-To: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> Message-ID: <1486936517.7.0.0645245876556.issue29527@psf.upfronthosting.co.za> STINNER Victor added the comment: I see that Travis CI now compiles the doc to HTML, there is a single warning and the doc works. So I close the issue. Thanks! If you want to upgrade Sphinx, fix more warnings, etc. : please open new more specific issues for these tasks. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 17:02:56 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Feb 2017 22:02:56 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486936976.53.0.178224642179.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding the naming of the test file: I agree this can just be added to Lib/test/test_importlib/test_util:MagicNumberTests rather than being added as a new test file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 17:03:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Feb 2017 22:03:48 +0000 Subject: [issue29524] Move functions to call objects into a new Objects/call.c file In-Reply-To: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> Message-ID: <1486937028.79.0.0420455231639.issue29524@psf.upfronthosting.co.za> STINNER Victor added the comment: commit c22bfaae83ab5436d008ac0d13e7b47cbe776f08 Author: Victor Stinner Date: Sun Feb 12 19:27:05 2017 +0100 bpo-29524: Add Objects/call.c file (#12) * Move all functions to call objects in a new Objects/call.c file. * Rename fast_function() to _PyFunction_FastCallKeywords(). * Copy null_error() from Objects/abstract.c * Inline type_error() in call.c to not have to copy it, it was only called once. * Export _PyEval_EvalCodeWithName() since it is now called from call.c. Thanks Serhiy and Naoki for your reviews! It's probably not perfect, but IMHO it's better than what we had previously, and we can rework this file later. About file history: "git blame Objects/call.c" shows me that the first and only author, *but* "git blame -C Objects/call.c" works as expected (show the full history)! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 17:29:35 2017 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 12 Feb 2017 22:29:35 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1486938575.83.0.538282136066.issue19675@psf.upfronthosting.co.za> Camilla Montonen added the comment: @dsoprea: would you like to open a PR for this issue on Github? if not, are you happy for me to do it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 17:54:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 22:54:32 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486940072.58.0.371942510312.issue29514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't understand how the table can make maintaining easier. You need to support multiple values in every branch even if the only one value is used. I'm sure unused values will became outdated pretty fast. "alpha" and "beta" stages are not related here. The test should be skipped at these stages (I recommend to use skipTest() or the skipUnless() decorator rather than just make test always success). Magic number can be changed multiple times at "alpha" and "beta" stages. Release manager needs to update the test only when forming the first release candidate. And his should not do anything if the magic number was not changed in this feature release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 18:38:04 2017 From: report at bugs.python.org (Dustin Oprea) Date: Sun, 12 Feb 2017 23:38:04 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1486938575.83.0.538282136066.issue19675@psf.upfronthosting.co.za> Message-ID: Dustin Oprea added the comment: https://github.com/python/cpython/pull/57 On Sun, Feb 12, 2017 at 5:29 PM, Camilla Montonen wrote: > > Camilla Montonen added the comment: > > @dsoprea: would you like to open a PR for this issue on Github? if not, > are you happy for me to do it? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 18:43:58 2017 From: report at bugs.python.org (Paul Schreiber) Date: Sun, 12 Feb 2017 23:43:58 +0000 Subject: [issue29538] bugs.python.org does not redirect to HTTPS Message-ID: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> New submission from Paul Schreiber: bugs.python.org does not redirect HTTP requests to HTTPS and does not provide Strict Transport Security. ---------- messages: 287661 nosy: paulschreiber priority: normal severity: normal status: open title: bugs.python.org does not redirect to HTTPS type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 19:45:25 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Mon, 13 Feb 2017 00:45:25 +0000 Subject: [issue29539] [smtplib] collect response data for all recipients Message-ID: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): Feature request; collect SMTP response results for all recipients so data likely including the queue ID or SMTP delay expectation can be collected I propose the keyword "keep_results=False" be added to smtplib.sendmail() to accomplish this. The default value of False maintains the legacy functionality of prior versions. No other changes have been done to smtplib.send_message() pending discussion of the following. @@ -785,7 +785,7 @@ return (resp, reply) def sendmail(self, from_addr, to_addrs, msg, mail_options=[], - rcpt_options=[]): + rcpt_options=[], keep_results=False): """This command performs an entire mail transaction. The arguments are: @@ -797,6 +797,8 @@ mail command. - rcpt_options : List of ESMTP options (such as DSN commands) for all the rcpt commands. + - keep_results : If True, return a dictionary of recipients and the + SMTP result for each. msg may be a string containing characters in the ASCII range, or a byte string. A string is encoded to bytes using the ascii codec, and lone @@ -807,17 +809,20 @@ and each of the specified options will be passed to it. If EHLO fails, HELO will be tried and ESMTP options suppressed. - This method will return normally if the mail is accepted for at least - one recipient. It returns a dictionary, with one entry for each - recipient that was refused. Each entry contains a tuple of the SMTP - error code and the accompanying error message sent by the server. + If keep_results is False, this method will return normally if the mail + is accepted for at least one recipient. It returns a dictionary, with + one entry for each recipient that was refused. Each entry contains a + tuple of the SMTP error code and the accompanying error message sent by + the server. If keep_results is True, this method returns a dictionary + of all recipients and the SMTP result whether refused or accepted + unless all are refused then the normal exception is raised. This method may raise the following exceptions: SMTPHeloError The server didn't reply properly to the helo greeting. - SMTPRecipientsRefused The server rejected ALL recipients - (no mail was sent). + SMTPRecipientsRefused The server rejected ALL recipients (no mail + was sent). SMTPSenderRefused The server didn't accept the from_addr. SMTPDataError The server replied with an unexpected error code (other than a refusal of @@ -879,6 +884,10 @@ self._rset() raise SMTPRecipientsRefused(senderrs) (code, resp) = self.data(msg) + if keep_results: + for each in to_addrs: + if not each in senderrs: + senderrs[each]=(code, resp) if code != 250: if code == 421: self.close() ---------- components: email messages: 287662 nosy: David Ford (FirefighterBlu3), barry, r.david.murray priority: normal severity: normal status: open title: [smtplib] collect response data for all recipients type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 21:04:34 2017 From: report at bugs.python.org (Alex Gordon) Date: Mon, 13 Feb 2017 02:04:34 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps Message-ID: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> New submission from Alex Gordon: Broadly speaking, there are three main output styles for json.dump/dumps: 1. Default: json.dumps(obj) 2. Compact: json.dumps(obj, separators=(',', ':')) 3. Pretty-printing: json.dumps(obj, sort_keys=True, indent=4) The 'compact' style is the densest, suitable if the JSON is to be sent over the network, archived on disk, or otherwise consumed by a machine. The pretty-printed style is for human consumption: configuration files, debugging, etc. Even though the compact style is often desirable, the API for producing it is unforgiving. It's easy to accidentally write code like the following, which silently produces invalid nonsense: json.dumps(obj, separators=(':', ',')) I propose the addition of a new flag `compact=True`, that simply sets `separators=(',', ':')`. e.g. >>> obj = {"foo": 1, "bar": 2} >>> json.dumps(obj, compact=True) '{"foo":1,"bar":2}' The defaults for `separators=` are good, so eventually `compact=` would relegate `separators=` to obscurity. Setting both `compact=True` and `separators=` at the same time should be an error. ---------- components: Library (Lib) messages: 287663 nosy: Alex Gordon priority: normal severity: normal status: open title: Add compact=True flag to json.dump/dumps type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 22:28:26 2017 From: report at bugs.python.org (Benjamin Gilbert) Date: Mon, 13 Feb 2017 03:28:26 +0000 Subject: [issue29424] Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks In-Reply-To: <1486071181.22.0.61090318362.issue29424@psf.upfronthosting.co.za> Message-ID: <1486956506.87.0.34100587868.issue29424@psf.upfronthosting.co.za> Changes by Benjamin Gilbert : ---------- nosy: +bgilbert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 22:42:21 2017 From: report at bugs.python.org (Thomas Caswell) Date: Mon, 13 Feb 2017 03:42:21 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1486957341.89.0.316212955585.issue29481@psf.upfronthosting.co.za> Thomas Caswell added the comment: I agree this is very confusing (and in fact confused me for about an hour between getting import errors, double checking the docs, checking I was in the right env, double checking the docs, checking the source of my env, double checking the docs, checking the git source and then tracking through these too issues). ---------- nosy: +tcaswell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 23:45:12 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 13 Feb 2017 04:45:12 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486961112.44.0.354044874696.issue29514@psf.upfronthosting.co.za> ?ukasz Langa added the comment: I commented on the original issue where the magic number was changed. This broke the world at work for me. Our distribution mechanism for Python programs is zipped bundles of .pyc and .so files, the optimized variant doesn't keep .py files around. So suddenly otherwise correct bundles were refusing to start. Better yet, since the rollout of Python is staged and takes a while to do safely, new packages started appear with the new magic number that were refusing to start on 3.5.0. This was not a fun day :) So, while I understand Brett's and Serhiy's reasoning, I'd be very careful about ever bumping magic numbers in minor releases again, and definitely communicate loudly if doing so. Oh, if you're wondering why I even hit this problem before 3.5.3: since 3.5.2 had a few regressions we couldn't live with, I released 3.5.2+ from the latest commit on the 3.5 branch at the time (after checking the buildbots, running tests on our own, etc.). I repeated this feat with 3.6.0+ and again hit a thing that would likely upset some people in 3.6.1 (see #29519) but this time decided to patch it instead of just complaining ;) ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 00:00:09 2017 From: report at bugs.python.org (Thomas Caswell) Date: Mon, 13 Feb 2017 05:00:09 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1486962009.4.0.432438333312.issue29481@psf.upfronthosting.co.za> Changes by Thomas Caswell : ---------- pull_requests: +50 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 02:52:24 2017 From: report at bugs.python.org (=?utf-8?q?Honza_Sk=C3=BDpala?=) Date: Mon, 13 Feb 2017 07:52:24 +0000 Subject: [issue29541] Python3 error while building on Alt-F Message-ID: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> New submission from Honza Sk?pala: While trying to build Python 3.6.0 on emmbedded Linux device ? D-Link DNS-320L running Alt-F firmware (Linux 3.18.28 #1 Fri Jun 17 14:44:39 WEST 2016 armv5tel GNU/Linux), it fails with ./python: can't resolve symbol 'crypt' make: *** [sharedmods] Error 1 I can see the python executable is compiled fine in the source directory, if I try to run it, then it does work, including some quick tests (calculations, os.getcwd, random.randint -- works fine). I can also see that compiling the crypt modules did not report any errors and the .o file is present on the disk. I guess it is some kind of linking error? Attaching the log from the build. ---------- components: Build files: build.log messages: 287666 nosy: Honza Sk?pala priority: normal severity: normal status: open title: Python3 error while building on Alt-F type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file46636/build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 03:04:53 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 08:04:53 +0000 Subject: [issue29541] Python3 error while building on Alt-F In-Reply-To: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> Message-ID: <1486973093.91.0.825773289779.issue29541@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: My patch at https://hg.python.org/cpython/rev/ca2f024ce7cb may help. It points out missing symbols earlier. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 04:13:19 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 09:13:19 +0000 Subject: [issue29538] bugs.python.org does not redirect to HTTPS In-Reply-To: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> Message-ID: <1486977199.49.0.409386829024.issue29538@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Duplicate of http://psf.upfronthosting.co.za/roundup/meta/issue463 ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 04:35:20 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 09:35:20 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486978520.15.0.568258191212.issue29514@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 04:39:30 2017 From: report at bugs.python.org (=?utf-8?q?Honza_Sk=C3=BDpala?=) Date: Mon, 13 Feb 2017 09:39:30 +0000 Subject: [issue29541] Python3 error while building on Alt-F In-Reply-To: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> Message-ID: <1486978770.96.0.737156209714.issue29541@psf.upfronthosting.co.za> Honza Sk?pala added the comment: Hi Chi Hsuan Yen, thanks for trying to help, unfortunately no change, still getting the same error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 04:45:50 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 09:45:50 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486979150.82.0.576621319854.issue29514@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Nick] > "Requires a mass rebuild of all the Python packages in the distro to get things working properly again" is again a major concern for what's nominally a low impact maintenance update. With my Enthought developer hat on, I'd like to second this comment. We'll shortly be shipping Python 3.5.2 in Enthought Canopy, and this bytecode change presents us with a major issue to resolve (internal discussion about how to do so is ongoing). If/when we make 3.5.3 available, and the user upgrades their core Python, all user-installed 3rd party packages become semi-broken, and we potentially need to ask the user to upgrade many hundreds of packages. (We also need to rebuild and re-test all those packages for our own repository, which is a time-consuming process.) [?ukasz] > I'd be very careful about ever bumping magic numbers in minor releases again, and definitely communicate loudly if doing so. Also seconded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:17:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Feb 2017 10:17:46 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: Message-ID: Nick Coghlan added the comment: Given some of the other folks encountering problems, perhaps Petr's patch to accept both magic numbers should be submitted upstream so it's the default in 3.5.4+? And then we ask Larry and the other release management folks nicely for an early 3.5.4 release? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:21:19 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Feb 2017 10:21:19 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486940072.58.0.371942510312.issue29514@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: On 12 Feb 2017 11:54 pm, "Serhiy Storchaka" wrote: Serhiy Storchaka added the comment: I don't understand how the table can make maintaining easier. You need to support multiple values in every branch even if the only one value is used. I'm sure unused values will became outdated pretty fast. "alpha" and "beta" stages are not related here. The test should be skipped at these stages (I recommend to use skipTest() or the skipUnless() decorator rather than just make test always success). Magic number can be changed multiple times at "alpha" and "beta" stages. Release manager needs to update the test only when forming the first release candidate. And his should not do anything if the magic number was not changed in this feature release. Serhiy's argument here & the fact we've switched to a cherrypick model for maintenance branches has persuaded me we just want a single "expected magic number" in the test case rather than the full table that covers multiple releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:28:32 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 10:28:32 +0000 Subject: [issue29538] bugs.python.org does not redirect to HTTPS In-Reply-To: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> Message-ID: <1486981712.62.0.179332401443.issue29538@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:33:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Feb 2017 10:33:33 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1486982013.64.0.592867625388.issue29532@psf.upfronthosting.co.za> INADA Naoki added the comment: patch LGTM. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:35:03 2017 From: report at bugs.python.org (Vladimir Shebunyaev) Date: Mon, 13 Feb 2017 10:35:03 +0000 Subject: [issue29542] python -m spacy.en.download undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz Message-ID: <1486982103.81.0.103428043844.issue29542@psf.upfronthosting.co.za> New submission from Vladimir Shebunyaev: I have (python 2.7.13 Anaconda 4.3.0 64bit Ubuntu 16 ) tried python -m spacy.en.download and got /home/vshebuniayeu/anaconda2/bin/python: /home/vshebuniayeu/anaconda2/lib/python2.7/site-packages/spacy/serialize/huffman.so: undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz ---------- messages: 287674 nosy: Vladimir Shebunyaev priority: normal severity: normal status: open title: python -m spacy.en.download undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:39:48 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 10:39:48 +0000 Subject: [issue29542] python -m spacy.en.download undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz In-Reply-To: <1486982103.81.0.103428043844.issue29542@psf.upfronthosting.co.za> Message-ID: <1486982388.76.0.491325694477.issue29542@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, but spacy is not part of the Python standard library. Please report your problem to spacy developers. ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:41:00 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 10:41:00 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486982460.02.0.308825668491.issue29514@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Nick] > perhaps Petr's patch to accept both magic numbers should be submitted upstream so it's the default in 3.5.4+? [...] Enthought's primary buildsystem maintainer is unfortunately out of contact for the week, so I can't speak with any authority on this, but I believe that we'd find this helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:57:06 2017 From: report at bugs.python.org (Andrew Nester) Date: Mon, 13 Feb 2017 10:57:06 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486983426.91.0.109560999759.issue29534@psf.upfronthosting.co.za> Andrew Nester added the comment: I've just added PR for this issue. ---------- nosy: +andrewnester pull_requests: +51 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 06:06:45 2017 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 13 Feb 2017 11:06:45 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486984005.84.0.504474930058.issue29514@psf.upfronthosting.co.za> Petr Viktorin added the comment: > perhaps Petr's patch to accept both magic numbers should be submitted upstream so it's the default in 3.5.4+? I don't think it can be submitted in the current state; it's a one-time hack intended to be removed and forgotten at the end of 3.5's lifetime. I could write a patch with proper support for accepting a range of magic numbers, but such a feature probably won't be needed again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 06:26:40 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 11:26:40 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486985200.68.0.0358197571045.issue29514@psf.upfronthosting.co.za> Mark Dickinson added the comment: > it's a one-time hack intended to be removed and forgotten at the end of 3.5's lifetime. Fair enough. If necessary, one of our options is to apply that patch or something like it to the Python executables that we distribute for Canopy. But in general, staying as close as possible to the upstream Python is desirable, so if there were a possibility for it to go into upstream Python, that would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 06:58:26 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 11:58:26 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486987106.13.0.0689494355729.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: Is there an observable difference in user behaviour if no subclassing of Decimal is involved? Or does this just affect Decimal subclasses? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:03:38 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 12:03:38 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486987418.55.0.887259549446.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: BTW, as a user, I'd expect `Decimal.from_float` to simply coerce its input to float if given an input that isn't actually a float in the first place; the fact that it has special handling in place for int inputs (and that that special handling takes the form of an isinstance check, rather than something more duck-typed) is surprising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:04:27 2017 From: report at bugs.python.org (Andrew Nester) Date: Mon, 13 Feb 2017 12:04:27 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486987467.57.0.152327158701.issue29534@psf.upfronthosting.co.za> Andrew Nester added the comment: actually, it's more related to subclassing, because the problem comes from the fact that before the fix __init__ method receives value as int not Decimal if int passed to from_float call. That's why only subclasses of Decimal can see difference in arguments received by __init__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:06:05 2017 From: report at bugs.python.org (Andrew Nester) Date: Mon, 13 Feb 2017 12:06:05 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486987565.06.0.0762292436502.issue29534@psf.upfronthosting.co.za> Andrew Nester added the comment: Agree about surprising behaviour but I guess it's better to fix it as other issue because it could break BC in some cases. At least it needs to be investigated. For now I would like to stick with same behaviour for _decimal and _pydecimal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:23:28 2017 From: report at bugs.python.org (Frak N) Date: Mon, 13 Feb 2017 12:23:28 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1486988608.85.0.337469157281.issue29525@psf.upfronthosting.co.za> Frak N added the comment: Excellent analysis guys! Thank you! The -X faulthandler option didn't work. The -S -v, however, did. Finally, renaming and deleting the readline entries fixed it such that I can now launch the REPL. Question. What does " disables the site module" for the -S option mean? Now, what do I do about the (py)readline issue? Do I need to reinstall something? Logs below: c:\Python27>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. c:\Python27>python -X faulthandler -S -v -X is reserved for implementation-specific arguments usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. c:\Python27>python -X -X is reserved for implementation-specific arguments usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. c:\Python27>python -X -faulthandler -S -v -X is reserved for implementation-specific arguments usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. c:\Python27>python -S -v # installing zipimport hook import zipimport # builtin # installed zipimport hook Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 >>> ^Z # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # clear sys.flags # clear sys.float_info # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] zipimport # cleanup[1] signal # cleanup[1] exceptions # cleanup[1] _warnings # cleanup sys # cleanup __builtin__ # cleanup ints: 6 unfreed ints # cleanup floats c:\Python27>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. c:\Python27>ren C:\Python27\Lib\site-packages\readline.py readline.py.bak c:\Python27>del C:\Python27\Lib\site-packages\readline.pyc c:\Python27>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:29:48 2017 From: report at bugs.python.org (Iryna) Date: Mon, 13 Feb 2017 12:29:48 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486988988.92.0.884375454713.issue29514@psf.upfronthosting.co.za> Changes by Iryna : ---------- nosy: +ishcherb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:30:00 2017 From: report at bugs.python.org (Iryna) Date: Mon, 13 Feb 2017 12:30:00 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1486989000.19.0.459400278569.issue29537@psf.upfronthosting.co.za> Changes by Iryna : ---------- nosy: +ishcherb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 07:30:07 2017 From: report at bugs.python.org (Iryna) Date: Mon, 13 Feb 2017 12:30:07 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1486989007.44.0.626072370888.issue27286@psf.upfronthosting.co.za> Changes by Iryna : ---------- nosy: +ishcherb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:00:02 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 13:00:02 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1486990802.22.0.849714091523.issue29537@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:04:03 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Feb 2017 13:04:03 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1486991042.99.0.385665376871.issue29540@psf.upfronthosting.co.za> R. David Murray added the comment: An alternative would be to define a COMPACT constant in the json module equal to (',', ':'). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:04:43 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Feb 2017 13:04:43 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1486991083.63.0.465002180752.issue29410@psf.upfronthosting.co.za> INADA Naoki added the comment: Christian Heimes: Could you create pull request? https://github.com/tiran/cpython/tree/siphash13 is 404 now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:05:31 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 13 Feb 2017 13:05:31 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486991131.61.0.776170907196.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Andrew] > it's better to fix it as other issue No, it's better not to "fix" it at all. :-) It's one of those many behaviour changes where the answer to "Should we have done this differently in the first place" might possibly be "Yes" (and might also be "No"), but the answer to "Should we *change* it now" is a definite "No" (especially given that the "from_float" method is there almost entirely for backwards compatibility). I shouldn't have brought it up. Apologies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:08:01 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 13 Feb 2017 13:08:01 +0000 Subject: [issue29410] Moving to SipHash-1-3 In-Reply-To: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> Message-ID: <1486991281.56.0.497792566727.issue29410@psf.upfronthosting.co.za> Christian Heimes added the comment: The old repos has a different name, https://github.com/tiran/cpython-mirror I'm busy with work at the moment. I'll get to the patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:10:05 2017 From: report at bugs.python.org (Andrew Nester) Date: Mon, 13 Feb 2017 13:10:05 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1486991405.59.0.975452820617.issue29534@psf.upfronthosting.co.za> Andrew Nester added the comment: thanks for your notes, it's absolutely fine and I agree with you :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:28:47 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 13:28:47 +0000 Subject: [issue29541] Python3 error while building on Alt-F In-Reply-To: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> Message-ID: <1486992527.31.0.0484550356554.issue29541@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: That's super strange. crypt() is used in _crypt module only, and this modules is not used elsewhere in Python. A few more tests may help diagnostics 1. What's the result of ```./python -E```? 2. Does `import crypt` run fine in ./python? 3. Are there pre-installed Python on Alt-F? Uninstall them first may help 4. Is there a symbol called crypt in `nm ./python`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:33:32 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 13:33:32 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486992812.92.0.925613237137.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I've found a simpler patch set for supporting Android builds, so I don't need this patch anymore. If you don't think it's necessary, just close it. > usage of os.system() in some places I'm indeed sick with them :D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:54:31 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 13 Feb 2017 13:54:31 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1486994071.87.0.265231706701.issue29523@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Pull Request has been sent: https://github.com/python/cpython/pull/67 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 08:57:15 2017 From: report at bugs.python.org (Brian Curtin) Date: Mon, 13 Feb 2017 13:57:15 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1486994235.64.0.358662201209.issue29387@psf.upfronthosting.co.za> Brian Curtin added the comment: New changeset 3d707be950b387552585451071928e7b39cdfa53 by Brian Curtin in branch 'master': bpo-29521 Fix two minor documentation build warnings (#41) https://github.com/python/cpython/commit/3d707be950b387552585451071928e7b39cdfa53 ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 09:02:23 2017 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 13 Feb 2017 14:02:23 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1486994543.04.0.0356726014674.issue29514@psf.upfronthosting.co.za> Petr Viktorin added the comment: In Fedora also want to stay close to upstream: every downstream patch is like an open issue, something we'd like to merge given enough time and people. But, for a problem that: - is fixed in the latest version (3.6) - is getting a test to not happen again - only affects downstream distributions I'm fine with a downstream patch. I'd also be happy to work on making the patch acceptable upstream, but I need to hear some core devs' expectations on that. Where on the spectrum from throwaway hack to full-scale mechanism for accepting ranges of magic numbers should such a patch patch be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 09:19:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 13 Feb 2017 14:19:10 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1486995550.59.0.231934877122.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: The commit 3d707be950b387552585451071928e7b39cdfa53 broke the Docs buildbot slave. I proposed https://github.com/python/cpython/pull/68 to run the rstlint.py check on Travis as well, and to fix the 2 warnings. http://buildbot.python.org/all/builders/Docs%203.x/builds/399/steps/lint/logs/stdio python3 tools/rstlint.py -i tools -i venv [1] faq/windows.rst:303: trailing whitespace [1] faq/windows.rst:305: trailing whitespace 2 problems with severity 1 found. Makefile:156: recipe for target 'check' failed ---------- nosy: +haypo pull_requests: +52 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 09:27:04 2017 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Feb 2017 14:27:04 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486996024.91.0.455020577364.issue29442@psf.upfronthosting.co.za> Stefan Krah added the comment: It's not a matter of *necessary*, you simply cannot use argparse in setup.py. Try to build with your patch and you'll see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 09:31:29 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Feb 2017 14:31:29 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486921344.94.0.483523353541.issue29514@psf.upfronthosting.co.za> Message-ID: <20170213093125.51552a37@subdivisions.wooz.org> Barry A. Warsaw added the comment: On Feb 12, 2017, at 05:42 PM, Brett Cannon wrote: >That comment is poorly worded. Pretty sure at one time it was accurately worded, but things have changed since PEP 3147 so the comment could use an update. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 09:51:43 2017 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Feb 2017 14:51:43 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486997503.25.0.458907031927.issue29442@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:01:46 2017 From: report at bugs.python.org (Paul Schreiber) Date: Mon, 13 Feb 2017 15:01:46 +0000 Subject: [issue29538] bugs.python.org does not redirect to HTTPS In-Reply-To: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> Message-ID: <1486998106.74.0.592350068011.issue29538@psf.upfronthosting.co.za> Paul Schreiber added the comment: The issue you linked to: http://psf.upfronthosting.co.za/roundup/meta/issue463 covers psf.upfronthosting.co.za (which doesn't support HTTPS at all) and not bugs.python.org (which supports, but does not enforce HTTPS). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:02:37 2017 From: report at bugs.python.org (Paul Schreiber) Date: Mon, 13 Feb 2017 15:02:37 +0000 Subject: [issue29543] Allow login to bugs.python.org with email address Message-ID: <1486998157.34.0.838139169099.issue29543@psf.upfronthosting.co.za> New submission from Paul Schreiber: Allow users to log in to bugs.python.org with the email address in the username field. ---------- messages: 287699 nosy: paulschreiber priority: normal severity: normal status: open title: Allow login to bugs.python.org with email address type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:04:09 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 15:04:09 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1486998249.74.0.844654258053.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I have used my old patch several days on Android, and it seems quite fine. Anyway that's not important anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:07:47 2017 From: report at bugs.python.org (Paul Schreiber) Date: Mon, 13 Feb 2017 15:07:47 +0000 Subject: [issue29544] Allow login to bugs.python.org with Google account Message-ID: <1486998467.47.0.572774798613.issue29544@psf.upfronthosting.co.za> New submission from Paul Schreiber: I created a standard account on bugs.python.org with username paulschreiber and email address paulschreiber at gmail.com. Later, I attempted to log in to bugs.python.org using Google and was shown an error message: There is already an account for paulschreiber at gmail.com Instead of showing me the error message, I should have been logged in. ---------- messages: 287701 nosy: paulschreiber priority: normal severity: normal status: open title: Allow login to bugs.python.org with Google account type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:09:41 2017 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Feb 2017 15:09:41 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486998249.74.0.844654258053.issue29442@psf.upfronthosting.co.za> Message-ID: <20170213150927.GA5671@bytereef.org> Stefan Krah added the comment: On Mon, Feb 13, 2017 at 03:04:09PM +0000, Chi Hsuan Yen wrote: > > Chi Hsuan Yen added the comment: > > I have used my old patch several days on Android, and it seems quite fine. Anyway that's not important anymore. I find that very surprising: ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "./setup.py", line 4, in import sys, os, importlib.machinery, re, argparse File "/home/stefan/althome/pydev/commit-master-LATEST/Lib/argparse.py", line 93, in from gettext import gettext as _, ngettext File "/home/stefan/althome/pydev/commit-master-LATEST/Lib/gettext.py", line 49, in import locale, copy, io, os, re, struct, sys File "/home/stefan/althome/pydev/commit-master-LATEST/Lib/struct.py", line 13, in from _struct import * ModuleNotFoundError: No module named '_struct' Yes, it is important, because you called the original a "dirty hack", which some core devs do not appreciate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:12:18 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 15:12:18 +0000 Subject: [issue29538] bugs.python.org does not redirect to HTTPS In-Reply-To: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> Message-ID: <1486998738.13.0.570654423312.issue29538@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: >From CPython's developer guide [1]: "Issues about the tracker should be reported to the meta tracker." > which doesn't support HTTPS at all I don't know where I should go for issues about the meta tracker. Maybe a meta-meta tracker? :D [1] http://cpython-devguide.readthedocs.io/tracker.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:31:56 2017 From: report at bugs.python.org (Sanket Dasgupta) Date: Mon, 13 Feb 2017 15:31:56 +0000 Subject: [issue21056] csv documentation is incorrect In-Reply-To: <1395720703.0.0.19592596057.issue21056@psf.upfronthosting.co.za> Message-ID: <1486999916.05.0.991825834561.issue21056@psf.upfronthosting.co.za> Sanket Dasgupta added the comment: Hi, I am looking to fix this bug. So as per the discussion, should I remove the documentation of __next__() ? ---------- nosy: +sanketdg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:46:04 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 13 Feb 2017 15:46:04 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487000764.66.0.443968727541.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: You're right. argparse has indirect dependency on dynamic modules so it can't be used in setup.py. Cross builds use prebuilt Python binaries so there's no problem. Sorry for those noises. I still think it's a dirty hack as it limits scalability and brings lots of problems when adding new features, but I can't find a good way to remove it :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:46:52 2017 From: report at bugs.python.org (Gireesh) Date: Mon, 13 Feb 2017 15:46:52 +0000 Subject: [issue29545] Python behavioral difference between Linux and AIX Message-ID: New submission from Gireesh: Here is my python code (parent): #!/usr/bin/env python import errno import os import pty from subprocess import Popen, STDOUT master_fd, slave_fd = pty.openpty() proc = Popen(['./a.out'],stdout=slave_fd, close_fds=True) os.close(slave_fd) data = os.read(master_fd, 512) print('got ' + repr(data)) Child(C++): #include #include #include int main() { printf("hello world\n"); exit(0); } behavior: Linux: got 'hello world\r\r\n' AIX: Hangs. versions: Linux: Linux 2.6.32-131.12.1.el6.x86_64 #1 SMP Sun Jul 31 16:44:56 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux AIX: 1 6 00F460A94C00 Python: 2.7.10 ---------- messages: 287706 nosy: gireeshpunathil priority: normal severity: normal status: open title: Python behavioral difference between Linux and AIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:51:42 2017 From: report at bugs.python.org (Andrew Nester) Date: Mon, 13 Feb 2017 15:51:42 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487001102.96.0.301383338368.issue29540@psf.upfronthosting.co.za> Andrew Nester added the comment: I've just added PR implementing alternative version provided by R. David Murray as more simple and straight-forward one. ---------- nosy: +andrewnester pull_requests: +53 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:30:11 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Feb 2017 16:30:11 +0000 Subject: [issue29546] A more helpful ImportError message Message-ID: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: I haven't really thought about this deeply but I've observed that there are lots of cases where a user will report getting an ImportError trying to import a name from a module, where it turns out that the problem is that the module is coming from an unexpected location. Examples include pip installed packages overriding system packages, or unexpected vendorized wheels. The standard first response is typically, "can you please run this to tell us where the foo library is coming from?" E.g. ``` ^^ this is indicative of an old version of urllib3. Can you please double check whether you have an old urllib3 installed e.g. in /usr/local or ~/. Testing: $ python3 -c 'import urllib3; print(urllib3.__file__)' should return: /usr/lib/python3/dist-packages/urllib3/__init__.py and might tell you where else a locally installed urllib3 is to be found if it doesn't return that value. ``` It would be kind of useful if the original ImportError showed you where the module came from (i.e. its __file__), if such information can be discerned. E.g.: ``` >>> import requests; requests.__version__.split('.') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 61, in from .packages.urllib3.exceptions import DependencyWarning ImportError: cannot import name DependencyWarning from requests.packages.urllib3.exceptions (/usr/local/lib/python3.5/site-packages/requests/packages/urllib3.py) ``` If you saw that in a bug report, you'd almost immediately know that the user has some local override that's potentially causing the problem. ---------- components: Interpreter Core messages: 287708 nosy: barry priority: normal severity: normal status: open title: A more helpful ImportError message versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:33:17 2017 From: report at bugs.python.org (Eric N. Vander Weele) Date: Mon, 13 Feb 2017 16:33:17 +0000 Subject: [issue29545] Python behavioral difference between Linux and AIX In-Reply-To: Message-ID: <1487003597.42.0.22986484527.issue29545@psf.upfronthosting.co.za> Changes by Eric N. Vander Weele : ---------- nosy: +ericvw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:50:40 2017 From: report at bugs.python.org (Davin Potts) Date: Mon, 13 Feb 2017 16:50:40 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1487004640.19.0.212799222938.issue19675@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- versions: +Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:50:29 2017 From: report at bugs.python.org (Davin Potts) Date: Mon, 13 Feb 2017 16:50:29 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1487004629.55.0.94843992283.issue19675@psf.upfronthosting.co.za> Davin Potts added the comment: @Winterflower: Thank you for encouraging @dsoprea to create the new PR and working to convert the previous patch. @dsoprea: Thank you for taking the time to create the PR especially after this has been sitting unloved for so long. Though the new workflow using PR's is still in a bit of a state of flux, my understanding is that we will want to have one PR per feature branch (i.e. one for each of 2.7, 3.6, 3.7) that we want to target. Now that we seem to have spawned two parallel discussion tracks (one here and one in the PR https://github.com/python/cpython/pull/57), I'm not sure how best to resolve that but for the time being I'll offer code-related comments here as they're much more likely to be preserved (and thus discoverable) for posterity: we do need some sort of tests around this to complete the patch -- something that would exercise both the non-exception and exception paths (and thus would detect that intended call to util.debug()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:54:51 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 13 Feb 2017 16:54:51 +0000 Subject: [issue29547] Add c code coverage to codecov Message-ID: <1487004891.23.0.966480827994.issue29547@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: I had it done in my fork of cpython-mirror: https://github.com/abalkin/cpython/tree/ci ---------- assignee: belopolsky components: Tests messages: 287710 nosy: belopolsky priority: normal severity: normal status: open title: Add c code coverage to codecov versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:00:12 2017 From: report at bugs.python.org (Dustin Oprea) Date: Mon, 13 Feb 2017 17:00:12 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1487004640.22.0.448907271959.issue19675@psf.upfronthosting.co.za> Message-ID: Dustin Oprea added the comment: Okay. Thanks for weighing-in. I'm trying to figure out how to write the tests. The existing set of tests for multiprocessing is a near nightmare. It seems like I might have to use one of the existing "source code" definitions to test for the no-cleanup (traditional) scenario but then have to define a new one to define the pool with an initializer that fails. However, then, I'll have to define three new TestCase-based classes to test for the various start-methods. Any suggestions? On Mon, Feb 13, 2017 at 11:50 AM, Davin Potts wrote: > > Changes by Davin Potts : > > > ---------- > versions: +Python 2.7, Python 3.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:19:23 2017 From: report at bugs.python.org (Davin Potts) Date: Mon, 13 Feb 2017 17:19:23 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1487006363.0.0.0348355093815.issue19675@psf.upfronthosting.co.za> Davin Potts added the comment: For triggering the exception, supplying a Process target that deliberately fails sounds right. As for tests for the various start methods (fork/forkserver/spawn), if you are looking at the 3.x branches you'll find this was been consolidated so that one test could conceivably be written to handle multiple variants (see Lib/test/_test_multiprocessing.py). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:35:33 2017 From: report at bugs.python.org (Eric Snow) Date: Mon, 13 Feb 2017 17:35:33 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1487007333.19.0.416850680537.issue29514@psf.upfronthosting.co.za> Eric Snow added the comment: > These files *do not* belong to the CPython package, they belong to the > individual Python modules that depend on CPython, so messing with them > when installing a new version of CPython would be a significant breach > of distro policies. Thanks for clarifying, Nick. This was the piece I'd missed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:36:52 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Feb 2017 17:36:52 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. Message-ID: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> New submission from INADA Naoki: As reading call.c, PyEval_Call* APIs are mostly duplicate of PyObject_Call* APIs. While they are not documented, they seems part of limited APIs. So we can't remove them easily. Let's deprecate them for now. ---------- components: Interpreter Core messages: 287714 nosy: inada.naoki priority: normal severity: normal status: open title: deprecate PyEval_Call*() functions. versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:38:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Feb 2017 17:38:21 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487007501.79.0.580198029727.issue29548@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +54 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:40:58 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 13 Feb 2017 17:40:58 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1487007658.82.0.13526446228.issue27593@psf.upfronthosting.co.za> Steve Dower added the comment: This is now blocking all releases for all versions. I'll try and make some time to update the Windows build scripts and project files, but if someone else gets there first feel free to post a PR. ---------- nosy: +benjamin.peterson, larry, steve.dower priority: deferred blocker -> release blocker versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:08:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Feb 2017 18:08:08 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487009288.55.0.243830994292.issue29540@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm -1. This adds the maintenance and learning burden and doesn't make the user code more clear. The reader needs to search what json.COMPACT means. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:10:11 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 13 Feb 2017 18:10:11 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487009411.82.0.135141539582.issue29548@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please note that the two sets of APIs are not identical, e.g. you cannot simply replace PyEval_CallObject() with PyObject_Call(), since the former applies a few extra checks and defaults, which the latter doesn't. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:20:49 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Feb 2017 18:20:49 +0000 Subject: [issue29518] 'for' loop not automatically breaking (index error on line of loop header) In-Reply-To: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> Message-ID: <1487010049.3.0.732382838507.issue29518@psf.upfronthosting.co.za> Brett Cannon added the comment: Since Justin can't provide the original email, it could have been his setup, and the chances that range() is broken on Python 2.7 is extremely small, I'm closing this as not a bug. ---------- nosy: +brett.cannon resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:24:50 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Feb 2017 18:24:50 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487010290.21.0.630767463619.issue29546@psf.upfronthosting.co.za> Brett Cannon added the comment: So 'path' already exists on ImportError so tweaking the message when the path is known wouldn't be difficult (https://docs.python.org/3/library/exceptions.html?highlight=importerror#ImportError). ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:24:56 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Feb 2017 18:24:56 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487010296.21.0.479290643548.issue29546@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:30:07 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Feb 2017 18:30:07 +0000 Subject: [issue29547] Add c code coverage to codecov In-Reply-To: <1487004891.23.0.966480827994.issue29547@psf.upfronthosting.co.za> Message-ID: <1487010607.72.0.0541765158495.issue29547@psf.upfronthosting.co.za> Brett Cannon added the comment: I have https://github.com/python/core-workflow/issues/2 sitting open for this specific idea. :) If Codecov will do the appropriate merging between coverage.py and lcov then I think it's worth a PR to set it up. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 13:55:10 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 18:55:10 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487012110.37.0.488956685578.issue29520@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch type: compile error -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 14:04:29 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 19:04:29 +0000 Subject: [issue26213] Document BUILD_*_UNPACK opcodes In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za> Message-ID: <1487012669.93.0.493489790377.issue26213@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 14:19:03 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 19:19:03 +0000 Subject: [issue29543] Allow login to bugs.python.org with email address In-Reply-To: <1486998157.34.0.838139169099.issue29543@psf.upfronthosting.co.za> Message-ID: <1487013543.66.0.00445547658539.issue29543@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. Feature requests about bugs.python.org should be reported to http://psf.upfronthosting.co.za/roundup/meta/ ---------- nosy: +berker.peksag stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 14:20:38 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 19:20:38 +0000 Subject: [issue29544] Allow login to bugs.python.org with Google account In-Reply-To: <1486998467.47.0.572774798613.issue29544@psf.upfronthosting.co.za> Message-ID: <1487013638.97.0.272292447832.issue29544@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. Feature requests about bugs.python.org should be reported to http://psf.upfronthosting.co.za/roundup/meta/ ---------- nosy: +berker.peksag stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 15:12:06 2017 From: report at bugs.python.org (=?utf-8?q?Honza_Sk=C3=BDpala?=) Date: Mon, 13 Feb 2017 20:12:06 +0000 Subject: [issue29541] Python3 error while building on Alt-F In-Reply-To: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> Message-ID: <1487016726.76.0.109290778009.issue29541@psf.upfronthosting.co.za> Honza Sk?pala added the comment: 1. What's the result of ```./python -E```? Python 3.6.0 (default, Feb 13 2017, 08:16:44) [GCC 4.5.4 20120202 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. 2. Does `import crypt` run fine in ./python? No, gives the error ./python: can't resolve symbol 'crypt' 3. Are there pre-installed Python on Alt-F? Uninstall them first may help No, there is no python preinstalled (no python3, not even python2) 4. Is there a symbol called crypt in `nm ./python`? No, `nm ./python | grep crypt` gives no results ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 15:54:25 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Feb 2017 20:54:25 +0000 Subject: [issue29403] mock's autospec's behavior on method-bound builtin functions is broken In-Reply-To: <1485903715.23.0.569013669104.issue29403@psf.upfronthosting.co.za> Message-ID: <1487019265.48.0.234952851988.issue29403@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag, michael.foord stage: -> patch review versions: -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 15:57:22 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 Feb 2017 20:57:22 +0000 Subject: [issue29549] Improve docstring for str.index Message-ID: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The docstring for str.index() needs to be synced with the main documentation rather than presuming knowledge of str.find(). Currently it reads: >>> help(str.index) Help on method_descriptor: index(...) S.index(sub[, start[, end]]) -> int Like S.find() but raise ValueError when the substring is not found. And it should read more like str.find: help(str.find) Help on method_descriptor: find(...) S.find(sub[, start[, end]]) -> int Return the lowest index in S where substring sub is found, such that sub is contained within S[start:end]. Optional arguments start and end are interpreted as in slice notation. Return -1 on failure. Lisa, it would be great if you could draft-up a patch. ---------- assignee: lisroach components: Documentation messages: 287724 nosy: lisroach, rhettinger priority: normal severity: normal stage: needs patch status: open title: Improve docstring for str.index versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 16:14:39 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Feb 2017 21:14:39 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1487020479.41.0.903444561684.issue27593@psf.upfronthosting.co.za> Ned Deily added the comment: Yeah, I'll get to the non-Windows parts shortly. I'd been waiting for the transition to happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 16:24:46 2017 From: report at bugs.python.org (David Bolen) Date: Mon, 13 Feb 2017 21:24:46 +0000 Subject: [issue29550] Mac build-installer touch step fails after github conversion Message-ID: <1487021086.07.0.216604793795.issue29550@psf.upfronthosting.co.za> New submission from David Bolen: The "make touch" step during the Mac installer builds on the bolen-dmg build slave no longer works after the conversion to github, which breaks the daily builds on the 3.* branches. It looks like in issue 23404 Zachary disabled the touch step for the buildbots for now to avoid the issue in general builds, so perhaps the same thing should be done in build-installer pending a more general replacement of that step. ---------- components: Build messages: 287726 nosy: db3l, ned.deily, zach.ware priority: normal severity: normal status: open title: Mac build-installer touch step fails after github conversion type: compile error versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 16:27:19 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Feb 2017 21:27:19 +0000 Subject: [issue29550] Mac build-installer touch step fails after github conversion In-Reply-To: <1487021086.07.0.216604793795.issue29550@psf.upfronthosting.co.za> Message-ID: <1487021239.99.0.934108569717.issue29550@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, I'll take a look. ---------- assignee: -> ned.deily nosy: +larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 16:54:01 2017 From: report at bugs.python.org (John W.) Date: Mon, 13 Feb 2017 21:54:01 +0000 Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in two same calls In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za> Message-ID: <1487022841.93.0.27570819549.issue26752@psf.upfronthosting.co.za> John W. added the comment: This also seems to apply to unittest.mock in Python3.4. I described my similar issue on SO: http://stackoverflow.com/questions/42212433/what-is-wrong-with-this-simple-py-test-use-case It seems like it may be the same issue described here. For reference, this is my repro case: from unittest.mock import patch, call class Foo: def __init__(self): pass def my_method(self, value): pass def test_foo(): with patch('test.Foo', autospec=True) as MockFoo: m = MockFoo() m.my_method(123) MockFoo.assert_has_calls([call(), call().my_method(123)]) It fails with: ... E AssertionError: Calls not found. E Expected: [call(), call().my_method(123)] E Actual: [call(), call().my_method(123)] Which seems nonsensical to me. Removing the `value` parameter and the `123` arguments in the test makes it pass(!) ---------- nosy: +jwdevel versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 17:36:10 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 13 Feb 2017 22:36:10 +0000 Subject: [issue28941] Update the link to Source Code in Python Docs from hg to github In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za> Message-ID: <1487025370.5.0.820277038282.issue28941@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: This was addressed in the very first pull request on CPython GitHub (Thanks, Brett ) Backported to 2.7, 3.5, and 3.6 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 18:18:59 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 13 Feb 2017 23:18:59 +0000 Subject: [issue11339] annotation for class being defined In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za> Message-ID: <1487027939.29.0.807817304771.issue11339@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 20:26:07 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 14 Feb 2017 01:26:07 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487035567.12.0.69824273701.issue29481@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, we should put versionadded in the docs to augment the MISC/NEWS entries. Mariatta, do you want to take a crack at the patch? It should hit both 3.5 and 3.6 docs. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 21:57:57 2017 From: report at bugs.python.org (David Steele) Date: Tue, 14 Feb 2017 02:57:57 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487041077.6.0.696086515691.issue24241@psf.upfronthosting.co.za> David Steele added the comment: See https://github.com/python/cpython/pull/85 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 22:00:32 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 03:00:32 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487041232.48.0.941964119334.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks, Lemburg to pointing it out. Here is detail of the difference. ## PyEval_CallFunction(), PyEval_CallMethod() They are very similar to PyObject_CallFunction() and PyObject_CallMethod(). difference are: * PyEval_Call...() doesn't respect Py_SSIZE_T_CLEAN * PyObject_Call... has following special case. PyEval_CallFunction(callable, "i", (int)i) will raise TypeError("keyword list must be a tuple") and PyObject_CallFunction(callable, "i", (int)i) calls `callable(i)` if (nargs == 1 && PyTuple_Check(stack[0])) { /* Special cases for backward compatibility: - PyObject_CallFunction(func, "O", tuple) calls func(*tuple) - PyObject_CallFunction(func, "(OOO)", arg1, arg2, arg3) calls func(*(arg1, arg2, arg3)): func(arg1, arg2, arg3) */ PyObject *args = stack[0]; result = _PyObject_FastCall(callable, &PyTuple_GET_ITEM(args, 0), PyTuple_GET_SIZE(args)); } PyEval_CallFunction is not called from Python source tree. PyEval_CallMethod has only one caller in tree and format string is "(Oi)". It can be replaced with PyObject_CallMethod safely. ## PyEval_CallObject(), PyEval_CallObjectWithKeywords() PyEval_CallObject() is a just macro calling PyEval_CallObjectWithKeywords() (call it COWK later). PyEval_CallObject() is identical to PyObject_CallObject(). Only difference is it's a macro or function. COWK is similar to PyObject_Call(), but COWK raise TypeError when args is not a tuple or kwds is not a dictionary and PyObject_Call() uses assert. There are only two caller of PyEval_CallObjectWithKeywords() other than PyEval_CallObject and PyObject_CallObject. One is tp_call of weakcallableproxy. Type of kwargs is checked before calling tp_call. Another is in threading (boot->keyw). The threading module checks it's a dict. So replacing them to PyObject_CallObject() is safe. ---- While they are complex API, there are few (or no) callers in Python tree. It's too hard to maintain. Actually, I found regression of COWK in Python 3.6. https://github.com/python/cpython/commit/155ea65e5c88d250a752ee5321860ef11ede4085 It calls _PyObject_FastCallDict() when args is NULL. If kwargs is not dict, it can crash instead of raising TypeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 22:07:41 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 03:07:41 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487041661.59.0.979015510125.issue29548@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 22:48:22 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 03:48:22 +0000 Subject: [issue29438] use after free in key sharing dict In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> Message-ID: <1487044102.36.0.608689429947.issue29438@psf.upfronthosting.co.za> INADA Naoki added the comment: All pull requests are merged. https://github.com/python/cpython/pull/17 (master) https://github.com/python/cpython/pull/39 (3.6) https://github.com/python/cpython/pull/40 (3.5) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 23:31:56 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 04:31:56 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487046716.45.0.626713432836.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: PR 87 fixes the regression in 3.6 branch ---------- pull_requests: +55 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 00:40:40 2017 From: report at bugs.python.org (Alex) Date: Tue, 14 Feb 2017 05:40:40 +0000 Subject: [issue6143] IDLE - an extension to clear the shell window In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za> Message-ID: <1487050840.04.0.852212361216.issue6143@psf.upfronthosting.co.za> Alex added the comment: The ClearWindow.py extension works well with the specified shortcut, How can i invoke it in my source code to clear the window ? Thanks in advance. ---------- nosy: +Alex type: enhancement -> resource usage versions: +Python 2.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 00:52:56 2017 From: report at bugs.python.org (Florent Gallaire) Date: Tue, 14 Feb 2017 05:52:56 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487051576.62.0.568148196513.issue24665@psf.upfronthosting.co.za> Florent Gallaire added the comment: After discussion with Haypo, CJK support is now implemented as and option, disabled by default for backward compatibility reasons. PR on GitHub: https://github.com/python/cpython/pull/89 ---------- pull_requests: +56 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 01:11:26 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 06:11:26 +0000 Subject: [issue29339] Interactive: Move to same indentation level as previousline In-Reply-To: <1485039375.56.0.473197770315.issue29339@psf.upfronthosting.co.za> Message-ID: <1487052686.56.0.990510510907.issue29339@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > IPython3 solved this issue by adding special magic functions, but this is not a way for CPython. IPython 5 improve on that with prompt toolkit. It does not break paste, as prompt_toolkit has a bracketed-past mode, that most terminal emulator support (control chars sent by terminal "hey I'm pasting", "hey I'm done pasting"). So it works nicely. IPython 6 even will remove the need for magics to activate paste mode. Though it's far from trivial to implement and to get it "right". Once you start giving indentation to user, they start to be demanding, like indenting 1 more on `:`, and one less on `return`, `pass`... , multiple line string. etc... See https://github.com/ipython/ipython/issues/9283 for some of the issues and limitation you can hit. If you decide to implement this kind of things, there are likely a lot you can borrow from IPython, the InputSplitter class has likely the sate needed to give you the indent level to use in readline. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 02:10:49 2017 From: report at bugs.python.org (Wolfgang Rohdewald) Date: Tue, 14 Feb 2017 07:10:49 +0000 Subject: [issue29551] unittest: TestSuite.debug() does not like subTest() Message-ID: <1487056249.29.0.788036995635.issue29551@psf.upfronthosting.co.za> New submission from Wolfgang Rohdewald: the main code is appended in main.py if a test uses with self.subTest(), subTest() fails right in its first statement "if not self._outcome ..." because _outcome is None. In main.py, the commented runner.run(suite) would work correctly. If this is not meant to work, please mention it in the documentation and improve unittest's reaction. what I would find more logical from the users's point of view is something like runner.debug(suite) ---------- components: Library (Lib) files: main.py messages: 287738 nosy: wrohdewald priority: normal severity: normal status: open title: unittest: TestSuite.debug() does not like subTest() type: crash versions: Python 3.5 Added file: http://bugs.python.org/file46637/main.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 02:45:22 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 14 Feb 2017 07:45:22 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487058322.38.0.780743973184.issue29540@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Serhiy and think this API change would be a net increase in complexity. FWIW, network transmission size issues can already be handled more effectively "Accept-Encoding: gzip, deflate". Bob, do you have any thoughts? ---------- assignee: -> bob.ippolito nosy: +bob.ippolito, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 02:54:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Feb 2017 07:54:00 +0000 Subject: [issue29551] unittest: TestSuite.debug() does not like subTest() In-Reply-To: <1487056249.29.0.788036995635.issue29551@psf.upfronthosting.co.za> Message-ID: <1487058840.97.0.331090150066.issue29551@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, michael.foord, pitrou, rbcollins type: crash -> behavior versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 03:02:47 2017 From: report at bugs.python.org (Bob Ippolito) Date: Tue, 14 Feb 2017 08:02:47 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487059367.86.0.718262490005.issue29540@psf.upfronthosting.co.za> Bob Ippolito added the comment: I agree, in isolation it's a fine proposal, but the interface here is already a bit too complex and the benefit is pretty minimal. When the size really does matter, you can take care to set it correctly once and be done with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 03:38:41 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 08:38:41 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487061521.46.0.618387372202.issue29546@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Unsure if GitHub PR autolinks here. I'm attempting part of that at https://github.com/python/cpython/pull/91 AFAICT with my little knowledge of CPython internal, `name` and `path` where unset for `from ... import`. I'll be happy to change the formatting as well but I suspect this will lead to lot of bikeshedding. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 03:46:40 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 08:46:40 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487062000.78.0.965326163132.issue29548@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also #11165 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:04:39 2017 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 14 Feb 2017 09:04:39 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1487063079.9.0.77969636848.issue28598@psf.upfronthosting.co.za> Changes by Martijn Pieters : ---------- pull_requests: +57 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:05:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Feb 2017 09:05:58 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487063158.65.0.157039620619.issue29548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue485165, issue8276 and issue11173. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:06:53 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 14 Feb 2017 09:06:53 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487063213.05.0.267809174976.issue29548@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks, but you missed the main difference: The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced with an empty tuple), but will raise a segfault for PyObject_Call(). Now, apart from looking at the use cases in the core, you also have to check whether you are removing useful functionality when deprecating APIs. Code in third party extensions may not be that easy to adapt to the PyObject_Call*() APIs, since they lack several checks which the PyEval_Call*() APIs apply. Deprecation of existing published APIs is only an option in case there are other APIs which can reasonably replace them and those other APIs would have to have been around for a while, since otherwise third party code would have to provide wrappers for Python versions which don't supply these APIs or only ones which do not implement the extra functionality. E.g. if you now add the extra support for args being NULL to PyObject_Call() in Python 3.7, third party code would have to either switch being using PyEval_CallObject() and PyObject_Call() depending on Python version or provide its own wrappers around the two APIs depending on Python version. Since calling objects is rather common in Python extensions, special care has to be taken. It would have been better to add the special case for args == NULL and the extra types checks to PyObject_Call() a long long time ago, since it's the only API that allows calling an object with both args and kwargs. Alas, didn't happen, so we have to live with it. It may actually be better to add a new API PyObject_CallObjectWithKeywords() which works like the PyEval_CallObjectWithKeywords() API and then deprecate the PyEval_COWK() API. Third party code can then use a simple macro to provide a backwards compatibility shim for older Python versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:13:01 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 14 Feb 2017 09:13:01 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1487063581.84.0.184057675307.issue8800@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Side note, in case anyone else finds themselves looking for the MSDN magazine article referenced above: it appears to be in the June 2007 issue, titled "CONCURRENCY: Synchronization Primitives New To Windows Vista". For the moment at least, this link seems to work: http://download.microsoft.com/download/3/A/7/3A7FA450-1F33-41F7-9E6D-3AA95B5A6AEA/MSDNMagazineJune2007en-us.chm ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:20:39 2017 From: report at bugs.python.org (Alex Gordon) Date: Tue, 14 Feb 2017 09:20:39 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487064039.84.0.620117262161.issue29540@psf.upfronthosting.co.za> Alex Gordon added the comment: The point is that, as a principle of good API design, the json module should not generate malformed JSON unless the user very explicitly asks for their JSON to be corrupted. Python stands alone in having a JSON serializer that can produce strings such as {"k",[1:2:3]} if the user holds it wrong. Outside of Python, the 'compact' encoding is just the normal way that JSON is encoded. It's the default almost everywhere else. I'm not suggesting Python should default to it also, but I am suggesting that it should be safe and easy to remove the extraneous whitespace. Historically there were two values you might want to pass to separators. Aside from (',', ':'), the other was (',', ': ') when indent was not None, to suppress the trailing space at the end of each line. This is no longer necessary after 3.4. After 3.4, separators= currently acts as a very complicated boolean flag, because the only value that makes sense to pass to it is (',', ':'). With a compact flag, users could ignore separators entirely and so the API would be made simpler and safer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:27:46 2017 From: report at bugs.python.org (Prudvi Mangadu) Date: Tue, 14 Feb 2017 09:27:46 +0000 Subject: [issue29552] Issue in Dictionary fromkeys Message-ID: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> New submission from Prudvi Mangadu: If we load the keys and values using fromkeys on dic. Later the modification in the values is reflects for all keys in the DIC, please follow the below code. ####################################################################################### PS C:\Python27> py Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> input = ['1','2'] >>> result = {} >>> result = result.fromkeys(input,[]) >>>> Issue with this line >>> >>> result {'1': [], '2': []} >>> >>> result['1'].append("item1") >>> >>> result {'1': ['item1'], '2': ['item1']} >>>>>>>>>>>>>>>>>> Here result['2'] also overwrites >>> >>> result['1'].append("item2") >>> result {'1': ['item1', 'item2'], '2': ['item1', 'item2']} >>>>>>>>>>>>>>>>>> Here result['2'] also overwrites >>> >>> ####################################################################################### ---------- components: Windows messages: 287747 nosy: paul.moore, prudvibt81, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Issue in Dictionary fromkeys type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:31:42 2017 From: report at bugs.python.org (Prudvi Mangadu) Date: Tue, 14 Feb 2017 09:31:42 +0000 Subject: [issue29552] Issue in Dictionary fromkeys In-Reply-To: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> Message-ID: <1487064702.78.0.624448701628.issue29552@psf.upfronthosting.co.za> Prudvi Mangadu added the comment: Workaround is replace the below 2 lines with "result ={D_IP:[] for D_IP in input}" ========================== result = {} result = result.fromkeys(input,[]) >>>> Issue with this line ========================== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:37:22 2017 From: report at bugs.python.org (Prudvi Mangadu) Date: Tue, 14 Feb 2017 09:37:22 +0000 Subject: [issue29552] Issue in Dictionary fromkeys In-Reply-To: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> Message-ID: <1487065042.77.0.486779152347.issue29552@psf.upfronthosting.co.za> Prudvi Mangadu added the comment: Also observed that ID of the values are pointing same, its ok. But if some one later modified that values which causes the un-usual output. >>> id(result['1']) 38121184 >>> id(result['2']) 38121184 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:38:38 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Feb 2017 09:38:38 +0000 Subject: [issue26467] Add async magic method support to unittest.mock.Mock In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za> Message-ID: <1487065118.86.0.589890568262.issue26467@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:41:15 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 14 Feb 2017 09:41:15 +0000 Subject: [issue11173] Undocumented public APIs in Python 3.2 In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za> Message-ID: <1487065275.44.0.489068623741.issue11173@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: PyEval_CallObject wasn't removed. It's a macro now. And it was documented for a long time in Extending Python... in fact, the documentation was removed, not the API :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:48:49 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 14 Feb 2017 09:48:49 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487065729.83.0.416822301041.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: 2017-02-14 06:58:29 INFO connected: mustang.blue-labs.org/107.170.82.162:37188 2017-02-14 06:58:29 INFO No cert required for this host *** Error in `/usr/bin/python': double free or corruption (out): 0x00007fb0f8003400 *** 2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:749) Fatal Python error: Aborted Thread 0x00007fb0effff700 (most recent call first): File "/var/bluelabs/python/_cams_threaded_server.py", line 116 in handle File "/usr/lib/python3.6/socketserver.py", line 696 in __init__ File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/pytho2017-02-14 06:58:29 INFO goodbye3 107.170.82.162 2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:749) 2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:749) 2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:749) n3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb100de2700 (most recent call first): File "/var/bluelabs/python/_cams_thread2017-02-14 06:58:29 INFO goodbye3 107.170.82.162 2017-02-14 06:58:29 INFO disconnect: Thread-6 2017-02-14 06:58:29 INFO goodbye3 107.170.82.162 2017-02-14 06:58:29 INFO disconnect: Thread-5 ed_server.py", line 116 in handle File "/usr/lib/python3.6/socketserver.py", line 696 in __init__ File "2017-02-14 06:58:29 INFO goodbye3 107.170.82.162 2017-02-14 06:58:29 INFO disconnect: Thread-10 /usr/lib/python3.6/socketserver.py", line 361 in 2017-02-14 06:58:29 INFO disconnect: Thread-11 finish_request File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb1025e5700 (most recent call first): File "/var/bluelabs/python/_cams_threaded_server.py", line 137 in handle File "/usr/lib/python3.6/socketserver.py", line 696 in __init__ File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb102de6700 (most recent call first): File "/var/bluelabs/python/_cams_threaded_server.py", line 137 in handle File "/usr/lib/python3.6/socketserver.py", line 696 in __init__ File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Current thread 0x00007fb1035e7700 (most recent call first): File "/var/bluelabs/python/_cams_threaded_server.py", line 49 in sni_callback File "/usr/lib/python3.6/ssl.py", line 683 in do_handshake File "/usr/lib/python3.6/ssl.py", line 1061 in do_handshake File "/var/bluelabs/python/_cams_threaded_server.py", line 152 in handle File "/usr/lib/python3.6/socketserver.py", line 696 in __init__ File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb11131a700 (most recent call first): File "/usr/lib/python3.6/threading.py", line 299 in wait File "/usr/lib/python3.6/threading.py", line 551 in wait File "/var/bluelabs/bots/cams/camsbot.py", line 753 in start_message_queue_handler File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb111b1b700 (most recent call first): File "/var/bluelabs/python/irclib.py", line 230 in process_once File "/var/bluelabs/python/irclib.py", line 246 in process_forever File "/var/bluelabs/python/irclib.py", line 1228 in start File "/var/bluelabs/python/ircbot.py", line 258 in start File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb11231c700 (most recent call first): File "/usr/lib/python3.6/selectors.py", line 376 in select File "/usr/lib/python3.6/socketserver.py", line 236 in serve_forever File "/usr/lib/python3.6/threading.py", line 864 in run File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap Thread 0x00007fb11a936400 (most recent call first): File "/usr/lib/python3.6/threading.py", line 1072 in _wait_for_tstate_lock File "/usr/lib/python3.6/threading.py", line 1056 in join File "/usr/lib/python3.6/threading.py", line 1290 in _shutdown Aborted (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:49:03 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 09:49:03 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487065743.5.0.643738126106.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: > The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced with an empty tuple), but will raise a segfault for PyObject_Call(). PyObject_CallObject() accepts NULL as args. Macro vs function is only difference of them. On the other hand, PyObject_CallObjectWithKeyword() doesn't have identical function. So I agree your suggestion to add NULL support to PyObject_Call(). We have more fast _PyObject_FastCall* APIs for performance critical code. Additional cost to check NULL in PyObject_Call() would be negligible. Any opinion from others? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:01:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:01:02 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487066462.59.0.328100927258.issue24665@psf.upfronthosting.co.za> STINNER Victor added the comment: Florent Gallaire: Since Python 3.0 was released in 2008, new features are no more accepted in Python 2 (Python 2.7, the last release of Python 2). It's a deliberate choice, mostly motivated by the lack of CPython developers. See also the PEP 404. I'm only talking about Python core and its builtin stdlib: it became very easy to extend Python with third party modules. We even added ensurepip to Python 2.7.9, even if we didn't want to add new features to Python 2. So just create a module on PyPI as you did, make it working on Python 2.7+ and you are done ;-) In 2016, INADA Naoki and Xiang Zhang got promoted to Python core developers: Naoki is japanese and Xiang is chinese. Maybe they would help on CJK issues. Please remind that Python core developers are volunteers contributing to Python in their free time. Have a nice day :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:03:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:03:31 +0000 Subject: [issue5667] Interpreter fails to initialize on build dir when IO encoding is one of CJK In-Reply-To: <1238664339.95.0.0471411238024.issue5667@psf.upfronthosting.co.za> Message-ID: <1487066611.0.0.929926637359.issue5667@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to reproduce the bug. It seems like it was fixed since 8 years ;-) haypo at selma$ LC_ALL=ko_KR.eucKR ./python Python 3.7.0a0 (default, Feb 14 2017, 10:48:09) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> haypo at selma$ LC_ALL=ko_KR.eucKR ./python -S Python 3.7.0a0 (default, Feb 14 2017, 10:48:09) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux >>> ---------- nosy: +haypo resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:03:38 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 14 Feb 2017 10:03:38 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1487066618.68.0.267815242271.issue11165@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The PyEval_Call*() APIs indeed predate the PyObject_Call*() ones. The PyObject_Call*() APIs came into existence when the abstract layer was added in Python 1.3. The PyObject_Call*() APIs lacked a way to call an object with keyword arguments for a long time. I guess that's what most people continued to use the PyEval_Call*() ones. The latter also provide better protection against wrong parameters. The interpreter itself used them interchangeably. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:06:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:06:59 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487066819.16.0.381970203869.issue24665@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the now old issue #12568: "Add functions to get the width in columns of a character". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:09:11 2017 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 14 Feb 2017 10:09:11 +0000 Subject: [issue25720] Fix curses module compilation with ncurses6 In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za> Message-ID: <1487066951.9.0.200066308686.issue25720@psf.upfronthosting.co.za> Ismail Donmez added the comment: What's the status on this? Can you please create a pull request on Github so we can continue there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:09:53 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 14 Feb 2017 10:09:53 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487066993.17.0.129702033196.issue29548@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Looking through Python's history, it's interesting that PyObject_Call() did apply the args == NULL checks up until Python 2.1. In Python 2.2 this was replaced by a direct call to tp_call, without the checks. However, the tp_call slots don't do this check as you can see in function_call() of function objects. And indeed, the documentation of PyObject_Call() was changed in that version as well to disallow args == NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:13:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:13:06 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487067186.32.0.661621168555.issue29548@psf.upfronthosting.co.za> STINNER Victor added the comment: "you now add the extra support for args being NULL to PyObject_Call()" I dislike this idea. I don't want to change the API of this function. If it is likely that NULL is the result of a previous error: args = Py_BuildValue(...); res = PyObject_Call(func, args, NULL); There are already enough ways to call a function with no argument: res = PyObject_CallFunction(func, NULL); res = PyObject_CallFunctionObjArgs(func, NULL); res = _PyObject_CallNoArg(func) # private If you want to call a function only with keyword arguments, well, create an empty tuple ... which is a singleton in CPython, no risk of memory allocation failure ... and use PyObject_Call(), no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:16:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:16:29 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487067389.18.0.5784746708.issue29548@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please note that the two sets of APIs are not identical, e.g. you cannot simply replace PyEval_CallObject() with PyObject_Call(), since the former applies a few extra checks and defaults, which the latter doesn't. IMHO these checks are too expensive at runtime for little benefit. If you pass non-tuple to PyObject_Call(), Python immediately crash. You are immediately noticied of the bug :-) I don't think that such bugs are common enough to justify the overhead. Any idea of the popularity of the undocumented PyEval_xxx() functions? Are they used by Cython for example? By a single random extension module in the world? I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and deprecate them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:20:21 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:20:21 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487067621.82.0.0714756096417.issue29470@psf.upfronthosting.co.za> STINNER Victor added the comment: You now have to test "PYTHONMALLOC=malloc valgrind python3 ...". IMHO it's not a bug in Python, but in your code ussing OpenSSL: File "/var/bluelabs/python/_cams_threaded_server.py", line 49 in sni_callback ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:27:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 10:27:05 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487068025.3.0.469327365376.issue29157@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 2.7, see issue #29188: "Backport random.c from Python 3.5 to Python 2.7". Mercurial commit 13a39142c047, Git commit 01bdbad3e951014c58581635b94b22868537901c. https://github.com/python/cpython/commit/01bdbad3e951014c58581635b94b22868537901c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:35:32 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 10:35:32 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487068532.55.0.240069503687.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: > I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and deprecate them. That's PR 75 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:39:44 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 14 Feb 2017 10:39:44 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487068784.76.0.391142433753.issue29470@psf.upfronthosting.co.za> Christian Heimes added the comment: Please install debug symbols and provide a proper C backtrace of the invalid free call. The backtrace in your first comment is missing both line numbers, file and function names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 05:41:20 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 14 Feb 2017 10:41:20 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487068880.71.0.303878786048.issue29470@psf.upfronthosting.co.za> Christian Heimes added the comment: Please also provide more information about your system: platform, distro, architecture, OpenSSL version, exact Python version etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:00:44 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 14 Feb 2017 11:00:44 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487067389.18.0.5784746708.issue29548@psf.upfronthosting.co.za> Message-ID: <27a13fa7-3a57-3514-cb6e-2a1603906a9c@egenix.com> Marc-Andre Lemburg added the comment: On 14.02.2017 11:16, STINNER Victor wrote: > >> Please note that the two sets of APIs are not identical, e.g. you cannot simply replace PyEval_CallObject() with PyObject_Call(), since the former applies a few extra checks and defaults, which the latter doesn't. > > IMHO these checks are too expensive at runtime for little benefit. If you pass non-tuple to PyObject_Call(), Python immediately crash. You are immediately noticied of the bug :-) I don't think that such bugs are common enough to justify the overhead. >From the design of the abstract API layer, it is rather uncommon to have these not do extra checks to prevent segfaults. They were originally designed to be safe and developer friendly. OTOH, the PyEval_* APIs were designed to be fast, only for people who know what they are doing and for interpreter internals. Historically, this design approach appears to have been swapped somewhere between Python 2.1 and 2.2 for the call APIs, which is unfortunate. So from a design perspective, it would be better to have the abstract APIs again do proper checks and leave the low level, "segfault protected" :-) call APIs around as PyEval_Call*() or better yet: not make them public at all. > Any idea of the popularity of the undocumented PyEval_xxx() functions? Are they used by Cython for example? By a single random extension module in the world? Well, I know that our eGenix extensions are using them and there are quite a few hits on github as well: https://github.com/search?utf8=%E2%9C%93&q=PyEval_CallObjectWithKeywords&type=Code&ref=searchresults > I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and deprecate them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:05:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Feb 2017 11:05:08 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487070308.67.0.961284561548.issue29548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyEval_CallObject() was added at Jan 12 1995 (05360cd616ae). PyObject_CallObject(), PyObject_CallFunction() and PyObject_CallMethod() were added with Include/abstract.h at Jul 18 1995 (d5398acafa2c) and implemented in terms of PyEval_CallObject(). PyEval_CallObjectWithKeywords() was added few minutes later (0261bf5b3819). PyObject_Call() was added at Aug 02 2001 (09df3254b49d) as a simple wrapper around tp_call. PyObject_CallFunction() and PyObject_CallMethod() were reimplemented in terms of PyObject_Call() at Aug 16 2002 (255d1d3e66a3). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:11:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Feb 2017 11:11:13 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487070673.48.0.821335331596.issue29548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Any idea of the popularity of the undocumented PyEval_xxx() functions? You can just search code at GitHub. I would suggest to deprecate PyEval_Call*() functions first only in the documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:37:38 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 11:37:38 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487072258.2.0.603655547954.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: > I would suggest to deprecate PyEval_Call*() functions first only in the documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute. doesn't excluded by PEP 384. And these 3 functions and 1 macro is outside of "#ifndef Py_LIMITED_API" check. So they are part of stable ABI. We can't remove them until Python 4. No reason to hurry up. I'll remove Py_DEPRECATED for Python 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:55:28 2017 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Feb 2017 11:55:28 +0000 Subject: [issue29552] Issue in Dictionary fromkeys In-Reply-To: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> Message-ID: <1487073328.37.0.633615936239.issue29552@psf.upfronthosting.co.za> Martin Panter added the comment: This is similar to the problem of building a list by repeating one item: . With dict.fromkeys(), the resulting dictionary maps each specified key object to the one and only value object (empty list) you passed to fromkeys(). If you look up one of the keys, it returns the list object. If you modify that object, all references to that object will see the update. The difference with the dictionary comprehension workaround is that the interpreter executes the expressions ?D_IP? and ?[]? once for each iteration of ?input?, resulting in a new empty list instance each iteration. But when you call fromkeys(), you pass a single object. The fromkeys() method just copies references; it does not create objects itself. If the id() function returns the same identity, it means you have two references to the same underlying object instance. This is the same as checking ?result['1'] is result['2']?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 06:56:21 2017 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Feb 2017 11:56:21 +0000 Subject: [issue29552] Issue in Dictionary fromkeys In-Reply-To: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> Message-ID: <1487073381.4.0.44106269706.issue29552@psf.upfronthosting.co.za> Martin Panter added the comment: I suggest to close this as not a bug. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 07:10:24 2017 From: report at bugs.python.org (Prudvi Mangadu) Date: Tue, 14 Feb 2017 12:10:24 +0000 Subject: [issue29552] Issue in Dictionary fromkeys In-Reply-To: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> Message-ID: <1487074224.23.0.21409650717.issue29552@psf.upfronthosting.co.za> Prudvi Mangadu added the comment: Thanks Martin , I will close it. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 08:26:12 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Feb 2017 13:26:12 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487078772.87.0.749925068667.issue29540@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm +1 on the idea. Currently, a user needs to find this information in a wall of text: "To get the most compact JSON representation, you should specify (',', ':') to eliminate whitespace." It's easy to miss the lack of trailing space in (',', ':'). Perhaps the constant name could be changed to something more descriptive, but I don't have a better suggestion at the moment. (Adding Brett since he also reviewed the PR.) ---------- nosy: +berker.peksag, brett.cannon stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 08:32:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 13:32:45 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487079165.0.0.219611801051.issue29540@psf.upfronthosting.co.za> STINNER Victor added the comment: "Add compact=True flag to json.dump/dumps" Oh, fun, I implemented exactly this option in my perf project. Extract: def dump(data, fp, compact): kw = {} if compact: kw['separators'] = (',', ':') else: kw['indent'] = 4 json.dump(data, fp, sort_keys=True, **kw) So I like the idea of moving the compact=True feature directly into the json module ;-) (I don't propose to change the default to indent=4, that's a personal choice ;-)) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 08:39:12 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Feb 2017 13:39:12 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487072258.2.0.603655547954.issue29548@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > So they are part of stable ABI. We can't remove them until Python 4. Please just stop right now using "Python 4" as the starting point to break -again- the Python world. If you plan to remove the function, plan it right now with versions like "in 2 cycles". If the function is part of the stable ABI, we simply cannot remove it. Since these functions are used outside CPython and they are part of the stable ABI, I'm not sure anymore that there is any value to remove them. Maybe just document them and write "please don't use them", but don't deprecate the functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 09:59:53 2017 From: report at bugs.python.org (Christoph Stahl) Date: Tue, 14 Feb 2017 14:59:53 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups Message-ID: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> New submission from Christoph Stahl: When creating nested mutually exclusive groups, all closing brackets except one are omitted. Example: parser = ArgumentParser() group = parser.add_mutually_exclusive_group() group.add_argument('-a') group.add_argument('-b') group2 = group.add_mutually_exclusive_group() group2.add_argument('-c') group2.add_argument('-d') group3 = group2.add_mutually_exclusive_group() group3.add_argument('-e') group3.add_argument('-f') prints a usage line of: usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F] it should print something like: usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F]]] ---------- components: Library (Lib) messages: 287776 nosy: christofsteel priority: normal severity: normal status: open title: Argparser does not display closing parentheses in nested mutex groups versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 10:22:50 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Feb 2017 15:22:50 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487085770.31.0.2628754026.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: I stopped deprecating PyEval_Call APIs, and removing it's usage in PR 75. Summary of current pull requests: PR 87 contains fix regression of PyEval_CallObjectWithKeywords for Python 3.6. PR 75 is for master branch. It contains fix same to PR 87. Additionally, PyEval_CallFunction and PyEval_CallMethod is now copy of PyObject_CallFunction and PyObject_CallMethod. And comment about PyObject_Call preference is added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:00:59 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 16:00:59 +0000 Subject: [issue29554] profile/pstat doc clariification Message-ID: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: profile .rst say: > Each restriction is either an integer (to select a count of lines), or a decimal fraction between 0.0 and 1.0 inclusive (to select a percentage of lines), **or a regular expression** Actually it accept a string that will be compiled to a regex. Profile.py also mention: > (i.e., in addition to the old -1, 0, 1, or 2) Which is not really helpful, to newcomers to Python who do not know what these are meant to be. Either explaining (or removing if considered old behavior that should be stopped) seem to be better alternative. See https://github.com/python/cpython/pull/88 ---------- assignee: docs at python components: Documentation messages: 287778 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: profile/pstat doc clariification versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:02:01 2017 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 Feb 2017 16:02:01 +0000 Subject: [issue29555] Update Python Software Foundation Copyright Year Message-ID: <1487088120.64.0.260258993464.issue29555@psf.upfronthosting.co.za> New submission from Senthil Kumaran: In the attached patch, I updated the copyright year to 2017 at places it was mentioned until 2016. There was a suggestion that we remove the copyright line of Python Software Foundation from module headers since the code is already covered 1) by top level copyright mention, 2) The mention of copyright is inconsistent in modules, 3) will avoid unnecessary churn every year. This idea needs to be vetted by PSF Board and legal staff. ---------- files: pr-4.diff keywords: patch messages: 287779 nosy: orsenthil priority: normal severity: normal status: open title: Update Python Software Foundation Copyright Year versions: Python 2.7, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46638/pr-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:02:33 2017 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 Feb 2017 16:02:33 +0000 Subject: [issue29555] Update Python Software Foundation Copyright Year In-Reply-To: <1487088120.64.0.260258993464.issue29555@psf.upfronthosting.co.za> Message-ID: <1487088153.46.0.411130759503.issue29555@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:06:53 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 14 Feb 2017 16:06:53 +0000 Subject: [issue29556] Remove an unused #include from bltinmodule.c Message-ID: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: This #include is added in b744ba1d14c5487576c95d0311e357b707600b47 (issue8610) and later the use of CODESET is removed in d64e8a75e5138d5e5970f0c70995ae5cc377c421 (issue9642). Found this in investigating issue29436 Add haypo as both commit is written by you ---------- components: Build messages: 287780 nosy: Chi Hsuan Yen, haypo priority: normal severity: normal status: open title: Remove an unused #include from bltinmodule.c type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:09:39 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 14 Feb 2017 16:09:39 +0000 Subject: [issue29556] Remove an unused #include from bltinmodule.c In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487088579.12.0.132241870676.issue29556@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- pull_requests: +58 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:20:44 2017 From: report at bugs.python.org (David Wilemski) Date: Tue, 14 Feb 2017 16:20:44 +0000 Subject: [issue29557] binhex documentation claims unknown bug Message-ID: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> New submission from David Wilemski: The binhex documentation has a line in it that says "As of this writing, hexbin() appears to not work in all cases." This is a bit ambiguous and there is no context for what the bug may be. It appears this line is from the first commit to the hexbin function's documentation in 1995 (https://hg.python.org/cpython/rev/3911d4a89ab0#l4.40) but the commit also has no information about what this bug may be. I also see no current open bugs for the binhex module that seem related. In 2009, there was a patch for the hexbin function but I have no idea if this is the bug from the original documentation or if it was something else entirely: https://bugs.python.org/issue6369 Given this, I believe the line should be removed unless more details about the referenced buggy behavior can be found. ---------- assignee: docs at python components: Documentation messages: 287781 nosy: David Wilemski, docs at python priority: normal pull_requests: 59 severity: normal status: open title: binhex documentation claims unknown bug versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:23:25 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 14 Feb 2017 16:23:25 +0000 Subject: [issue29556] Remove an unused #include from bltinmodule.c In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487089405.34.0.772233001321.issue29556@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Hmmm, seems there are more redundant #include ; let me check one by one ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:25:00 2017 From: report at bugs.python.org (Christoph Stahl) Date: Tue, 14 Feb 2017 16:25:00 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487089500.21.0.300497701417.issue29553@psf.upfronthosting.co.za> Changes by Christoph Stahl : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:54:25 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 14 Feb 2017 16:54:25 +0000 Subject: [issue29387] Tabs vs spaces FAQ out of date In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za> Message-ID: <1487091265.48.0.0482235256443.issue29387@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 38c8354f3204441f6c6bd22213b449d2d8954fcc by GitHub in branch '3.5': bpo-29521 Fix two minor documentation build warnings (#41) (#84) https://github.com/python/cpython/commit/38c8354f3204441f6c6bd22213b449d2d8954fcc ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 12:07:10 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 14 Feb 2017 17:07:10 +0000 Subject: [issue29556] Remove unused #include In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487092030.78.0.186163253535.issue29556@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- title: Remove an unused #include from bltinmodule.c -> Remove unused #include _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 12:17:00 2017 From: report at bugs.python.org (Javier Domingo) Date: Tue, 14 Feb 2017 17:17:00 +0000 Subject: [issue29558] Provide run_until_complete inside loop Message-ID: <1487092620.31.0.174365857148.issue29558@psf.upfronthosting.co.za> New submission from Javier Domingo: The current architecture of asyncio makes it really hard to combine both async and sync code. When porting a Thread based application to asyncio, the first step is usually to start merging threads to the main loop, by using `run_coroutine_threadsafe`. This works well and allows to use a single ioloop from different threads. There is another step, that usually involves the patching of libraries to work in an async way. One will typically patch the IO calls to be asyncio, and using `run_until_complete` proves useful in these situations. However, at the moment it's not possible to `run_until_complete` from an ioloop. The possibility to be able to patch sync libraries to run in asyncio is something that would help a lot the migration. This functionality would basically provide a way to continue running the ioloop until the future is resolved. Sync code -> async code -> Sync code -> Async code If you know how to have this without spawning an executor, that would be good too, in such case I would rather ask for documentation on how to do it =) ---------- components: asyncio messages: 287784 nosy: gvanrossum, txomon, yselivanov priority: normal severity: normal status: open title: Provide run_until_complete inside loop type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 12:34:38 2017 From: report at bugs.python.org (Dustin Oprea) Date: Tue, 14 Feb 2017 17:34:38 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1487093678.66.0.928533126063.issue19675@psf.upfronthosting.co.za> Dustin Oprea added the comment: I don't think this can be tested. Throwing exceptions in the remote process causes exceptions that can't be caught in the same way (when the initializer fails the pool just attempts to recreate the process over and over) and I don't think it'd be acceptable to try to spawn too many processes in order to induce the original problem. There's not a lot of surface area to what we've doing here. We can't simulate failures any other way. Can I get an agreement on this from someone? ---------- pull_requests: +60 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 12:53:17 2017 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Feb 2017 17:53:17 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487094797.66.0.160678919363.issue29540@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm a little confused as the PR proposes a COMPACT constant for the module but the issue proposes a new compact argument. Which are we actively considering? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:22:58 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 18:22:58 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1487096578.46.0.0879649589254.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset 6d1dece06d13a7d40637e07b2c79f34aab368766 by Mark Dickinson in branch 'master': Fixed #29534 - _decimal difference with _pydecimal (#65) https://github.com/python/cpython/commit/6d1dece06d13a7d40637e07b2c79f34aab368766 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:30:29 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 18:30:29 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1487097029.04.0.531644773387.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: PR merged; thank you! Unfortunately, just after I merged it I noticed that the Misc/NEWS entry was in the wrong section. I'll make a new PR to fix that, and close this issue once it's done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:38:59 2017 From: report at bugs.python.org (Ted Shaneyfelt) Date: Tue, 14 Feb 2017 18:38:59 +0000 Subject: [issue29559] Detect mouse over lines on canvas while mouse button is down Message-ID: <1487097539.49.0.870342047727.issue29559@psf.upfronthosting.co.za> New submission from Ted Shaneyfelt: There way mouse captures are done, mouse-over events seem to be disabled while dragging. This makes it difficult to provides hints as feedback, and more complicated than it should be to detect when dropping over a particular line object. Tk may not directly support it, but is there any way of getting into its guts to provide an option to re-enable mouse-over events while dragging? Or even providing a tuple with the pending mouse-overs upon release? or perhaps even simulate a mouse-up-mouse-down sequence to allow the events to propagate through and consume the noise within tkinter? Or even detect that there is a pending mouseover waiting for the mouseup event and delivering it along with the mouseup or notifying within the event that there is one pending? ---------- components: Tkinter messages: 287789 nosy: Ted Shaneyfelt2 priority: normal severity: normal status: open title: Detect mouse over lines on canvas while mouse button is down type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:43:07 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 18:43:07 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1487097787.01.0.897962253756.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: PR to fix the Misc/NEWS entry: https://github.com/python/cpython/pull/99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:55:36 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Feb 2017 18:55:36 +0000 Subject: [issue6143] IDLE - an extension to clear the shell window In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za> Message-ID: <1487098536.54.0.930434613762.issue6143@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Alwx, please do not change the headers. IDLE menu commands cannot be invoked from a program. ---------- type: resource usage -> behavior versions: +Python 3.6, Python 3.7 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 14:18:56 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 19:18:56 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1487099936.82.0.850482256845.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset 996c3874fdbc91d29f0a06b37043f62cf4ead6cb by GitHub in branch 'master': Issue #29534: move Misc/NEWS entry to correct section; add Misc/ACS entry for Andrew Nester. (#99) https://github.com/python/cpython/commit/996c3874fdbc91d29f0a06b37043f62cf4ead6cb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 14:21:21 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Feb 2017 19:21:21 +0000 Subject: [issue29534] _decimal difference with _pydecimal In-Reply-To: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> Message-ID: <1487100081.18.0.217380667032.issue29534@psf.upfronthosting.co.za> Mark Dickinson added the comment: All done. Closing. (In theory, as a bugfix, this could be backported to 3.5 and 3.6. In practice, I doubt it's worth the effort.) ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 14:22:08 2017 From: report at bugs.python.org (John Simmons) Date: Tue, 14 Feb 2017 19:22:08 +0000 Subject: [issue29560] Turtle graphics fill behavior differs between versions Message-ID: <1487100128.83.0.366459584593.issue29560@psf.upfronthosting.co.za> New submission from John Simmons: When I run the demo program on the library 24.1 documentation page to draw the star, it colors the entire star yellow, not just the parts that are show yellow on the page. This appears to be a behavior change. This is running on a Windows 7 or 10 machine with Python 3.2, 3.5, or 3.6. I have not tried this program at home, but when I run a similar program that draws and then fills 10 overlapping circles, my Linux Mint 17.3 computer at home, running IDLE in Python 3.4, fills the "interior" points inside and odd number of circles but does not fill the "exterior" points inside an even number of circles. This appears to be the behavior shown on documentation page 24.1. I would like to know what is intended to be the correct behavior and why the implementations differ. ---------- components: Tkinter messages: 287794 nosy: John Simmons priority: normal severity: normal status: open title: Turtle graphics fill behavior differs between versions type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 14:24:40 2017 From: report at bugs.python.org (Pauli Virtanen) Date: Tue, 14 Feb 2017 19:24:40 +0000 Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za> Message-ID: <1487100280.88.0.252694421145.issue10746@psf.upfronthosting.co.za> Pauli Virtanen added the comment: Converted patch to Github PR + some cleanup. ---------- pull_requests: +61 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:13:10 2017 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 14 Feb 2017 20:13:10 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1487103190.51.0.394010540117.issue11165@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:14:16 2017 From: report at bugs.python.org (Gennady Kovalev) Date: Tue, 14 Feb 2017 20:14:16 +0000 Subject: [issue28695] Add SSL_CTX_set_client_cert_engine In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za> Message-ID: <1487103256.1.0.925125289908.issue28695@psf.upfronthosting.co.za> Gennady Kovalev added the comment: Is there any news? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:15:28 2017 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 14 Feb 2017 20:15:28 +0000 Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za> Message-ID: <1487103328.06.0.518590567847.issue10746@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:22:27 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 14 Feb 2017 20:22:27 +0000 Subject: [issue28695] Add SSL_CTX_set_client_cert_engine In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za> Message-ID: <1487103747.24.0.686496707558.issue28695@psf.upfronthosting.co.za> Christian Heimes added the comment: I haven't started to design the new feature yet. Since it is going to be a new feature and feature freeze of 3.7 is 2018-01-29, I'm going to start working on new stuff around in April or May for PyCon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:33:36 2017 From: report at bugs.python.org (Gennady Kovalev) Date: Tue, 14 Feb 2017 20:33:36 +0000 Subject: [issue28695] Add SSL_CTX_set_client_cert_engine In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za> Message-ID: <1487104416.78.0.0049206616735.issue28695@psf.upfronthosting.co.za> Gennady Kovalev added the comment: Ok, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:34:39 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Tue, 14 Feb 2017 20:34:39 +0000 Subject: [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line Message-ID: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When you run the Python interpreter in interactive mode, get a sys.ps1 prompt (`...`), and type a comment-only or white-space-only line, the interpreter responds with a sys.ps2 prompt (`...`), instead of a sys.ps1 prompt. This seems wrong. For example: % ./python.exe Python 3.7.0a0 (default, Feb 13 2017, 16:27:07) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> # comment-only <<-- line A ... <<-- line B >>> <<-- line C >>> <<-- line D Line A is a comment-only line entered by the user. The interpreter responds with the sys.ps2 prompt (`...`), in line B. Line C is a null line (user enters only the Enter key, nothing else). The interpreter responds with a sys.ps1 prompt (`...`). If user enters a white-space-only line at a sys.ps1 prompt, the interpreter responds the same as if it were a comment-only line, with a sys.ps2 prompt (line B). The expected expected interpreter behaviour in response to a comment-only line or a white-space-only line, not in the midst of a compound statement, is that it be the same as to a null line, with a sys.ps1 prompt. In the context of a compound statement, the expected interpreter behaviour is that a comment-only line or a white-space-only line continue the compound statement. Entering a null line in a compound statement ends the compound statement. Another way to phrase it: the expected interpreter behaviour is that a comment-only line or white-space-only line not change the interpreter prompt: if it was sys.ps1, it remains so; if it was sys.ps2, it remains so. I have reproduced this behaviour on my build of cpython 3.7.a0, python 3.6 from MacPorts, python 2.7 from MacPorts, all on Mac OS X. I see the same behaviour in the interactive shell at python.org/shell . This makes me suspect that the Python design says my expectations are wrong. In that case, the current behaviour certainly is surprising. It should be documented. I haven't found such documentation yet. ---------- components: Interpreter Core messages: 287799 nosy: JDLH priority: normal severity: normal status: open title: Interactive mode gives sys.ps2 not sys.ps1 after comment-only line type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:54:24 2017 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Feb 2017 20:54:24 +0000 Subject: [issue29558] Provide run_until_complete inside loop In-Reply-To: <1487092620.31.0.174365857148.issue29558@psf.upfronthosting.co.za> Message-ID: <1487105664.27.0.418882951351.issue29558@psf.upfronthosting.co.za> Martin Panter added the comment: Sounds related to Issue 22239 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 17:20:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 22:20:28 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487110828.44.0.0580721449963.issue29546@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +62 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 17:20:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 22:20:28 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487110828.53.0.500844806749.issue29546@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +62, 63 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 17:20:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 22:20:28 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487110828.6.0.816268934075.issue29546@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +62, 63, 64 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 17:37:52 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Feb 2017 22:37:52 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487111872.33.0.827456687275.issue29557@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 6de2b7817fa9403e81dc38f13f3690f0bbf3d064 by Berker Peksag in branch 'master': bpo-29557: Remove ambiguous line in binhex docs (#90) https://github.com/python/cpython/commit/6de2b7817fa9403e81dc38f13f3690f0bbf3d064 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 17:40:10 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Feb 2017 22:40:10 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487112010.77.0.713323214413.issue29557@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 19:05:27 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Feb 2017 00:05:27 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487117127.98.0.654662470545.issue29546@psf.upfronthosting.co.za> Brett Cannon added the comment: New changeset bc4bed440504597cac47d0a215ee094bfa99ba7e by Brett Cannon in branch 'master': bpo-29546: Set 'path' on ImportError for ``from ... import ...`` (GH-91) https://github.com/python/cpython/commit/bc4bed440504597cac47d0a215ee094bfa99ba7e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 19:31:59 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Feb 2017 00:31:59 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487118719.83.0.244089204751.issue29546@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks to Matthias' PR the information is all there in the exception, but the message has not been changed. One idea for this -- depending on how much C code you want to write -- is to provide a default message for __str__() that changes depending on whether 'path' and/or 'name' are set. Then you can just set the attributes in the __init__() and have __str__() take care of providing a common message format. Another option is to do all of that in the __init__() so that BaseException.args continues to have the full error message (but that is added overhead if the __str__() is never taken of the exception). I also have no clue how much C code this would take :) (This is all why I have toyed with the idea of re-implementing the exceptions in Python for easier customization.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 19:51:41 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 00:51:41 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487119901.86.0.718504995242.issue29546@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: I'm unsure I understand changing only the default __str__() method. You will anyway have to format the message differently depending on whether you raise from a from-import or a from-import-* or any other locations. AFAIU you "just" need the following - PyErr_SetImportError(PyUnicode_FromFormat("cannot import name %R", name), pkgname, pkgpath); + PyErr_SetImportError( + PyUnicode_FromFormat("cannot import name %R from %R (%S)", + name, pkgname, pkgpath), + pkgname, pkgpath); To use Barry format (though keeping quotes around identifiers to match current behavior). (And similar if path is null). I'm unsure if you meant to provide a set of "format-template" to ImportError that are guarantied to be called with format(name=..., path=...) but I doubt it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 20:00:11 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 01:00:11 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487120411.74.0.408474602712.issue29546@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +66 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 20:01:11 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 01:01:11 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487120471.46.0.671841151557.issue29546@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: See https://github.com/python/cpython/pull/103 that implements Barry's proposed format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 20:07:06 2017 From: report at bugs.python.org (Roger Sachan) Date: Wed, 15 Feb 2017 01:07:06 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst In-Reply-To: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> Message-ID: <1487120826.22.0.640343501464.issue29531@psf.upfronthosting.co.za> Changes by Roger Sachan : ---------- pull_requests: +67 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 20:07:21 2017 From: report at bugs.python.org (Roger Sachan) Date: Wed, 15 Feb 2017 01:07:21 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst In-Reply-To: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> Message-ID: <1487120841.7.0.800884658809.issue29531@psf.upfronthosting.co.za> Changes by Roger Sachan : ---------- pull_requests: -31 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:03:06 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 02:03:06 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) Message-ID: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I run test.test_posix.PosixTester.test_getgroups on my Mac OS X system, it fails: % ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups test_getgroups (test.test_posix.PosixTester) ... FAIL ====================================================================== FAIL: test_getgroups (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 824, in test_getgroups self.assertTrue(not symdiff or symdiff == {posix.getegid()}) AssertionError: False is not true ---------------------------------------------------------------------- Ran 1 test in 0.013s FAILED (failures=1) Details of my system: % sw_vers ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F2109 % id -G 20 507 12 61 80 98 399 33 100 204 395 398 701 % id -G -n staff xampp everyone localaccounts admin _lpadmin com.apple.access_ssh _appstore _lpoperator _developer com.apple.access_ftp com.apple.access_screensharing com.apple.sharepoint.group.1 # I wrapped these lines similarly, to make the correspondence clearer % ./python.exe -c 'import grp,os; g={i: (n, p, i, mem) for (n, p, i, mem) in grp.getgrall()}; print(sorted([(i, g[i][0]) for i in os.getgroups()]) )' [(12, 'everyone'), (20, 'staff'), (33, '_appstore'), (61, 'localaccounts'), (80, 'admin'), (98, '_lpadmin'), (100, '_lpoperator'), (204, '_developer'), (395, 'com.apple.access_ftp'), (399, 'com.apple.access_ssh'), (507, 'xampp')] So the difference, which triggers the test failure, is that id -G is returning groups (701, 'com.apple.sharepoint.group.1'), and (398, 'com.apple.access_screensharing'), while posix.getgroups() is not. I do not yet understand why. Others say this test works on their OS X 10.10 system, so maybe it's triggered by something in my environment. Also: python3.6 from MacPorts, and python2.7 from MacPorts, return the same set of groupids as does the dev build of python3.7. This bug affects the same test, and the same posix.getgroups() call, as http://bugs.python.org/issue17557 "test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups" (2013-2014, closed). But I think it is a different problem: issue17557 is related to how posix.getgroups() deals with large numbers of groups, and it is fixed. I would appreciate help in getting this test to pass. Maybe my environment is wrong, in which case I should fix my environment. But maybe the cpython code is sensitive to some detail of my environment, in which case perhaps I should fix the cpython code. ---------- components: Tests messages: 287806 nosy: JDLH priority: normal severity: normal status: open title: test_getgroups of test_posix fails (on OS X 10.10) type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:19:33 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 02:19:33 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487125173.78.0.785382984644.issue29562@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I have pushed a branch for this issue to my cpython fork: https://github.com/JDLH/cpython/tree/bpo-29562_failing_test_getgroups_on_os_x It modifies test_getgroups in test_posix.py to give better diagnostics in the event of a test failure. It says specifically which groups were in id -G, and posix.getgroups(), but not in the other. % ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups test_getgroups (test.test_posix.PosixTester) ... FAIL ====================================================================== FAIL: test_getgroups (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 841, in test_getgroups self.assertEqual(len(symdiff), 0, msg) AssertionError: 2 != 0 : id -G and posix.groups() should have zero difference. Groups in id -G but not posix.groups(): [(701, 'com.apple.sharepoint.group.1'), (398, 'com.apple.access_screensharing')] Groups in posix.groups() but not id -G: [] (Effective GID (20) was disregarded.) ---------------------------------------------------------------------- Ran 1 test in 0.020s I don't think this branch is ready yet to submit to the main codebase, but it may help people diagnose the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:46:18 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 02:46:18 +0000 Subject: [issue29563] Update Devguide about building documentation. Message-ID: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: The Devguide section 7.5.1 "Building the documentation" / "Using make / make.bat" is out of date. The document lists 10 documentation targets for `make`. The Doc/Makefile lists 17. One important omission is `make check`, which looks for errors in reStructuredText syntax, using `rstlint.py`. It's important for contributors to know about and to run `make check`, because with the move to GitHub, the project is running make check after pulling in new code. If contributors haven't cleaned up their submissions, the build fails. I suggest that the following improvements be made: 1. rewrite the bullet list "Available make targets are:" in 7.5.1 https://cpython-devguide.readthedocs.io/documenting.html#using-make-make-bat to match the list of targets in Doc/Makefile:21-38. 2. add a comment that `make help` will give the most up-to-date list of targets from the makefile, which might be better than the list in the Devguide. 3. add `make help` to both Doc/Makefile:21-38 and Devguide 7.5.1. 4. add to Devguide 6.3. "Helping with the Developer?s Guide" an instruction to run `make check` before submitting a pull request to the Devguide. ---------- assignee: docs at python components: Documentation messages: 287808 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Update Devguide about building documentation. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:46:23 2017 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 15 Feb 2017 02:46:23 +0000 Subject: [issue18779] Misleading documentations and comments in regular expression HOWTO In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za> Message-ID: <1487126783.86.0.506205084732.issue18779@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Unfortunately making the sentences pedantically correct also makes them ungainly, and I think people generally assume that underscores are treated as a letter. ---------- nosy: +akuchling resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:11:36 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 03:11:36 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket Message-ID: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): the following warning is incorrectly reported as initiated at psycopg2/extras.py:314, it actually occurs inside the Twilio python module. /usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: unclosed ts = super(NamedTupleCursor, self).fetchall() namedtuple_Record:19: ResourceWarning: unclosed This is the snippet of my code which makes the Twilio API call over https (noted by the >>> line). # get failed/undelivered with (yield from self.aiopg_pool.cursor(cursor_factory=psycopg2.extras.NamedTupleCursor)) as c: yield from c.execute(stmt_bad, (id,)) rows = yield from c.fetchall() # make calls to twilio and fetch failure reasons for r in rows: >>> msg = self._twilio.messages.get(r.delivery_id) errors[r.delivery_id] = r.recipient, msg.error_code, msg.error_message my tool uses crossbar.io's python-autobahn asyncio classes which do not use threading to my knowledge. psycopg2/pool.py does use threading. python-twilio does not use threading either. ---------- messages: 287810 nosy: David Ford (FirefighterBlu3) priority: normal severity: normal status: open title: ResourceWarning tracking is attaching incorrect file:position to unclosed socket type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:15:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 03:15:42 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487128542.23.0.62102205937.issue29529@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +68 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:36:47 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 03:36:47 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487129807.12.0.675084230918.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: in process of creating a non-stripped python install. the default Arch Linux PKGBUILD uses xvfb-run at the end of the build process which is crashing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:40:53 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 03:40:53 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487130053.37.0.0295393237646.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: my SNI callback is a function that chooses which SSL certificate to load and summarized is: 6 def sni_callback(sock, servername, context): [...] 44 # load a specific crt/key 45 store = crtstore[servername] 46 47 context.load_cert_chain( certfile = store['certfile'], 48 keyfile = store['keyfile'], 49 password = store['password'] ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:46:44 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 03:46:44 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487130404.67.0.745809476595.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: Arch Linux (updated ~weekly but not often rebooted) on a Digital Ocean droplet. Kernel 4.5.1-1-ARCH, x86_64, OpenSSL 1.0.2j, Python 3.6.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:58:25 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Feb 2017 03:58:25 +0000 Subject: [issue29563] Update Devguide about building documentation. In-Reply-To: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> Message-ID: <1487131105.52.0.401446376978.issue29563@psf.upfronthosting.co.za> Zachary Ware added the comment: I'd suggest replacing as much as possible in the devguide with a link to Doc/README.rst (or Doc/README.txt, if that's what it still is). Other improvements should be made in the README. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:58:55 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 03:58:55 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487131135.69.0.393972227446.issue29521@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +69 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:02:43 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Feb 2017 04:02:43 +0000 Subject: [issue29536] test_hashlib failure on Ubuntu 16.04 In-Reply-To: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> Message-ID: <1487131363.1.0.815176547017.issue29536@psf.upfronthosting.co.za> Xiang Zhang added the comment: I am using 16.10 but I can't reproduce the failures. Sachin can you reliably reproduce the failures? And one thing interesting is that all the failed test cases need the network source to be enabled but your command doesn't do that, it's better to use ./python -m test -uall -v test_hashlib. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:26:28 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:26:28 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487132788.35.0.787682602032.issue29481@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +70 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:33:58 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:33:58 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487133238.47.0.0875938505835.issue29481@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +71 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:39:38 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:39:38 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487133578.11.0.829135291855.issue29481@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +72 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:43:54 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:43:54 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487133834.37.0.298020183846.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Raymond :) I prepared the pull requests for 3.5, 3.6, and master branches. Thomas, you mentioned about needing to go over CLA with your employer in your PR. Not sure if you have any update on that? If your CLA is approved, I can merge and cherry-pick your PR instead. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:48:10 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:48:10 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487134090.58.0.94221732414.issue29521@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +73 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 23:48:39 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 04:48:39 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487134119.86.0.644495342187.issue29521@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +74 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 00:09:13 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 05:09:13 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1487135353.88.0.940162830089.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +75 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 00:27:58 2017 From: report at bugs.python.org (Thomas Caswell) Date: Wed, 15 Feb 2017 05:27:58 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1487133834.37.0.298020183846.issue29481@psf.upfronthosting.co.za> Message-ID: Thomas Caswell added the comment: I am not optimistic about the speed at which my employer will get this sorted out. better to just fix it and drop my commit! On Tue, Feb 14, 2017, 23:43 Mariatta Wijaya wrote: Mariatta Wijaya added the comment: Thanks, Raymond :) I prepared the pull requests for 3.5, 3.6, and master branches. Thomas, you mentioned about needing to go over CLA with your employer in your PR. Not sure if you have any update on that? If your CLA is approved, I can merge and cherry-pick your PR instead. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 00:38:13 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 05:38:13 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487137093.64.0.739016191146.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Thomas :) I'll let you close your own PR on GitHub. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 01:02:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 06:02:35 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487138555.37.0.649370269962.issue29557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this should be read in the context of previous lines: If you code or decode textfiles on non-Macintosh platforms they will still use the old Macintosh newline convention (carriage-return as end of line). And may be related to the in-code comment: # XXXX Do translation on non-mac systems ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 01:03:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 06:03:03 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487138583.07.0.624232118562.issue29557@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +macOS nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 01:23:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 06:23:34 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487139814.17.0.892015451532.issue24665@psf.upfronthosting.co.za> INADA Naoki added the comment: Sorry, I'm not unicode expert. Important usage of textwrap is printing in terminal. So I think we should learn from software relating terminal. tmux uses utf8proc. utf8proc calculates display width by script at here. https://github.com/JuliaLang/utf8proc/tree/master/data ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 01:30:38 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 15 Feb 2017 06:30:38 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487140238.02.0.619337990748.issue24665@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Some CJK character are marked as "ambiguous width". Seems in this patch ambiguous characters are assumed as narrow. Maybe it's better to document it? ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 01:55:27 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 06:55:27 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487141727.76.0.686204330288.issue24665@psf.upfronthosting.co.za> INADA Naoki added the comment: FYI, I had implemented textwrap respects EAW in Bazaar project. See here. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5874 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 02:12:00 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 15 Feb 2017 07:12:00 +0000 Subject: [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line In-Reply-To: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za> Message-ID: <1487142720.43.0.065446739388.issue29561@psf.upfronthosting.co.za> Eryk Sun added the comment: For the tokenizer, a blank line is "[a] logical line that contains only spaces, tabs, formfeeds and possibly a comment" [1]. A blank line is normally ignored, except in the REPL an entirely blank line (i.e. no whitespace or comment) is used to end a multi-line statement. This behavior is coded in Parser/tokenizer.c in tok_get(). After removing leading whitespace to get the indentation level, it decides whether the line should be ignored as blank as follows: if (c == '#' || c == '\n') { /* Lines with only whitespace and/or comments shouldn't affect the indentation and are not passed to the parser as NEWLINE tokens, except *totally* empty lines in interactive mode, which signal the end of a command group. */ if (col == 0 && c == '\n' && tok->prompt != NULL) { blankline = 0; /* Let it through */ } else { blankline = 1; /* Ignore completely */ } /* We can't jump back right here since we still may need to skip to the end of a comment */ } The tokenizer switches to the ps2 prompt unconditionally, even if the first line was ignored as a blank line. One can argue that this behavior is outside of the norm for a shell or REPL. For example, bash doesn't switch to its PS2 prompt after ignoring an initial blank line. On the other hand, the interpreter is correctly conveying that it's still tokenizing the input; it hasn't compiled or executed any code. [1]: https://docs.python.org/3/reference/lexical_analysis.html#blank-lines ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 02:40:56 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Feb 2017 07:40:56 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487144456.56.0.445025665024.issue29564@psf.upfronthosting.co.za> Martin Panter added the comment: Without more information about what the relevant code is and why you think the line number is wrong, my best guess is you may not realize how the ResourceWarning is emitted. It happens when the garbage collector runs and destroys the socket object, which happens sometime after the last reference to the socket has been deleted. So the line number can be rather arbitrary, especially if it was a reference cycle that triggered the garbage collector. If you are having trouble tracking down what socket is involved, the new ?python -X tracemalloc=? option may help. It saves stack traces when objects are created. ---------- nosy: +martin.panter stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 02:44:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 07:44:17 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1487144657.73.0.857282354587.issue24665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Add functions to get the width in columns of a character, textwrap.wrap: add control for fonts with different character widths _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 03:09:49 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Feb 2017 08:09:49 +0000 Subject: [issue29536] test_hashlib failure on Ubuntu 16.04 In-Reply-To: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> Message-ID: <1487146189.87.0.0450603337909.issue29536@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like the tests should run if the data is already downloaded. First run needs -u urlfetch. My guess is your data is somehow corrupted. Check out your copy of the files in Lib/test/data/, compare them to e.g. . If you delete the files and re-run the test, you should get a fresh copy. If my theory is correct, I wonder how the data got corrupted. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 03:20:47 2017 From: report at bugs.python.org (Elvis Stansvik) Date: Wed, 15 Feb 2017 08:20:47 +0000 Subject: [issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace In-Reply-To: <1484062635.84.0.0152072002193.issue29225@psf.upfronthosting.co.za> Message-ID: <1487146847.74.0.750826142594.issue29225@psf.upfronthosting.co.za> Elvis Stansvik added the comment: It's been over a month. It would be great if someone could at least acknowledge the bug. The current behavior is clearly wrong. I realize changes to distutils is perhaps not the most fun thing to review, but I'd like some kind of fix for this to go in. I have a hard time seeing anyone is relying on this broken behavior or have put in workarounds for it, so provided the fix is good, it should have minimal impact. ---------- nosy: +estan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:07:42 2017 From: report at bugs.python.org (Palm Kevin) Date: Wed, 15 Feb 2017 09:07:42 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487149662.64.0.955703977432.issue29355@psf.upfronthosting.co.za> Changes by Palm Kevin : ---------- nosy: +palm.kevin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:32:39 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Feb 2017 09:32:39 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487151159.16.0.157049161909.issue29540@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Everyone can chime in with their thoughts, but Bob gets to make the decision on this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:37:41 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Feb 2017 09:37:41 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487151461.82.0.587147548929.issue29557@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Georg, do remember why this admonition was present? ---------- nosy: +georg.brandl, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:43:27 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Feb 2017 09:43:27 +0000 Subject: [issue29548] deprecate PyEval_Call*() functions. In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487151807.98.0.460171286104.issue29548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In general, we should have a strong aversion to deprecation except in cases where something is actually broken. API changes make it more difficult for people to migrate to Python 3 or to upgrade between minor releases. The longer an API has existed, the more pronounced are effects of changing it (invalidating published references, killing weakly maintained projects, and affecting more code that we may not know about). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:48:06 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 09:48:06 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487152086.44.0.28441467191.issue29564@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: i do know what's causing it, it's the twilio module not cleanly finishing up. i pointed out my call to this in the initial description. /usr/lib/python3.6/site-packages/httplib2/__init__.py:857: DeprecationWarning: key_file, cert_file and check_hostname are deprecated, use a custom context instead. check_hostname=disable_ssl_certificate_validation ^ True) /usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: unclosed ts = super(NamedTupleCursor, self).fetchall() Object allocated at (most recent call first): File "/usr/lib/python3.6/ssl.py", lineno 401 _context=self, _session=session) File "/usr/lib/python3.6/http/client.py", lineno 1400 server_hostname=server_hostname) File "/usr/lib/python3.6/site-packages/httplib2/__init__.py", lineno 994 conn.connect() File "/usr/lib/python3.6/site-packages/httplib2/__init__.py", lineno 1071 (response, content) = self._conn_request(conn, request_uri, method, body, headers) File "/usr/lib/python3.6/site-packages/httplib2/__init__.py", lineno 1321 (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey) File "/usr/lib/python3.6/site-packages/twilio/rest/resources/base.py", lineno 117 resp, content = http.request(url, method, headers=headers, body=data) File "/usr/lib/python3.6/site-packages/twilio/rest/resources/base.py", lineno 152 resp = make_request(method, uri, **kwargs) File "/usr/lib/python3.6/site-packages/twilio/rest/resources/base.py", lineno 200 resp = make_twilio_request(method, uri, auth=self.auth, **kwargs) File "/usr/lib/python3.6/site-packages/twilio/rest/resources/base.py", lineno 333 resp, item = self.request("GET", uri) File "/usr/lib/python3.6/site-packages/twilio/rest/resources/base.py", lineno 328 return self.get_instance(sid) File "provider.py", lineno 524 msg = self._twilio.messages.get(r.delivery_id) File "/usr/lib/python3.6/asyncio/events.py", lineno 126 self._callback(*self._args) File "/usr/lib/python3.6/asyncio/base_events.py", lineno 1425 handle._run() File "/usr/lib/python3.6/asyncio/base_events.py", lineno 421 self._run_once() File "/usr/lib/python3.6/site-packages/autobahn/asyncio/wamp.py", lineno 168 loop.run_forever() File "provider.py", lineno 595 runner.run(make) the socket is referenced by ip:port correctly and is coherent with the stack trace. nothing about the IP, socket, or stack trace, is related to the referenced file:position that is reported: /usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: unclosed ts = super(NamedTupleCursor, self).fetchall() the psycopg2 connection is against a completely different IP and on the standard pgsql port of 5432. here's the snippet of psycopg2/extras.py: 313 def fetchall(self): 314 ts = super(NamedTupleCursor, self).fetchall() 315 nt = self.Record 316 if nt is None: 317 nt = self.Record = self._make_nt() 318 return list(map(nt._make, ts)) nothing at all between my pgsql database and twilio share any form of connection or socket and there are no similarly named variables, complex code paths, or global variables. the only object data which has any shared scope is the twilio message fetch using the ID fetched from the pgsql database. if this section of code is commented out, the resource warning vanishes. msg = self._twilio.messages.get(r.delivery_id) if i patch the involved calls in twilio so i can touch the socket object and close it such as: class Response(object): """ Take a httplib2 response and turn it into a requests response """ def __init__(self, httplib_resp, content, url, http_obj): self.content = content self.cached = False self.status_code = int(httplib_resp.status) self.ok = self.status_code < 400 self.url = url self.connections = http_obj.connections (http_obj added which is an instance of httplib2.Http which has a property of .connections wherein sockets are cached) then after modifying the twilio module to pass the Response object to me as well as the message resource, i can eventually in my code: for r in rows: resp, msg = self._twilio.messages.get(r.delivery_id) errors[r.delivery_id] = r.recipient, msg.error_code, msg.error_message for k in resp.connections: resp.connections[k].close() this closes all the cached sockets and ensures the ResourceWarning is never emitted. this messiness is another conversation however, the incorrect file:pos annotation for the ResourceWarning is the purpose of this bug. ======== the only way i can see this inaccurate message being presented as above, is if the resource warning code is not correctly tracking state inside GC runs. supposition: * psycopg2 opened the socket to the PG database (threading is involved when the pool is used) * psycopg2 fetches the rows * psycopg2 closed socket, releasing object * twilio opens a socket which coincidently uses the same object resource just closed but not purged in GC * twilio doesn't close it the SSL socket so it is left hanging * method exits, GC runs but RW state wasn't updated somewhere to say that the twilio/httplib2/http/ssl series of calls now owns that object memory * RW code emits an unclosed socket warning against the outdated psycopg2/extras.py:314 information i'm definitely not intimate with GC code so the above is purely speculation. i've seen people post some vague references to confusing resource warnings when threading is involved. as nothing appears to be affected with long running instances, the actual object handling seems solid, it's just the state tracking for the resource warning which is not correct ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:48:34 2017 From: report at bugs.python.org (Igor Kudrin) Date: Wed, 15 Feb 2017 09:48:34 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) Message-ID: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> New submission from Igor Kudrin: It looks like resolving https://bugs.python.org/issue20160 didn't fix all the issues. When a large struct is used as a parameter, a reference to the object itself is passed to the function, not a reference to a temporary copy, as it is required in https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx. Here is the reproduction sample: === Sample.c: === typedef struct { int v[3]; } Data; __declspec(dllexport) void Cripple(Data data) { data.v[0] = 0; } === Sample.py === from ctypes import * class Data(Structure): _fields_ = [("v", c_int * 3)] lib = cdll.LoadLibrary('Sample.dll') getattr(lib, 'Cripple').argtypes = [Data] data = Data() data.v[0] = 42 lib.Cripple(data) assert data.v[0] == 42 print "OK" === repro.cmd === call "%VS140COMNTOOLS%/../../VC/vcvarsall.bat" x86_amd64 cl /LD Sample.c python Sample.py ---------- components: Windows, ctypes messages: 287831 nosy: Igor Kudrin, christian.heimes, doko, mark.dickinson, meador.inge, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware priority: normal severity: normal status: open title: Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:51:49 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 15 Feb 2017 09:51:49 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487152309.18.0.850166746963.issue29532@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Agree that this is a bug. Patch and test looks good. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:56:51 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 09:56:51 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487152611.94.0.286997533471.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: I've stopped to deprecating. changed issue title. ---------- title: deprecate PyEval_Call*() functions. -> Recommend PyObject_Call* APIs over PyEval_Call*() APIs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:01:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 10:01:06 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487152866.1.0.191846884499.issue29548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think first at all PyEval_Call* functions should be documented (issue11165). The documentation should recommend to use corresponding PyObject_Call* functions and explicitly describe the difference between PyEval_Call* and PyObject_Call* APIs. Few releases after deprecating PyEval_Call APIs in documentation we can add the Py_DEPRECATED attribute for emitting compiler warnings. Few releases after deprecating in code we can remove PyEval_Call* declarations from headers, but keep exporting them in binary library. In Python 4 (or other major release that will break binary compatibility) they can be removed at all. ---------- dependencies: +Document PyEval_Call* functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:03:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 10:03:25 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1487153005.86.0.658065019872.issue11165@psf.upfronthosting.co.za> INADA Naoki added the comment: I think PyObject_Call* APIs should be preferred. As discussed in #29548, we can't remove or deprecate PyEval_Call*. But I don't think it's worth enough to document them. How about keep them undocumented? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:09:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 10:09:31 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1487153371.42.0.832822864875.issue11165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: While they are undocumented there is no a place for adding the recommendation of using corresponding PyObject_Call* functions and describing the way of porting from PyEval_Call* functions to PyObject_Call* functions. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:11:24 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 10:11:24 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487152866.1.0.191846884499.issue29548@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "I think first at all PyEval_Call* functions should be documented (issue11165). The documentation should recommend to use corresponding PyObject_Call* functions (...)" I *now* agree :-) ---------- title: Recommend PyObject_Call* APIs over PyEval_Call*() APIs -> Recommend PyObject_Call* APIs over PyEval_Call*() APIs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:11:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 10:11:54 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1487153514.03.0.501441440956.issue11165@psf.upfronthosting.co.za> INADA Naoki added the comment: In PR 75, I added a comment in Include/ceval.h, right before PyEval_Call* APIs. https://github.com/python/cpython/pull/75/files#diff-da3df9def5eca3595399b0a5a7698eac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:31:50 2017 From: report at bugs.python.org (Andrew Nester) Date: Wed, 15 Feb 2017 10:31:50 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487154710.39.0.374044093794.issue29553@psf.upfronthosting.co.za> Changes by Andrew Nester : ---------- pull_requests: +76 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:32:47 2017 From: report at bugs.python.org (Andrew Nester) Date: Wed, 15 Feb 2017 10:32:47 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487154767.46.0.00168825215997.issue29553@psf.upfronthosting.co.za> Andrew Nester added the comment: I've just added PR fixing this. ---------- nosy: +andrewnester _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:33:18 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Feb 2017 10:33:18 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487154798.12.0.5523006941.issue29564@psf.upfronthosting.co.za> Martin Panter added the comment: You say that the line number is incorrect. What would you consider a correct line number to be? Let me try again to explain my theory about garbage collection and reference cycles. Perhaps you have two objects a and b, linked such that a.x = b and b.y = a. This is a reference cycle. Suppose that the socket is also attached e.g. as the attribute a.socket. Even if all functions have deleted their references to a and b and the socket, the interpreter does not immediately realize that a and b (and therefore the socket) can be cleaned up and released from memory. At some arbitrary point after everything has released its reference to a, b, and the socket, the interpreter will run the garbage collecter. It will pull apart the reference cycle, call the socket?s destructor, and trigger the warning. So I would expect that the line number that happened to trigger the garbage collector is indeed as reported. It is just not very useful in your case. Please try calling gc.collect() at some point before just before the line indicated in the warning. That should force the warning to be emitted as part of the garbage collector run, and indicate that was indeed the indicated line that was triggering the warning. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:37:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 10:37:52 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487155072.59.0.45561151242.issue29564@psf.upfronthosting.co.za> STINNER Victor added the comment: The report issue is not a bug. By design, Python cannot emits the ResourceWarning warning where you expect that it should be emitted. Martin explained you the thing with reference counter, reference cycles and the garbage collector. It is exactly *why* I implemented the glue with tracemalloc to provide the traceback where the socket was allocated. I'm very happy to see that this feature (the traceback using tracemalloc) works as expected! By the way, the warning module might log a message suggesting to enable tracemalloc to get the traceback if tracemalloc is available but disabled? What do you think? The root issue is that the code doesn't close the SSLSocket: fix the code to close the socket, no? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 05:39:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 10:39:07 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487155147.63.0.491549677214.issue29564@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the implementation of the ResourceWarning traceback was not as simple as I expected :-) I just wrote a blog post about, search for "ResourceWarning warnings now come with a traceback" in: https://haypo.github.io/contrib-cpython-2016q1.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 06:40:37 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 11:40:37 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487158837.57.0.452023397514.issue29564@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: i quite understand the way objects can be associated with reference counts by using a, a.b, c=a.b, d=a, etc etc, and how they increase/decrease and when the GC can prune the objects. yes, the root issue is the unclosed web socket and i've already filed a bug with Twilio. @Martin, /usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: unclosed /usr/lib/python3.6/site-packages/psycopg2/extras.py:314 is unrelated to the resource in question. there is nothing in psycopg2 that can have any direct or indirect reference to the tcp/443 socket used by the twilio by any path in the code all the way back to glibc under python. nothing in psycopg2 and twilio down to _ssl/glibc have any associated references. the reference link between the two is at best as vague as connecting the water in the garden hose to the condensation on the hot shower mirror. the pg socket is created and used which will fetch a result that has no reference to the socket used by that query method. regardless, the socket is a completely different IP/port pair. there is nothing in the pool, connection, cursor, or query that will ever be used by twilio. psycopg2 has nothing to do with any of the http or httplib2 modules. after the pgsql query is completed, the twilio module gets used. a new https socket is created. the only data every seen by the twilio module that has a reference to any objected created by the psycopg2 module is the r.delivery_id which is a UUID value derived from the pgsql database. it has no references to its parent chain of objects and the twilio module doesn't derive any objects from it. to be more obtuse about it, if i replace the r.delivery_id with a quoted string i manually insert, the ResourceWarning is now logged against asyncio/events.py. the traceback is still the same. /usr/lib/python3.6/asyncio/events.py:126: ResourceWarning: unclosed self._callback(*self._args) this one happens to exist in the stack trace albeit even further up the call chain. if the ResourceWarning is unable to emit an accurate file:pos, then it shouldn't print it at all and instead, use the stack print as mentioned by @STINNER. at least at this point, the developer has a legitimate stack to wander through and isn't going on a wild goose chase in an unrelated file. i argue that printing a completely unrelated file:pos is definitely a bug. if it is likely to emit a wholly unrelated file:pos, it shouldn't be printed at all. unreliable information is just useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 06:44:45 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 15 Feb 2017 11:44:45 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487159085.02.0.822387397255.issue29470@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you modify the SSLContext object in your SNI callback? That's the wrong way to do it. You have to create a SSLContext object for each certificate/key pair at startup and then change the socket's context attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 06:45:59 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 11:45:59 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487159159.01.0.53164943282.issue29564@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: @stinner your traceback suggestion was highly useful and much appreciated. i have spent several dozen hours researching ResourceWarnings in the past and tearing my hair out because the emitted warning was very much useless. i couldn't even make educated guesses about the code as socket pairs were used randomly. i strongly approve of mentioning the tracemalloc / traceback in the warning, and i would also very much encourage saying "this filename:position could be completely wrong" or do away with it all together. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 06:47:00 2017 From: report at bugs.python.org (Javier Domingo) Date: Wed, 15 Feb 2017 11:47:00 +0000 Subject: [issue29558] Provide run_until_complete inside loop In-Reply-To: <1487092620.31.0.174365857148.issue29558@psf.upfronthosting.co.za> Message-ID: <1487159220.52.0.213813753008.issue29558@psf.upfronthosting.co.za> Javier Domingo added the comment: Yes, indeed it is. Would it be possible to reconsider this functionality? It plays a key role when trying to rewrite full applications to async. Rewriting the full stack of libraries at once is impossible, but the patching can easily be done in many cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 07:10:36 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 12:10:36 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487160636.95.0.472983927759.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: yes, i create a context and then when a request comes in, i load the appropriate key. this is how most [all?] SNI capable python server examples show how to do it, or did, at the time I wrote this module a few years ago. from that time, ~py 3.2 until now, it worked perfectly. thank you for this information, i'll rewrite my callback accordingly. perhaps 18.2.5.3 in https://docs.python.org/3/library/ssl.html can be updated to inform developers how to change their socket.context in an SNI callback ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 07:13:35 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 12:13:35 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0; ssl SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487160815.72.0.0926041731878.issue29470@psf.upfronthosting.co.za> Changes by David Ford (FirefighterBlu3) : ---------- title: [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 -> [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0; ssl SNI callbacks should not modify context objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 07:21:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 12:21:05 +0000 Subject: [issue29566] binhex() creates files with mixed line endings Message-ID: <1487161265.61.0.450348509296.issue29566@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: binhex.binhex() creates files with mixed line endings in Python 3. The header line '(This file must be converted with BinHex 4.0)' is separated from the data by LFs, but the data is split for lines by CRs. >>> import binhex >>> with open('inp', 'wb') as f: f.write(bytes(range(256))) ... 256 >>> binhex.binhex('inp', 'outp') >>> for line in open('outp', 'rb').read().splitlines(True): print(repr(line)) ... b'(This file must be converted with BinHex 4.0)\r' b'\r' b':!fPZF!!rN!J!N!3"!*!&*VF!!3)$"!8\'"`J*#JX-$3i2%"%5%a39&KFB\'4SE("d\n' b'H(b!K)L-N*5BR+#NU+b`Y,Lm`-6)c0$8f0cJj1MXm26ir3%d4&4NG)58T,6%e\n' b'16e"48P0899CA@&PD at eaGAPpJB@*MC\'9QCfKTDQYXE at j[F(&bFh4eGRGiHATlI(e\n' b'qIi#"JS1%KBD(L)Q+Lib0MSq3!*\'5Nj59PTHBQCUER*fHRk#KSU1NTDDRU+QUUkb\n' b'YVUq`XE+cY, at fYlLjZVZm[Ekr`-(#`m6&aXI)bFV,c-h1cp$4dY28eGEAf0RDfpc\n' b'GhYrJiH,Mj1AQjqMTkZ[XlHl[m2(bmr6ep[IiqIVlr2hqrhj9!!!:\n' In Python 2 the output file was file object usually opened in text mode. Newline characters were translated to platform-depending line endings: CRLF on Windows, LF on classic Mac OS. In Python 2 the output file is binary stream that doesn't do any newline translations. The last related commit is 34a042d301d6ab88645046a6dfa6c38265ca4b39 with Guido's message "This is the last time I fix binhex. If it breaks again it goes in the dustbin." ---------- components: macOS messages: 287849 nosy: gvanrossum, ned.deily, ronaldoussoren, serhiy.storchaka priority: normal severity: normal status: open title: binhex() creates files with mixed line endings type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:02:05 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Feb 2017 13:02:05 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487163725.52.0.135232602747.issue29564@psf.upfronthosting.co.za> Martin Panter added the comment: The file position is often useful when the cleanup is deterministic. Example: def f1(): file1 = open("/dev/null") def f2(): file2 = open("/dev/null") del file2 # ResourceWarning f1() # ResourceWarning at function exit f2() In the these cases, the line number can identify the affected code: demo.py:8: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> f1() # ResourceWarning at function exit demo.py:6: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> del file2 # ResourceWarning ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:20:36 2017 From: report at bugs.python.org (Christoph Stahl) Date: Wed, 15 Feb 2017 13:20:36 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487164836.44.0.592232902772.issue29553@psf.upfronthosting.co.za> Christoph Stahl added the comment: Hi, I thought a bit about the problem and came up with the following: The | in the usage is de facto an XOR operator. Exactly one of the options can be used. The XOR operator has the associative property, meaning: (A XOR B) XOR C = A XOR (B XOR C) So translated to the | this means: [[ -a | -b ] | -c ] = [ -a | [ -b | -c ]] usually one writes: [ -a | -b | -c ] So I propose dropping the inner brackets altogether. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:29:31 2017 From: report at bugs.python.org (Brian Curtin) Date: Wed, 15 Feb 2017 13:29:31 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487165371.6.0.0434449654955.issue29553@psf.upfronthosting.co.za> Brian Curtin added the comment: Dropping the inner brackets sounds like a better move to me. ---------- nosy: +bethard, brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:48:52 2017 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 15 Feb 2017 13:48:52 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <1487166532.87.0.250737834373.issue23109@psf.upfronthosting.co.za> A.M. Kuchling added the comment: It looks like there's nothing left to do for this ticket. ---------- nosy: +akuchling resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:55:12 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 15 Feb 2017 13:55:12 +0000 Subject: [issue29567] Allow argparse to be used in setup.py Message-ID: <1487166912.35.0.34823901081.issue29567@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: When proposing a fix for issue29442, I got another issue - argparse can't be used in setup.py for native (non-cross) builds because argparse imports gettext and gettext imports struct. I'll propose a fix for that. ---------- components: Build messages: 287854 nosy: Chi Hsuan Yen priority: normal severity: normal status: open title: Allow argparse to be used in setup.py type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:57:35 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 15 Feb 2017 13:57:35 +0000 Subject: [issue29567] Allow argparse to be used in setup.py In-Reply-To: <1487166912.35.0.34823901081.issue29567@psf.upfronthosting.co.za> Message-ID: <1487167055.81.0.361446138323.issue29567@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- pull_requests: +78 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:59:17 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 15 Feb 2017 13:59:17 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487167157.15.0.0159211142005.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Aha the fix is simple => issue29567 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:21:23 2017 From: report at bugs.python.org (Andrew Nester) Date: Wed, 15 Feb 2017 14:21:23 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487168483.15.0.43837131718.issue29553@psf.upfronthosting.co.za> Changes by Andrew Nester : ---------- pull_requests: +80 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:22:00 2017 From: report at bugs.python.org (Andrew Nester) Date: Wed, 15 Feb 2017 14:22:00 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487168520.72.0.201822587549.issue29553@psf.upfronthosting.co.za> Andrew Nester added the comment: Ive just added alternative PR that drops inner brackets. So we've got options to choose! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:53:02 2017 From: report at bugs.python.org (Jerry Dimitrov) Date: Wed, 15 Feb 2017 14:53:02 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting Message-ID: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> New submission from Jerry Dimitrov: Hello everyone, This is my first bug report to the python project, so please excuse me if the metadata for this particular issue is not 100% accurate. Today I noticed (with the help from couple of people in IRC) a strange behavior in the python string formatting functionality. Consider the following code snippets: ``` '%(a)s %(b)' % {'a': '1', 'b': '2'} # result: Traceback (most recent call last): File "", line 1, in ValueError: incomplete format ``` ``` '%(a) %(b)s' % {'a': '1', 'b': '2'} # result: '%(b)s' # expected result: Traceback (most recent call last): File "", line 1, in ValueError: incomplete format ``` It seems that there is some kind of inconsistent (undefined) behavior, during the parsing of the type character for the formatted string (tested across all major python 2.x/3.x versions). According to the documentation for string formatting and the relevant PEPs, there is no additional info about this particular case. I want to say thank you to Yhg1s, JustASlacker, Jerub and lz1irq for discovering this 'bug/feature' and the additional information about it. Please let me know if this is a bug, since I am not 100% sure if this is the case. Thanks in advance for your time! Best Regards, Jerry ---------- components: Interpreter Core messages: 287857 nosy: Jerry Dimitrov priority: normal severity: normal status: open title: undefined parsing behavior with the old style string formatting type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:54:10 2017 From: report at bugs.python.org (slytomcat) Date: Wed, 15 Feb 2017 14:54:10 +0000 Subject: [issue29569] threading.Timer class: Continue periodical execution till action returns True Message-ID: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> New submission from slytomcat: I think that functionality of threading.Timer class can be easily extended to generate the sequence of runs with specified period. The idea comes from the GLib.timeout_add function. Run method of threading.Timer should look like: def run(self): """Continue execution after wait till function returns True""" while(not self.finished.wait(self.interval)): if not self.function(*self.args, **self.kwargs): break self.finished.set() ---------- components: Library (Lib) messages: 287858 nosy: slytomcat priority: normal severity: normal status: open title: threading.Timer class: Continue periodical execution till action returns True type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 10:01:15 2017 From: report at bugs.python.org (slytomcat) Date: Wed, 15 Feb 2017 15:01:15 +0000 Subject: [issue29569] threading.Timer class: Continue periodical execution till action returns True In-Reply-To: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> Message-ID: <1487170875.05.0.18165419618.issue29569@psf.upfronthosting.co.za> Changes by slytomcat : ---------- pull_requests: +81 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 10:19:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 15:19:37 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487171977.53.0.53683533346.issue29568@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In this example characters between percents are parsed as for any conversion specifier but ignored and '%(a) %' is formatted to '%'. '(a)' specifies a mapping key, ' ' is a conversion flag, the second '%' is a conversion type. >>> '%(a) d' % {'a': 123} ' 123' >>> '%(a) %' % {'a': 123} '%' This behavior is explicable but looks weird and errorprone. I'm not sure about changing behavior in maintained branches (technically this may be not a bug), but I think it is worth to make this an error in the developed branch. ---------- nosy: +benjamin.peterson, larry, ned.deily, rhettinger, serhiy.storchaka versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 10:38:54 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Feb 2017 15:38:54 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487173134.73.0.46858299884.issue29557@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I think the comment about needing translation on non-mac systems is incorrect. Binhex is (or rather was) a textual encoding for binary files used on classic MacOS. The encoded file is more likely to be binary data than a text file and replacing b'\r' by the line ending of the current platform could well corrupt that data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 10:49:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 15:49:01 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487173741.33.0.19346090769.issue29557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: File flags are saved in binhex format, therefore it is possible to distinguish text files from binary files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:04:01 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 15 Feb 2017 16:04:01 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487174641.58.0.449548310695.issue29548@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +82 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:13:54 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Feb 2017 16:13:54 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487175234.22.0.122439940619.issue29568@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think we should change the behavior in maintenance branches. I take it what you want to do is make it so that if the parser ends up thinking it is seeing '%%' but there is stuff between the two %s, that's an error? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:54:26 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 16:54:26 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487177666.97.0.0351367635383.issue28814@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +83 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:54:27 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 16:54:27 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1487177667.1.0.589904442932.issue20438@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +84 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:54:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 16:54:36 +0000 Subject: [issue29570] Windows Buildbot 2.7 is broken Message-ID: <1487177676.07.0.331471484641.issue29570@psf.upfronthosting.co.za> New submission from STINNER Victor: Example of failure: http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/67/steps/test/logs/stdio FAIL: test_incrementaldecoder (test.test_codecencodings_iso2022.Test_ISO2022_KR) => failure with newline, maybe caused by the migration to GitHub: see issue #29530 ERROR: test_bug_1727780 (test.test_random.WichmannHill_TestBasicOps) ImportError: No module named random => ... no idea, can it be related to the commit 0f48ecddfb79ef541500ecfcbda0b4178af1cc29 which only changes a comment!? ---------- components: Tests, Windows keywords: buildbot messages: 287863 nosy: haypo, inada.naoki, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Buildbot 2.7 is broken versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:56:04 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 15 Feb 2017 16:56:04 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487177764.78.0.363018345623.issue28814@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:05:56 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 17:05:56 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487178356.72.0.47899067171.issue29568@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it is what I want. Current behavior is just an artefact of the implementation. I have doubts that any other implementation of printf-like formatting has such behavior. Bytes formatting starves from the same issue. >>> b'% %' % {} b'%' But there are differences: >>> '%12%' % () '%' >>> b'%12%' % () b' %' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:27:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:27:01 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487179621.92.0.475805808105.issue29548@psf.upfronthosting.co.za> STINNER Victor added the comment: > # builtin min and max doesn't support FASTCALL > (...): 1.16x slower (+16%) Hum, the slowdown is not negligible, even if functools.reduce() is rarely used. Do you think that it would be insane to have two code paths instead? * New FASTCALL path if func suports FASTCALL calling _PyObject_FastCall() * Current code path using cached args tuple otherwise For example, you can use args==NULL marker for the FASTCALL path. Maybe we need a _PyObject_SupportFastCall() function which would return 1 for Python functions and C functions, except of C functions with METH_VARARGS flag set. My expectation is a speedup for functions supporting FASTCALL, but *no slowdown* for functions not supporting FASTCALL. -- property_descr_get() also caches args tuple. I started my work on FASTCALL because this optimization caused bugs (but also because I wanted to make Python faster, but that's a different topic ;-)). In the past, the _pickle module also used cached args tuple, but the cache was removed because it was vulnerable to race conditions. For this issue, I suggest to leave functools.reduce() unchanged, but open a new issue to discuss what to do with code still using a cached args tuple. My long term goal with FASTCALL was to remove completely cached tuple used to call functions. I wrote tp_fastcall for that, but tp_fastcall (issue #29259) was rejected. The rejected tp_fastcall blocked my long term plan, we have to find a different approach. Maybe we should add support for FASTCALL for a little bit more functions, and later simply remove the optimization (hack, cached tuple)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:28:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:28:29 +0000 Subject: [issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0; ssl SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487179709.94.0.409335348322.issue29470@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you modify the SSLContext object in your SNI callback? That's the wrong way to do it. You have to create a SSLContext object for each certificate/key pair at startup and then change the socket's context attribute. Would it be possible to prevent bugs? For example, make SSLContext "read only" while the SNI callback is called? Or my question doesn't make sense? :-) I don't know well how OpenSSL works. At least, we should warn users in the ssl documentation to mention such crash? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:29:11 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Wed, 15 Feb 2017 17:29:11 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` Message-ID: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> New submission from Jaysinh shukla: Description: A test case is failing while running `./python -m test -v test_re`. Traceback: $>./python -m test -v test_re == CPython 3.7.0a0 (default, Feb 15 2017, 22:28:32) [GCC 5.4.0 20160609] == Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian == hash algorithm: siphash24 64bit == cwd: /home/bigj/Jaysinh/cpython_git/cpython/build/test_python_613 == encodings: locale=UTF-8, FS=utf-8 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_re test_re_benchmarks (test.test_re.ExternalTests) re_tests benchmarks ... ok test_re_tests (test.test_re.ExternalTests) re_tests test suite ... ok test_overlap_table (test.test_re.ImplementationTest) ... ok test_bytes (test.test_re.PatternReprTests) ... ok test_inline_flags (test.test_re.PatternReprTests) ... ok test_locale (test.test_re.PatternReprTests) ... ok test_long_pattern (test.test_re.PatternReprTests) ... ok test_multiple_flags (test.test_re.PatternReprTests) ... ok test_quotes (test.test_re.PatternReprTests) ... ok test_single_flag (test.test_re.PatternReprTests) ... ok test_unicode_flag (test.test_re.PatternReprTests) ... ok test_unknown_flags (test.test_re.PatternReprTests) ... ok test_without_flags (test.test_re.PatternReprTests) ... ok test_anyall (test.test_re.ReTests) ... ok test_ascii_and_unicode_flag (test.test_re.ReTests) ... ok test_backref_group_name_in_exception (test.test_re.ReTests) ... ok test_basic_re_sub (test.test_re.ReTests) ... ok test_big_codesize (test.test_re.ReTests) ... ok test_bigcharset (test.test_re.ReTests) ... ok test_bug_113254 (test.test_re.ReTests) ... ok test_bug_114660 (test.test_re.ReTests) ... ok test_bug_117612 (test.test_re.ReTests) ... ok test_bug_1661 (test.test_re.ReTests) ... ok test_bug_16688 (test.test_re.ReTests) ... ok test_bug_20998 (test.test_re.ReTests) ... ok test_bug_2537 (test.test_re.ReTests) ... ok test_bug_29444 (test.test_re.ReTests) ... ok test_bug_3629 (test.test_re.ReTests) ... ok test_bug_418626 (test.test_re.ReTests) ... ok test_bug_448951 (test.test_re.ReTests) ... ok test_bug_449000 (test.test_re.ReTests) ... ok test_bug_449964 (test.test_re.ReTests) ... ok test_bug_462270 (test.test_re.ReTests) ... ok test_bug_527371 (test.test_re.ReTests) ... ok test_bug_581080 (test.test_re.ReTests) ... ok test_bug_612074 (test.test_re.ReTests) ... ok test_bug_6509 (test.test_re.ReTests) ... ok test_bug_6561 (test.test_re.ReTests) ... ok test_bug_725106 (test.test_re.ReTests) ... ok test_bug_725149 (test.test_re.ReTests) ... ok test_bug_764548 (test.test_re.ReTests) ... ok test_bug_817234 (test.test_re.ReTests) ... ok test_bug_926075 (test.test_re.ReTests) ... ok test_bug_931848 (test.test_re.ReTests) ... ok test_bytes_str_mixing (test.test_re.ReTests) ... ok test_category (test.test_re.ReTests) ... ok test_character_set_errors (test.test_re.ReTests) ... ok test_compile (test.test_re.ReTests) ... ok test_constants (test.test_re.ReTests) ... ok test_dealloc (test.test_re.ReTests) ... ok test_debug_flag (test.test_re.ReTests) ... ok test_dollar_matches_twice (test.test_re.ReTests) $ matches the end of string, and just before the terminating ... ok test_empty_array (test.test_re.ReTests) ... ok test_enum (test.test_re.ReTests) ... ok test_error (test.test_re.ReTests) ... ok test_expand (test.test_re.ReTests) ... ok test_finditer (test.test_re.ReTests) ... ok test_flags (test.test_re.ReTests) ... ok test_getattr (test.test_re.ReTests) ... ok test_getlower (test.test_re.ReTests) ... ok test_group (test.test_re.ReTests) ... ok test_group_name_in_exception (test.test_re.ReTests) ... ok test_groupdict (test.test_re.ReTests) ... ok test_ignore_case (test.test_re.ReTests) ... ok test_ignore_case_range (test.test_re.ReTests) ... ok test_ignore_case_set (test.test_re.ReTests) ... ok test_inline_flags (test.test_re.ReTests) ... ok test_issue17998 (test.test_re.ReTests) ... ok test_keep_buffer (test.test_re.ReTests) ... ok test_keyword_parameters (test.test_re.ReTests) ... ok test_large_search (test.test_re.ReTests) ... ok test_large_subn (test.test_re.ReTests) ... ok test_locale_caching (test.test_re.ReTests) ... skipped 'test needs en_US.iso88591 locale' test_locale_flag (test.test_re.ReTests) ... FAIL test_lookahead (test.test_re.ReTests) ... ok test_lookbehind (test.test_re.ReTests) ... ok test_match_getitem (test.test_re.ReTests) ... ok test_match_repr (test.test_re.ReTests) ... ok test_misc_errors (test.test_re.ReTests) ... ok test_multiple_repeat (test.test_re.ReTests) ... ok test_not_literal (test.test_re.ReTests) ... ok test_nothing_to_repeat (test.test_re.ReTests) ... ok test_other_escapes (test.test_re.ReTests) ... ok test_pattern_compare (test.test_re.ReTests) ... ok test_pattern_compare_bytes (test.test_re.ReTests) ... ok test_pickling (test.test_re.ReTests) ... ok test_qualified_re_split (test.test_re.ReTests) ... ok test_qualified_re_sub (test.test_re.ReTests) ... ok test_re_escape (test.test_re.ReTests) ... ok test_re_escape_byte (test.test_re.ReTests) ... ok test_re_escape_non_ascii (test.test_re.ReTests) ... ok test_re_escape_non_ascii_bytes (test.test_re.ReTests) ... ok test_re_findall (test.test_re.ReTests) ... ok test_re_fullmatch (test.test_re.ReTests) ... ok test_re_groupref (test.test_re.ReTests) ... ok test_re_groupref_exists (test.test_re.ReTests) ... ok test_re_groupref_overflow (test.test_re.ReTests) ... ok test_re_match (test.test_re.ReTests) ... ok test_re_split (test.test_re.ReTests) ... ok test_re_subn (test.test_re.ReTests) ... ok test_repeat_minmax (test.test_re.ReTests) ... ok test_repeat_minmax_overflow (test.test_re.ReTests) ... ok test_repeat_minmax_overflow_maxrepeat (test.test_re.ReTests) ... ok test_scanner (test.test_re.ReTests) ... ok test_scoped_flags (test.test_re.ReTests) ... ok test_search_coverage (test.test_re.ReTests) ... ok test_search_dot_unicode (test.test_re.ReTests) ... ok test_search_star_plus (test.test_re.ReTests) ... ok test_special_escapes (test.test_re.ReTests) ... ok test_sre_byte_class_literals (test.test_re.ReTests) ... ok test_sre_byte_literals (test.test_re.ReTests) ... ok test_sre_character_class_literals (test.test_re.ReTests) ... ok test_sre_character_literals (test.test_re.ReTests) ... ok test_stack_overflow (test.test_re.ReTests) ... ok test_string_boundaries (test.test_re.ReTests) ... ok test_sub_template_numeric_escape (test.test_re.ReTests) ... ok test_symbolic_groups (test.test_re.ReTests) ... ok test_symbolic_refs (test.test_re.ReTests) ... ok test_unlimited_zero_width_repeat (test.test_re.ReTests) ... ok test_weakref (test.test_re.ReTests) ... ok ====================================================================== FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bigj/Jaysinh/cpython_git/cpython/Lib/test/test_re.py", line 1422, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true ---------------------------------------------------------------------- Ran 120 tests in 2.079s FAILED (failures=1, skipped=1) test test_re failed test_re failed 1 test failed: test_re Total duration: 2 sec Tests result: FAILURE Local value: $>locale LANG=en_IN LANGUAGE=en_IN:en LC_CTYPE="en_IN" LC_NUMERIC="en_IN" LC_TIME="en_IN" LC_COLLATE="en_IN" LC_MONETARY="en_IN" LC_MESSAGES="en_IN" LC_PAPER="en_IN" LC_NAME="en_IN" LC_ADDRESS="en_IN" LC_TELEPHONE="en_IN" LC_MEASUREMENT="en_IN" LC_IDENTIFICATION="en_IN" LC_ALL= Operating system: Ubuntu 16.04 LTS(64 bit) ---------- components: Regular Expressions messages: 287867 nosy: ezio.melotti, jaysinh.shukla, mrabarnett priority: normal severity: normal status: open title: test_re is failing when local is set for `en_IN` versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:29:12 2017 From: report at bugs.python.org (Georg Brandl) Date: Wed, 15 Feb 2017 17:29:12 +0000 Subject: [issue29557] binhex documentation claims unknown bug In-Reply-To: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> Message-ID: <1487179752.33.0.422974251113.issue29557@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't remember anything specific about this, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:31:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:31:04 +0000 Subject: [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket In-Reply-To: <1487159159.01.0.53164943282.issue29564@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: David Ford (FirefighterBlu3) added the comment: > @stinner your traceback suggestion was highly useful and much appreciated. i have spent several dozen hours researching ResourceWarnings in the past and tearing my hair out because the emitted warning was very much useless. i couldn't even make educated guesses about the code as socket pairs were used randomly. So did I. Why do you think that I implemented this feature? :-D > i strongly approve of mentioning the tracemalloc / traceback in the warning, and i would also very much encourage saying "this filename:position could be completely wrong" or do away with it all together. I dislike removing filename:line information: in some cases, the information is valid and helps to understand a warning. Ok, let's go to add a line suggestion to enable tracemalloc. Is there someone here interested to propose a pull request? It should only be done in Python 3.7 and later 3.6, it's a new feature in Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:32:43 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:32:43 +0000 Subject: [issue29564] ResourceWarning: suggest to enable tracemalloc in the message In-Reply-To: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> Message-ID: <1487179963.37.0.314360817935.issue29564@psf.upfronthosting.co.za> STINNER Victor added the comment: To be clear: warnings should only suggest to enable tracemalloc if tracemalloc.is_tracing() is False. It is possible to tracemalloc is tracing, but failed (for different reasons) to track where the memory of the resource was allocated. ---------- title: ResourceWarning tracking is attaching incorrect file:position to unclosed socket -> ResourceWarning: suggest to enable tracemalloc in the message _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:33:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:33:07 +0000 Subject: [issue29470] ssl: SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487179987.72.0.19139637566.issue29470@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0; ssl SNI callbacks should not modify context objects -> ssl: SNI callbacks should not modify context objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:34:21 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Feb 2017 17:34:21 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487180061.37.0.805178152533.issue29568@psf.upfronthosting.co.za> Xiang Zhang added the comment: The documentation[1] explicitly states using % to do string format could be error-prone and recommends using str.format(). So +1 on no change in maintenance branches. [1] https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:37:47 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Feb 2017 17:37:47 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487180267.63.0.882077944709.issue29568@psf.upfronthosting.co.za> Xiang Zhang added the comment: Or even not fix it in develop branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:41:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 17:41:28 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487180488.31.0.589158864818.issue29571@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:45:19 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Feb 2017 17:45:19 +0000 Subject: [issue29563] Update Devguide about building documentation. In-Reply-To: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> Message-ID: <1487180719.61.0.264613973519.issue29563@psf.upfronthosting.co.za> Brett Cannon added the comment: Would you mind moving this issue over to https://github.com/python/devguide/issues where we track devguide issues, Jim? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:52:28 2017 From: report at bugs.python.org (Sachin Kumar) Date: Wed, 15 Feb 2017 17:52:28 +0000 Subject: [issue29536] test_hashlib failure on Ubuntu 16.04 In-Reply-To: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> Message-ID: <1487181148.01.0.698148822034.issue29536@psf.upfronthosting.co.za> Sachin Kumar added the comment: @Xiang I tried that command earlier but that returned around 8 failed test cases. I think it is due to a fault with my connection. Although I can replicate this error every time. I've tried over 5 times already. @Martin I compared the data. My file has been attached. Deleting the files fixed the issue. Can all the test files be deleted safely, since some other tests are failing too? ---------- Added file: http://bugs.python.org/file46639/blake2b.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:54:51 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 15 Feb 2017 17:54:51 +0000 Subject: [issue29470] ssl: SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487181291.34.0.215077284234.issue29470@psf.upfronthosting.co.za> Christian Heimes added the comment: It's not a bug in Python's ssl module. If I understand David's approach correctly, then he is using the SNI callback the wrong way. By using it the wrong way he has discovered a threading bug in OpenSSL. There is some kind of race condition going on in which two threads free and replace the RSA private key at the same time. I'm -1 to try to make the SSLContext object magically read-only. David, which examples did you read? The documentation https://docs.python.org/3/library/ssl.html#ssl.SSLContext.set_servername_callback is pretty clear: A typical use of this callback is to change the ssl.SSLSocket?s SSLSocket.context attribute to a new object of type SSLContext representing a certificate chain that matches the server name. Apache mod_ssl does it correctly, the first hit on stack overflow, too. https://stackoverflow.com/questions/5113333/how-to-implement-server-name-indication-sni ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:59:11 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 15 Feb 2017 17:59:11 +0000 Subject: [issue29536] test_hashlib failure on Ubuntu 16.04 In-Reply-To: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> Message-ID: <1487181551.49.0.914236850763.issue29536@psf.upfronthosting.co.za> Christian Heimes added the comment: Yeah, somehow you ended up with a broken vector file. Your file contains HTTP with JavaScript redirect. Did you attempt to download test data from a hotel or airport wifi? You can safely remove Lib/test/data and start over. ---------- nosy: +christian.heimes resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:02:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 18:02:04 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487181724.05.0.696639816333.issue29571@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:06:12 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Feb 2017 18:06:12 +0000 Subject: [issue29572] Upgrade installers to OpenSSL 1.0.2k Message-ID: <1487181972.09.0.437715679754.issue29572@psf.upfronthosting.co.za> New submission from Zachary Ware: It's that time once again (as of a few weeks ago). This one doesn't seem to be a high severity update, though. Also, it seems that 1.1.0e is due tomorrow; I'm not sure if that means 1.0.2l will also come out tomorrow, so we'll want to hold off until at least then anyway. This is mostly just a reminder for now. ---------- assignee: christian.heimes components: Installation, SSL, Windows, macOS messages: 287877 nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: high severity: normal status: open title: Upgrade installers to OpenSSL 1.0.2k type: security versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:30:06 2017 From: report at bugs.python.org (Stuart Berg) Date: Wed, 15 Feb 2017 18:30:06 +0000 Subject: [issue28837] 2to3 does not wrap zip correctly In-Reply-To: <1480503898.29.0.0471565347052.issue28837@psf.upfronthosting.co.za> Message-ID: <1487183406.34.0.364528475935.issue28837@psf.upfronthosting.co.za> Changes by Stuart Berg : ---------- pull_requests: +85 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:32:36 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 15 Feb 2017 18:32:36 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487183556.07.0.291997831999.issue22273@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- priority: normal -> high versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:33:01 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 15 Feb 2017 18:33:01 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487183581.95.0.228556359298.issue22273@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:34:14 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 15 Feb 2017 18:34:14 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487183654.76.0.689506648662.issue29565@psf.upfronthosting.co.za> Eryk Sun added the comment: Our support of passing structs and unions by value is really bad. Passing this particular struct by value is also broken on 64-bit Unix, but instead because it's small. It crashes Python due to an abort(). See issue 22273. ---------- nosy: +eryksun priority: normal -> high stage: -> needs patch versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:56:16 2017 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 15 Feb 2017 18:56:16 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487184976.86.0.360705730982.issue29571@psf.upfronthosting.co.za> Matthew Barnett added the comment: I'm just wondering whether the problem is just due to the locale's encoding being UTF-8. The locale support in re really only works with encodings that use 1 byte/character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:03:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 19:03:27 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487185407.87.0.820119398172.issue29571@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Locale encoding is ISO8859-1. This test is skipped on non 8-bit locale. This is a problem with tests, not with the re module. I don't have a solution. ---------- components: +Tests versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:12:23 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 15 Feb 2017 19:12:23 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487185943.05.0.34694954794.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: ctypes defines arrays as a pointer FFI type because they degenerate as pointers in C calls. But it's generally wrong to set a pointer FFI type for an array in the `elements` of a struct's FFI type. An integer array in a struct that's 16 bytes or less should be packed in one or two general-purpose registers (rdi, rsi, rdx, rcx, r8, r9). For the example 16-byte struct, classify_argument() in ffi64.c expects to classify two 8-byte words. But the struct's FFI type only has one element, which we've incorrectly defined as a pointer element. Thus the second word is left at the default classification X86_64_NO_CLASS. Back in ffi_call() it expects two classified words, so it aborts when it sees X86_64_NO_CLASS. I think we can special-case small arrays in PyCStructUnionType_update_stgdict when assigning the `elements` of the FFI type of a struct or union. If we have an array that's 32 bytes or less, unpack it as individual FFI elements, e.g. a c_ushort * 8 array would be stored as 8 ffi_type_uint16 elements in the struct's FFI type. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:25:47 2017 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 15 Feb 2017 19:25:47 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487186747.18.0.849520611707.issue29571@psf.upfronthosting.co.za> Matthew Barnett added the comment: The report says "== encodings: locale=UTF-8, FS=utf-8". It says that "test_locale_caching" was skipped, but also that "test_locale_flag" failed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:37:20 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 19:37:20 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487187440.85.0.5906591893.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 36da1c3589e1bc4246cccf6bd0094a110416a43a by GitHub in branch 'master': bpo-29481: add versionadded 3.6.1 to typing.Deque docs (#107) https://github.com/python/cpython/commit/36da1c3589e1bc4246cccf6bd0094a110416a43a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:38:50 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 19:38:50 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487187530.52.0.647283185606.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 7224a049b88ed37c510861528147e0db54911bb7 by GitHub in branch '3.6': bpo-29481: add versionadded 3.6.1 to typing.Deque docs (#108) https://github.com/python/cpython/commit/7224a049b88ed37c510861528147e0db54911bb7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:39:40 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 19:39:40 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487187580.13.0.00152825489746.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset bb53a27a5d56a4f33c3fc8eebb486b34808c92b7 by GitHub in branch '3.5': [cherry-pick for 3.5] bpo-29481: add versionadded 3.5.4 to typing.Deque docs (#109) https://github.com/python/cpython/commit/bb53a27a5d56a4f33c3fc8eebb486b34808c92b7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 14:41:12 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 15 Feb 2017 19:41:12 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487187672.42.0.857677199659.issue29481@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Merged and backported to 3.5 and 3.6. Thanks all :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 15:32:48 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Feb 2017 20:32:48 +0000 Subject: [issue28334] netrc does not work if $HOME is not set In-Reply-To: <1475336154.44.0.44449733804.issue28334@psf.upfronthosting.co.za> Message-ID: <1487190768.66.0.91161183121.issue28334@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +86 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:18:46 2017 From: report at bugs.python.org (DAVID ALEJANDRO Pineda) Date: Wed, 15 Feb 2017 21:18:46 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... In-Reply-To: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> Message-ID: <1487193526.94.0.354988729017.issue29517@psf.upfronthosting.co.za> DAVID ALEJANDRO Pineda added the comment: Now I try again with different ways to run a method with args, without args works fine to insert in the executor. I find there are big differences with file functools betwen versions 3.5.1 to 3.6.0. Here a more simple example for test the functools: https://github.com/dpineiden/async_multiprocessing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:21:19 2017 From: report at bugs.python.org (Richard Xia) Date: Wed, 15 Feb 2017 21:21:19 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted Message-ID: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> New submission from Richard Xia: Here is a very short program to demonstrate what I'm seeing: >>> import tempfile >>> import os >>> with tempfile.NamedTemporaryFile(delete=True) as fp: ... print(fp.name) ... os.system('rm {}'.format(fp.name)) /tmp/tmpomw0udc6 0 Traceback (most recent call last): File "", line 3, in File "/usr/local/lib/python3.6/tempfile.py", line 502, in __exit__ self.close() File "/usr/local/lib/python3.6/tempfile.py", line 509, in close self._closer.close() File "/usr/local/lib/python3.6/tempfile.py", line 446, in close unlink(self.name) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpomw0udc6' In my specific use case, I am shelling out to another program (binutils' objcopy) and passing the path of the NamedTemporaryFile as the output file. objcopy apparently deletes the output file if it encounters an error, which causes NamedTemporaryFile's exit method to fail when it tries to delete the file. While I can work around this by using delete=False and manually doing the cleanup on my own, it's less elegant than being able to rely on the normal context manager exit. ---------- components: IO messages: 287888 nosy: richardxia priority: normal severity: normal status: open title: NamedTemporaryFile with delete=True should not fail if file already deleted type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:28:40 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Feb 2017 21:28:40 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... In-Reply-To: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> Message-ID: <1487194120.51.0.503888924149.issue29517@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:42:37 2017 From: report at bugs.python.org (Jakub Stasiak) Date: Wed, 15 Feb 2017 21:42:37 +0000 Subject: [issue27494] 2to3 parser failure caused by a comma after a generator expression In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za> Message-ID: <1487194957.19.0.477908435836.issue27494@psf.upfronthosting.co.za> Changes by Jakub Stasiak : ---------- pull_requests: +87 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:54:17 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 21:54:17 +0000 Subject: [issue29563] Update Devguide about building documentation. In-Reply-To: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> Message-ID: <1487195657.59.0.644868396611.issue29563@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Per request from Brett Cannon, I've moved this issue to https://github.com/python/devguide/issues/116 . Please continue the discussion there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:03:42 2017 From: report at bugs.python.org (Jakub Stasiak) Date: Wed, 15 Feb 2017 22:03:42 +0000 Subject: [issue27494] 2to3 parser failure caused by a comma after a generator expression In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za> Message-ID: <1487196222.54.0.652346812311.issue27494@psf.upfronthosting.co.za> Changes by Jakub Stasiak : ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:46:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 22:46:17 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487198777.5.0.115002764262.issue29568@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- keywords: +patch stage: -> patch review versions: -Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46640/format-percent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:50:47 2017 From: report at bugs.python.org (Dave Anderson) Date: Wed, 15 Feb 2017 22:50:47 +0000 Subject: [issue29574] python-3.6.0.tgz permissions borked Message-ID: <1487199047.25.0.291984947125.issue29574@psf.upfronthosting.co.za> New submission from Dave Anderson: Downloaded https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tgz Extracted on CentOS6 with sudo tar -xf Python-3.6.0.tgz Result: [vagrant at developer tmp]$ ls -l Python-3.6.0 ls: cannot access Python-3.6.0/Tools: Permission denied ls: cannot access Python-3.6.0/config.guess: Permission denied ls: cannot access Python-3.6.0/pyconfig.h.in: Permission denied ls: cannot access Python-3.6.0/config.sub: Permission denied ls: cannot access Python-3.6.0/configure.ac: Permission denied ls: cannot access Python-3.6.0/Python: Permission denied ls: cannot access Python-3.6.0/Objects: Permission denied ls: cannot access Python-3.6.0/PCbuild: Permission denied ls: cannot access Python-3.6.0/Include: Permission denied ls: cannot access Python-3.6.0/aclocal.m4: Permission denied ls: cannot access Python-3.6.0/configure: Permission denied ls: cannot access Python-3.6.0/Misc: Permission denied ls: cannot access Python-3.6.0/Makefile.pre.in: Permission denied ls: cannot access Python-3.6.0/setup.py: Permission denied ls: cannot access Python-3.6.0/Lib: Permission denied ls: cannot access Python-3.6.0/PC: Permission denied ls: cannot access Python-3.6.0/Doc: Permission denied ls: cannot access Python-3.6.0/README: Permission denied ls: cannot access Python-3.6.0/Programs: Permission denied ls: cannot access Python-3.6.0/install-sh: Permission denied ls: cannot access Python-3.6.0/LICENSE: Permission denied ls: cannot access Python-3.6.0/Modules: Permission denied ls: cannot access Python-3.6.0/Grammar: Permission denied ls: cannot access Python-3.6.0/Parser: Permission denied ls: cannot access Python-3.6.0/Mac: Permission denied total 0 -????????? ? ? ? ? ? aclocal.m4 -????????? ? ? ? ? ? config.guess -????????? ? ? ? ? ? config.sub -????????? ? ? ? ? ? configure -????????? ? ? ? ? ? configure.ac d????????? ? ? ? ? ? Doc d????????? ? ? ? ? ? Grammar d????????? ? ? ? ? ? Include -????????? ? ? ? ? ? install-sh d????????? ? ? ? ? ? Lib -????????? ? ? ? ? ? LICENSE d????????? ? ? ? ? ? Mac -????????? ? ? ? ? ? Makefile.pre.in d????????? ? ? ? ? ? Misc d????????? ? ? ? ? ? Modules d????????? ? ? ? ? ? Objects d????????? ? ? ? ? ? Parser d????????? ? ? ? ? ? PC d????????? ? ? ? ? ? PCbuild d????????? ? ? ? ? ? Programs -????????? ? ? ? ? ? pyconfig.h.in d????????? ? ? ? ? ? Python -????????? ? ? ? ? ? README -????????? ? ? ? ? ? setup.py d????????? ? ? ? ? ? Tools [vagrant at developer tmp]$ Same operation with Python 3.5.2 tgz file downloaded from same location: [vagrant at developer tmp]$ ls -l Python-3.5.2 total 1008 -rw-r--r-- 1 1000 1000 8464 Jun 25 2016 aclocal.m4 -rwxr-xr-x 1 1000 1000 42856 Jun 25 2016 config.guess -rwxr-xr-x 1 1000 1000 35740 Jun 25 2016 config.sub -rwxr-xr-x 1 1000 1000 474932 Jun 25 2016 configure -rw-r--r-- 1 1000 1000 155069 Jun 25 2016 configure.ac drwxrwxr-x 18 1000 1000 4096 Jun 25 2016 Doc drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Grammar drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Include -rwxr-xr-x 1 1000 1000 7122 Jun 25 2016 install-sh drwxrwxr-x 46 1000 1000 12288 Jun 25 2016 Lib -rw-r--r-- 1 1000 1000 12767 Jun 25 2016 LICENSE drwxrwxr-x 8 1000 1000 4096 Jun 25 2016 Mac -rw-r--r-- 1 1000 1000 58449 Jun 25 2016 Makefile.pre.in drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Misc drwxrwxr-x 11 1000 1000 4096 Jun 25 2016 Modules drwxrwxr-x 4 1000 1000 4096 Jun 25 2016 Objects drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Parser drwxrwxr-x 4 1000 1000 4096 Jun 25 2016 PC drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 PCbuild drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Programs -rw-r--r-- 1 1000 1000 41897 Jun 25 2016 pyconfig.h.in drwxrwxr-x 3 1000 1000 4096 Jun 25 2016 Python -rw-r--r-- 1 1000 1000 8060 Jun 25 2016 README -rw-r--r-- 1 1000 1000 99778 Jun 25 2016 setup.py drwxrwxr-x 22 1000 1000 4096 Jun 25 2016 Tools [vagrant at developer tmp]$ ---------- components: Build messages: 287891 nosy: Dave_Anderson priority: normal severity: normal status: open title: python-3.6.0.tgz permissions borked versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:52:32 2017 From: report at bugs.python.org (Dave Anderson) Date: Wed, 15 Feb 2017 22:52:32 +0000 Subject: [issue29574] python-3.6.0.tgz permissions borked In-Reply-To: <1487199047.25.0.291984947125.issue29574@psf.upfronthosting.co.za> Message-ID: <1487199152.39.0.515231595577.issue29574@psf.upfronthosting.co.za> Dave Anderson added the comment: Sorry, should have shown sudo ls -l output for 3.6: [vagrant at developer tmp]$ sudo ls -l Python-3.6.0 total 1016 -rw-r--r-- 1 caturra games 10910 Dec 22 18:21 aclocal.m4 -rwxr-xr-x 1 caturra games 42856 Dec 22 18:21 config.guess -rwxr-xr-x 1 caturra games 35740 Dec 22 18:21 config.sub -rwxr-xr-x 1 caturra games 481627 Dec 22 18:21 configure -rw-r--r-- 1 caturra games 158661 Dec 22 18:21 configure.ac drwxr--r-- 18 caturra games 4096 Dec 22 18:23 Doc drwxr--r-- 2 caturra games 4096 Dec 22 18:21 Grammar drwxr--r-- 2 caturra games 4096 Dec 22 18:21 Include -rwxr-xr-x 1 caturra games 7122 Dec 22 18:21 install-sh drwxr--r-- 33 caturra games 4096 Dec 22 18:21 Lib -rw-r--r-- 1 caturra games 12767 Dec 22 18:21 LICENSE drwxr--r-- 8 caturra games 4096 Dec 22 18:21 Mac -rw-r--r-- 1 caturra games 58829 Dec 22 18:21 Makefile.pre.in drwxr--r-- 2 caturra games 4096 Dec 22 18:21 Misc drwxr--r-- 13 caturra games 4096 Dec 22 18:21 Modules drwxr--r-- 4 caturra games 4096 Dec 22 18:21 Objects drwxr--r-- 2 caturra games 4096 Dec 22 18:21 Parser drwxr--r-- 5 caturra games 4096 Dec 22 18:21 PC drwxr--r-- 2 caturra games 4096 Dec 22 18:21 PCbuild drwxr--r-- 2 caturra games 4096 Dec 22 18:21 Programs -rw-r--r-- 1 caturra games 41250 Dec 22 18:21 pyconfig.h.in drwxr--r-- 3 caturra games 4096 Dec 22 18:21 Python -rw-r--r-- 1 caturra games 8434 Dec 22 18:21 README -rw-r--r-- 1 caturra games 101041 Dec 22 18:21 setup.py drwxr--r-- 24 caturra games 4096 Dec 22 18:21 Tools [vagrant at developer tmp]$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:57:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 22:57:27 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487199447.82.0.225354730991.issue29571@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point. The test used locale.getlocale() and it returned returned ('en_IN', 'ISO8859-1'). Following patch makes the test using locale.getpreferredencoding(False), the same encoding as was reported at the header of test report. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file46641/test_re_locale_flag.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:58:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 22:58:47 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487199526.99.0.966551978485.issue29571@psf.upfronthosting.co.za> STINNER Victor added the comment: > Following patch ... Seriously? Not a GitHub pull request? ;-) (old habit?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:59:20 2017 From: report at bugs.python.org (Joachim) Date: Wed, 15 Feb 2017 22:59:20 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic Message-ID: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> New submission from Joachim: The ?basic example of data parallelism using Pool? is too basic. It demonstrates the syntax, but otherwise makes no sense, and therefore is potentially confusing. It is blatant nonsense to run 5 processes when there are only 3 data to be treated. Let me suggest the following: from multiprocessing import Pool import time def f(x): time.sleep(1) return x*x if __name__ == '__main__': start_time = time.time() with Pool(4) as p: print(p.map(f, range(20))) print("elapsed wall time: ", time.time()-start_time) The sleep command makes f representative for a function that takes significant time to execute. Printing the elapsed time shows the user that the 20 calls of f have indeed taken place in parallel. ---------- assignee: docs at python components: Documentation messages: 287895 nosy: docs at python, j5w6 priority: normal severity: normal status: open title: doc 17.2.1: basic Pool example is too basic versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:08:43 2017 From: report at bugs.python.org (Roger Sachan) Date: Wed, 15 Feb 2017 23:08:43 +0000 Subject: [issue29531] Update Doc/README.txt to README.rst In-Reply-To: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> Message-ID: <1487200123.35.0.184674136493.issue29531@psf.upfronthosting.co.za> Changes by Roger Sachan : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:10:39 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 23:10:39 +0000 Subject: [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line In-Reply-To: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za> Message-ID: <1487200239.34.0.28446430814.issue29561@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Thank you for the analysis, Eryk Sun. You wrote, "the interpreter is correctly conveying that it's still tokenizing the input; it hasn't compiled or executed any code." I think one important question for this issue is, what meaning should the choice of prompt convey? That breaks down into, 1. what meaning does the user believe it conveys, and 2. what meaning does the present behaviour of the code imply? "it's still tokenizing the input" translates to a meaning, sys.ps1 indicates the interpreter just finished executing and has no input, while sys.ps2 indicates the interpreter is tokenizing input and awaiting a chance to execute. I think my intuition is, and the bash shell's behaviour says, sys.ps1 indicates the interpreter is ready to start a new statement, and sys.ps2 indicates the interpreter is in the midst of a compound statement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:14:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:14:41 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487200481.21.0.883593273938.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset de553b8210882823d3df3f1ef6882eba3f8accf3 by Victor Stinner in branch '3.5': bpo-29521 update Misc/ACKS (#111) https://github.com/python/cpython/commit/de553b8210882823d3df3f1ef6882eba3f8accf3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:14:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:14:44 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487200484.02.0.353733660019.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 02e3357e089f37c23d0f3d1ebee9aa3d7a1492a9 by Victor Stinner in branch '3.6': bpo-29521 update Misc/ACKS (#110) https://github.com/python/cpython/commit/02e3357e089f37c23d0f3d1ebee9aa3d7a1492a9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:16:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:16:26 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487200586.8.0.412787625127.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 85064db281545d587992df61154e76439138319f by Victor Stinner in branch 'master': bpo-29521 update Misc/ACKS (#106) https://github.com/python/cpython/commit/85064db281545d587992df61154e76439138319f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:34:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:34:32 +0000 Subject: [issue29556] Remove unused #include In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487201672.33.0.590167971849.issue29556@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in branch 'master': bpo-29556: Remove unused #include (#98) https://github.com/python/cpython/commit/72e81d00eee685cfe33aaddf2aa9feef2d07591f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:36:06 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 23:36:06 +0000 Subject: [issue29470] ssl: SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487201766.47.0.0133121178487.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: @Christian, that was years ago and there were few examples available of people that had tried to make an SNI capable server. in several cases, people were monkey patching to make a callback. .set_servername_callback() didn't formally show up in ssl mod until 3.4. i disagree that the documentation is very clear about this. there's one direct reference to usage which is worded as "A typical use of this callback is to...". that doesn't imply 'very clear' :} i cannot recall anything anywhere that says one must not modify the context after it is used. 18.2.3 implies that a context is a long lived object, longer lived than a socket. it's clear that several people including myself, have mistakenly tried modifying the context after it was built. until now, it worked, probably purely by coincidence. as a matter of fact, i used to change more than just the key loaded. i changed the ciphers, options, and verify_flags when i knew the incoming IP was incapable of supporting modern ciphers and options. i also modified the verify paths to support a messed up corporate environment. i suggest the 18.2.3 documentation be modified to be clear about: a) if, when, and how a context can be modified after creation b) an SNI example that changes contexts and explicitly indicates (a) i don't see any value to not being clear about it, and it's disingenuous to leave nooses hiding in shadows for devs to hang themselves with :-] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:41:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:41:02 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1487202062.29.0.418591196726.issue29324@psf.upfronthosting.co.za> STINNER Victor added the comment: @matejcik: would you mind to create a pull request for your patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:48:36 2017 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Feb 2017 23:48:36 +0000 Subject: [issue29566] binhex() creates files with mixed line endings In-Reply-To: <1487161265.61.0.450348509296.issue29566@psf.upfronthosting.co.za> Message-ID: <1487202516.19.0.109958213421.issue29566@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:49:24 2017 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Feb 2017 23:49:24 +0000 Subject: [issue29563] Update Devguide about building documentation. In-Reply-To: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> Message-ID: <1487202564.82.0.702173452584.issue29563@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for moving the issue, Jim! ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 18:56:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 23:56:56 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487203016.72.0.764788856183.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset b300c660d34d2027d443098ea605a8e0eb51d383 by GitHub in branch '3.6': Backport36 doc fixes: PR#68 and PR#124 (#125) https://github.com/python/cpython/commit/b300c660d34d2027d443098ea605a8e0eb51d383 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 19:05:44 2017 From: report at bugs.python.org (Julia Dolgova) Date: Thu, 16 Feb 2017 00:05:44 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487203544.56.0.289183296638.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: Surely noone is concerned that programms written on python could work better when addressing to "python.org"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 19:07:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 00:07:17 +0000 Subject: [issue29470] ssl: SNI callbacks should not modify context objects In-Reply-To: <1487201766.47.0.0133121178487.issue29470@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: David Ford: would you mind to directly propose a doc patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 19:26:03 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 16 Feb 2017 00:26:03 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487204763.39.0.552589826811.issue29548@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 72dccde884d89586b0cafd990675b7e21720a81f by GitHub in branch 'master': bpo-29548: Fix some inefficient call API usage (GH-97) https://github.com/python/cpython/commit/72dccde884d89586b0cafd990675b7e21720a81f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 20:27:34 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 16 Feb 2017 01:27:34 +0000 Subject: [issue29576] Improve some deprecations in the importlib Message-ID: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: A couple of function in importlib are marked as deprecated in the documentation but do not raise deprecation warnings. As the same time it would be great to improve some deprecation warnings and docstring to include the version since when this is deprecated. This should be take care of by https://github.com/python/cpython/pull/32 ---------- assignee: docs at python components: Documentation messages: 287908 nosy: docs at python, mbussonn priority: normal pull_requests: 88 severity: normal status: open title: Improve some deprecations in the importlib type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 21:00:34 2017 From: report at bugs.python.org (Brett Cannon) Date: Thu, 16 Feb 2017 02:00:34 +0000 Subject: [issue29576] Improve some deprecations in the importlib In-Reply-To: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> Message-ID: <1487210434.74.0.291803014631.issue29576@psf.upfronthosting.co.za> Brett Cannon added the comment: New changeset 1d4601c2c6952d03fc4dda2b041be9aa8713c0bc by Brett Cannon in branch 'master': bpo-29576: add explicit deprecation for importlib.abc.find_loader() and find_module() (GH-32) https://github.com/python/cpython/commit/1d4601c2c6952d03fc4dda2b041be9aa8713c0bc ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 21:00:59 2017 From: report at bugs.python.org (Brett Cannon) Date: Thu, 16 Feb 2017 02:00:59 +0000 Subject: [issue29576] Improve some deprecations in the importlib In-Reply-To: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> Message-ID: <1487210459.84.0.144326209993.issue29576@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 21:09:44 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 16 Feb 2017 02:09:44 +0000 Subject: [issue29577] Enum: mixin classes don't mix well with already mixed Enums Message-ID: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> New submission from Ethan Furman: Consider: -------- class AllEnum(Enum): @classattr def ALL(cls): members = list(cls) all_value = None if members: all_value = members[0] for member in members[1:]: all_value |= member cls.ALL = all_value return all_value class Color(AllEnum, Flag): RED = auto() BLUE = auto() GREEN = auto() class IntColor(AllEnum, IntFlag): RED = auto() BLUE = auto() GREEN = auto() -------- The Color class works fine, but the IntColor fails. This is due to the way the base data type and __new__ method is discovered. If we switch the order of the bases class IntColor(IntFlag, AllEnum) it works, but having to put the mixin class last is both bizarre and unworkable when the mixin should be overriding behavior. ---------- assignee: ethan.furman components: Library (Lib) messages: 287910 nosy: barry, eli.bendersky, ethan.furman priority: normal severity: normal status: open title: Enum: mixin classes don't mix well with already mixed Enums versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 22:34:04 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 Feb 2017 03:34:04 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487216044.81.0.083459605676.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- assignee: -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 22:54:16 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 16 Feb 2017 03:54:16 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487217256.82.0.54157649501.issue29562@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Some diagnosis. Group `com.apple.sharepoint.group.1` appears to be related to a certain kind of file sharing, but I don't have hard evidence. Its only member was a test user I created as part of screen sharing with Apple Support. ``` % dscacheutil -q group -a name com.apple.sharepoint.group.1 name: com.apple.sharepoint.group.1 password: * gid: 701 users: testuser ``` I removed File Sharing for this user's home directory. 1. Open System Preferences... Sharing. 2. Click on "File Sharing", which is checked. In the right pane, a list of shared folders appears. 3. Click on the entry "Testuser Public Folder" in the Shared Folders list. 4. Click on the "-" button below the Shared Folders list. The "Testuser Public Folder" entry disappears. Having done that, the group `com.apple.sharepoint.group.1` no longer appeared. ``` % dscacheutil -q group -a name com.apple.sharepoint.group.1 % ``` Interestingly, `test_getgroups` still failed, and still had a discrepancy of two groups from the output of `id -G`. ``` % ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups test_getgroups (test.test_posix.PosixTester) ... FAIL ====================================================================== FAIL: test_getgroups (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 841, in test_getgroups self.assertEqual(len(symdiff), 0, msg) AssertionError: 2 != 0 : id -G and posix.groups() should have zero difference. Groups in id -G but not posix.groups(): [(395, 'com.apple.access_ftp'), (398, 'com.apple.access_screensharing')] Groups in posix.groups() but not id -G: [] (Effective GID (20) was disregarded.) ---------------------------------------------------------------------- Ran 1 test in 0.013s FAILED (failures=1) ``` Earlier, group `com.apple.access_ftp` was not part of the difference. Now it is. The output of `id -G` didn't change. The implementation of `posix.getgroups()` didn't change. It calls getgroups (2), I believe: https://github.com/python/cpython/blob/master/Modules/posixmodule.c#L6078-L6103 That makes me think that the behaviour of getgroups (2) in Mac OS is behaving differently than we expect. `man 2 getgroups` gives documentation. (I can't find this page at an apple URL, but http://www.manpagez.com/man/2/getgroups/ seems to have the same content.) It says, >>> "To provide compatibility with applications that use getgroups() in environments where users may be in more than {NGROUPS_MAX} groups, a variant of getgroups(), obtained when compiling with either the macros _DARWIN_UNLIMITED_GETGROUPS or _DARWIN_C_SOURCE defined, can be used that is not limited to {NGROUPS_MAX} groups. However, this variant only returns the user's default group access list and not the group list modified by a call to setgroups(2) (either in the current process or an ancestor process). Use of setgroups(2) is highly discouraged, and there is no foolproof way to determine if it has been previously called." I don't know how to determine if my copy of Mac OS X 10.10 was complied with either of these two macros. On my system, I chased NGROUPS_MAX down to /usr/include/sys/syslimits.h:84, where it is set to 16. That is more than the number of groups `id -G` is reporting, so I don't see how that is relevant. ```% id -G 20 507 12 61 80 98 399 33 100 204 395 398 ``` This is 12 groups, whereas before it was 13 groups (see my message from 2017-02-15 02:03). This is unsurprising. However, the number of groups returned by posix.getgroups() has also shrunk by 1: ```% ./python.exe -c 'import grp,os; g={i: (n, p, i, mem) for (n, p, i, mem) in grp.getgrall()}; print(sorted([(i, g[i][0]) for i in os.getgroups()]) )' [(12, 'everyone'), (20, 'staff'), (33, '_appstore'), (61, 'localaccounts'), (80, 'admin'), (98, '_lpadmin'), (100, '_lpoperator'), (204, '_developer'), (399, 'com.apple.access_ssh'), (507, 'xampp')] ``` Notice that group (395, 'com.apple.access_ftp') is no longer being returned by os.getgroups(). This is as a consequence of a different group being deleted. The test_getgroups comment asserts: "# 'id -G' and 'os.getgroups()' should return the same groups, ignoring order, duplicates, and the effective gid." https://github.com/python/cpython/blob/master/Lib/test/test_posix.py#L819-L820 I'm getting skeptical about that claim. Does Mac OS X actually guarantee that 'id -G' and 'getgroups(2)' return the same groups? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 23:18:37 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Feb 2017 04:18:37 +0000 Subject: [issue28806] Improve the netrc library In-Reply-To: <1480158810.39.0.736994382472.issue28806@psf.upfronthosting.co.za> Message-ID: <1487218717.09.0.119067058215.issue28806@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +89 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 23:25:41 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Feb 2017 04:25:41 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487219141.04.0.0976271891796.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 23:41:39 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Thu, 16 Feb 2017 04:41:39 +0000 Subject: [issue29470] ssl: SNI callbacks should not modify context objects In-Reply-To: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> Message-ID: <1487220099.06.0.437118679623.issue29470@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: yes, after i've modified my tool and ensured i know the correct way of doing it. one of the problems i'm dealing with is not carting around a global variable holding prebuilt contexts. i find it unappealing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 23:44:30 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Feb 2017 04:44:30 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487220270.86.0.45318008327.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +90 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 00:13:06 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 16 Feb 2017 05:13:06 +0000 Subject: [issue29577] Enum: mixin classes don't mix well with already mixed Enums In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> Message-ID: <1487221986.02.0.704023833101.issue29577@psf.upfronthosting.co.za> Ethan Furman added the comment: To get the above code snippet to fail properly: - remove the @classattr line - prepend from enum import Enum, Flag, IntFlag, auto ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 00:19:21 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 16 Feb 2017 05:19:21 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487222361.77.0.515485779593.issue29562@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: I guess I didn't state the things I find odd about what the new test_getgroups results. 1. `os.getgroups()` used to return group (395, 'com.apple.access_ftp'), but no longer does. I don't see a reason why. 2. `os.getgroups()` is returning 2 fewer group id's than `id -G`, even as the total number of groups is reduced. This is not the behaviour of an API limited by {NGROUPS_MAX}. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 00:48:36 2017 From: report at bugs.python.org (Jerry Dimitrov) Date: Thu, 16 Feb 2017 05:48:36 +0000 Subject: [issue29568] undefined parsing behavior with the old style string formatting In-Reply-To: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> Message-ID: <1487224116.59.0.756906059257.issue29568@psf.upfronthosting.co.za> Jerry Dimitrov added the comment: Thanks for the documentation reference. Can we at least add this link reference [1] as a note or something like that into those documentation sections: [2] https://docs.python.org/2/library/stdtypes.html#string-formatting and [3] https://docs.python.org/3/library/string.html#string-formatting I couldn't fine the printf specific documentation at first, so this is why I created the report. Regards, Jerry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 01:53:19 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 16 Feb 2017 06:53:19 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487227999.82.0.798557656433.issue29562@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: The Mac OS 10.10 man page for initgroups(3) says: "Processes should not use the group ID numbers from getgroups(2) to determine a user's group membership. The list obtained from getgroups() may only be a partial list of a user's group membership. Membership checks should use the mbr_gid_to_uuid(3), mbr_uid_to_uuid(3), and mbr_check_membership(3) functions." (http://www.manpagez.com/man/3/initgroups/ -- not official Apple page, but it matches what I see in my OS.) When the man page says, "The list obtained from getgroups() may only be a partial list of a user's group membership.", and the list from `id -G` is presumably a complete list, should we understand that Apple is saying their getgroups(2) implementation isn't POSIX-compliant? If so, maybe we should skip test_getgroups on Mac OS X systems? Or, should we consider rewriting os_getgroups_impl() to use a Mac-specific implementation on Mac OS X? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 02:00:43 2017 From: report at bugs.python.org (Zero Piraeus) Date: Thu, 16 Feb 2017 07:00:43 +0000 Subject: [issue29577] Enum: mixin classes don't mix well with already mixed Enums In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> Message-ID: <1487228443.39.0.154688412314.issue29577@psf.upfronthosting.co.za> Changes by Zero Piraeus : ---------- nosy: +zero.piraeus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 03:52:13 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 16 Feb 2017 08:52:13 +0000 Subject: [issue29574] python-3.6.0.tgz permissions borked In-Reply-To: <1487199047.25.0.291984947125.issue29574@psf.upfronthosting.co.za> Message-ID: <1487235133.83.0.168380059764.issue29574@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Indeed, there are two issue with the .tgz file: * it uses "staff" as group for all files (which will likely exist on some systems), but this appears unrelated in you case * all subdirs have go-x set, which prevents changing into the dir if you're not in the staff group, which is more of an issue In your case, the system does not seem to have a staff group, but the numeric IDs stored in the .tgz file map to another user/group. As a result, you don't get access. When creating .tgz files for redistribution, it's usually better to explicitly set the owner and group to either something that's not likely to exist on target machines or to root.root via --owner=root --group=root. As user, you can work around this by using the options --no-same-owner --no-same-permissions when extracting the archive. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 03:56:15 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 08:56:15 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 Message-ID: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> New submission from Big Stone: Hi, I have two file "t1.py" and "t2.py" in the same directory. "t2.py" can't import "t1.py" when launched from python.exe on Python-3.6. it was ok on Python-3.5 (all other things being equal). And it's ok when launched from IDLE. Has there been a volontary change ? t1.py: print("i am t1") t2.py: import t1 print("I am t2") result (on WinPython-3.6): python.Exe C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py Traceback (most recent call last): File "C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py", line 1, in import t1 ModuleNotFoundError: No module named 't1' C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\scripts> nota: Winpython specificity is the use of python._pth, with: python36.zip DLLs Lib . import site ---------- components: Windows messages: 287919 nosy: Big Stone, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 03:56:28 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 08:56:28 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487235388.79.0.681399125054.issue29578@psf.upfronthosting.co.za> Changes by Big Stone : ---------- title: "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 -> "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:07:03 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 09:07:03 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487236023.79.0.456917355067.issue29578@psf.upfronthosting.co.za> Paul Moore added the comment: This sounds like a bug in winpython, not in Python itself. You need the location of t1.py in your _pth file. See https://docs.python.org/3.6/using/windows.html#finding-modules for details. Python 3.5 didn't use the _pth file mechanism, which is why the behaviour is different. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:39:30 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 09:39:30 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487237970.71.0.655151343274.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: doesn't the "." entry means "look at same place as current source file" ? Could there be a way to get that "classic" behavior on Python-3.6 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:43:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 09:43:18 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487238198.56.0.262983198689.issue29521@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 5e04dfecec478db13031fa507d6b2e21adbce035 by GitHub in branch '3.5': Backport35 doc fixes: PR#68 and PR#124 (#125) (#126) https://github.com/python/cpython/commit/5e04dfecec478db13031fa507d6b2e21adbce035 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:46:50 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 09:46:50 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487238410.06.0.70238002713.issue29578@psf.upfronthosting.co.za> Paul Moore added the comment: No (see the doc link I referenced) - paths are absolute, or relative to the _pth file. So "." means "in the same place as the pth file". I don't think there's a way with _pth files to get the "add the location of the executed script to the front of sys.path" behaviour. It's not really a good idea for an embedded interpreter (which is the _pth file intended use case) as it makes it a bit too easy to run code from unexpected locations. In an embedded application, you could of course add sys.path entries in your C code. Maybe WinPython could do that too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:48:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 09:48:36 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst Message-ID: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> New submission from STINNER Victor: Copy of https://github.com/python/cpython/pull/104#issuecomment-280174576 --- The Windows installer build picks up this readme file and distributes it as readme.txt (see Tools/msi/exe/exe_files.wxs, which now needs fixing). I vote we should keep both so that we can distribute the file without rst formatting. (As an aside, we also read the /LICENSE file, so if someone wants to come in and "fix" that too then they'll also need to update the installer.) --- README.txt was renamed to README.rst by the PR#2: https://github.com/python/cpython/pull/2 But README.rst was then modified by PR #70, PR #73 and #21. ---------- components: Build, Windows messages: 287924 nosy: georg.brandl, haypo, ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Python 3.7 installer broken by README.txt renamed to README.rst versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:49:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 09:49:00 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487238540.77.0.684603367497.issue29579@psf.upfronthosting.co.za> STINNER Victor added the comment: I proposed to convert README.rst to HTML and provide the HTML file in the Windows installer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 05:00:47 2017 From: report at bugs.python.org (Eric Appelt) Date: Thu, 16 Feb 2017 10:00:47 +0000 Subject: [issue29026] time.time() documentation should mention UTC timezone In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za> Message-ID: <1487239247.33.0.447619889264.issue29026@psf.upfronthosting.co.za> Changes by Eric Appelt : ---------- pull_requests: +91 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 05:00:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 10:00:47 +0000 Subject: [issue29026] time.time() documentation should mention UTC timezone In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za> Message-ID: <1487239247.86.0.0601946474666.issue29026@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 23557d59b819f57800ddef0b1373acef8e024670 by Victor Stinner in branch 'master': bpo-29026: Clarify documentation of time.time (#34) https://github.com/python/cpython/commit/23557d59b819f57800ddef0b1373acef8e024670 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 05:06:25 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 10:06:25 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487239585.88.0.302653887492.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: The "targeted" user, a beginner in Python, will put its t1.py & t2.py examples anywhere on his disk, and discover that it doesn't work like in the book. It is very annoying for WinPython intended purpose, if a simple trick cannot provide the beginner "expected" behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 05:13:08 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 10:13:08 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487239988.94.0.16459126257.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: and I fail to understand why IDLE doesn't feel the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 06:21:52 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 16 Feb 2017 11:21:52 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1487244112.73.0.643714159963.issue20210@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- pull_requests: +92 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 06:28:24 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 16 Feb 2017 11:28:24 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1487244504.69.0.147126365793.issue20210@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The PR https://github.com/python/cpython/pull/132 implements the support of the *disabled* marker in a Setup file as suggested by Martin. ---------- versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 06:45:48 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 16 Feb 2017 11:45:48 +0000 Subject: [issue29577] Enum: mixin classes don't mix well with already mixed Enums In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> Message-ID: <1487245548.21.0.418246678972.issue29577@psf.upfronthosting.co.za> Ethan Furman added the comment: While only IntColor fails with an error, Color also fails as it is not a Flag type Enum: >>> list(Color) [, , ] It should have values of 1, 2, 4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 06:53:20 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 11:53:20 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487246000.63.0.570974856867.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: ok, I found this as a possible workaound. I hope it's correct on t2.py, specify the __path__ variable before importing t1. import os __path__=[os.path.dirname(os.path.abspath(__file__))] from . import t1 print("t2 done") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 07:05:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Feb 2017 12:05:04 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487246704.78.0.0177459745233.issue29571@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Seriously? Not a GitHub pull request? ;-) (old habit?) I'm not experienced with git, and devguide still looks not ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 07:29:35 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 16 Feb 2017 12:29:35 +0000 Subject: [issue29577] Enum: mixin classes don't mix well with already mixed Enums In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> Message-ID: <1487248175.0.0.787071236759.issue29577@psf.upfronthosting.co.za> Ethan Furman added the comment: Possibilities: - only allow one base Enum class (fails with All and IntFlag) - only allow base Enum classes that are compatible (so not an Enum and a Flag) (would require multiple base classes for the same behavior: DocEnum, DocFlag, etc.) - only allow one mixin (before/after that one mixin the inheritance is linear) (same issue as above) - only allow one non-Enum mixin, critical Enum is last one in the bases, previous Enums in bases are mixins (all sunder/dunder methods come from critical Enum, all normal methods and attributes are in normal base order) - be smarter about determining/saving the correct __new__ and base data type The last one needs to happen, and some form of the next-to-last one (hopefully allowing for more than one non-Enum mixin). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 07:29:49 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 12:29:49 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487248189.53.0.64018171511.issue29578@psf.upfronthosting.co.za> Paul Moore added the comment: I'm not sure about this, I've never seen __path__ used like this. Why can't you just set sys.path? sys.path.append(os.path.dirname(os.path.abspath(__file__))) That's how scripts typically adjust their search path if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:26:16 2017 From: report at bugs.python.org (jan matejek) Date: Thu, 16 Feb 2017 13:26:16 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1487251576.57.0.619846482885.issue29324@psf.upfronthosting.co.za> Changes by jan matejek : ---------- pull_requests: +94 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:29:12 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 13:29:12 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487251752.71.0.648888840974.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: Using sys.path.append could result in an arbitrary long sys.path, full of duplicates, isn't it ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:31:43 2017 From: report at bugs.python.org (Andrew Nester) Date: Thu, 16 Feb 2017 13:31:43 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487251903.1.0.923810090423.issue29553@psf.upfronthosting.co.za> Andrew Nester added the comment: any updates on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:32:06 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 13:32:06 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487251926.21.0.263467038534.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: I'm okay with including a html readme in the installer, but it has to be fully self-contained with no separate images or style sheets, and can't have any dependencies on reaching the network (until the user clicks a link, obviously). My concern with just including the rst file as-is is the formatting, particularly of links, which are now much harder to read and copy than in the txt format. In any case, we can't build a release until this is resolved one way or another. Perhaps RMs are happy to maintain the plain text version? Or we should let the github home page version diverge entirely from the actual readme and add back the original file. (I am only concerned about releasing it, so I'd like the people who maintain it to weigh in.) ---------- nosy: +benjamin.peterson priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:38:42 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 13:38:42 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487252322.05.0.586457333146.issue29578@psf.upfronthosting.co.za> Paul Moore added the comment: No more so than any other method of adding entries to sys.path (which is what __path__ does for packages, I've just never seen it used for modules). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:39:09 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 13:39:09 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487252349.92.0.185456827773.issue29578@psf.upfronthosting.co.za> Steve Dower added the comment: The ._pth file is certainly not meant to cover beginner scenarios. But with that list of paths you should get almost exactly the same sys.path by default. Modifying a module's __path__ will only affect that module (and imports via that module), whereas sys.path affects your entire program. Adding an empty string to either should give you the default behavior back, but this is specifically not supported by ._pth. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:39:20 2017 From: report at bugs.python.org (Brian Curtin) Date: Thu, 16 Feb 2017 13:39:20 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487252360.69.0.113854643896.issue29553@psf.upfronthosting.co.za> Brian Curtin added the comment: PR 120 looks fine to me, but Steven Bethard is the maintainer of argparse so he's better suited to say for sure if exclusive groups are ok how they are in 120 or if 117 is actually the way forward. ---------- assignee: -> bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:41:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 13:41:31 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487251926.21.0.263467038534.issue29579@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Another option (don't know if it's a good idea or not) is to not include any README file in the installer. Is it really worth it? Why not pointing to docs.python.org/3.7/ for example? Or suggest to install the "Windows help file" package? I just checked on my Fedora 25: the python3 package includes /usr/share/doc/python3/README file. I also checked if any other package include .rst doc: I found a lot of them. As you may expect, most Python packages. But for example, the "dnf" system tool used to manage packages only uses a README.rst file which even includes a reference to an external image: https://raw.githubusercontent.com/rpm-software-management/dnf/gh-pages/logos/DNF_logo.png You can find dnf README file at: https://github.com/rpm-software-management/dnf/blob/master/README.rst Other examples of packages including reST doc (excluding python*): devassistant, koji, vex, fpaste, pypy, git-review, hawkey, subunit, libbytesize, etc. Ah just to be clear: Fedora packages provide reST as plain text, .rst files, not HTML. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:43:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 13:43:01 +0000 Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9 In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za> Message-ID: <1487252581.08.0.236710537549.issue29324@psf.upfronthosting.co.za> STINNER Victor added the comment: Even when the fix will be backported to Python 3.6, please keep the issue open until Christian Heimes has time to review the kernel changes. Copy/paste of his message on the PR#133: "I still haven't had time to study the changes in the Linux kernel. Let's merge the PR to silence the test error. Please leave the ticket open as reminder for me." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:44:23 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 13:44:23 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487252663.46.0.0802701226311.issue29533@psf.upfronthosting.co.za> Steve Dower added the comment: There's a few reasons why you haven't heard a reply. First among them is that we're all volunteers with limited free time, and second is that we just migrated to github and all that free time is being consumed right now. Python 2.7 is only receiving security fixes at this point. We might apply a fix for this in 3.5 and later, but you haven't indicated whether it applies to those and (I assume) nobody has tested it yet. Your initial report is very good and much appreciated, we've just been busy and this doesn't jump out as urgent. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:52:42 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 16 Feb 2017 13:52:42 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487253162.19.0.638309148999.issue29533@psf.upfronthosting.co.za> Eryk Sun added the comment: gethostbyname_ex won't do a reverse lookup on an IP to get the fully-qualified domain name, which seems pointless for a function named getfqdn. I think calling gethostbyaddr is intentional here and goes back to the Python 1.x days. Also, FYI, socket_gethostbyaddr in socketmodule.c doesn't pass a name to C gethostbyaddr. It first calls setipaddr, which calls getaddrinfo to get the IP address. For "docs.python.org", the reverse lookup on the IP address has no data. Well, in Windows the error code is WSANO_DATA; in Linux I get HOST_NOT_FOUND. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:52:46 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 16 Feb 2017 13:52:46 +0000 Subject: [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies In-Reply-To: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> Message-ID: <1487253166.9.0.140346511928.issue29523@psf.upfronthosting.co.za> Changes by Charalampos Stratakis : ---------- pull_requests: +95 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:57:47 2017 From: report at bugs.python.org (Andrew Nester) Date: Thu, 16 Feb 2017 13:57:47 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted In-Reply-To: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> Message-ID: <1487253467.6.0.0164893297879.issue29573@psf.upfronthosting.co.za> Changes by Andrew Nester : ---------- pull_requests: +96 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 08:58:04 2017 From: report at bugs.python.org (Andrew Nester) Date: Thu, 16 Feb 2017 13:58:04 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted In-Reply-To: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> Message-ID: <1487253484.87.0.362950140707.issue29573@psf.upfronthosting.co.za> Andrew Nester added the comment: I've just added PR fixing this issue. ---------- nosy: +andrewnester _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 09:04:38 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 16 Feb 2017 14:04:38 +0000 Subject: [issue28787] Out of tree --with--dtrace builds fail with a traceback In-Reply-To: <1479982245.65.0.843842109576.issue28787@psf.upfronthosting.co.za> Message-ID: <1487253878.64.0.787537115349.issue28787@psf.upfronthosting.co.za> Changes by Charalampos Stratakis : ---------- pull_requests: +97 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 09:07:13 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 14:07:13 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487254033.33.0.907245891294.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: Hi Steve, Could there be a "" (or "@source" or whatever string) convention be added in python._pth to explicitely allow that "formerly default" situation ? It would not break anything backward, and allow again classic Python-3.5 code to work unchanged in all circumstances (of WinPython) again. in python-3.6.1 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 09:10:47 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 14:10:47 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487254247.65.0.131157501521.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: or just I add a blank line in current python._pth and all is ok immediately ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 09:22:14 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 14:22:14 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487254934.54.0.31575158753.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: If I place a blank line or a semi-column, nothing happen. If i put my relative path ..\test, then I must do "import t1" If I set a __path__ in t2.py, then I have to do "from . import t1" "There should be one-- and preferably only one --obvious way to do it.", but I don't clearly see it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 10:45:10 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 Feb 2017 15:45:10 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487259910.63.0.733985998996.issue22807@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I changed my mind on whether this should affect older versions of Python. I have a branch which adds an UUID.is_safe attribute that relays the platform information about whether the UUID was generated safely or not, if available. It's an enum named SafeUUID with values .safe, .unsafe, .unknown (the default). ---------- versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 10:47:02 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 Feb 2017 15:47:02 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487260022.49.0.444948133726.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- pull_requests: +98 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 10:48:50 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 15:48:50 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487260130.49.0.172263523882.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: I see absolutely no reason to use other projects on github as precedent here, as the developers have likely not made an explicit decision and are just shipping files that they already have. Github may be the home of our development now, but most users don't know or care. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 10:51:31 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 15:51:31 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487260291.44.0.387400191191.issue29578@psf.upfronthosting.co.za> Steve Dower added the comment: The semantics of the ._pth file won't be changing to accommodate security vulnerabilities, sorry. Add a sitecustomize.py file to modify sys.path if you want that behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:03:16 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 16 Feb 2017 16:03:16 +0000 Subject: [issue29567] Allow argparse to be used in setup.py In-Reply-To: <1487166912.35.0.34823901081.issue29567@psf.upfronthosting.co.za> Message-ID: <1487260996.47.0.481620431423.issue29567@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: As PR 119 is closed, I'll continue this in issue29442 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:04:18 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 16:04:18 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487261058.64.0.787308617471.issue29578@psf.upfronthosting.co.za> Paul Moore added the comment: It's probably worth also saying that maybe winpython shouldn't even be using the _pth file feature. I don't know why it is, but the intended use case for _pth files is embedded systems, so it's not clear how an alternative standalone Python interpreter matches that scenario... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:07:42 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 16:07:42 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487261262.38.0.905496315683.issue29578@psf.upfronthosting.co.za> Steve Dower added the comment: > an alternative standalone Python interpreter It's a convenient way to avoid having your standard library hijacked by registry keys installed by the regular interpreter. However, if it detects "Lib\os.py" or "python36.zip" alongside the executable, it shouldn't look in the registry to figure out its home directory. That ought to be sufficient for portable cases, though of course there are some registry entries that will still have an impact (until 3.6.1, when we should be registry clean provided one of the landmark files is found). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:10:05 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 16 Feb 2017 16:10:05 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487261405.26.0.0923699709483.issue29442@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- pull_requests: +99 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:13:17 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 16 Feb 2017 16:13:17 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487261597.26.0.0105602068013.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Now I have a working patch at PR 139, and dropping optparse is still the way to go, so I reopen it. I'm not familiar with CPython conventions. Sorry if reopening an issue is impolite. ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:13:36 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 16 Feb 2017 16:13:36 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487261616.02.0.982718569485.issue29442@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : Removed file: http://bugs.python.org/file46511/setup-argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 11:24:35 2017 From: report at bugs.python.org (Paul Moore) Date: Thu, 16 Feb 2017 16:24:35 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487261262.38.0.905496315683.issue29578@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: >> an alternative standalone Python interpreter > > It's a convenient way to avoid having your standard library hijacked by registry keys installed by the regular interpreter. Ah yes, that makes sense - it's maybe not the *right* way, but as a practical approach it has benefits :-) > However, if it detects "Lib\os.py" or "python36.zip" alongside the executable, it shouldn't look in the registry to figure out its home directory. That ought to be sufficient for portable cases, though of course there are some registry entries that will still have an impact (until 3.6.1, when we should be registry clean provided one of the landmark files is found). And that of course is the "right" way - it's just taken a long time to get there because of all the nastiness involved in interpreter startup (see PEP 432 :-)) I'd forgotten (and hadn't gone and checked) that WinPython was designed as a portable build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:12:07 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 17:12:07 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487265127.12.0.754759312463.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: ok, I understand that the improvement over current solution is, starting with python-3.6.1rc: - remove "python._pth" - check I have a "Lib\os.py" (otherwise a "python36.zip"), - and no pixie dust here or there ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:13:10 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 Feb 2017 17:13:10 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487265190.58.0.146590961216.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: Just trying to confirm my understanding - in both this issue and #22273, the example struct has a single array member. Is the problem confined just to how ctypes describes arrays in structs/unions to libffi? The comment on #22273 seems to suggest so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:32:03 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 17:32:03 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487266323.46.0.936210696127.issue29578@psf.upfronthosting.co.za> Steve Dower added the comment: > starting with python-3.6.1rc Works with 3.6.0. The only relevant changes in 3.6.1 are to skip empty lines in the ._pth file, and to avoid overwriting sys.path[0] arbitrarily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:32:50 2017 From: report at bugs.python.org (Stefan Pochmann) Date: Thu, 16 Feb 2017 17:32:50 +0000 Subject: [issue29580] "Built-in Functions" not being functions Message-ID: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> New submission from Stefan Pochmann: About https://docs.python.org/3/library/functions.html: The title "Built-in Functions", the table header "Built-in Functions" and the "functions" in the URL all suggest that what's on this page are functions. But many things on that page don't appear to be functions, like "range" or "dict". They appear to be callable types instead. For example "range": >>> type(range) >>> import types >>> isinstance(range, types.FunctionType) False >>> isinstance(range, types.BuiltinFunctionType) False Compare with "abs": >>> type(abs) >>> isinstance(abs, types.FunctionType) False >>> isinstance(abs, types.BuiltinFunctionType) True The text between title and table talks about "functions and types", but the title/tableheader/URL disagree. Also, the table is wrong in saying that "abs()" etc are functions. Should say "abs" instead, i.e., remove the "()". Many, like "abs", aren't even allowed to be called like that, as it results in "TypeError: abs() takes exactly one argument (0 given)". ---------- assignee: docs at python components: Documentation messages: 287961 nosy: Stefan Pochmann, docs at python priority: normal severity: normal status: open title: "Built-in Functions" not being functions type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:43:13 2017 From: report at bugs.python.org (Stefan Pochmann) Date: Thu, 16 Feb 2017 17:43:13 +0000 Subject: [issue29580] "Built-in Functions" not being functions In-Reply-To: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> Message-ID: <1487266993.82.0.730039614083.issue29580@psf.upfronthosting.co.za> Stefan Pochmann added the comment: The page also contains many references like "As repr(), return a string containing..." where the "()" should be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:44:46 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Feb 2017 17:44:46 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487267086.53.0.290447871555.issue29565@psf.upfronthosting.co.za> Steve Dower added the comment: The contents of the struct is just being big enough to reach the point where it is passed by reference rather than by value. This issue is pointing out that it should be a reference to a temporary copy of the struct, so that if the called function modifies the argument then it doesn't affect the caller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:48:17 2017 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Feb 2017 17:48:17 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487267297.78.0.663996866582.issue29442@psf.upfronthosting.co.za> Stefan Krah added the comment: It's okay to reopen if some conditions have changed (which is the case here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 13:00:48 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 16 Feb 2017 18:00:48 +0000 Subject: [issue29580] "Built-in Functions" not being functions In-Reply-To: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> Message-ID: <1487268048.69.0.640317926275.issue29580@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: While "functions" may not be accurate anymore, they are all callables. Historically, those callables were functions. Later on some of the built-ins were replaced with type objects. Regarding your last comment: It is common in Python to write "func()" for callables in Python. The "()" signal the callable property. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 13:54:07 2017 From: report at bugs.python.org (Nate Soares) Date: Thu, 16 Feb 2017 18:54:07 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) Message-ID: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> New submission from Nate Soares: I believe I've found a bug (or, at least, critical shortcoming) in the way that python 3.6's __init_subclass__ interacts with abc.ABCMeta (and, presumably, most other metaclasses in the standard library). In short, if a class subclasses both an abstract class and a class-that-uses-__init_subclass__, and the __init_subclass__ uses keyword arguments, then this will often lead to TypeErrors (because the metaclass gets confused by the keyword arguments to __new__ that were meant for __init_subclass__). Here's an example of the failure. This code: from abc import ABCMeta class Initifier: def __init_subclass__(cls, x=None, **kwargs): super().__init_subclass__(**kwargs) print('got x', x) class Abstracted(metaclass=ABCMeta): pass class Thingy(Abstracted, Initifier, x=1): pass thingy = Thingy() raises this TypeError when run: Traceback (most recent call last): File "", line 10, in class Thingy(Abstracted, Initifier, x=1): TypeError: __new__() got an unexpected keyword argument 'x' See http://stackoverflow.com/questions/42281697/typeerror-when-combining-abcmeta-with-init-subclass-in-python-3-6 for further discussion. ---------- messages: 287966 nosy: Nate Soares priority: normal severity: normal status: open title: __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 14:30:54 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Feb 2017 19:30:54 +0000 Subject: [issue29580] "Built-in Functions" not being functions In-Reply-To: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> Message-ID: <1487273454.58.0.827133383761.issue29580@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed with Marc. I don't think there is anything to do here. The fact that python allows classes (which are callables) to be substituted for functions is a strength, but can lead to confusion (and people getting upset when classes end up with lowercase names :) I think it would be more confusing than helpful to say "Built-in Callables". ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 14:45:02 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Feb 2017 19:45:02 +0000 Subject: [issue29582] Add Python coverage make target(s) Message-ID: <1487274302.16.0.894945109017.issue29582@psf.upfronthosting.co.za> New submission from Zachary Ware: Inspired by Barry's post to core-workflow, I'd like to suggest renaming the current "coverage" target to "ccoverage", adding a "pycoverage" target that does what .travis.yml currently does for coverage (minus uploading to codecov), and a "fullcoverage" target that does both "ccoverage" and "pycoverage". ---------- components: Build messages: 287968 nosy: barry, zach.ware priority: normal severity: normal stage: needs patch status: open title: Add Python coverage make target(s) type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 14:56:34 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 Feb 2017 19:56:34 +0000 Subject: [issue29582] Add Python coverage make target(s) In-Reply-To: <1487274302.16.0.894945109017.issue29582@psf.upfronthosting.co.za> Message-ID: <1487274994.25.0.810036805632.issue29582@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: +1 Probably ought to reconfigure .travis.yml to use the new targets too, if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 14:57:16 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 19:57:16 +0000 Subject: [issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 In-Reply-To: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> Message-ID: <1487275036.07.0.840097085323.issue29578@psf.upfronthosting.co.za> Big Stone added the comment: Thanks Steve. Change applied, byebye python._pth. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 15:15:52 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Thu, 16 Feb 2017 20:15:52 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487276152.05.0.0406228861561.issue29453@psf.upfronthosting.co.za> Changes by Jim Fasarakis-Hilliard : ---------- pull_requests: +100 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 16:45:01 2017 From: report at bugs.python.org (=?utf-8?b?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Thu, 16 Feb 2017 21:45:01 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487281501.4.0.530486979999.issue29157@psf.upfronthosting.co.za> Vladim?r ?un?t added the comment: Nitpick: here you always state that it's about glibc-2.24 but I'm very confident it only started with 2.25. ---------- nosy: +Vladim?r ?un?t _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 17:03:49 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 16 Feb 2017 22:03:49 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487282629.88.0.197221980541.issue29157@psf.upfronthosting.co.za> Christian Heimes added the comment: Some vendors backport security features to older glibc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 19:03:48 2017 From: report at bugs.python.org (Lane Campbell) Date: Fri, 17 Feb 2017 00:03:48 +0000 Subject: [issue29583] Python 3.6 won't install on Windows 2012 R2 Message-ID: <1487289828.27.0.409999068421.issue29583@psf.upfronthosting.co.za> New submission from Lane Campbell: When trying to install Python 3.6 using the "python-3.6.0-amd64.exe" installer on Windows 2012 R2 I encounter a failure. I'm flagging the options in the installer for: Customize Installation Add Python 3.6 to PATH Leaving all Optional Features selected Under Advanced Options I'm checking "Install for all users" and letting Python's installer select "Precompile standard library". This is what the installer outputs when it fails: http://pastebin.com/XUzVJ1Y5 I've tried to download KB2999226 & KB3118401 manually but they say they aren't for my version of Windows. I believe that the Python installer is detecting my version of Windows is 8.1 and isn't installing because of the Windows dependencies also fail since they are for version 8.1 (or at least appear to be). ---------- components: Windows messages: 287973 nosy: Lane Campbell, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.6 won't install on Windows 2012 R2 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 20:06:29 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 01:06:29 +0000 Subject: [issue29583] Python 3.6 won't install on Windows 2012 R2 In-Reply-To: <1487289828.27.0.409999068421.issue29583@psf.upfronthosting.co.za> Message-ID: <1487293589.76.0.46374249784.issue29583@psf.upfronthosting.co.za> Eryk Sun added the comment: To install KB3118401 [3], you may first need to install KB2919442 [1] and KB2919355 [2]. The installation order would be as follows: KB2919442: Windows8.1-KB2919442-x64.msu KB2919355: clearcompressionflag.exe Windows8.1-KB2919355-x64.msu Windows8.1-KB2932046-x64.msu Windows8.1-KB2959977-x64.msu Windows8.1-KB2937592-x64.msu Windows8.1-KB2938439-x64.msu Windows8.1-KB2934018-x64.msu KB3118401: Windows8.1-KB3118401-x64.msu [1]: https://www.microsoft.com/en-us/download/details.aspx?id=42153 [2]: https://www.microsoft.com/en-us/download/details.aspx?id=42334 [3]: https://www.microsoft.com/en-us/download/details.aspx?id=50410 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 20:55:48 2017 From: report at bugs.python.org (Yaowei Zhang) Date: Fri, 17 Feb 2017 01:55:48 +0000 Subject: [issue29584] 2D list with Bugs when defined by using Multiplication Message-ID: <1487296548.29.0.763683149264.issue29584@psf.upfronthosting.co.za> Changes by Yaowei Zhang : ---------- components: Library (Lib) nosy: Yaowei Zhang priority: normal severity: normal status: open title: 2D list with Bugs when defined by using Multiplication versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 21:03:45 2017 From: report at bugs.python.org (Yaowei Zhang) Date: Fri, 17 Feb 2017 02:03:45 +0000 Subject: [issue29584] 2D list with Bugs when defined by using Multiplication Message-ID: <1487297025.75.0.614273224132.issue29584@psf.upfronthosting.co.za> New submission from Yaowei Zhang: #If we define a list by: nums = [[0]*3]*3 #nums = [[0,0,0],[0,0,0],[0,0,0]] nums[0][1] = 1 print(mums) # the result is [[0,1,0],[0,1,0],[0,1,0]] #I think it is because all the line use the same list variable, but it suppose #not. ---------- components: +Build -Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 21:05:26 2017 From: report at bugs.python.org (Julia Dolgova) Date: Fri, 17 Feb 2017 02:05:26 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487297126.9.0.0272238570988.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: I sincerely appreciate your time. Thank you very much for your answer. I'll try to test this on python 3.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 21:17:02 2017 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Feb 2017 02:17:02 +0000 Subject: [issue29584] 2D list with Bugs when defined by using Multiplication In-Reply-To: <1487297025.75.0.614273224132.issue29584@psf.upfronthosting.co.za> Message-ID: <1487297822.35.0.982813598676.issue29584@psf.upfronthosting.co.za> Ezio Melotti added the comment: Not a bug, see https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list and https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 03:40:38 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 08:40:38 +0000 Subject: [issue26787] test_distutils fails when configured --with-lto In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za> Message-ID: <1487320838.35.0.689678750813.issue26787@psf.upfronthosting.co.za> INADA Naoki added the comment: Would you send pull request on Github? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 03:44:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 08:44:44 +0000 Subject: [issue26788] test_gdb fails all tests on a profile-opt build configured --with-lto In-Reply-To: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za> Message-ID: <1487321084.04.0.936679605943.issue26788@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM, but would you send pull request on Github? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 04:06:31 2017 From: report at bugs.python.org (Lane Campbell) Date: Fri, 17 Feb 2017 09:06:31 +0000 Subject: [issue29583] Python 3.6 won't install on Windows 2012 R2 In-Reply-To: <1487289828.27.0.409999068421.issue29583@psf.upfronthosting.co.za> Message-ID: <1487322391.72.0.685394457944.issue29583@psf.upfronthosting.co.za> Lane Campbell added the comment: Thanks Eryk, in case this helps anyone else the system is a new install of Windows 2012 R2 as of this week that I updated with all applicable Windows updates. I tried your approach and succeeded after got the following for two of your packages: KB2919442 - http://clicky.strapr.com/2W202P2k363m KB3118401 - http://clicky.strapr.com/3N301p281b0d The updates in KB2919355 did install and that seemed to fix the error. Thank you so much! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 04:57:03 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 09:57:03 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. Message-ID: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> New submission from INADA Naoki: site.py uses sysconfig (and sysconfigdata, _osx_support) module for user-site package. But sysconfig module is not so lightweight, and very rarely used. Actually speaking, only tests and distutils uses sysconfig in stdlibs. And it takes about 7% of startup time, only for searching user-site path. I tried to port minimal subset of sysconfig into site.py (GH-136). But 'PYTHONFRAMEWORK' is only in sysconfigdata. So I couldn't get rid sysconfig dependency completely. How can I do to solve this? a) Drop "osx_framework_user" (`~/Library/Python/3.7/`) support completely. b) Add "sys._osx_framework" attribute c) Create minimal sysconfigdata only for site.py d) anything else? ---------- components: Library (Lib) messages: 287981 nosy: inada.naoki priority: normal pull_requests: 101 severity: normal status: open title: site.py imports relatively large `sysconfig` module. type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:07:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 10:07:29 +0000 Subject: [issue26788] test_gdb fails all tests on a profile-opt build configured --with-lto In-Reply-To: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za> Message-ID: <1487326049.25.0.0624441148219.issue26788@psf.upfronthosting.co.za> STINNER Victor added the comment: + at unittest.skipIf(python_is_optimized(), + "Python was compiled with optimizations") class PrettyPrintTests(DebuggerTests): I disagree with this skip. I just compiled Python with "./configure" and GCC: these tests pass. Except of one buildbot, PGO is not used on buildbots nor Travis CI. I would prefer to keep running these tests by default, but only skip on PGO build. By the way, would it maybe possible to find the missing information "" from other variables? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:20:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 10:20:36 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487326836.03.0.208565963669.issue29585@psf.upfronthosting.co.za> STINNER Victor added the comment: Instead of using slow sysconfig and loading the big _sysconfig_data dictionary in memory, would it be possible to extract the minimum set of sysconfig needed by the site module and put it in a builtin module? In site.py, I only found 4 variables: from sysconfig import get_config_var USER_BASE = get_config_var('userbase') from sysconfig import get_path USER_SITE = get_path('purelib', 'osx_framework_user') USER_SITE = get_path('purelib', '%s_user' % os.name) from sysconfig import get_config_var framework = get_config_var("PYTHONFRAMEWORK") Because of the site module, the _sysconfig_data module dictionary is always loaded in memory even for for a dummy print("Hello World!"). I suggest to start building a _site builtin module: subset of site.py which would avoid sysconfig and reimplement things in C for best performances. speed.python.org: * python_startup: 14 ms * python_startup_nosite: 8 ms Importing site takes 6 ms: 42% of 14 ms... I'm interested to know if it would be possible to reduce these 6 ms by rewriting some parts of site.py in C. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:23:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 10:23:08 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487326988.21.0.396546606825.issue29585@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy collected interesting numbers, copy/paste of this message: http://bugs.python.org/issue28637#msg280380 On my computer: Importing empty module: 160 us Creating empty class: 30 us Creating empty function: 0.16 us Creating empty Enum/IntEnum: 125/150 us Creating Enum/IntEnum member: 25/27 us Creating empty namedtuple: 600 us Creating namedtuple member: 50 us Importing the itertools module: 40 us Importing the io module: 900 us Importing the os module: 1600 us Importing the functools module: 2100 us Importing the re module (with all sre submodules): 3300 us Python startup time: 43000 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:25:34 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 10:25:34 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1487327134.71.0.0509125776719.issue28637@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:32:02 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 10:32:02 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487327522.33.0.403832959954.issue29585@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:33:35 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 10:33:35 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487327615.16.0.13538850647.issue29585@psf.upfronthosting.co.za> Christian Heimes added the comment: What's your platform, Inada? Are you running macOS? I optimized site.py for Linux and BSD users a couple of years ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:48:03 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 10:48:03 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 Message-ID: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> New submission from Adrian Chan: I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3. Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error: C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed Installation details: * win 7 64 bit. * python 3.5.3 32 bit. * chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib. * installed to non-standard directory. ---------- assignee: docs at python components: Documentation, Installation, Windows messages: 287986 nosy: Adrian Chan, docs at python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot run pip in fresh install of py 3.5.3 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:01:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 11:01:49 +0000 Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad Message-ID: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za> New submission from Nathaniel Smith: Example 1: ----------- def f(): try: raise KeyError except Exception: yield gen = f() gen.send(None) gen.throw(ValueError) --------- Output: Traceback (most recent call last): File "", line 1, in File "", line 5, in f ValueError Expected output: Something involving the string "During handling of the above exception, another exception occurred", and a traceback for the original KeyError. Example 2: ----------- import sys def f(): try: raise KeyError except Exception: print(sys.exc_info()) try: yield except Exception: pass print(sys.exc_info()) raise gen = f() gen.send(None) gen.throw(ValueError) ----------- Output: (, KeyError(), ) (None, None, None) Traceback (most recent call last): File "/tmp/foo.py", line 17, in gen.throw(ValueError) File "/tmp/foo.py", line 13, in f raise RuntimeError: No active exception to reraise Expected output: certainly not that :-) This seems to happen because normally, generators save the current exc_info when yielding, and then restore it when re-entered. But, if we re-enter through 'throw' (throwflag is true), this is disabled: https://github.com/python/cpython/blob/b2ee40ed9c9041dcff9c898aa19aacf9ec60308a/Python/ceval.c#L1027 This check seems to have been added in ae5f2f4a39e6a3f4c45e9dc95bd4e1fe5dfb60f2 as a fix for: https://bugs.python.org/issue7173 which had to do with a nasty situation involving a generator object that was part of a reference cycle: the gc sometimes would free the objects stored in the generator's saved exc_info, and then try to clean up the generator by throwing in a GeneratorExit. AFAICT this situation shouldn't be possible anymore thanks to PEP 442, which makes it so that finalizers are run before any part of the cycle is freed. And in any case it certainly doesn't justify breaking code like the examples above. (Note: the examples use generators for simplicity, but of course the way I noticed this was that I had some async/await code where exceptions were mysteriously disappearing instead of showing up in __context__ and couldn't figure out why. It's likely that more people will run into this in the future as async/await becomes more widely used. As a workaround for now I'll probably modify my coroutine runner so that it never uses 'throw'.) ---------- messages: 287987 nosy: njs priority: normal severity: normal status: open title: Generator/coroutine 'throw' discards exc_info state, which is bad versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:16:31 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 11:16:31 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487330191.91.0.264283721632.issue29585@psf.upfronthosting.co.za> INADA Naoki added the comment: Christian: I'm using macOS on office and Linux on home. sysconfig is imported even on Linux https://github.com/python/cpython/blob/master/Lib/site.py#L247-L248 https://github.com/python/cpython/blob/master/Lib/site.py#L263-L271 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:35:23 2017 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 17 Feb 2017 11:35:23 +0000 Subject: [issue29588] importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined Message-ID: <1487331323.42.0.794986300226.issue29588@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: This is a regression introduced in Python 2.7.13: Importing the ssl module can fail with >>> import ssl Traceback (most recent call last): File "", line 1, in File "/Users/jdemeyer/sage/local/lib/python/ssl.py", line 133, in PROTOCOL_SSLv23 = PROTOCOL_TLS NameError: name 'PROTOCOL_TLS' is not defined While getting an ImportError from the ssl module is expected if SSL is not available (httplib for example handles that fine), a NameError is not. ---------- assignee: christian.heimes components: SSL messages: 287989 nosy: christian.heimes, jdemeyer priority: normal severity: normal status: open title: importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:45:59 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 Feb 2017 11:45:59 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487331959.6.0.49591003398.issue29585@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I don't think rewriting party of site.py in C is a good idea. It's a rather maintenance intense module. However, optimizing access is certainly something that's possible, e.g. by placing the few variables that are actually needed by site.py into a bootstrap module for sysconfig, which only contains the few variables needed by interpreter startup. Alternatively, sysconfig data could be made available via a C lookup function; with the complete dictionary only being created on demand. get_config_var() already is such a lookup API which could be used as front-end. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:46:32 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 11:46:32 +0000 Subject: [issue29588] importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined In-Reply-To: <1487331323.42.0.794986300226.issue29588@psf.upfronthosting.co.za> Message-ID: <1487331992.95.0.780147756911.issue29588@psf.upfronthosting.co.za> Christian Heimes added the comment: The _ssl extension module always defines and exports PROTOCOL_TLS. The name is always available. I guess you somehow mixed a new ssl.py with an old _ssl.so. Please verify that _ssl is correct and defines the name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:49:20 2017 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Feb 2017 11:49:20 +0000 Subject: [issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad In-Reply-To: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za> Message-ID: <1487332160.79.0.808179100516.issue29587@psf.upfronthosting.co.za> Martin Panter added the comment: The second example seems like the original complaint in Issue 25612. That spawned a separate bug related to the first situation, which was later closed: Issue 25683. ---------- nosy: +martin.panter type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:55:09 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 11:55:09 +0000 Subject: [issue25683] __context__ for yields inside except clause In-Reply-To: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za> Message-ID: <1487332509.31.0.127120222249.issue25683@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I disagree with the stated reason for closing this, because in general, implicit context chaining doesn't care about where the exception was instantiated, only where it was raised. For example: ----- err = ValueError() try: raise KeyError except Exception: raise err ----- Prints: ----- Traceback (most recent call last): File "/tmp/bar.py", line 3, in raise KeyError KeyError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/bar.py", line 5, in raise err ValueError ----- I would expect 'gen.throw(OBJ)' to be equivalent to doing 'raise OBJ' inside the generator, and raise does set __context__. ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:59:37 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 11:59:37 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487332777.71.0.971659155004.issue29586@psf.upfronthosting.co.za> Eryk Sun added the comment: Please provide the complete traceback. Copy and paste it from the command prompt. Also, include the fully-qualified path for what "python" runs, e.g. run `where python` in the command prompt. Also, include the value of the environment variables PYTHONHOME and PYTHONPATH, e.g. run `echo %PYTHONHOME% & echo %PYTHONPATH%` in the command prompt. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:01:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 12:01:49 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1487332909.48.0.70223680664.issue25612@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I read the patch but I don't understand the logic behind it :-). Why should the value of tstate->exc_type affect whether we save/restore exc_info? Won't this mean that things are still broken for code like: ----- def f(): try: raise KeyError except Exception: try: yield except Exception: pass raise try: raise NameError except Exception: gen = f() gen.send(None) gen.throw(ValueError) ----- ? Conceptually I would have thought the fix would be to remove the '!throwflag' check, but I haven't actually tried it... ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:05:01 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 12:05:01 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1487333101.64.0.144091101269.issue25612@psf.upfronthosting.co.za> Nathaniel Smith added the comment: (Issue 29587 is a duplicate of this one, but it has some more information on where the !throwflag check came from and why it might be possible to remove it now.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:06:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 12:06:23 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487331959.6.0.49591003398.issue29585@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Marc-Andre Lemburg added the comment: > I don't think rewriting party of site.py in C is a good idea. It's a rather maintenance intense module. > > However, optimizing access is certainly something that's possible, e.g. by placing the few variables that are actually needed by site.py into a bootstrap module for sysconfig, which only contains the few variables needed by interpreter startup. Right, I don't propose to rewrite the 598 lines of site.py in C, but only rewrite the parts which have a huge impact on the startup time. It seems like the minimum part would be to write a _site module which provide the 4 variables currently read from sysconfig. I'm proposing to add a new private module because I don't want to pollute site which already contains too many things. I looked at site.py history: I don't see *major* changes last 2 years. Only small enhancements, updates and fixes. > Alternatively, sysconfig data could be made available via a C lookup function; with the complete dictionary only being created on demand. get_config_var() already is such a lookup API which could be used as front-end. I don't think that it's worth it to reimplement partially sysconfig in C. This module is huge, complex, and platform dependant. Well, I'm not sure about what is the best approach, but I'm sure that we can do something to optimize site.py. 6 ms is a lot! I never liked site.py. It seems like a huge workaround. I also dislike having a different behaviour if site is imported or not. That's why I asked Steve Dower to removing the code to create the cpXXX alias for the mbcs codec from site.py to encodings/__init__.py: see commit f5aba58480bb0dd45181f609487ac2ecfcc98673. I'm happy that this code was removed from site.py! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:12:04 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 12:12:04 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487333524.59.0.934793215956.issue29586@psf.upfronthosting.co.za> Adrian Chan added the comment: There is no traceback, that is the entirety of the output of the command. Python bin is C:\Python\Python35-32\python.exe PYTHONHOME is not set. PYTHONPATH is C:\python27\lib\site-packages\ I don't know why PYTHONPATH was set. I cleared it but it made no difference -- same error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:14:05 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 12:14:05 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487333645.56.0.725189530296.issue29585@psf.upfronthosting.co.za> Christian Heimes added the comment: Instead of _site, would it make sense to include the four vars in sys, perhaps as named structure like sys.flags? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:28:46 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 12:28:46 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487334526.45.0.719596926171.issue29585@psf.upfronthosting.co.za> INADA Naoki added the comment: FYI, here is profile of site: https://gist.github.com/methane/1f1fe4385dad84f03eb429359f0f917b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:46:11 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 12:46:11 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487335571.49.0.418317185163.issue29585@psf.upfronthosting.co.za> INADA Naoki added the comment: no-site python_startup_no_site: Median +- std dev: 9.13 ms +- 0.02 ms default: python_startup: Median +- std dev: 15.6 ms +- 0.0 ms GH-136 + skip abs_paths(). python_startup: Median +- std dev: 14.2 ms +- 0.0 ms profile of GH-136 + skip abs_paths(): https://gist.github.com/methane/26fc0a2382207655a6819a92f867620c Most of time is consumed by importlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:53:23 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 12:53:23 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487336003.77.0.372373495445.issue29586@psf.upfronthosting.co.za> Eryk Sun added the comment: That error looks like __init__.py[c] was left in "C:\python27\lib\site-packages\pip". Just to be sure, since I don't know what you did to clear the value, please run `set PYTHONPATH=` to clear the value for the current shell. Then try `python -m pip`. When you modify or remove an environment variable using the control panel dialog, it broadcasts a window message that causes Explorer to reload its environment. Generally console applications such as cmd.exe do not own a top-level window (the console window is owned by conhost.exe) and thus cannot see this broadcasted message. To get the updated environment, you have to run a new instance of cmd from Explorer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 07:58:51 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 12:58:51 +0000 Subject: [issue29583] Python 3.6 won't install on Windows 2012 R2 In-Reply-To: <1487289828.27.0.409999068421.issue29583@psf.upfronthosting.co.za> Message-ID: <1487336331.91.0.635982308933.issue29583@psf.upfronthosting.co.za> Eryk Sun added the comment: That's good news. As far as I can see, there isn't anything Python's installer can do if the CRT update fails for reasons beyond our control, so I'm closing this as a 3rd party issue. Thank you for the report. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 08:20:57 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 13:20:57 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487337657.28.0.69321751787.issue29586@psf.upfronthosting.co.za> Adrian Chan added the comment: Thanks, but I know how to drive a terminal ;) Your hunch was basically correct though. I ran again with `python -v -m pip` (see with_pip_dir.txt), and see that python is attempting to import pip from my user directory (C:\Users\amc2\pip). This is an empty directory, except for an old pip log file from 2.7. If I rename the directory to something unrelated, `python -m pip` just fails with: C:\Python\Python35-32\python.exe: No module named pip. So mystery 1 is solved. I've definitely selected the pip option in the python installer. I also repaired the installation, with the pip option selected, and the error still remains. Where is pip supposed to be located on a win7 install? ---------- Added file: http://bugs.python.org/file46642/import_logs.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 08:23:21 2017 From: report at bugs.python.org (Dima Zhukov) Date: Fri, 17 Feb 2017 13:23:21 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed Message-ID: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> New submission from Dima Zhukov: Hi, i'm new to Python. Just have downloded source code and tried to install it, but "make test" failed 2 test: test_asyncio and test_multiprocessing_forkserver. How bad is it and what should i do? Logs attached ---------- components: Build files: tests.output messages: 288005 nosy: Dima Zhukov priority: normal severity: normal status: open title: test_asyncio & test_multiprocessing_forkserver failed type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46643/tests.output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 08:51:33 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 17 Feb 2017 13:51:33 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487339493.02.0.771804439144.issue29176@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Here are test results for PR 53: shell at ASUS_Z00E_2:/data/local/tmp $ python3.7m -m test -u curses test_curses Run tests sequentially 0:00:00 [1/1] test_curses 1 test OK. Total duration: 1 sec Tests result: SUCCESS abcshell at ASUS_Z00E_2:/data/local/tmp $ I know little about the C API. Just a question: isn't PyImport_ImportModuleNoBlock deprecated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 08:55:06 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 13:55:06 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487339706.14.0.803530601557.issue29586@psf.upfronthosting.co.za> Eryk Sun added the comment: pip should be installed in site-packages, which for you is "C:\Python\Python35-32\Lib\site-packages". Try manually running ensurepip to make sure pip is installed: python -m ensurepip --verbose --upgrade --default-pip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 09:13:09 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 14:13:09 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487340789.88.0.13232730769.issue29586@psf.upfronthosting.co.za> Adrian Chan added the comment: It's all working fine now, thanks. If one of the installer/windows guys wants to dig more into why this didn't install properly I'm happy to run things in my environment as necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 09:22:18 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 14:22:18 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487341338.88.0.173691539885.issue29586@psf.upfronthosting.co.za> Eryk Sun added the comment: If you have the 3.5 installation logs in your %TEMP% directory, please zip them up and attach them to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 09:23:48 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 14:23:48 +0000 Subject: [issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw() Message-ID: <1487341428.62.0.272190755105.issue29590@psf.upfronthosting.co.za> New submission from Nathaniel Smith: The attached script sets up a stack of generators calling each other via 'yield from': f yields from g yield from h. Then the generator at the bottom of the stack yields. Before they yield, sys._getframe shows the expected stack (or if you put in traceback.print_stack() you get the same thing). After they yield, it depends: if the generator is resumed via 'gen.send(None)', then the stack looks sensible. But if the generator is resumed via 'gen.throw(...)', then the stack is weird: Objects/genobject.c:_gen_throw implements 'yield from' in an weird manual way, where it first directly resumes the innermost generator frame, and then propagates any result to the next generator frame, etc. So the output I get from the sample script is: ~$ python3.6 weird-throw-stack.py -- f before yielding -- f -- g before yielding -- g f -- h before yielding -- h g f -- h after yielding -- h -- g after yielding -- g -- f after yielding -- f This causes problems for stack-based profiling (https://github.com/vmprof/vmprof-python/issues/117), debuggers, and other tools that need to introspect the stack. ---------- files: weird-throw-stack.py messages: 288010 nosy: njs priority: normal severity: normal status: open title: Incorrect stack traces when re-entering a generator/coroutine stack via .throw() versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46644/weird-throw-stack.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 09:59:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 14:59:55 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1487339493.02.0.771804439144.issue29176@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thank you for your check! Good to know that it works on Android. Chi Hsuan Yen added the comment: > I know little about the C API. Just a question: isn't PyImport_ImportModuleNoBlock deprecated? I am not aware of any deprecation: https://docs.python.org/dev/c-api/import.html#c.PyImport_ImportModuleNoBlock Oh, it seems like the function is now more an less an alias to PyImport_ImportModule(). I wasn't aware that the "NoBlock" is no more needed: I copied/pasted from a different .c file, I don't recall which one. I should updated other files ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:18:43 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Feb 2017 15:18:43 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1487344723.46.0.886837456424.issue25612@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From mal at egenix.com Fri Feb 17 10:30:34 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 17 Feb 2017 16:30:34 +0100 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: References: Message-ID: <5462d68e-f0a1-01cf-0aab-0f3cf252a1f9@egenix.com> On 17.02.2017 13:06, STINNER Victor wrote: >> Alternatively, sysconfig data could be made available via a C lookup function; with the complete dictionary only being created on demand. get_config_var() already is such a lookup API which could be used as front-end. > > I don't think that it's worth it to reimplement partially sysconfig in > C. This module is huge, complex, and platform dependant. Sorry, I was just referring to the data part of sysconfig, not sysconfig itself. Having a lookup function much like we have for unicodedata makes things much more manageable, since you don't need to generate a dictionary in memory for all the values in the config data. Creating that dictionary takes a while (in terms of ms). -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Fri Feb 17 10:30:39 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 Feb 2017 15:30:39 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: Message-ID: <5462d68e-f0a1-01cf-0aab-0f3cf252a1f9@egenix.com> Marc-Andre Lemburg added the comment: On 17.02.2017 13:06, STINNER Victor wrote: >> Alternatively, sysconfig data could be made available via a C lookup function; with the complete dictionary only being created on demand. get_config_var() already is such a lookup API which could be used as front-end. > > I don't think that it's worth it to reimplement partially sysconfig in > C. This module is huge, complex, and platform dependant. Sorry, I was just referring to the data part of sysconfig, not sysconfig itself. Having a lookup function much like we have for unicodedata makes things much more manageable, since you don't need to generate a dictionary in memory for all the values in the config data. Creating that dictionary takes a while (in terms of ms). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:37:46 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Feb 2017 15:37:46 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1487345866.83.0.0891673982949.issue28637@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:38:24 2017 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Feb 2017 15:38:24 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487345904.21.0.633025370452.issue29579@psf.upfronthosting.co.za> Zachary Ware added the comment: With the exception of the Travis and Codecov badges, `rst2html README.rst` produces a nicely self-contained HTML readme. However, I'm not sure how useful that readme is on Windows. Perhaps we should draft a new, simple readme for inclusion in the Windows installers that focuses on Python on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:39:39 2017 From: report at bugs.python.org (Natanael Copa) Date: Fri, 17 Feb 2017 15:39:39 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat Message-ID: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> New submission from Natanael Copa: cpython bundles expat in Modules/expat/ and needs to be updated to expat-2.2.0 to fix various security vulnerabilities. 21 June 2016, Expat 2.2.0 released. Release 2.2.0 includes security & other bug fixes. Security fixes CVE-2016-0718 (issue 537) Fix crash on malformed input CVE-2016-4472 Improve insufficient fix to CVE-2015-1283 / CVE-2015-2716 introduced with Expat 2.1.1 CVE-2016-5300 (issue 499) Use more entropy for hash initialization than the original fix to CVE-2012-0876 CVE-2012-6702 (issue 519) Resolve troublesome internal call to srand that was introduced with Expat 2.1.0 when addressing CVE-2012-0876 (issue 496) Fix should be applied to all maintained python branches. ---------- messages: 288014 nosy: Natanael Copa priority: normal severity: normal status: open title: Various security vulnerabilities in bundled expat type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:41:04 2017 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Feb 2017 15:41:04 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487346064.64.0.402946267367.issue29579@psf.upfronthosting.co.za> Zachary Ware added the comment: Another option acceptable to me would be to simply leave out the readme entirely. I wasn't even aware it was included until this issue came up :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:41:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 15:41:46 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487346106.89.0.306262096079.issue29591@psf.upfronthosting.co.za> STINNER Victor added the comment: > CVE-2012-6702 (issue 519) > Resolve troublesome internal call to srand that was introduced with Expat 2.1.0 when addressing CVE-2012-0876 (issue 496) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6702 Extract of Modules/pyexpat.c: --- #if ((XML_MAJOR_VERSION >= 2) && (XML_MINOR_VERSION >= 1)) || defined(XML_HAS_SET_HASH_SALT) /* This feature was added upstream in libexpat 2.1.0. Our expat copy * has a backport of this feature where we also define XML_HAS_SET_HASH_SALT * to indicate that we can still use it. */ XML_SetHashSalt(self->itself, (unsigned long)_Py_HashSecret.prefix); #endif --- Python 2.7, 3.5, 3.6 and 3.7 have this call at least (I didn't check other versions). ---------- nosy: +christian.heimes, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:42:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 15:42:34 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487346154.93.0.721601609167.issue29591@psf.upfronthosting.co.za> STINNER Victor added the comment: You may want to look also at https://pypi.python.org/pypi/defusedxml ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:43:56 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 17 Feb 2017 15:43:56 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487346236.81.0.0445786901781.issue29591@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:44:49 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 15:44:49 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487346289.11.0.697992723862.issue29591@psf.upfronthosting.co.za> Christian Heimes added the comment: CVE-2016-0718 and CVE-2016-4472 might be relevant for Python. CVE-2016-5300 and CVE-2012-6702 are irrelevant. As Victor already pointed out, Python seeds libexpat from a good CPRNG. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:46:00 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 Feb 2017 15:46:00 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487346360.4.0.992200557451.issue29591@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes components: +XML stage: -> needs patch versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 11:19:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 16:19:42 +0000 Subject: [issue29592] abs_paths() in site.py is slow Message-ID: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> New submission from INADA Naoki: abs_paths() is the another most slow parts of site module. We can speedup it if we have C implementation of os.path.abspath() or abs_paths(). But before trying it, is abs_paths() really needed for now? It only rewrite `__file__` and `__cached__` of modules imported before site is imported. What is difference between modules loaded befere / after site module? Here is profile output. sysconfig dependency is removed by #29585 patch, and pstat is modified to show time in ms instead of sec. Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 3/1 0.004 0.001 2.525 2.525 {built-in method builtins.exec} 1 0.003 0.003 2.524 2.524 x.py:1() 1 0.010 0.010 1.806 1.806 site.py:555(main) 4/3 0.022 0.005 1.179 0.393 :958(_find_and_load) 4/3 0.017 0.004 1.110 0.370 :931(_find_and_load_unlocked) 1 0.195 0.195 0.928 0.928 site.py:99(abs_paths) 108 0.098 0.001 0.776 0.007 posixpath.py:367(abspath) 4 0.035 0.009 0.647 0.162 :861(_find_spec) 4 0.005 0.001 0.589 0.147 :1150(find_spec) 4 0.043 0.011 0.584 0.146 :1118(_get_spec) 2/1 0.012 0.006 0.557 0.557 :641(_load_unlocked) 2/1 0.006 0.003 0.511 0.511 :673(exec_module) 108 0.461 0.004 0.493 0.005 posixpath.py:329(normpath) 16 0.150 0.009 0.453 0.028 :1234(find_spec) ---------- components: Library (Lib) messages: 288019 nosy: inada.naoki priority: normal severity: normal status: open title: abs_paths() in site.py is slow type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 11:42:40 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 16:42:40 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487349760.33.0.160846563555.issue29585@psf.upfronthosting.co.za> INADA Naoki added the comment: I create #29592 for abs_paths(). Let's focus on sysconfig in this issue. PR 136 ports really needed part of sysconfig into site.py already. 'PYTHONFRAMEWORK' on macOS is the only variable we need import from sysconfig. Adding `site.cfg` like `pyvenv.cfg` make sense? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 11:52:26 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 17 Feb 2017 16:52:26 +0000 Subject: [issue26788] test_gdb fails all tests on a profile-opt build configured --with-lto In-Reply-To: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za> Message-ID: <1487350346.72.0.173743444871.issue26788@psf.upfronthosting.co.za> Gregory P. Smith added the comment: there may be something in sysconfig.get_config_vars() we could use or, better, we could add something specific to indicate both pgo and lto builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:00:56 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 17:00:56 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487350856.76.0.323158819118.issue29586@psf.upfronthosting.co.za> Adrian Chan added the comment: Install logs attached. First set from initial install, second set from repair. ---------- Added file: http://bugs.python.org/file46645/py_install_logs.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:06:57 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 17 Feb 2017 17:06:57 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names Message-ID: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: Raymond Hettinger reported during PyCon Canada 2016 Keynote (~20m30 sec) that unbound local error message was inaccurate, it state that : > local variable 'xxx' referenced before assignment Though it can be assigned and deleted. for a toy example: def foo(): x = 1 del x print(x) foo() Do the same for free variable. def multiplier(n): def multiply(x): return x * n del n return multiply The error message can be improved by adding "or got deleted". ---------- messages: 288023 nosy: mbussonn priority: normal pull_requests: 102 severity: normal status: open title: Improve UnboundLocalError message for deleted names type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:11:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Feb 2017 17:11:32 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names In-Reply-To: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> Message-ID: <1487351492.42.0.498563832384.issue29593@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wouldn't be better to say just "local variable 'xxx' is not set"? ---------- components: +Interpreter Core nosy: +martin.panter, r.david.murray, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:18:24 2017 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 17 Feb 2017 17:18:24 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487351904.32.0.262234966403.issue29549@psf.upfronthosting.co.za> Ben Hoyt added the comment: Good call. Additionally, it's weird to me that the docstring for str.find() says "Return -1 on failure." because the string not being found is not a "failure". Like the docs (https://docs.python.org/3.5/library/stdtypes.html#str.find) say, the str.find() docstring should say "Return -1 if sub is not found." ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:28:25 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 17 Feb 2017 17:28:25 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487352505.47.0.51352761007.issue29581@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:31:10 2017 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 17 Feb 2017 17:31:10 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487352670.49.0.851902507592.issue29540@psf.upfronthosting.co.za> Ben Hoyt added the comment: I agree with the confusion (PR proposes separators=COMPACT, issue compact=True). I like the concept but not either of the APIs proposed. I *much* more often want to get pretty output -- if I had a dime for every time I've written "json.dumps(obj, sort_keys=True, indent=4)" I'd be rich enough to buy an entire cup of Starbucks coffee. But then you'd need a pretty=True option as well, which would be mutually exclusive with compact=True, so not great. But what about a style= (or "format="?) parameter, which defaults to 'default' (or just None) meaning the same as now. If you pass format='pretty' you get "sort_keys=True, indent=4" and if you pass format='compact' you get "separators=(',', ':')". ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:46:47 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 17 Feb 2017 17:46:47 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487353607.05.0.782917970235.issue29546@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:47:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Feb 2017 17:47:54 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487353674.48.0.373114022915.issue29549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: str.index() still is not converted to Argument Clinic (this is not easy). The docstring needs to be rewritten when convert it to Argument Clinic in any case. It would be nice to make it Argument Clinic compatible right now. The first line line should be short description, following paragraph(s) can describe more details, the description shouldn't refer to the metavariable S. Docstrings for str, bytes and bytearray methods should be synchronised. Look also at docstrings for the index() method in other sequence types (list, tuple, deque, array, Sequence). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:57:50 2017 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Feb 2017 17:57:50 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487354270.83.0.667827733495.issue29579@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, we do not include the top-level README in the macOS installer package. Instead, we supply Mac-installer specific Welcome and Readme files that are displayed by the macOS Installer app during the installation process and the installer Readme is also installed for later reference. These files are also the primary documentation for python.org macOS binary installer changes. I agree with Zach that the top-level README doesn't seem very useful for binary installs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:59:34 2017 From: report at bugs.python.org (Marc Guetg) Date: Fri, 17 Feb 2017 17:59:34 +0000 Subject: [issue29594] implement __or__ in enum.auto Message-ID: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> New submission from Marc Guetg: At the moment it is only possible to combine flags that already exist: from enum import * class Foo(Flag): A = auto() # 1 B = auto() # 2 AB = A | B # 3 (1 | 2) AC = auto() | A # Fails, but should be 5 (1 | 4) ABD = auto() | A | B # Just taking it one step further to make a point, 11 (1 | 2 | 8) It would be nice to have this for cases when C only makes sense in combination with A but not on its own. A solution to achieve this one would need to change two things in ~/cpython/Lib/enum.py First extend class auto by: class auto: """ Instances are replaced with an appropriate value in Enum class suites. """ value = _auto_null or_value = 0 def __or__(self, other): """ Postpone the real or operation until value creation in _EnumDict """ self.or_value |= other return self And second change one line in _EnumDict: value = value.value changes to: value = value.value | value.or_value Some simple tests show the expected results: print(repr(Foo.A)) # A - 1 print(repr(Foo.B)) # B - 2 print(repr(Foo.AB)) # AB - 3 print(repr(Foo.AC)) # AC - 5 print(repr(Foo.A | Foo.AC)) # AC - 5 print(repr(Foo.A & Foo.AC)) # A - 1 print(repr(Foo.ABD)) # ABD - 11 Would it make sense to enhance python enums with that functionality? ---------- components: Library (Lib) files: test.py messages: 288029 nosy: magu priority: normal severity: normal status: open title: implement __or__ in enum.auto type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46646/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 13:00:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Feb 2017 18:00:38 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487354438.61.0.757490000043.issue29540@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since core developers have different opinions about this issue, it should be discussed on the Python-Dev maillist until one side convince the other side or BDFL make his decision. Personally I dislike any complication of json API. Likely it is already the most complicated API in the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 13:06:08 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 18:06:08 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487354768.98.0.539543353446.issue29565@psf.upfronthosting.co.za> Eryk Sun added the comment: This issue is more straight-forward than #22273. ISTM, we just have to copy large values. For example, in ffi_call, we'd iterate over the arguments and alloca and memcpy the large values prior to calling ffi_call_AMD64: case FFI_SYSV: /* If a single argument takes more than 8 bytes, then a copy is passed by reference. */ for (unsigned i = 0; i < cif->nargs; i++) { size_t z = cif->arg_types[i]->size; if (z > 8) { void *temp = alloca(z); memcpy(temp, avalue[i], z); avalue[i] = temp; } } /*@-usedef@*/ return ffi_call_AMD64(ffi_prep_args, &ecif, cif->bytes, cif->flags, ecif.rvalue, fn); /*@=usedef@*/ break; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 13:30:21 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 17 Feb 2017 18:30:21 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names In-Reply-To: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> Message-ID: <1487356221.24.0.541883873671.issue29593@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > Wouldn't be better to say just "local variable 'xxx' is not set"? Thank you for responding that fast and for your interest in this issue. While I think that "local variable 'xxx' is not set" is technically correct, I think it would be a step back. The improvement of the error message is not really meant for the 99% of the developers hanging on b.p.o. I think for these just the fact that there is an UnboundLocalError is sufficient to know what's happening. The error message will mostly be useful for users that still don't have much clue about what's going on. For these kind of users UnboundLocalError("local variable 'xxx' is not set") is not much different from NameError("name 'xxx' is not defined")[*] The current error message already does a good job at giving some extra hint as to why this is the case. In particular that it is (often) assigned but not in the right place. Changing to "local variable 'xxx' is not set" will likely make many novices check the spelling, and be more confused. Note that "local variable 'xxx' referenced before assignment, or got deleted" would not be completely obvious for novices either, why would the following not trigger such an error ? In [1]: def foo(): ...: if False: ...: print(n) ...: n = 1 Well, for you and me it's (likely) obvious. I want to point out (just stealing rhettinger example) that it might not be obvious either the variable has been deleted: In [5]: def foo(): ...: n = 1 ...: def g(): # imagine a more complex g ...: del n ...: g() ...: print(n) #UnboundLocalError ...: So I think expanding the error message to give hints as of _why_ is better than just stating what is. [*] Source: The users I work with. Last question I got on wednesday: "Can you re-explain the difference between a string and a function". They meant "list" and "list comprehension". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 13:53:40 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 Feb 2017 18:53:40 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487357620.37.0.416278772882.issue29585@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +merwok _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 13:55:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Feb 2017 18:55:14 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names In-Reply-To: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> Message-ID: <1487357714.52.0.867632515389.issue29593@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Adding "or got deleted" makes the error message longer, and since "del" is rarely used for deleting local variables I afraid that it can add confusion in most cases. The "del" statement is not the only way to unset the local variable. >>> def foo(): ... e = None ... try: ... 1/0 ... except Exception as e: ... pass ... print(e) ... >>> foo() Traceback (most recent call last): File "", line 1, in File "", line 7, in foo UnboundLocalError: local variable 'e' referenced before assignment ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 14:05:34 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Feb 2017 19:05:34 +0000 Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses Message-ID: <1487358334.6.0.405170673757.issue1025395@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +103 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 14:20:15 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Feb 2017 19:20:15 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487359215.84.0.158656761243.issue29586@psf.upfronthosting.co.za> Eryk Sun added the comment: The original install failed with the status code STATUS_DLL_NOT_FOUND (0xC0000135), as reported in "Python 3.5.3 (32-bit)_20170217102132_008_pip_JustForMe.log": MSI (s) (88:D8) [10:22:59:574]: Executing op: ActionStart(Name=UpdatePip,,) MSI (s) (88:D8) [10:22:59:575]: Executing op: CustomActionSchedule( Action=UpdatePip,ActionType=1089, Source=BinaryData,Target=CAQuietExec, CustomActionData="C:\Python\Python35-32\python.exe" -E -s -m ensurepip -U --default-pip) MSI (s) (88:C4) [10:22:59:588]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2C60.tmp, Entrypoint: CAQuietExec MSI (s) (88:B0) [10:22:59:588]: Generating random cookie. MSI (s) (88:B0) [10:22:59:590]: Created Custom Action Server with PID 6212 (0x1844). MSI (s) (88:A8) [10:22:59:630]: Running as a service. MSI (s) (88:A8) [10:22:59:631]: Hello, I'm your 32bit Impersonated custom action server. CAQuietExec: Error 0xc0000135: Command line returned an error. CAQuietExec: Error 0xc0000135: QuietExec Failed CAQuietExec: Error 0xc0000135: Failed in ExecCommon method MSI (s) (88:D8) [10:22:59:658]: Executing op: End(Checksum=0, ProgressTotalHDWord=0,ProgressTotalLDWord=287056) CustomAction UpdatePip returned actual error code 1603 but will be translated to success due to continue marking Did your system require a reboot for Python 3.5 to work? >From what I can see in "Python 3.5.3 (32-bit)_20170217131555_007_pip_JustForMe.log", it looks like the repair skipped installing pip. MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetRemovePipCommandLine (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetUpdatePipCommandLine (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Skipping action: UpdatePip (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Doing action: InstallFinalize MSI (s) (D8:1C) [13:16:31:822]: Note: 1: 2205 2: 3: ActionText Action ended 13:16:31: PublishProduct. Return value 1. Maybe Steve Dower can shed light on why a repair with pip selected didn't try to install pip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 15:13:46 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Feb 2017 20:13:46 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487362426.21.0.657605703195.issue29586@psf.upfronthosting.co.za> Steve Dower added the comment: Depending on why the pip install failed, we may still have registered that it was installed. IIRC, we only trigger the install on a state change, which wouldn't happen in repair. That deserves its own bug (though maybe this one will suffice if we figure out the original failure - I haven't looked at the logs yet) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 15:16:38 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Feb 2017 20:16:38 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487362598.35.0.111252523575.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: Okay. Unless someone volunteers to write a Windows specific one, I'll make the change to the installer to leave it out. Anyone know how far the change has been backported? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 15:21:12 2017 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Feb 2017 20:21:12 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487362872.51.0.845673392742.issue29579@psf.upfronthosting.co.za> Zachary Ware added the comment: So far, to 3.6. I don't really expect it to move back to 3.5, and 2.7's README is its own mess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 15:37:35 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 17 Feb 2017 20:37:35 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names In-Reply-To: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> Message-ID: <1487363855.2.0.77536351524.issue29593@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > makes the error message longer Out of curiosity is there a guide as to what is considered a too long error message ? Or is there a technical reason like after a certain length strings are not cached and exception will be slower to construct ? I'm trying to understand why rhettinger would have proposed in his talk to make this specific error message longer and there is a push back now. > and since "del" is rarely used for deleting local variables I afraid that it can add confusion in most cases. > The "del" statement is not the only way to unset the local variable. Good point, would "or has been unset" be acceptable ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 15:50:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Feb 2017 20:50:54 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487362872.51.0.845673392742.issue29579@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Steve> Anyone know how far the change has been backported? Ah, it seems like the README.txt => README.rst change was backported: commit 1e8cc88a48a049b064f786bb4b97ea60b70dc504. Since it breaks the Windows installer, I suggest to revert this change. FYI my first motivation to convert README to reST was to have a nicer homepage for http://github.com/python/cpython/ But the homepage uses the README of the master branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 16:10:14 2017 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Feb 2017 21:10:14 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487365814.46.0.258452243837.issue29579@psf.upfronthosting.co.za> Zachary Ware added the comment: There were significant corrections to the README in that backport that should not be lost if we do de-restify the 3.6 readme. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 16:20:15 2017 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Feb 2017 21:20:15 +0000 Subject: [issue29593] Improve UnboundLocalError message for deleted names In-Reply-To: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> Message-ID: <1487366415.83.0.451357806645.issue29593@psf.upfronthosting.co.za> Martin Panter added the comment: Matthias?s proposal sounds reasonable to me. There is a minor disadvantage that it will exceed the width of an 80-character terminal: UnboundLocalError: local variable 'x' referenced before assignment, or got delet ed But I don?t think the wrapping is a big deal; it already happens with longer variable names anyway. I doubt using ?unset? instead of ?deleted? is any better. If you really wanted to make it clear, you would have to say ?or got deleted, perhaps by an exception handler?, but that is probably going too far. Another idea, which separates the hint from the technical error: UnboundLocalError: local variable 'x' not set; perhaps it is not yet assigned ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 17:07:24 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Feb 2017 22:07:24 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487369244.7.0.719297084366.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: I don't think that removing the readme.txt from the install constitutes a breaking change (LICENSE would be a bigger deal), and removing the file from the installer sounds simpler than updating the readme. Also, if you choose the 3.6 branch from the GitHub page you'll see whatever readme is in there, hence my thought that it would be backported. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 17:10:23 2017 From: report at bugs.python.org (prayerslayer) Date: Fri, 17 Feb 2017 22:10:23 +0000 Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor Message-ID: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za> New submission from prayerslayer: Hi! I think the ThreadPoolExecutor should allow to set the maximum size of the underlying queue. The situation I ran into recently was that I used ThreadPoolExecutor to parallelize AWS API calls; I had to move data from one S3 bucket to another (~150M objects). Contrary to what I expected the maximum size of the underlying queue doesn't have a non-zero value by default. Thus my process ended up consuming gigabytes of memory, because it put more items into the queue than the threads were able to work off: The queue just kept growing. (It ran on K8s and the pod was rightfully killed eventually.) Of course there ways to work around this. One could use more threads, to some extent. Or you could use your own queue with a defined maximum size. But I think it's more work for users of Python than necessary. ---------- messages: 288043 nosy: prayerslayer priority: normal pull_requests: 104 severity: normal status: open title: Expose max_queue_size in ThreadPoolExecutor type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 18:04:27 2017 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 17 Feb 2017 23:04:27 +0000 Subject: [issue19675] Pool dies with excessive workers, but does not cleanup In-Reply-To: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za> Message-ID: <1487372667.23.0.79871637521.issue19675@psf.upfronthosting.co.za> Camilla Montonen added the comment: Would it be possible to see a review of the existing attempts at testing this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 18:18:47 2017 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 17 Feb 2017 23:18:47 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic In-Reply-To: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> Message-ID: <1487373527.57.0.8897640259.issue29575@psf.upfronthosting.co.za> Camilla Montonen added the comment: Would you like to open a PR with a patch on GH? I think the docs could certainly do with another example for Pool. ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 18:21:10 2017 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 17 Feb 2017 23:21:10 +0000 Subject: [issue29247] Document return value of epoll.poll In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za> Message-ID: <1487373670.86.0.132970562007.issue29247@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 18:29:07 2017 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 17 Feb 2017 23:29:07 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1487374147.93.0.169799900773.issue6721@psf.upfronthosting.co.za> Changes by Camilla Montonen : ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 19:56:01 2017 From: report at bugs.python.org (Eric Lafontaine) Date: Sat, 18 Feb 2017 00:56:01 +0000 Subject: [issue28879] smtplib send_message should add Date header if it is missing, per RFC5322 In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za> Message-ID: <1487379361.84.0.31481180454.issue28879@psf.upfronthosting.co.za> Eric Lafontaine added the comment: Hi, Could someone put this ticket on "waiting for review"? Regards, Eric Lafontaine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:12:00 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 18 Feb 2017 01:12:00 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487380320.23.0.864750747928.issue29453@psf.upfronthosting.co.za> Raymond Hettinger added the comment: >> But maybe it is worth to mention that the output >> corresponds to the order of passed keyword arguments > Should I add this note? Yes, please. This is a section on keyword arguments, making it the preferred place to mention the new guaranteed output order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:12:12 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sat, 18 Feb 2017 01:12:12 +0000 Subject: [issue29596] Unfinished sentense in howto/clinic.rst Message-ID: <1487380332.64.0.682733186171.issue29596@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: Around line 1400 of Doc/howto/clinic.rst ``two-pass`` A buffer like ``buffer``. However, a two-pass buffer can only be written once, and it prints out all text sent to it during all of processing, even from Clinic blocks *after* the I've rarely be kept in such suspense ! Unless it's a reference to Monty Python's "The Man Who Finishes Other People's Sentences". In which case, I must say it's ---------- assignee: docs at python components: Documentation messages: 288048 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Unfinished sentense in howto/clinic.rst versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:26:59 2017 From: report at bugs.python.org (James R Barlow) Date: Sat, 18 Feb 2017 01:26:59 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1487381219.84.0.252710067381.issue5945@psf.upfronthosting.co.za> Changes by James R Barlow : ---------- pull_requests: +105 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:29:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 18 Feb 2017 01:29:42 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487381382.92.0.509733973047.issue29592@psf.upfronthosting.co.za> INADA Naoki added the comment: path normalization was added by https://github.com/python/cpython/commit/38cb9f1f174415d3b37fbaeb5d152d65525839d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:32:45 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Feb 2017 01:32:45 +0000 Subject: [issue29560] Turtle graphics fill behavior differs between versions In-Reply-To: <1487100128.83.0.366459584593.issue29560@psf.upfronthosting.co.za> Message-ID: <1487381565.65.0.154124990611.issue29560@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe that there is a known difference between tk on Windows and linux with respect to filling of even and odd areas. If I understand correctly, you saw one behavior on Windows and the other on Linux. If so, this is not a bug in tkinter. ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:39:31 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 18 Feb 2017 01:39:31 +0000 Subject: [issue29580] "Built-in Functions" not being functions In-Reply-To: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> Message-ID: <1487381971.98.0.454155655852.issue29580@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with the other respondents and am going to mark this as closed. ---------- nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 21:12:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 18 Feb 2017 02:12:54 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487383974.24.0.595065993562.issue29592@psf.upfronthosting.co.za> INADA Naoki added the comment: https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap_external.py#L1089-L1095 While '' in sys.path, it is converted to `getcwd()` before calling PathHook. Is there any chance relative / not normalized path is in sys.path before site is loaded? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 21:18:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 18 Feb 2017 02:18:25 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487384305.03.0.586839460108.issue29592@psf.upfronthosting.co.za> INADA Naoki added the comment: $ python2 -S Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 >>> import x >>> x.__file__ 'x.py' $ python3 -S Python 3.6.0 (default, Dec 30 2016, 20:49:54) [GCC 6.2.0 20161005] on linux >>> import x >>> x.__file__ '/home/inada-n/x.py' I think we can remove `abs_paths()` in site.py, thanks to _frozen_importlib_external. I added all import experts to nosy list. Please give me advice. ---------- nosy: +brett.cannon, eric.snow, fdrake, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 21:29:24 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Feb 2017 02:29:24 +0000 Subject: [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line In-Reply-To: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za> Message-ID: <1487384964.93.0.458306926892.issue29561@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If src is effectively blank, compile(src, filename, mode) raises SyntaxError if mode is 'single' but not if it is 'exec'. I believe IDLE compiles with 'single', but it has the behavior Jim (and I) expect and consider correct, printing '>>>' after effectively blank lines. This is because IDLE uses code.InteractiveInterpreter, which uses codeop.compile_command, which uses codeop._maybe_compile, which replaces effectively blank statements with 'pass'. compile('pass', '', 'single') returns a do-nothing code object. The C-coded interactive interpreter is doing something else. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 22:54:28 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 18 Feb 2017 03:54:28 +0000 Subject: [issue18861] Problems with recursive automatic exception chaining In-Reply-To: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za> Message-ID: <1487390068.88.0.158947620312.issue18861@psf.upfronthosting.co.za> Changes by Nathaniel Smith : ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:00:34 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:00:34 +0000 Subject: [issue28087] macOS 12 poll syscall returns prematurely In-Reply-To: <1473637008.93.0.918549766701.issue28087@psf.upfronthosting.co.za> Message-ID: <1487394033.99.0.766557632451.issue28087@psf.upfronthosting.co.za> Nick Coghlan added the comment: The failures in test_eintr and test_asyncio are confusing new contributors on Mac OS X - could we get some variant of this workaround merged until Apple fix their bug? ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:04:15 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:04:15 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487394255.89.0.295969600016.issue29571@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a few folks hitting this at the PyCon Pune sprints, so I'm going to apply Serhiy's patch :) ---------- assignee: serhiy.storchaka -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:06:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 18 Feb 2017 05:06:25 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487394385.32.0.450949796419.issue29585@psf.upfronthosting.co.za> INADA Naoki added the comment: PR 136 now adds `sys._framework` and 'PYTHONFRAMEWORK' macro in pyconfig.h. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:18 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:18 +0000 Subject: [issue29556] Remove unused #include In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487394798.21.0.260460339353.issue29556@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in branch 'ncoghlan-devguide-link': bpo-29556: Remove unused #include (#98) https://github.com/python/cpython/commit/72e81d00eee685cfe33aaddf2aa9feef2d07591f ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:18 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:18 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487394798.4.0.921401850746.issue29548@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 72dccde884d89586b0cafd990675b7e21720a81f by GitHub in branch 'ncoghlan-devguide-link': bpo-29548: Fix some inefficient call API usage (GH-97) https://github.com/python/cpython/commit/72dccde884d89586b0cafd990675b7e21720a81f ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:18 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:18 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487394798.54.0.146220718066.issue29481@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 36da1c3589e1bc4246cccf6bd0094a110416a43a by GitHub in branch 'ncoghlan-devguide-link': bpo-29481: add versionadded 3.6.1 to typing.Deque docs (#107) https://github.com/python/cpython/commit/36da1c3589e1bc4246cccf6bd0094a110416a43a ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:18 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:18 +0000 Subject: [issue29576] Improve some deprecations in the importlib In-Reply-To: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> Message-ID: <1487394798.83.0.642520591769.issue29576@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 1d4601c2c6952d03fc4dda2b041be9aa8713c0bc by Brett Cannon in branch 'ncoghlan-devguide-link': bpo-29576: add explicit deprecation for importlib.abc.find_loader() and find_module() (GH-32) https://github.com/python/cpython/commit/1d4601c2c6952d03fc4dda2b041be9aa8713c0bc ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:19 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:19 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487394799.01.0.9361690703.issue29521@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 85064db281545d587992df61154e76439138319f by Victor Stinner in branch 'ncoghlan-devguide-link': bpo-29521 update Misc/ACKS (#106) https://github.com/python/cpython/commit/85064db281545d587992df61154e76439138319f ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:13:19 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 05:13:19 +0000 Subject: [issue29026] time.time() documentation should mention UTC timezone In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za> Message-ID: <1487394799.21.0.535706288737.issue29026@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 23557d59b819f57800ddef0b1373acef8e024670 by Victor Stinner in branch 'ncoghlan-devguide-link': bpo-29026: Clarify documentation of time.time (#34) https://github.com/python/cpython/commit/23557d59b819f57800ddef0b1373acef8e024670 ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:17:15 2017 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 18 Feb 2017 05:17:15 +0000 Subject: [issue29505] Submit the re, json, & csv modules to oss-fuzz testing In-Reply-To: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za> Message-ID: <1487395035.63.0.329702802001.issue29505@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:26:46 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:26:46 +0000 Subject: [issue29026] time.time() documentation should mention UTC timezone In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za> Message-ID: <1487395606.36.0.850678843882.issue29026@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288063 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:26:53 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:26:53 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487395613.78.0.234979075561.issue29521@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288062 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:27:04 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:27:04 +0000 Subject: [issue29576] Improve some deprecations in the importlib In-Reply-To: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> Message-ID: <1487395624.82.0.491050317808.issue29576@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288061 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:27:15 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:27:15 +0000 Subject: [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque In-Reply-To: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> Message-ID: <1487395635.62.0.742063072306.issue29481@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288060 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:27:33 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:27:33 +0000 Subject: [issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs In-Reply-To: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> Message-ID: <1487395653.79.0.303674521133.issue29548@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288059 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 00:27:43 2017 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Feb 2017 05:27:43 +0000 Subject: [issue29556] Remove unused #include In-Reply-To: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> Message-ID: <1487395663.86.0.877287797261.issue29556@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg288058 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 01:40:59 2017 From: report at bugs.python.org (Amit Kumar) Date: Sat, 18 Feb 2017 06:40:59 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487400059.22.0.655071053352.issue29521@psf.upfronthosting.co.za> Changes by Amit Kumar : ---------- pull_requests: +106 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 01:41:35 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 18 Feb 2017 06:41:35 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487400095.34.0.835951164261.issue29549@psf.upfronthosting.co.za> Changes by Sanyam Khurana : ---------- pull_requests: +107 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 02:20:17 2017 From: report at bugs.python.org (Marc Guetg) Date: Sat, 18 Feb 2017 07:20:17 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487402417.73.0.185396663017.issue29594@psf.upfronthosting.co.za> Changes by Marc Guetg : ---------- title: implement __or__ in enum.auto -> implementation of __or__ in enum.auto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 03:26:42 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 18 Feb 2017 08:26:42 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic In-Reply-To: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> Message-ID: <1487406402.83.0.570644337455.issue29575@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 03:54:00 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 08:54:00 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487408040.93.0.828945729319.issue29571@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking into this at the PyCon Pune sprints, the problem appears to be arising due to the following difference in behaviour when the unqualifed `en_IN` locale is set: $ LANG=en_IN.UTF-8 python3 -c "import locale; print(locale.getlocale(locale.LC_CTYPE), locale.getpreferredencoding(False), sep='\n')" ('en_IN', 'UTF-8') UTF-8 $ LANG=en_IN python3 -c "import locale; print(locale.getlocale(locale.LC_CTYPE), locale.getpreferredencoding(False), sep='\n')" ('en_IN', 'ISO8859-1') UTF-8 re.LOCALE is presumably picking up the "UTF-8" rather than the "ISO8859-1", and hence the test is failing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 03:57:43 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Feb 2017 08:57:43 +0000 Subject: [issue19180] some RFC references could be updated In-Reply-To: <525144B9.3040305@python.org> Message-ID: <1487408263.12.0.672611802158.issue19180@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +109 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:14:44 2017 From: report at bugs.python.org (Amit Kumar) Date: Sat, 18 Feb 2017 09:14:44 +0000 Subject: [issue21056] csv documentation is incorrect In-Reply-To: <1395720703.0.0.19592596057.issue21056@psf.upfronthosting.co.za> Message-ID: <1487409284.08.0.0695390385562.issue21056@psf.upfronthosting.co.za> Changes by Amit Kumar : ---------- pull_requests: +110 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:15:46 2017 From: report at bugs.python.org (Chandan kumar) Date: Sat, 18 Feb 2017 09:15:46 +0000 Subject: [issue19180] some RFC references could be updated In-Reply-To: <525144B9.3040305@python.org> Message-ID: <1487409345.97.0.405264054836.issue19180@psf.upfronthosting.co.za> Chandan kumar added the comment: I have updated the RFC references from [0] to [2]. I am not able to find out the TLS links mentioned in the https://docs.python.org/3.4/library/ssl.html. I have attached the pull request. ---------- nosy: +chkumar246 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:19:08 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 09:19:08 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487409548.1.0.209474986813.issue29571@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +112 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:25:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 09:25:58 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487409958.62.0.179323905567.issue29571@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, please push it Nick. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:31:25 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 09:31:25 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487410285.29.0.287833437034.issue29571@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 by GitHub in branch 'master': bpo-29571: Use correct locale encoding in test_re (#149) https://github.com/python/cpython/commit/ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:35:33 2017 From: report at bugs.python.org (Subhendu Ghosh) Date: Sat, 18 Feb 2017 09:35:33 +0000 Subject: [issue27470] -3 commandline option documented differently via man In-Reply-To: <1467994985.16.0.513883147731.issue27470@psf.upfronthosting.co.za> Message-ID: <1487410533.03.0.550624770772.issue27470@psf.upfronthosting.co.za> Changes by Subhendu Ghosh : ---------- pull_requests: +113 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:37:59 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 18 Feb 2017 09:37:59 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1487410679.26.0.0823626929835.issue29506@psf.upfronthosting.co.za> Changes by Sanyam Khurana : ---------- pull_requests: +114 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:48:34 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 09:48:34 +0000 Subject: [issue28087] macOS 12 poll syscall returns prematurely In-Reply-To: <1473637008.93.0.918549766701.issue28087@psf.upfronthosting.co.za> Message-ID: <1487411314.03.0.423874897958.issue28087@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, I meant test_poll and test_asyncore as described in http://bugs.python.org/issue28456 (I misremembered due to the test_poll failure mentioning EINTR) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 04:53:29 2017 From: report at bugs.python.org (Amit Kumar) Date: Sat, 18 Feb 2017 09:53:29 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1487411609.93.0.529165896902.issue16011@psf.upfronthosting.co.za> Changes by Amit Kumar : ---------- pull_requests: +116 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 05:12:17 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 18 Feb 2017 10:12:17 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487412736.99.0.697620226294.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: The issue applies to 3.6 as well. I agree that the replacement of gethostbyaddr with gethostbyname_ex is not a solution. But is there a way to check whether a hostname is in the that doesn't bring to the reverse lookup? I suppose that IE doesn't make a reverse lookup for each request. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 05:43:24 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 18 Feb 2017 10:43:24 +0000 Subject: [issue28866] Type cache is not correctly invalidated on a class defining mro() In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za> Message-ID: <1487414604.77.0.086424811701.issue28866@psf.upfronthosting.co.za> Julien Palard added the comment: Hi, Tried again, this time getting some stats with MCACHE_STATS 1, to check if my patch is defeating the cache: Without my patch: $ time ./python performance/benchmarks/bm_chaos.py --worker -l1 -w0 -n1 --filename chaos.ppm --width=512 --height=512 --iterations 50000 chaos: Median: 2.51 sec -- Method cache hits = 16581735 (99%) -- Method cache true misses = 4092 (0%) -- Method cache collisions = 28542 (0%) -- Method cache size = 96 KB With my patch: $ time ./python performance/benchmarks/bm_chaos.py --worker -l1 -w0 -n1 --filename chaos.ppm --width=512 --height=512 --iterations 50000 chaos: Median: 2.53 sec -- Method cache hits = 16582260 (99%) -- Method cache true misses = 4096 (0%) -- Method cache collisions = 28012 (0%) -- Method cache size = 96 KB ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 05:44:50 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 10:44:50 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487414690.92.0.183141703078.issue29571@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +117 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 05:45:14 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 10:45:14 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487414714.69.0.619818099039.issue29571@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 05:47:14 2017 From: report at bugs.python.org (Chandan kumar) Date: Sat, 18 Feb 2017 10:47:14 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1487414834.11.0.906955075071.issue10938@psf.upfronthosting.co.za> Changes by Chandan kumar : ---------- pull_requests: +119 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:12:13 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 18 Feb 2017 11:12:13 +0000 Subject: [issue22702] to improve documentation for join() (str method) In-Reply-To: <1414017441.98.0.187335340973.issue22702@psf.upfronthosting.co.za> Message-ID: <1487416333.59.0.566578817709.issue22702@psf.upfronthosting.co.za> Changes by Sanyam Khurana : ---------- pull_requests: +120 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:25:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 11:25:14 +0000 Subject: [issue22702] to improve documentation for join() (str method) In-Reply-To: <1414017441.98.0.187335340973.issue22702@psf.upfronthosting.co.za> Message-ID: <1487417114.24.0.866736383638.issue22702@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Current documentation looks good to me and not needing changes (except fixing the doubled "iterable"). Proposed change looks incorrect to me. No parameter named "str" is provided in this method. See also the docstring of str.join. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:26:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Feb 2017 11:26:24 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1487417184.56.0.845581593707.issue28624@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +121 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:38:30 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 18 Feb 2017 11:38:30 +0000 Subject: [issue18423] Document limitations on -m In-Reply-To: <1373461112.24.0.280779659137.issue18423@psf.upfronthosting.co.za> Message-ID: <1487417910.23.0.804152366768.issue18423@psf.upfronthosting.co.za> Changes by Sanyam Khurana : ---------- pull_requests: +122 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:44:13 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 11:44:13 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1487418253.24.0.927285145928.issue28624@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:45:08 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 11:45:08 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487418308.55.0.991202401085.issue29549@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:45:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 11:45:37 +0000 Subject: [issue29506] Incorrect documentation for the copy module In-Reply-To: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> Message-ID: <1487418337.04.0.101346762977.issue29506@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:46:56 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 11:46:56 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1487418416.12.0.988521560392.issue10938@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:48:32 2017 From: report at bugs.python.org (Sayan Chowdhury) Date: Sat, 18 Feb 2017 11:48:32 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> New submission from Sayan Chowdhury: I tested and found that the code already works with PathLike. I have created a PR which updates the test and documentation. I think the issue can be in Windows. ---------- nosy: +sayanchowdhury _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 06:51:14 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 11:51:14 +0000 Subject: [issue18422] is_package missing so can't use -m In-Reply-To: <1373459784.39.0.18734737033.issue18422@psf.upfronthosting.co.za> Message-ID: <1487418674.82.0.387199535891.issue18422@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:08:49 2017 From: report at bugs.python.org (Sayan Chowdhury) Date: Sat, 18 Feb 2017 12:08:49 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1487419729.39.0.213695329091.issue25452@psf.upfronthosting.co.za> Sayan Chowdhury added the comment: I am taking over to do the rest part required for this ticket. ---------- nosy: +sayanchowdhury _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:32:00 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 18 Feb 2017 12:32:00 +0000 Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za> Message-ID: <1487421120.39.0.867807696543.issue29595@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- components: +Library (Lib) versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:41:21 2017 From: report at bugs.python.org (Subhendu Ghosh) Date: Sat, 18 Feb 2017 12:41:21 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487421681.72.0.565793596892.issue23890@psf.upfronthosting.co.za> Changes by Subhendu Ghosh : ---------- nosy: +subho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:42:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 12:42:37 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1487421757.66.0.136898906302.issue25452@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:46:34 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 18 Feb 2017 12:46:34 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487421994.07.0.0319850201772.issue23890@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Robert noted, this is a straight up error, where the clear_frames() call and deleting the exception traceback from the saved object aren't enough to drop all references to `callable_obj`. The trick is that the cleanup code isn't accounting for __cause__ and __context__: it's only clearing and dropping the traceback for the topmost exception in the chain. In Vjacheslav's example, there are *two* tracebacks to worry about: both the top level one (which is getting cleaned up) and the inner one from exc.__context__ which isn't being touched. We could likely use a "traceback.clear_all_frames()" helper that walks an exception tree clearing *all* the traceback frames, both on the original exception, and on all the __cause__ and __context__ attributes. (We can't just clear __cause__ and __context__, since those can be accessed and tested when using the context manager form and the `exception` attribute) ---------- assignee: docs at python -> components: -Documentation nosy: +ncoghlan type: enhancement -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:52:23 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 18 Feb 2017 12:52:23 +0000 Subject: [issue23384] urllib.proxy_bypass_registry slow down under Windows if website has no reverse DNS and Fiddler is runing In-Reply-To: <1422954339.65.0.892974237114.issue23384@psf.upfronthosting.co.za> Message-ID: <1487422343.8.0.93569681744.issue23384@psf.upfronthosting.co.za> Changes by Julia Dolgova : ---------- nosy: +juliadolgova _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 07:56:44 2017 From: report at bugs.python.org (David Steele) Date: Sat, 18 Feb 2017 12:56:44 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487422604.38.0.336693785934.issue24241@psf.upfronthosting.co.za> Changes by David Steele : ---------- pull_requests: +123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 08:04:02 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Sat, 18 Feb 2017 13:04:02 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487423042.64.0.633197991776.issue24241@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Hello David, I hope you are still working on https://github.com/python/cpython/pull/85 I tried to add few suggestions. Please write back on any confusions. Thanks! ---------- nosy: +jaysinh.shukla _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 08:11:21 2017 From: report at bugs.python.org (David Steele) Date: Sat, 18 Feb 2017 13:11:21 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487423481.74.0.629315525204.issue24241@psf.upfronthosting.co.za> David Steele added the comment: Jaysinh, Thanks for the feedback. I'm adding the documentation now. As I noted in github, I'm not sure what the preferred exception handling would be for xdg-settings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 08:20:23 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 18 Feb 2017 13:20:23 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487424023.31.0.770499064141.issue29436@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- pull_requests: +124 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 08:24:20 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 18 Feb 2017 13:24:20 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487424260.45.0.0825645950823.issue29436@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I've improved the patch and submitted it as PR 159. Now on Android: 1. _locale is built 2. _locale has several symbols, including CODESET 3. _locale doesn't have nl_langinfo() Basically _locale maps what langinfo.h does. On Android langinfo.h has several #defines like CODESET but nl_langinfo() is missing from langinfo.h and libc.so. On my ASUS ZE500KL, both test_locale and test_site (see: issue28596) pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 08:59:33 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 18 Feb 2017 13:59:33 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487426373.36.0.50156543484.issue29436@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Well, I have to commit changes to configure and pyconfig.h, otherwise Travis tests fail. Maybe .travis.yml should call autoreconf first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 09:37:55 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 18 Feb 2017 14:37:55 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487428675.02.0.627764774527.issue29453@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Added the following short sentence to the PR, which I believe makes the point clear: Note that the order in which the keyword arguments are printed is guaranteed to match the order in which they were provided in the function call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 09:51:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Feb 2017 14:51:10 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1487426373.36.0.50156543484.issue29436@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Previously, we asked to not include generated files in patches, like configure. With the new dev process (github, travis), you must now include generated files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 12:39:40 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 18 Feb 2017 17:39:40 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487439580.98.0.570361056771.issue29436@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I've improved the patch and submitted it as PR 159. Now on Android: This is confusing. Android NDK r14 has not been released yet. We do not develop CPython for platform beta releases. Unified headers, the reason for your proposed change, are only introduced in NDK r14. Any reason why you do omit mentioning these important facts in the issue ? Maybe you think that Stephan, Victor and the other readers are aware of this ? What about the time they waste reading this issue and your PR when this issue does not make sense with the NDK we are using (NDK r13) and is just a waste of time now ? Why do you publish a PR ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 12:45:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 18 Feb 2017 17:45:10 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487439910.45.0.885837062993.issue29436@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Closing this issue as 'later'. Chi Hsuan Yen, I am still interested by your answers to my questions. ---------- resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 12:47:58 2017 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Feb 2017 17:47:58 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1487440078.76.0.337061571187.issue10938@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 12:48:38 2017 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Feb 2017 17:48:38 +0000 Subject: [issue18423] Document limitations on -m In-Reply-To: <1373461112.24.0.280779659137.issue18423@psf.upfronthosting.co.za> Message-ID: <1487440118.45.0.415861192653.issue18423@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 13:05:28 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 18 Feb 2017 18:05:28 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487441128.52.0.000549395331158.issue29436@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: > Any reason why you do omit mentioning these important facts in the issue ? Both in the title of this issue and that PR, I mention "NDK r14 beta 2". I'm not sure what you're referring to. On IRC, irker states the title first and then the comment content. I believe people will read the title first to determine whether they're interested or not. On email notifications of b.p.o and Github updates, the title is used as the email subject, so people can determine whether they want to see this email fast. > Maybe you think that Stephan, Victor and the other readers are aware of this ? As explained above, I've already stated "beta" clearly > What about the time they waste reading this issue and your PR when this issue does not make sense with the NDK we are using (NDK r13) and is just a waste of time now ? For me, reading the title takes a few seconds. If a developer thinks there's no need to support beta platforms, they can just ignore it. > Why do you publish a PR ? This is a real issue. Usually NDK beta 2 is almost identical to the final release. For me it's good to fix things as soon as possible. There are some other examples for beta toolchains like issue1465, issue27806 or issue27596. If you think issues on beta should be postponed until the final release, I can keep my patches locally and submit them later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 14:37:00 2017 From: report at bugs.python.org (Ratnadeep Debnath) Date: Sat, 18 Feb 2017 19:37:00 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1487446620.62.0.731649019716.issue16285@psf.upfronthosting.co.za> Ratnadeep Debnath added the comment: I have started to work on this issue and get it merge ready. ---------- nosy: +rtnpro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 14:47:02 2017 From: report at bugs.python.org (Ratnadeep Debnath) Date: Sat, 18 Feb 2017 19:47:02 +0000 Subject: [issue29237] Create enum for pstats sorting options In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za> Message-ID: <1487447222.63.0.183147600874.issue29237@psf.upfronthosting.co.za> Ratnadeep Debnath added the comment: I am taking up to create a patch/pull request for this to get it reviewed. ---------- nosy: +rtnpro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:31:11 2017 From: report at bugs.python.org (Max) Date: Sat, 18 Feb 2017 20:31:11 +0000 Subject: [issue29597] __new__ / __init__ calls during unpickling not documented correctly Message-ID: <1487449871.91.0.908560924036.issue29597@psf.upfronthosting.co.za> New submission from Max: According to the [docs](https://docs.python.org/3/library/pickle.html#pickling-class-instances): > Note: At unpickling time, some methods like `__getattr__()`, `__getattribute__()`, or `__setattr__()` may be called upon the instance. In case those methods rely on some internal invariant being true, the type should implement `__getnewargs__()` or `__getnewargs_ex__()` to establish such an invariant; otherwise, neither `__new__()` nor `__init__()` will be called. It seems, however, that this note is incorrect. First, `__new__` is called even if `__getnewargs__` isn't implemented. Second, `__init__` is not called even if it is (while the note didn't say that `__init__` would be called when `__getnewargs__` is defined, the wording does seem to imply it). class A: def __new__(cls, *args): print('__new__ called with', args) return object.__new__(cls) def __init__(self, *args): print('__init__ called with', args) self.args = args def __getnewargs__(self): print('called') return () a = A(1) s = pickle.dumps(a) a = pickle.loads(s) # __new__ called, not __init__ delattr(A, '__getnewargs__') a = A(1) s = pickle.dumps(a) a = pickle.loads(s) # __new__ called, not __init__ ---------- assignee: docs at python components: Documentation messages: 288088 nosy: docs at python, max priority: normal severity: normal status: open title: __new__ / __init__ calls during unpickling not documented correctly versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:45:51 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 18 Feb 2017 20:45:51 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487450751.86.0.316094357386.issue22807@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: New changeset 8c130d7f8114158f5b94749032ec0c17dba96f83 by GitHub in branch 'master': bpo-22807: Expose platform UUID generation safety information. (#138) https://github.com/python/cpython/commit/8c130d7f8114158f5b94749032ec0c17dba96f83 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:47:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 20:47:07 +0000 Subject: [issue29597] __new__ / __init__ calls during unpickling not documented correctly In-Reply-To: <1487449871.91.0.908560924036.issue29597@psf.upfronthosting.co.za> Message-ID: <1487450827.71.0.993108603744.issue29597@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue27635. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> pickle documentation says that unpickling may not call __new__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:47:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 20:47:59 +0000 Subject: [issue27635] pickle documentation says that unpickling may not call __new__ In-Reply-To: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za> Message-ID: <1487450879.27.0.494909221196.issue27635@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, serhiy.storchaka stage: -> needs patch type: -> behavior versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:57:19 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 20:57:19 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487451439.29.0.956997503701.issue29579@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:01:33 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 21:01:33 +0000 Subject: [issue29525] Python 2.7.13 for Windows broken (from prompt) In-Reply-To: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> Message-ID: <1487451693.74.0.0339610228123.issue29525@psf.upfronthosting.co.za> Steve Dower added the comment: You should be able to update whatever package installed that module. Unfortunately, we can't guess what that would be, but it's probably worthwhile updating all the packages you have installed. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:03:50 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 21:03:50 +0000 Subject: [issue29503] Make embedded-Python detectable In-Reply-To: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> Message-ID: <1487451830.49.0.872075039263.issue29503@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:09:56 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 21:09:56 +0000 Subject: [issue20823] Clarify copyreg.pickle() documentation In-Reply-To: <1393749966.08.0.529137298895.issue20823@psf.upfronthosting.co.za> Message-ID: <1487452196.77.0.944112931691.issue20823@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The phrase "*function* should return either a string or a tuple containing two or three elements." de-facto is outdated too. Since Python 2.3 a tuple returned by the function must have two to five elements. copyreg.constructor() no longer does anything useful, and the constructor parameter of copyreg.pickle() is virtually ignored. ---------- nosy: +serhiy.storchaka stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:10:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Feb 2017 21:10:23 +0000 Subject: [issue11924] Pickle and copyreg modules don't document the interface In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za> Message-ID: <1487452223.91.0.366697413362.issue11924@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:17:16 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 21:17:16 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487452636.56.0.409858311823.issue29579@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:30:20 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 21:30:20 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487453420.5.0.979117209896.issue29579@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +126 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:38:58 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Feb 2017 21:38:58 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487453938.54.0.770861131705.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: Pull request is at https://github.com/python/cpython/pull/160 and backport at https://github.com/python/cpython/pull/161 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 16:43:17 2017 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Feb 2017 21:43:17 +0000 Subject: [issue11924] Pickle and copyreg modules don't document the interface In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za> Message-ID: <1487454197.72.0.0258796514645.issue11924@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 17:48:51 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 18 Feb 2017 22:48:51 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` In-Reply-To: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> Message-ID: <1487458131.72.0.0817207182424.issue28624@psf.upfronthosting.co.za> Changes by Jim Fasarakis-Hilliard : ---------- components: +Tests -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 18:12:56 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 18 Feb 2017 23:12:56 +0000 Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za> Message-ID: <1487459576.57.0.758234128185.issue29595@psf.upfronthosting.co.za> Changes by Jim Fasarakis-Hilliard : ---------- nosy: +Jim Fasarakis-Hilliard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 18:14:31 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Feb 2017 23:14:31 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` In-Reply-To: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> Message-ID: <1487459671.9.0.0409604647179.issue28624@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Library (Lib) -Tests stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 18:42:13 2017 From: report at bugs.python.org (Anthony Zhang) Date: Sat, 18 Feb 2017 23:42:13 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1487461333.93.0.717613341633.issue29110@psf.upfronthosting.co.za> Changes by Anthony Zhang : ---------- pull_requests: +127 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 19:12:04 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 19 Feb 2017 00:12:04 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487463124.17.0.306871723468.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: New changeset 52a7e92e3d38d3d003552db6795deeeee75db2e4 by GitHub in branch 'master': bpo-29579: Removes readme.txt from the installer. (#160) https://github.com/python/cpython/commit/52a7e92e3d38d3d003552db6795deeeee75db2e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 19:12:08 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 19 Feb 2017 00:12:08 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487463128.68.0.997446548289.issue29579@psf.upfronthosting.co.za> Steve Dower added the comment: New changeset d372cda5cd46712c4e59262ec1ab981773b20bff by GitHub in branch '3.6': bpo-29579: Removes readme.txt from the installer. (#161) https://github.com/python/cpython/commit/d372cda5cd46712c4e59262ec1ab981773b20bff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 21:57:32 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Sun, 19 Feb 2017 02:57:32 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487473052.18.0.300957330498.issue29520@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Hello Jim, I tried to run `make html` on `/Doc` directory at latest master. I was not able to reproduce this warning message. I am attaching console output I got while building the documentation with this issue. I request you to check that once. Will you re-install the dependancy and check for this issue once again? Many thanks! ---------- nosy: +jaysinh.shukla Added file: http://bugs.python.org/file46647/doc_logs_python.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 22:25:36 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 03:25:36 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487474736.36.0.364042783271.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: I can reproduce it with Sphinx 1.5.2. Additonally, "None" is shown at top. ---------- nosy: +inada.naoki Added file: http://bugs.python.org/file46648/sphinx-1.5-pydoc.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 22:28:35 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 19 Feb 2017 03:28:35 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> Message-ID: <1487474915.66.0.700776618569.issue29579@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 22:29:38 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 Feb 2017 03:29:38 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487474978.83.0.645159243475.issue29453@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the revision. Assigning to Mariatta so that she can apply the PR. ---------- assignee: serhiy.storchaka -> Mariatta nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 22:30:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 03:30:12 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487475012.11.0.74493984424.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: ref: https://github.com/sphinx-doc/sphinx/issues/2986 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 23:17:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 04:17:06 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487477826.67.0.72984748572.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +128 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 23:20:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 04:20:42 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487478042.52.0.19860161939.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: Could docs.python.org use new Sphinx, after fix this issue? Travis checks doc with Sphinx 1.5.2, but docs.python.org seems using 1.3.3. It's too old. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 23:33:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 04:33:37 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487478817.65.0.944536817588.issue29571@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 0683d6889bd4430599d22e12e201b8e9c45be5a2 by GitHub in branch '3.6': [3.6] bpo-29571: Use correct locale encoding in test_re (#149) (#153) https://github.com/python/cpython/commit/0683d6889bd4430599d22e12e201b8e9c45be5a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 23:33:52 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 04:33:52 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487478832.41.0.214740576371.issue29571@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 760f596b6a4b5514afe35e521621f484aef35413 by GitHub in branch '3.5': [3.5] bpo-29571: Use correct locale encoding in test_re (#149) (#154) https://github.com/python/cpython/commit/760f596b6a4b5514afe35e521621f484aef35413 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 23:35:03 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 04:35:03 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1487478903.03.0.382484240557.issue29571@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:09:50 2017 From: report at bugs.python.org (Peter McCormick) Date: Sun, 19 Feb 2017 05:09:50 +0000 Subject: [issue28909] Adding LTTng-UST tracing support In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za> Message-ID: <1487480990.1.0.992247191356.issue28909@psf.upfronthosting.co.za> Peter McCormick added the comment: Fork at with Francis' original patch, plus a revert for the DTrace provider name change. Here are instructions I used to try this out: ## LTTng installation Full installation instructions for LTTng are available at . On Ubuntu 19.04 you can currently install LTTng v2.7 from the `universe` repository if it is enabled: ```shell $ apt-get install lttng-tools lttng-modules-dkms liblttng-ust-dev babeltrace ``` ## Building Clone/fetch/checkout from and run: ```shell $ ./configure --with-lttngust $ make ``` ## Tracing a session LTTng operates around the concept of tracing selected userspace & kernelspace events of interest within the context of a session, so let's start one and run the instrumented interpreter to see what happens: ```shell $ lttng create 'pysession' $ lttng enable-event --userspace 'cpython:*' $ lttng start $ ./python -m this $ lttng stop $ lttng view | wc -l 48257 $ lttng view [23:50:04.493873655] (+?.?????????) keflavik cpython:gc__start: { cpu_id = 1 }, { generation = 0 } [23:50:04.493910472] (+0.000036817) keflavik cpython:gc__done: { cpu_id = 1 }, { collected = 0 } [23:50:04.494281326] (+0.000370854) keflavik cpython:gc__start: { cpu_id = 1 }, { generation = 0 } [23:50:04.494305307] (+0.000023981) keflavik cpython:gc__done: { cpu_id = 1 }, { collected = 0 } [23:50:04.495031049] (+0.000725742) keflavik cpython:gc__start: { cpu_id = 1 }, { generation = 0 } [23:50:04.495074272] (+0.000043223) keflavik cpython:gc__done: { cpu_id = 1 }, { collected = 0 } [23:50:04.495403759] (+0.000329487) keflavik cpython:function__entry: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 8 } [23:50:04.495405056] (+0.000001297) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 8 } [23:50:04.495406486] (+0.000001430) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 25 } [23:50:04.495407149] (+0.000000663) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 27 } [23:50:04.495408921] (+0.000001772) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 35 } [23:50:04.495409618] (+0.000000697) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 42 } [23:50:04.495410775] (+0.000001157) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 44 } [23:50:04.495412006] (+0.000001231) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 47 } [23:50:04.495421990] (+0.000009984) keflavik cpython:function__entry: { cpu_id = 1 }, { co_filename = "", co_name = "_DeadlockError", line_no = 47 } [23:50:04.495422496] (+0.000000506) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "_DeadlockError", line_no = 47 } [23:50:04.495423317] (+0.000000821) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "_DeadlockError", line_no = 48 } [23:50:04.495424559] (+0.000001242) keflavik cpython:function__return: { cpu_id = 1 }, { co_filename = "", co_name = "_DeadlockError", line_no = 48 } [23:50:04.495468551] (+0.000043992) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "", line_no = 51 } [23:50:04.495470096] (+0.000001545) keflavik cpython:function__entry: { cpu_id = 1 }, { co_filename = "", co_name = "_ModuleLock", line_no = 51 } [23:50:04.495470570] (+0.000000474) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "_ModuleLock", line_no = 51 } [23:50:04.495471249] (+0.000000679) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "_ModuleLock", line_no = 55 } [23:50:04.495471746] (+0.000000497) keflavik cpython:line: { cpu_id = 1 }, { co_filename = "", co_name = "_ModuleLock", line_no = 57 } ... ``` The raw trace files will be written under `~/lttng-traces/pysession-$TIMESTAMP`. To clean them up afterwards, you can run: ```shell $ lttng destroy ``` ## GitHub I would be happy to re-post this to GitHub issues if so desired. ---------- hgrepos: +367 nosy: +pdmccormick _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:12:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 05:12:02 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487481122.01.0.825413307357.issue29529@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 3337d33a4518f7ab8a7ab6c9a75b8b92ba348b27 by Nick Coghlan in branch '3.6': [backport to 3.6] bpo-29529: Add .travis.yml to 3.6 branch (#25) https://github.com/python/cpython/commit/3337d33a4518f7ab8a7ab6c9a75b8b92ba348b27 ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:12:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 05:12:02 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487481122.13.0.383510106656.issue29521@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 3337d33a4518f7ab8a7ab6c9a75b8b92ba348b27 by Nick Coghlan in branch '3.6': [backport to 3.6] bpo-29529: Add .travis.yml to 3.6 branch (#25) https://github.com/python/cpython/commit/3337d33a4518f7ab8a7ab6c9a75b8b92ba348b27 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:13:03 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 05:13:03 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487481183.89.0.39528467856.issue29529@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +129 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:13:04 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 05:13:04 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487481184.42.0.0199670787021.issue29529@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 24bfe15e83c24bf2c2e2654050da809553789002 by Nick Coghlan in branch '3.5': [backport to 3.5] bpo-29529: Add .travis.yml to 3.5 branch (#26) https://github.com/python/cpython/commit/24bfe15e83c24bf2c2e2654050da809553789002 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:13:04 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 05:13:04 +0000 Subject: [issue29521] Minor warning messages when compiling documentation In-Reply-To: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> Message-ID: <1487481184.52.0.10201014844.issue29521@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 24bfe15e83c24bf2c2e2654050da809553789002 by Nick Coghlan in branch '3.5': [backport to 3.5] bpo-29529: Add .travis.yml to 3.5 branch (#26) https://github.com/python/cpython/commit/24bfe15e83c24bf2c2e2654050da809553789002 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:55:16 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 05:55:16 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487483716.05.0.864910383037.issue23890@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've been looking into this further, and a reproducer that's independent of assertRaises() is to just bind the function to a local variable name in an outer function: def outer(): callable_obj = f try: callable_obj() except Exception as exc: return exc That should make it easier to test a basic recursive "clear_all_frames" operation like: def clear_all_frames(exc): cause = exc.__cause__ if cause is not None: clear_all_frames(cause) context = exc.__context__ if context is not None: clear_all_frames(context) traceback.clear_frames(exc.__traceback__) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 00:57:23 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 19 Feb 2017 05:57:23 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1487483843.61.0.339800298421.issue13691@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Hi, I'm working on fixing this issue. ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:02:47 2017 From: report at bugs.python.org (Peter McCormick) Date: Sun, 19 Feb 2017 06:02:47 +0000 Subject: [issue28909] Adding LTTng-UST tracing support In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za> Message-ID: <1487484167.35.0.0227399067709.issue28909@psf.upfronthosting.co.za> Peter McCormick added the comment: A few suggestions: * Disallow `--with-lttngust` on anything other than Linux (on macOS `configure` dies due to differences in acceptable `mktemp` arguments if you even attempt it) * Rename `cpython_inst.h` to `pytrace.h` and rename `pylttngust_probes.h` to `pytrace_lttngust_probes.h` - While we're at it, rename `pydtrace.h` to `pytrace_dtrace.h`, and other mentions of `PyDTrace_*` to `PyTrace_DTrace_*`? * Define a `WITH_TRACE` or `Py_TRACE` or similar preprocessor symbol * Using that symbol, in `Python/ceval.c` ifdef-guard the static function prototypes and function calls - Otherwise when BOTH DTrace and LTTng-UST are disabled, Clang on macOS gives `warning: code will never be executed` warnings on the various arms of the `if (PyTraceEnabled(...))` statements, and GCC on Linux warn about unused variables `lineno`, `funcname` and `filename` in `pytrace_function_{entry,return}`, since the actual use of those variables as arguments is preprocessed out of existance If everyone was in agreement, would it make sense to sequence this as first the generalization-renames to the existing DTrace/SystemTap code, and then recast the LTTng addition patch on top of those? I'd be happy to do this. So, `PyTrace` or `PyTracing`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:09:08 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 06:09:08 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487484548.53.0.548046012659.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: When adding the fix for #20160 I had added a test involving passing a struct by value to a Python callback. I modified that test to update the struct in the callback, and check that the passed-in struct hadn't changed. def test_callback_large_struct(self): class Check: pass class X(Structure): _fields_ = [ ('first', c_ulong), ('second', c_ulong), ('third', c_ulong), ] def callback(check, s): check.first = s.first check.second = s.second check.third = s.third # See issue #29565. # The structure should be passed by value, so # any changes to it should not be reflected in # the value passed s.first = s.second = s.third = 0x0badf00d check = Check() s = X() s.first = 0xdeadbeef s.second = 0xcafebabe s.third = 0x0bad1dea CALLBACK = CFUNCTYPE(None, X) dll = CDLL(_ctypes_test.__file__) func = dll._testfunc_cbk_large_struct func.argtypes = (X, CALLBACK) func.restype = None # the function just calls the callback with the passed structure func(s, CALLBACK(functools.partial(callback, check))) self.assertEqual(check.first, s.first) self.assertEqual(check.second, s.second) self.assertEqual(check.third, s.third) self.assertEqual(check.first, 0xdeadbeef) self.assertEqual(check.second, 0xcafebabe) self.assertEqual(check.third, 0x0bad1dea) # See issue #29565. # Ensure that the original struct is unchanged. self.assertEqual(s.first, check.first) self.assertEqual(s.second, check.second) self.assertEqual(s.third, check.third) The changed test still passes, so it looks like ctypes makes a copy when passing from C to a Python callback, but not when passing from Python to C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:21:48 2017 From: report at bugs.python.org (Amit Kumar) Date: Sun, 19 Feb 2017 06:21:48 +0000 Subject: [issue29526] Documenting format() function In-Reply-To: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> Message-ID: <1487485308.43.0.92287314653.issue29526@psf.upfronthosting.co.za> Changes by Amit Kumar : ---------- pull_requests: +130 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:27:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 06:27:21 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1487485641.26.0.0437475733934.issue13691@psf.upfronthosting.co.za> Nick Coghlan added the comment: Recapping the situations that need test cases before this can be merged: * behaviour when "help" is entered at the interactive help prompt (as the current behaviour is correct and should *not* change) * behaviour when calling "help(help)" * behaviour when calling "help('help')" * behaviour when running "python3 -m pydoc help" In the latter 3 cases, the default site._Helper docs currently shown are not particularly helpful. It does make me wonder whether it might be worth defining a __help__ magic method that completely overrides what help(obj) displays. It would limit the fix to 3.7+, but it would make it possible to do this cleanly just by defining __help__ on site._Helper. ---------- nosy: +ncoghlan versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:29:14 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 06:29:14 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487485754.67.0.160249760699.issue29592@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +131 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:39:19 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 06:39:19 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487486359.31.0.737759441708.issue29592@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, I agree it should be redundant now - import system should always be making __file__ and __cached__ absolutely at import time these days. So +1 for dropping this from 3.7 and getting a bit of startup time back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:43:00 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 06:43:00 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1487486580.81.0.0760472782937.issue16285@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:44:53 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 06:44:53 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1487486693.26.0.98753268728.issue20160@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- pull_requests: +132 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:44:53 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 06:44:53 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487486693.51.0.0621369010706.issue29565@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- pull_requests: +133 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 01:47:43 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 06:47:43 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487486863.74.0.167716810943.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: PR submitted. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:16:16 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Sun, 19 Feb 2017 07:16:16 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487488576.85.0.801730041482.issue29520@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: Jaysinh, thank you for checking. From your log, I see you are using Sphinx version 1.3.6. I am seeing this problem with Sphinx version 1.5.2. I think you need Sphinx 1.5.2 or later to see the warning message. I notice my original bug description didn't specify a Sphinx version. Now we know that it needs to be a fairly recent version of Sphinx. >From the discussion in https://github.com/sphinx-doc/sphinx/issues/2986, it looks like the Sphinx team added the warning message at or shortly after the release of 1.5.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:24:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 07:24:46 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1487489086.25.0.748503472195.issue27286@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +134 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:24:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 07:24:46 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487489086.39.0.428849469205.issue29537@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +135 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:24:47 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Sun, 19 Feb 2017 07:24:47 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487489087.14.0.479076080982.issue29520@psf.upfronthosting.co.za> Changes by Jaysinh shukla : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:25:00 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Sun, 19 Feb 2017 07:25:00 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487489100.13.0.313094065108.issue29520@psf.upfronthosting.co.za> Changes by Jaysinh shukla : ---------- pull_requests: +136 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:25:55 2017 From: report at bugs.python.org (Subhendu Ghosh) Date: Sun, 19 Feb 2017 07:25:55 +0000 Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za> Message-ID: <1487489155.65.0.60256914733.issue26128@psf.upfronthosting.co.za> Changes by Subhendu Ghosh : ---------- pull_requests: +137 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:31:31 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 07:31:31 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487489491.35.0.949350144655.issue29537@psf.upfronthosting.co.za> Nick Coghlan added the comment: In putting together a PR for this, I think it *only* makes sense if we also push Petr's change upstream to accept the legacy bytecode files in 3.5.4+. The reason is that the patch actually causes a test case to fail due to "f()" change to "function" in an error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:32:53 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 19 Feb 2017 07:32:53 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1487489572.99.0.441162461039.issue13691@psf.upfronthosting.co.za> Changes by Sanyam Khurana : ---------- pull_requests: +138 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:35:25 2017 From: report at bugs.python.org (Subhendu Ghosh) Date: Sun, 19 Feb 2017 07:35:25 +0000 Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za> Message-ID: <1487489725.49.0.654342073093.issue26128@psf.upfronthosting.co.za> Changes by Subhendu Ghosh : ---------- nosy: +subho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:46:17 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 07:46:17 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1487490377.21.0.606250419295.issue29514@psf.upfronthosting.co.za> Nick Coghlan added the comment: Serhiy posted a patch at http://bugs.python.org/issue29537 that addresses the original problem from http://bugs.python.org/issue27286 in a different way: it simply omits the function name in cases where the stack reference is ambiguous. So what I think we should do for 3.5.4 is implement the one-off patch that allows the remainder of the 3.5.x series to accept both the original 3.5.0 magic number and the 3.5.3+ magic number, in combination with Serhiy's change to the eval loop to render any malformed legacy bytecode harmless. The 2.7, 3.6 and master branches can then just get the test case that locks the bytecode to a particular value in any given branch that has reached release candidate status. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:52:52 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sun, 19 Feb 2017 07:52:52 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487490772.56.0.306013806057.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: I compared the behavior of IE and urllib. I put different addresses to the ("Do not use proxy server for address beginning with" setting), made different requests through IE and urllib and watched if the proxy was bypassed. IE doesn't even make a forward dns lookup for the hosname given to check whether it should bypass proxy, whereas urllib does. For example: proxy_bypass_list request IE bypasses proxy urllib bypasses proxy 23.253.135.79 https://python.org/ no yes 151.101.76.223 https://docs.python.org/ no yes ovinnik.canonical.com https://ubuntu.com/ no yes compare_ie_urllib.txt - full report ---------- Added file: http://bugs.python.org/file46649/compare_ie_urllib.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 02:53:54 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Sun, 19 Feb 2017 07:53:54 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1487490834.29.0.639471270631.issue13691@psf.upfronthosting.co.za> Changes by Jaysinh shukla : ---------- nosy: +jaysinh.shukla _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 03:06:13 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 08:06:13 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487491573.43.0.950624921704.issue29581@psf.upfronthosting.co.za> Nick Coghlan added the comment: This is going to be the case anytime an attempt is made to combine parent classes with incompatible constructor signatures. "type" is unusual in that it goes to great lengths to present an adaptive signature that aligns with whatever the class definition does. The main relevant trick is to filter the extra arguments out from those passed to metaclasses such that only init_subclass sees them: ================ def ignore_extra_args(base): base_meta = type(base) class _FilteredMeta(base_meta): def __new__(*args, **kwds): return base_meta.__new__(*args) def __init__(*args, **kwds): return base_meta.__init__(*args) class _Filtered(base, metaclass=_FilteredMeta): pass return _Filtered class InitX(): def __init_subclass__(cls, x=None): print('x') from abc import ABCMeta class Abstract(metaclass=ABCMeta): pass class AbstractWithInit(ignore_extra_args(Abstract), InitX, x=1): pass AbstractWithInit() ================ If folks were to iterate on "ignore_extra_args" variants outside the standard library with 3.6, then it would be something we could sensibly standardise for 3.7. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 03:35:28 2017 From: report at bugs.python.org (tomo cocoa) Date: Sun, 19 Feb 2017 08:35:28 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487493328.94.0.30441064939.issue29520@psf.upfronthosting.co.za> tomo cocoa added the comment: As for CPython documents, these uses only one assignment statement (``{% set ... %}``) [1]_, one h1 element and one p element [2]_ of defindex.html. These fragments are used to generate following sentences:: Python 3.6.0 documentation Welcome! This is the documentation for Python 3.6.0, last updated Feb 19, 2017. .. [1] https://github.com/sphinx-doc/sphinx/blob/8ecd7ff08249739bbc6d900527fe9306592456ab/sphinx/themes/basic/defindex.html#L11 .. [2] https://github.com/sphinx-doc/sphinx/blob/8ecd7ff08249739bbc6d900527fe9306592456ab/sphinx/themes/basic/defindex.html#L13-L18 Therefore, I suggest that we should make indexcontent.html extend layout.html directly and insert the jinja2 code into indexcontent.html in order to generate the sentences above (which is much the same option as mixture of JDLH's option 1 and 3). After I wrote this comment, I notice inada.naoki had created `pull request #165 `_. ---------- nosy: +cocoatomo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 03:55:11 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Feb 2017 08:55:11 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1487494511.6.0.96672439599.issue16285@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +139 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 03:58:02 2017 From: report at bugs.python.org (Ratnadeep Debnath) Date: Sun, 19 Feb 2017 08:58:02 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1487494682.7.0.474473620527.issue16285@psf.upfronthosting.co.za> Ratnadeep Debnath added the comment: Created a pull request for the attached patch along with update of related docstrings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 04:49:40 2017 From: report at bugs.python.org (Artem Muterko) Date: Sun, 19 Feb 2017 09:49:40 +0000 Subject: [issue29598] Write unit tests for pdb module Message-ID: <1487497780.63.0.173110624211.issue29598@psf.upfronthosting.co.za> Changes by Artem Muterko : ---------- components: Tests nosy: Artem Muterko priority: normal severity: normal status: open title: Write unit tests for pdb module versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 04:53:26 2017 From: report at bugs.python.org (Artem Muterko) Date: Sun, 19 Feb 2017 09:53:26 +0000 Subject: [issue29598] Write unit tests for pdb module Message-ID: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> New submission from Artem Muterko: I want to write unit tests for pdb module of stdlib. Should I create one pull request for entire module or should I split work into several pull requests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 05:11:17 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 19 Feb 2017 10:11:17 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487499077.49.0.962068854938.issue29436@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > For me it's good to fix things as soon as possible. The problem here is that you are attempting to push a change through a PR without providing the other core developers with important information. You should at least have given a reference to issue 29040 and explain why you think it is safe to push this change now and not wait for the decision to switch to r14 and you should have done it *before* publishing the PR. By behaving this way, you may lead other core developers to think that you cannot be trusted. > If you think issues on beta should be postponed until the final release, I can keep my patches locally and submit them later. Yes, please do. Note that this issue is closed for now anyway. Also when you are running Python on Android and publishing some results on bpo (such as for example in issue 29176) please make sure that Python has been built with r13. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 05:24:24 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 10:24:24 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487499864.52.0.971433006917.issue22273@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 05:42:26 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 19 Feb 2017 10:42:26 +0000 Subject: [issue29442] Use argparse and drop dirty optparse hacks in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487500946.35.0.473874863714.issue29442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I'm not familiar with CPython conventions. Sorry if reopening an issue is impolite. IMO asking if it's ok to reopen this issue by using the word 'impolite' is a clear reference to the fact that Stefan had told you previously that you are being insulting by saying "it's a dirty hack ". Not only did not you take the opportunity given by Stefan at that time to express your apologies as expected, but instead you repeated it, and here your are making fun of him by using the word 'impolite' when you could have asked if it is correct or allowed to reopen an issue. Few months ago you uttered the same kind of insults then directed at me in msg264605, a post addressed to Guido van Rossum in issue 26858. Please do read the CPython Code of Conduct and try to remember that the people that take the time to answer your posts do it on their own free time and that you should be nice to them. I am nosying Brett Cannon, the CPython maintainer and core dev in charge of the respect of the CoC. ---------- nosy: +brett.cannon, haypo, xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 05:56:38 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 19 Feb 2017 10:56:38 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1487501798.34.0.54741944633.issue29598@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Please use one single PR only when the tests are focused on a single topic and can be collected in their own class. When the tests are focused on breakpoints for example. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:14:50 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 19 Feb 2017 11:14:50 +0000 Subject: [issue29442] Replace optparse with argparse in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487502890.11.0.0770029637621.issue29442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I see your points. Indeed in many times I didn't think carefully before leaving a comment, and not even noticing that my comments can be offensive afterwards. I apologize for all those cases and I'll be more careful when interacting with others in the future. @Xavier: I'm gratitude for your patience on taking so much time explaining what I've done wrong. It's an invaluable course. Let me change the title of this issue first. That will make it more moderate and also clearer. ---------- title: Use argparse and drop dirty optparse hacks in setup.py -> Replace optparse with argparse in setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:22:53 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 11:22:53 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487503373.25.0.370636079894.issue29592@psf.upfronthosting.co.za> Nick Coghlan added the comment: CI failure indicating it isn't redundant, but could still potentially be made faster since non-absolute paths should be relatively rare now: ====================================================================== FAIL: test_s_option (test.test_site.HelperFunctionsTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_site.py", line 173, in test_s_option self.assertIn(usersite, sys.path) AssertionError: '/home/travis/.local/lib/python3.7/site-packages' not found in ['', '/usr/local/lib/python37.zip', '/home/travis/build/python/cpython/Lib', '/home/travis/build/python/cpython/build/lib.linux-x86_64-3.7-pydebug'] ====================================================================== FAIL: test_abs_paths (test.test_site.ImportSideEffectTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_site.py", line 365, in test_abs_paths .format(os__file__.decode('ascii'))) AssertionError: False is not true : expected absolute path, got ../../Lib/os.py ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:25:47 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 19 Feb 2017 11:25:47 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487503547.07.0.298071721634.issue29436@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Thanks for the response. Sorry if my previous work on Android brings confusion. To prevent possible wasting of time in the future, I'd like to confirm myself for some conclusions: CPython's support for Android targets only stable releases of the official NDK. That includes all building time and runtime results. I guess that's the current policy? Thanks in advance for any further replies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:27:53 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Feb 2017 11:27:53 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487503673.57.0.879665685769.issue29592@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that "os" doesn't get imported normally, it gets injected as part of the importlib bootstrapping process (since _bootstrap_external.py needs the os module in order to work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:37:36 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 19 Feb 2017 11:37:36 +0000 Subject: [issue29599] Github organization link is secret and not accessible from core-dev guide Message-ID: <1487504256.78.0.675328219638.issue29599@psf.upfronthosting.co.za> New submission from Sanyam Khurana: On visiting link: https://docs.python.org/devguide/coredev.html#github The first sentence is "You will be added to the Python core team on GitHub." The ``Python core team`` refers to a link to Github which is not accessible to anyone except for those who are part of the organization. I'd like to suggest to either remove the link from the documentation or make the team visible to public. ---------- assignee: docs at python components: Documentation messages: 288131 nosy: CuriousLearner, docs at python, ncoghlan priority: normal severity: normal status: open title: Github organization link is secret and not accessible from core-dev guide type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:05:23 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 13:05:23 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487509523.4.0.2106418.issue29520@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:18:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 13:18:19 +0000 Subject: [issue29442] Replace optparse with argparse in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487510299.22.0.681054504848.issue29442@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > (example: usage of os.system() in some places) See similar issue7438. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:21:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 13:21:07 +0000 Subject: [issue15317] Source installation sets incorrect permissions for Grammar3.2.3.final.0.pickle In-Reply-To: <1341904877.85.0.287783743443.issue15317@psf.upfronthosting.co.za> Message-ID: <1487510467.07.0.659312291638.issue15317@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:23:07 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 19 Feb 2017 13:23:07 +0000 Subject: [issue7438] Allow to use a part of subprocess module during building Python In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za> Message-ID: <1487510587.19.0.21115370762.issue7438@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:44:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 19 Feb 2017 13:44:49 +0000 Subject: [issue29600] Returning an exception object from a coroutine triggers implicit exception chaining?!? Message-ID: <1487511889.54.0.248268466732.issue29600@psf.upfronthosting.co.za> New submission from Nathaniel Smith: The following code prints "KeyError()", which is obviously wrong and rather baffling. Just passing an exception object around *as an object* should not trigger implicit exception chaining! If you replace the async functions with regular functions then it prints "None", as expected. Checked on 3.5, 3.6, and more-or-less current master -- bug is present in all 3. ------------ async def f(): return ValueError() async def g(): try: raise KeyError except: value_error = await f() print(repr(value_error.__context__)) try: g().send(None) except StopIteration: pass ---------- components: Interpreter Core messages: 288133 nosy: njs priority: normal severity: normal status: open title: Returning an exception object from a coroutine triggers implicit exception chaining?!? versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:47:23 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 13:47:23 +0000 Subject: [issue29599] Github organization link is secret and not accessible from core-dev guide In-Reply-To: <1487504256.78.0.675328219638.issue29599@psf.upfronthosting.co.za> Message-ID: <1487512043.6.0.562222854802.issue29599@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. I agree that the link can be removed. We have a separate issue tracker for devguide at https://github.com/python/devguide/issues Please report this there. ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:05:23 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 19 Feb 2017 14:05:23 +0000 Subject: [issue29237] Create enum for pstats sorting options In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za> Message-ID: <1487513123.87.0.493381441381.issue29237@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thank you, Ratnadeep. I've been assigned to this issue, and have made some progress on it. I'm away for a conference right now, and I plan on getting back once I'm back. Will it be possible for you to work on a different issue? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:11:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 14:11:09 +0000 Subject: [issue9592] Limitations in objects returned by multiprocessing Pool In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za> Message-ID: <1487513469.65.0.10314888473.issue9592@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem with pickling exceptions should be addressed in other issue (issue29466). Other problems seems are solved. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:16:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 14:16:14 +0000 Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe imports In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za> Message-ID: <1487513774.25.0.0873570858271.issue12680@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:23:49 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 14:23:49 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487514229.9.0.557887011851.issue29592@psf.upfronthosting.co.za> INADA Naoki added the comment: I got it. removeduppaths() may change relpath in sys.path to absolute path. abs_paths() changes __file__ and __cached__ for consistency with the changed sys.path. I updated PR 167 to call abs_paths() only if removeduppaths() modified sys.path. Strictly speaking, abs_paths() is required only when removeduppaths() converted relpath to absolute path. But because duplicated paths are rare too, I think this approach is practical enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:24:29 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 14:24:29 +0000 Subject: [issue10701] Error pickling objects with mutating __getstate__ In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1487514269.49.0.82504602274.issue10701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python status: open -> pending type: behavior -> enhancement versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:24:50 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 14:24:50 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487514290.36.0.958442113724.issue29553@psf.upfronthosting.co.za> Berker Peksag added the comment: FWIW, I also prefer PR 120 over PR 117. However, if Steven prefers PR 120 we probably should merge it only in master. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:30:53 2017 From: report at bugs.python.org (Steve Dower) Date: Sun, 19 Feb 2017 14:30:53 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487514653.94.0.412560417682.issue29533@psf.upfronthosting.co.za> Steve Dower added the comment: My guess is that IE is implemented using lower level APIs and it can choose whether to bypass based on its own list. There's no reason for any other software to take its settings into account. That said, it would be great if urllib can avoid adding long delays, at least more than once. I'm personally not sure how best to do that though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 09:40:46 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 19 Feb 2017 14:40:46 +0000 Subject: [issue29599] Github organization link is secret and not accessible from core-dev guide In-Reply-To: <1487504256.78.0.675328219638.issue29599@psf.upfronthosting.co.za> Message-ID: <1487515246.86.0.160695351721.issue29599@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Thanks a lot Berker! I've reported the issue there at https://github.com/python/devguide/issues/124 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:01:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 15:01:18 +0000 Subject: [issue11299] Allow deepcopying paused generators In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za> Message-ID: <1487516478.46.0.855704899268.issue11299@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Antoine. copy.deepcopy() should be used with care since it recursively copies all referred data. In case of generators the data can be referred implicitly. Every global value cached in local variable, every passed argument, every nonlocal variable should be copied. This may not just wastes memory and CPU time, but change the semantic. ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:03:22 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 15:03:22 +0000 Subject: [issue29574] python-3.6.0.tgz permissions borked In-Reply-To: <1487199047.25.0.291984947125.issue29574@psf.upfronthosting.co.za> Message-ID: <1487516602.23.0.528240941853.issue29574@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:04:06 2017 From: report at bugs.python.org (Harshul) Date: Sun, 19 Feb 2017 15:04:06 +0000 Subject: [issue28886] Move deprecated abc module decorators to separate section in docs In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za> Message-ID: <1487516646.5.0.147220008865.issue28886@psf.upfronthosting.co.za> Changes by Harshul : ---------- pull_requests: +141 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:07:10 2017 From: report at bugs.python.org (Harshul) Date: Sun, 19 Feb 2017 15:07:10 +0000 Subject: [issue28886] Move deprecated abc module decorators to separate section in docs In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za> Message-ID: <1487516830.54.0.613892042408.issue28886@psf.upfronthosting.co.za> Changes by Harshul : ---------- keywords: +patch Added file: http://bugs.python.org/file46651/bpo-28886_3.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:30:23 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 19 Feb 2017 15:30:23 +0000 Subject: [issue29559] Detect mouse over lines on canvas while mouse button is down In-Reply-To: <1487097539.49.0.870342047727.issue29559@psf.upfronthosting.co.za> Message-ID: <1487518223.89.0.904588123324.issue29559@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +gpolo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:33:13 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 15:33:13 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487518393.83.0.175337248525.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: > I think we can special-case small arrays in PyCStructUnionType_update_stgdict Is that definitely the right place? And is doing it only for small arrays going to be enough? Currently, PyCStructUnionType_update_stgdict does dict = PyType_stgdict(desc); and then stgdict->ffi_type_pointer.elements[ffi_ofs + i] = &dict->ffi_type_pointer; where dict is the ctypes object for the field type. If the ffi_type_pointer is used all over the place because arrays usually degenerate to pointers, and changing it would cause breakage elsewhere, maybe the answer is to have a new ffi_type_array field which is NULL for non-array types and set correctly for array types; then the above code can check for a non-NULL ffi_type_array and use that instead of the ffi_type_pointer? Or am I talking nonsense? Oddly (or perhaps not), this failure doesn't seem to occur on Windows - no crash happens and the correct value is returned from a function which sums the array, as in this example. See attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file46652/fix-22273-01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:35:22 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 19 Feb 2017 15:35:22 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487518522.87.0.0382028426834.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've not marked it "patch review" as the patch isn't complete. Just wanted to see if anyone can reproduce/explain the working on Windows/failing on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:59:09 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 15:59:09 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487519949.49.0.900981100139.issue29594@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 10:59:52 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 19 Feb 2017 15:59:52 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1487519992.37.0.766857164311.issue24339@psf.upfronthosting.co.za> Julien Palard added the comment: John: You should probably package this as a pip module alongisde with a git repository, at least to measure qty of interested persones, and get some feedback / contributions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 11:20:28 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 19 Feb 2017 16:20:28 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1487521228.01.0.313270706363.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- pull_requests: +143 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 11:41:47 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 16:41:47 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487522507.97.0.985125648368.issue29529@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +144 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 11:48:46 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 19 Feb 2017 16:48:46 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487522926.12.0.108945124104.issue29594@psf.upfronthosting.co.za> Julien Palard added the comment: Your implementation looks right, but I don't see the point of defining combinations AB, AC, ABD in the Foo enum. Foo may only define A, B, C, D and outside of Foo anyone can build any needed combinations. This way it looks clear in the Foo declaration (4 lines, 4 auto()). Did I missed a usefull usage of declaring combination inside the enum? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:03:05 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 19 Feb 2017 17:03:05 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487523785.06.0.619114647909.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:03:10 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 19 Feb 2017 17:03:10 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487523790.99.0.586604357703.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:07:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 17:07:34 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487524054.67.0.671959786178.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 3eea8c67fa870c6e2b7a521d292afe7fe3e95f58 by GitHub in branch 'master': bpo-29520: doc: fix deprecation warning from 'defindex' template (GH-165) https://github.com/python/cpython/commit/3eea8c67fa870c6e2b7a521d292afe7fe3e95f58 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:08:14 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 19 Feb 2017 17:08:14 +0000 Subject: [issue29601] Need reST markup for enum types Message-ID: <1487524094.89.0.393871634605.issue29601@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: Over in https://github.com/python/cpython/pull/138 I noticed that we don't currently have markup for enum types. While class:: is technically still correct, it's not helpful because the html documentation should render this as `Enum SafeUUID` not `class SafeUUID`. ---------- assignee: docs at python components: Documentation messages: 288147 nosy: barry, berker.peksag, docs at python priority: normal severity: normal status: open title: Need reST markup for enum types versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:11:41 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 17:11:41 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487524301.28.0.111516960351.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +145 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:12:47 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 17:12:47 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487524367.46.0.404505396079.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +146 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:13:51 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Feb 2017 17:13:51 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487524431.49.0.409381704034.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +147 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:43:58 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 19 Feb 2017 17:43:58 +0000 Subject: [issue29436] Compilation failure against Android NDK r14 beta 2 In-Reply-To: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> Message-ID: <1487526238.12.0.669344545479.issue29436@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > CPython's support for Android targets only stable releases of the official NDK. As the NDK is seeing many changes in the recent past and near future (deprecation of the support of gcc in favor of clang, Unified Headers, nearly all the NDK scripts written in python, ...) we should use the latest stable NDK release. > That includes all building time and runtime results. You can open new issues for NDK r14 with the description of the problem and with NDK r14 building time and runtime results, as a reminder of what will need to be done when we switch to r14 as it was done for issue 29040. But please no PR. Maybe add a comment saying that for the moment this is just a reminder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:51:27 2017 From: report at bugs.python.org (Marc Guetg) Date: Sun, 19 Feb 2017 17:51:27 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487526687.27.0.3952705331.issue29594@psf.upfronthosting.co.za> Marc Guetg added the comment: One made-up use-case would be: class LogLevel(Flags): start = auto() log1 = start | auto() log2 = start | auto() def fun(flags, *args): if start in flags: # open log file if log1 in flags: # Log important thing 1 if log2 in flags: # Log important thing 2 if start in flags: # close log file Alternatively the same could be achieved using the existing capabilities with: class LogLevel(Flags): start = auto() _log1 = auto() log1 = start | _log1 _log2 = auto() log2 = start | _log2 Which is less clear imho and could potentially a problem if somebody uses LogLevel._log2 Another alternative would be that within the function we would check for all cases. eg: if (start in flags) or (log1 in flags) or (log2 in flags): Which leads to less clear code and makes the code less maintainable when log3 gets introduced. In the existing case we need to remember to change the if clause both when opening and closing the file. After the proposed change we only need to change the enum. I'm sure there are more use-cases for it. The one I'm using it for is a bit more convoluted that's why I'm not presenting it here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:57:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 17:57:52 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487527072.49.0.717117525382.issue29594@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just make C and D protected or private. class Foo(Flag): A = auto() B = auto() AB = A | B _C = auto() __D = auto() AC = A | _C ABD = A | B | __D ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 13:19:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 18:19:16 +0000 Subject: [issue18400] Minor increase to Pickle test coverage In-Reply-To: <1373259878.07.0.171161881505.issue18400@psf.upfronthosting.co.za> Message-ID: <1487528356.07.0.475912058318.issue18400@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 13:27:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 18:27:08 +0000 Subject: [issue14124] _pickle.c comment/documentation improvement In-Reply-To: <1330203362.98.0.289163571674.issue14124@psf.upfronthosting.co.za> Message-ID: <1487528828.72.0.300639034253.issue14124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Using absolute line numbers in comments looks bad idea to me. This becomes outdated very fast. The code of _pickle.c was changed many times since writing the patch. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 13:43:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 18:43:33 +0000 Subject: [issue14336] Difference between pickle implementations for function objects In-Reply-To: <1331924619.34.0.890923032137.issue14336@psf.upfronthosting.co.za> Message-ID: <1487529813.55.0.617473305944.issue14336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In 3.x the fallback was removed by 6bd1f0a27e8e. If this is 2.7 only issue I prefer to close it as "won't fix". See also issue26959. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 13:58:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 18:58:51 +0000 Subject: [issue26959] pickle: respect dispatch for functions again In-Reply-To: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za> Message-ID: <1487530731.34.0.0712262379564.issue26959@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is saving global an atomic operation? Falling back to using reduce can be not safe if some data was written during saving global. That also might make error messages less helpful. Is not founding a function the only cause of PicklingError? Raising and catching an exception is not very efficient. Shouldn't the fallback be used for classes and C functions? If add this feature the patch should be significantly reworked. ---------- nosy: +serhiy.storchaka stage: patch review -> needs patch type: behavior -> enhancement versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:05:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:05:26 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487531126.91.0.56303584038.issue11572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is anything left to do with this issue? Many changes were made in the copy module and tests last year. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:09:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:09:18 +0000 Subject: [issue29580] "Built-in Functions" not being functions In-Reply-To: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> Message-ID: <1487531358.49.0.806915454469.issue29580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue11975. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:12:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:12:00 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1487531520.21.0.49887446061.issue21401@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:14:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:14:07 +0000 Subject: [issue9267] Update pickle opcode documentation in pickletools for 3.x In-Reply-To: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za> Message-ID: <1487531647.7.0.196052296156.issue9267@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:19:35 2017 From: report at bugs.python.org (Andrew Nester) Date: Sun, 19 Feb 2017 19:19:35 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted In-Reply-To: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> Message-ID: <1487531975.46.0.824557036439.issue29573@psf.upfronthosting.co.za> Andrew Nester added the comment: any updates on this? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:24:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:24:35 +0000 Subject: [issue24159] Misleading TypeError when pickling bytes to a file opened as text In-Reply-To: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za> Message-ID: <1487532275.94.0.627516959072.issue24159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is worth to improve the error message in the write() method of binary files. >>> sys.stdout.write(b'') Traceback (most recent call last): File "", line 1, in TypeError: write() argument must be str, not bytes >>> sys.stdout.buffer.write('') Traceback (most recent call last): File "", line 1, in TypeError: a bytes-like object is required, not 'str' >>> sys.stdout.buffer.raw.write('') Traceback (most recent call last): File "", line 1, in TypeError: a bytes-like object is required, not 'str' But this is large issue. Other file-like objects (GzipFile, ZipExtFile etc) should be updated too. ---------- nosy: +serhiy.storchaka type: behavior -> enhancement versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:28:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:28:26 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1487532506.41.0.453030369077.issue13566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a problem when pickle data in Python 3 for unpickling in Python 2. ---------- versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:29:21 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 19 Feb 2017 19:29:21 +0000 Subject: [issue29442] Replace optparse with argparse in setup.py In-Reply-To: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> Message-ID: <1487532561.1.0.714329738158.issue29442@psf.upfronthosting.co.za> Brett Cannon added the comment: I just wanted to acknowledge that I read this thread. I accept Chi's acknowledgement of his actions and I hope there aren't future missteps, but please also realize that there has been a warning about how you communicate here, Chi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:29:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:29:47 +0000 Subject: [issue23655] Memory corruption using pickle over pipe to subprocess In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za> Message-ID: <1487532587.64.0.995923308222.issue23655@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:31:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:31:43 +0000 Subject: [issue23655] Memory corruption using pickle over pipe to subprocess In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za> Message-ID: <1487532703.73.0.651458645518.issue23655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Without additional information we can't solve this issue. Is the problem still reproduced? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:31:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 19:31:51 +0000 Subject: [issue23655] Memory corruption using pickle over pipe to subprocess In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za> Message-ID: <1487532711.17.0.937601156402.issue23655@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:43:12 2017 From: report at bugs.python.org (Andrew Nester) Date: Sun, 19 Feb 2017 19:43:12 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487533392.21.0.695548167756.issue29540@psf.upfronthosting.co.za> Andrew Nester added the comment: Adding new argument sucs as format= or compact= will make API more complicated. In addition it's not easy and has obvious how to handle situations wheb we have both separatots= and format= arguments set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:44:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 19 Feb 2017 19:44:28 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487533468.66.0.943160476988.issue29554@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +148 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:44:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 19 Feb 2017 19:44:28 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487533468.73.0.959908894327.issue29554@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +148, 149 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:44:28 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 19 Feb 2017 19:44:28 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487533468.78.0.924986124338.issue29554@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +148, 149, 150 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 14:58:40 2017 From: report at bugs.python.org (Bob Ippolito) Date: Sun, 19 Feb 2017 19:58:40 +0000 Subject: [issue29540] Add compact=True flag to json.dump/dumps In-Reply-To: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> Message-ID: <1487534320.73.0.183714348622.issue29540@psf.upfronthosting.co.za> Bob Ippolito added the comment: I would recommend a moratorium on new options until we have a plan to make the usage of the JSON APIs simpler overall. It's accumulated too many options over time. The real trouble is figuring out how to do this in a backwards compatible way that does not impact performance too much. Off-hand, I can't think of any obvious way aside from using new function names with a cleaner options list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 15:29:42 2017 From: report at bugs.python.org (Eryk Sun) Date: Sun, 19 Feb 2017 20:29:42 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487536182.65.0.318871399505.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: Structs that are larger than 32 bytes get copied to the stack (see classify_argument in ffi64.c), so we don't have to worry about classifying their elements for register passing. Thus if a new field is added for this in StgDictObject, then PyCArrayType_new should only allocate it for array types that are 32 bytes or less. Using it for larger array types would serve no point. > explain the working on Windows/failing on Linux. In the Windows libffi we don't have examine_argument() and classify_argument(). The Win64 ABI is fairly simple [1]. A struct that's 8 bytes or less gets passed as an integer, so if it's in the first four arguments it gets passed in rcx, rdx, r8, or r9. Otherwise it gets copied and passed by reference. Unlike the 64-bit Unix ABI, we don't have to worry about packing struct elements across multiple registers or passing floating-point elements in vector registers. [1]: https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 15:55:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 20:55:25 +0000 Subject: [issue18195] error when deep copying module is confusing In-Reply-To: <1370990732.59.0.654966118724.issue18195@psf.upfronthosting.co.za> Message-ID: <1487537725.56.0.38395394394.issue18195@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue looks as enhancement rather than bug fix. Since it is fixed in 3.6 I'm closing it. ---------- resolution: -> out of date stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 16:56:23 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Feb 2017 21:56:23 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487541383.6.0.186465396313.issue11572@psf.upfronthosting.co.za> Berker Peksag added the comment: All changes to Lib/test/test_copy.py have already been committed. Perhaps the following hunks from the latest patch can still be useful: -try: - d[types.CodeType] = _deepcopy_atomic -except AttributeError: - pass +d[types.CodeType] = _deepcopy_atomic --- def _deepcopy_tuple(x, memo): + if not x: + return x --- - try: - issc = issubclass(cls, type) - except TypeError: # cls is not a class (old Boost; see SF #502085) - issc = 0 - if issc: + if issubclass(cls, type): ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 17:15:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Feb 2017 22:15:00 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487542500.06.0.620271833645.issue11572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree. The latter simplification can be applied to pickle.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:03:23 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 20 Feb 2017 00:03:23 +0000 Subject: [issue29601] Need reST markup for enum types In-Reply-To: <1487524094.89.0.393871634605.issue29601@psf.upfronthosting.co.za> Message-ID: <1487549003.14.0.473955302772.issue29601@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Is there some special treatment you think should be given to specific enum values as well? ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:13:44 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 00:13:44 +0000 Subject: [issue29601] Need reST markup for enum types In-Reply-To: <1487549003.14.0.473955302772.issue29601@psf.upfronthosting.co.za> Message-ID: <20170219191340.1ceeae89@subdivisions.wooz.org> Barry A. Warsaw added the comment: On Feb 20, 2017, at 12:03 AM, Fred L. Drake, Jr. wrote: >Is there some special treatment you think should be given to specific enum >values as well? The only thing I thought about was optionally provide the enum item's value, when that's useful. Usually you shouldn't care what the item's value is, but maybe sometimes you do, and in that case it would be nice if there was a way to express that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:16:35 2017 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 20 Feb 2017 00:16:35 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1487549795.64.0.416878579306.issue20160@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset a86339b83fbd0932e0529a3c91935e997a234582 by GitHub in branch 'master': Fixed bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64. (#168) https://github.com/python/cpython/commit/a86339b83fbd0932e0529a3c91935e997a234582 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:16:36 2017 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 20 Feb 2017 00:16:36 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487549796.27.0.750526133817.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset a86339b83fbd0932e0529a3c91935e997a234582 by GitHub in branch 'master': Fixed bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64. (#168) https://github.com/python/cpython/commit/a86339b83fbd0932e0529a3c91935e997a234582 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:20:01 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 00:20:01 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487550001.06.0.843925822479.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +151 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:25:29 2017 From: report at bugs.python.org (Bart Robinson) Date: Mon, 20 Feb 2017 00:25:29 +0000 Subject: [issue12450] Use the Grisu algorithms to convert floats to strings In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za> Message-ID: <1487550329.63.0.0524641337551.issue12450@psf.upfronthosting.co.za> Bart Robinson added the comment: Six years later, I have accepted Amaury's challenge and created an extension module that uses the double-conversion library to generate repr's for floats: https://pypi.python.org/pypi/frepr My rudimentary performance testing gives something like 8X speedup compared to the standard float_repr(). Scrutiny and suggestions welcome... ---------- nosy: +Bart Robinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:35:06 2017 From: report at bugs.python.org (Julia Dolgova) Date: Mon, 20 Feb 2017 00:35:06 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487550906.18.0.89504053698.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: Why not to take it into account? Imagine that someone wants that requests to "ovinnik.canonical.com" should bypass proxy and requests to "ubuntu.com" souldn't. I don't know what for, it's just an assumption. He adds a hostname "ovinnik.canonical.com" into and checks requests in IE. He sees that requests to "ovinnik.canonical.com" bypass proxy and requests to "ubuntu.com" go via proxy. And it's ok. But suddenly he discovers that requests in urllib to "ubuntu.com" bypass proxy and it's unexpected. I think this behavior of urllib should be at least optional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:44:55 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 00:44:55 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487551495.86.0.967082228365.issue29529@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 98604c7683f41f04c633935bb582399c50db838c by GitHub in branch '2.7': bpo-29529: Add .travis.yml to 2.7 branch (GH-27) https://github.com/python/cpython/commit/98604c7683f41f04c633935bb582399c50db838c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:45:58 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 00:45:58 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487551558.11.0.801892017773.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset cf44d957ec177be62f5349ef88515190dcfccbd6 by GitHub in branch '2.7': bpo-29520: doc: fix deprecation warning from 'defindex' template (GH-180) https://github.com/python/cpython/commit/cf44d957ec177be62f5349ef88515190dcfccbd6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:46:26 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 00:46:26 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487551586.88.0.890519162359.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset f0174c69b7b8bd27ee32d96e890d665da29472af by GitHub in branch '3.5': bpo-29520: doc: fix deprecation warning from 'defindex' template (GH-179) https://github.com/python/cpython/commit/f0174c69b7b8bd27ee32d96e890d665da29472af ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:46:49 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 00:46:49 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487551609.21.0.034142894399.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 7970cd483346dfd7723da214fb27399ecc574095 by GitHub in branch '3.6': bpo-29520: doc: fix deprecation warning from 'defindex' template (GH-178) https://github.com/python/cpython/commit/7970cd483346dfd7723da214fb27399ecc574095 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:49:52 2017 From: report at bugs.python.org (Tom Krauss) Date: Mon, 20 Feb 2017 00:49:52 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part Message-ID: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> New submission from Tom Krauss: Consider the following simple class that provides a "__complex__" method. class C(object): def __init__(self, x): self.x = x def __complex__(self): return self.x x=C(-0j) PYTHON 2.7.13 >>> x.x -0j >>> complex(x) 0j PYTHON 3.6 >>> x.x (-0-0j) >>> complex(x) (-0+0j) ---------- messages: 288177 nosy: Tom Krauss priority: normal severity: normal status: open title: complex() on object with __complex__ function loses sign of zero imaginary part type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 20:22:31 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 01:22:31 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487553751.31.0.0619924564474.issue29520@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset e395c4dbe19115aaab315c2a113b172e9fef307a by GitHub in branch 'master': bpo-29520: doc: add missing dot (GH-182) https://github.com/python/cpython/commit/e395c4dbe19115aaab315c2a113b172e9fef307a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 20:28:52 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 20 Feb 2017 01:28:52 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487554132.9.0.937452019282.issue29602@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 21:16:17 2017 From: report at bugs.python.org (Julia Dolgova) Date: Mon, 20 Feb 2017 02:16:17 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487556977.15.0.718264443933.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: http://bugs.python.org/issue23384 - same problem ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 23:25:18 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 04:25:18 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487564718.97.0.129003018794.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: New changeset d0e8212ed70445cc3d48b0d4ae7c9cb480004010 by GitHub in branch 'master': bpo-29347: Fix possibly dereferencing undefined pointers when creating weakref objects (#128) https://github.com/python/cpython/commit/d0e8212ed70445cc3d48b0d4ae7c9cb480004010 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 23:58:00 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 04:58:00 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487566680.47.0.716858027399.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +152 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 23:58:51 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 04:58:51 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487566731.18.0.317778651316.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +153 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 23:59:30 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 04:59:30 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487566770.35.0.420242821649.issue29347@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +154 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 01:11:16 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 06:11:16 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487571076.92.0.651466684944.issue29562@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 01:32:55 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 06:32:55 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487572375.84.0.68879122471.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: New changeset 7131a73f9655cfd325c798385905326f57b94640 by GitHub in branch '2.7': bpo-29347: Fix possibly dereferencing undefined pointers when creating weakref objects (#128) (#187) https://github.com/python/cpython/commit/7131a73f9655cfd325c798385905326f57b94640 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 01:33:04 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 06:33:04 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487572384.91.0.894616753804.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: New changeset 9a4577a4bb23888fed2cf192cf1a4c95ce5c26f8 by GitHub in branch '3.6': bpo-29347: Fix possibly dereferencing undefined pointers when creating weakref objects (#128) (#186) https://github.com/python/cpython/commit/9a4577a4bb23888fed2cf192cf1a4c95ce5c26f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 01:33:08 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 06:33:08 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487572388.24.0.255509684418.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: New changeset 7c95a94c3ab41e4296e94335d66b2400ad16f052 by GitHub in branch '3.5': bpo-29347: Fix possibly dereferencing undefined pointers when creating weakref objects (#128) (#188) https://github.com/python/cpython/commit/7c95a94c3ab41e4296e94335d66b2400ad16f052 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 01:35:53 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 06:35:53 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487572553.73.0.313025379845.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: Although no feedback from Saida, but IMHO the problem is solved so I close it now. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 02:22:43 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 Feb 2017 07:22:43 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487571077.0.0.218168471551.issue29562@psf.upfronthosting.co.za> Message-ID: Ronald Oussoren added the comment: Note that the result of getgroups(2) is fixed on login, while "id -G" reflects the current state of the user database on macOS. Could this explain this failure? That is, have you tried logging out and in again before running the test suite? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 02:32:53 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Mon, 20 Feb 2017 07:32:53 +0000 Subject: [issue29562] test_getgroups of test_posix fails (on OS X 10.10) In-Reply-To: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> Message-ID: <1487575973.16.0.181748463278.issue29562@psf.upfronthosting.co.za> Jim DeLaHunt added the comment: > Note that the result of getgroups(2) is fixed on login, while "id -G" reflects the current state of the user database on macOS. Wow, that's interesting! Thank you for this information. The test code for test_getgroups does not mention this interaction. I can certainly see how it could affect the test. Maybe it should be added? Since I last tried that test, I've logged out and restarted several times, and changed OS to Mac OS X 10.11 El Capitan. Nothing like changing several independent variables at once while diagnosing! I will try the test again and report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 02:38:15 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 07:38:15 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487576295.2.0.490427577139.issue27660@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +155 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 02:40:14 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 07:40:14 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487576414.4.0.687081768429.issue27660@psf.upfronthosting.co.za> Xiang Zhang added the comment: I opened a PR on GitHub for this issue. Hope Raymond you could review it some time. ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 03:50:16 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 08:50:16 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed In-Reply-To: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> Message-ID: <1487580616.95.0.647236881706.issue29589@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi Dima, can you stably reproduce the failures? Or try with the latest 3.6 code? ---------- nosy: +xiang.zhang stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:08:20 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 09:08:20 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487581700.21.0.29864495464.issue29532@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +156 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:12:24 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 09:12:24 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks Message-ID: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> New submission from slytomcat: Class queue.Queue control the number of unfinished tasks via method task_done(). But it is only possible to get the information about all task done (via join() method). I'm sure that exposing the number of unfinished tasks (unfinished_tasks class variable) can be very useful in many situations when you need more control over the process. But it is not good idea to provide write access to this internal variable (as it controls internal queue class status). Better way - provide RO access via class method like qsize or empty. It can be look like this: def unfinished(self): return self.unfinished_tasks One example of this method usage: there is not optimal function _adjust_thread_count in concurrent.futures.ThreadPoolExecutor with following comment: # TODO(bquinlan): Should avoid creating new threads if there are more # idle threads than items in the work queue. It can be easily done with following condition: if self._work_queue.unfinished() <= len(self._threads): return ---------- components: Library (Lib) messages: 288189 nosy: rhettinger, slytomcat priority: normal severity: normal status: open title: More informative Queue class: new method that returns number of unfinished tasks versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:13:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 09:13:12 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487581992.5.0.791859433961.issue11572@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:19:59 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 09:19:59 +0000 Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za> Message-ID: <1487582399.49.0.932847901979.issue29595@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:27:10 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 09:27:10 +0000 Subject: [issue29596] Unfinished sentense in howto/clinic.rst In-Reply-To: <1487380332.64.0.682733186171.issue29596@psf.upfronthosting.co.za> Message-ID: <1487582830.57.0.14344528589.issue29596@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +larry stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:37:16 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 20 Feb 2017 09:37:16 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487583436.23.0.0336116301218.issue29602@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:44:36 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 09:44:36 +0000 Subject: [issue29569] threading.Timer class: Continue periodical execution till action returns True In-Reply-To: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> Message-ID: <1487583876.59.0.878791850481.issue29569@psf.upfronthosting.co.za> Changes by slytomcat : ---------- pull_requests: +157 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:52:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 09:52:36 +0000 Subject: [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst In-Reply-To: <1487474915.7.0.0359048996741.issue29579@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I don't think that removing the readme.txt from the install constitutes a breaking change (LICENSE would be a bigger deal), and removing the file from the installer sounds simpler than updating the readme. Ok, fine :-) Happy to see this issue closed ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:55:39 2017 From: report at bugs.python.org (Natanael Copa) Date: Mon, 20 Feb 2017 09:55:39 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat (CVE-2016-0718 and CVE-2016-4472) In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487584538.99.0.454753750573.issue29591@psf.upfronthosting.co.za> Changes by Natanael Copa : ---------- title: Various security vulnerabilities in bundled expat -> Various security vulnerabilities in bundled expat (CVE-2016-0718 and CVE-2016-4472) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 05:00:23 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 10:00:23 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487584823.85.0.742935243658.issue29603@psf.upfronthosting.co.za> Changes by slytomcat : ---------- pull_requests: +158 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 05:02:35 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 10:02:35 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487584955.3.0.639832228208.issue29603@psf.upfronthosting.co.za> Changes by slytomcat : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 05:20:37 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 10:20:37 +0000 Subject: [issue29520] Documentation uses deprecated "defindex.html" Sphinx template In-Reply-To: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> Message-ID: <1487586037.58.0.555436801176.issue29520@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 05:21:23 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 10:21:23 +0000 Subject: [issue29529] Backport Travis configuration In-Reply-To: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> Message-ID: <1487586083.41.0.484144611305.issue29529@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 05:45:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 10:45:50 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487587550.36.0.793058859875.issue23890@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- pull_requests: +160 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:07:59 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:07:59 +0000 Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback() of _asynciomodule.c In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za> Message-ID: <1487588879.11.0.775269292518.issue28963@psf.upfronthosting.co.za> INADA Naoki added the comment: 3.6.0 had been released? Yury, would you create pull request? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:11:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:11:06 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487589066.77.0.415040617045.issue24274@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +161 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:13:02 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 11:13:02 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487589182.67.0.315313831881.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: Confirmed on my machine. The effect of the source is to do `complex(complex(x), 0.0)` in this case, which isn't correct. ---------- components: +Interpreter Core stage: -> needs patch versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:13:16 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 11:13:16 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487589196.17.0.456862879352.issue29602@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:20:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:20:06 +0000 Subject: [issue28331] "CPython implementation detail:" removed when content translated In-Reply-To: <1475328552.4.0.631332821236.issue28331@psf.upfronthosting.co.za> Message-ID: <1487589606.68.0.25252104489.issue28331@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +162 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:28:24 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:28:24 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487590104.25.0.0792953375983.issue24274@psf.upfronthosting.co.za> INADA Naoki added the comment: https://github.com/python/cpython/pull/194#issuecomment-281054701 Xiang Zhang found Python 3.6+ have similar issue. ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:29:32 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:29:32 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487590172.46.0.103957982808.issue24274@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 66fa9d4205e0da672ed19a397069281a4b177af4 by GitHub in branch '3.5': bpo-24274: fix comment in dictobject.c (GH-194) https://github.com/python/cpython/commit/66fa9d4205e0da672ed19a397069281a4b177af4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:32:54 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 11:32:54 +0000 Subject: [issue29569] threading.Timer class: Continue periodical execution till action returns True In-Reply-To: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> Message-ID: <1487590374.01.0.186150768589.issue29569@psf.upfronthosting.co.za> Changes by slytomcat : ---------- pull_requests: -81 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:34:59 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:34:59 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487590499.48.0.262515757004.issue24274@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +163 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:41:02 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:41:02 +0000 Subject: [issue25617] Installing local installation of Python In-Reply-To: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za> Message-ID: <1487590862.8.0.0614231425472.issue25617@psf.upfronthosting.co.za> INADA Naoki added the comment: close this issue because lack of information. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:41:15 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 11:41:15 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487590875.48.0.981431990632.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looking at the source, there's also an issue with complex subclasses here: >>> class C(complex): ... pass ... >>> complex(C(-0j)) (-0+0j) >>> complex(-0j) (-0-0j) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:41:49 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 11:41:49 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487590909.11.0.72071726866.issue29602@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:43:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:43:44 +0000 Subject: [issue26382] List object memory allocator In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za> Message-ID: <1487591024.37.0.416622604719.issue26382@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 06:54:46 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 11:54:46 +0000 Subject: [issue29509] redundant interning in PyObject_GetAttrString In-Reply-To: <1486626523.7.0.635584720165.issue29509@psf.upfronthosting.co.za> Message-ID: <1487591686.32.0.25743518834.issue29509@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +164 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 07:04:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 12:04:32 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487592272.92.0.433010962277.issue29532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 9639e4ab6d5bd3ca0ab34fef127e9fc84b6b88b9 by GitHub in branch 'master': bpo-29532: Altering a kwarg dictionary passed to functools.partial() (#190) https://github.com/python/cpython/commit/9639e4ab6d5bd3ca0ab34fef127e9fc84b6b88b9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 07:17:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 12:17:41 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487593061.65.0.786268945919.issue29532@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +165 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 07:55:25 2017 From: report at bugs.python.org (Gianluca Rossi) Date: Mon, 20 Feb 2017 12:55:25 +0000 Subject: [issue29604] ImportError when importing the package `queue` Message-ID: <1487595325.27.0.987897101008.issue29604@psf.upfronthosting.co.za> New submission from Gianluca Rossi: In Python 3.5.2 importing *queue* raises an *ImportError*. ``` Python 3.5.2 (default, Jul 5 2016, 12:43:10) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import queue Traceback (most recent call last): File "", line 1, in File "/home/gianluca/git/python/asyncio/queue.py", line 1, in import asyncio File "/usr/lib/python3.5/asyncio/__init__.py", line 21, in from .base_events import * File "/usr/lib/python3.5/asyncio/base_events.py", line 18, in import concurrent.futures File "/usr/lib/python3.5/concurrent/futures/__init__.py", line 17, in from concurrent.futures.process import ProcessPoolExecutor File "/usr/lib/python3.5/concurrent/futures/process.py", line 52, in from queue import Full ImportError: cannot import name 'Full' ``` I'm not very familiar with the *asyncio* module since I've just recently started working with it. Please let me know if I can be of more help. ---------- components: asyncio messages: 288198 nosy: Gianluca Rossi, gvanrossum, yselivanov priority: normal severity: normal status: open title: ImportError when importing the package `queue` type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:04:13 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 20 Feb 2017 13:04:13 +0000 Subject: [issue29604] ImportError when importing the package `queue` In-Reply-To: <1487595325.27.0.987897101008.issue29604@psf.upfronthosting.co.za> Message-ID: <1487595853.92.0.155125872215.issue29604@psf.upfronthosting.co.za> Christian Heimes added the comment: You have a queue module in your project which shadows the queue module from Python's standard library. ---------- nosy: +christian.heimes resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:05:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 13:05:12 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1487595912.86.0.662958927617.issue15216@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +166 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:13:49 2017 From: report at bugs.python.org (Marc Culler) Date: Mon, 20 Feb 2017 13:13:49 +0000 Subject: [issue29605] Python2.7-32 misreports architecture on macOS. Message-ID: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> New submission from Marc Culler: On macOS, the 32 bit python 2.7 reports its architecture as '64bit' in platform.architecture(). Note that the 32 bit Python versions 3.4, 3.5 and 3.6 all correctly report '32bit'. $ python-32 Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:39:47) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.architecture()[0] '64bit' >>> import sys >>> sys.maxsize > 2**32 False ---------- components: macOS messages: 288200 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python2.7-32 misreports architecture on macOS. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:31:25 2017 From: report at bugs.python.org (Adrian Chan) Date: Mon, 20 Feb 2017 13:31:25 +0000 Subject: [issue29586] Cannot run pip in fresh install of py 3.5.3 In-Reply-To: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> Message-ID: <1487597484.99.0.448651639324.issue29586@psf.upfronthosting.co.za> Adrian Chan added the comment: Ah, I'd forgotten about that. When I first tried to run python I got an error complaining about a missing api-ms-win-crt-runtime-l1-1.0.dll I installed the necessary VC redistributable and it solved that problem. So that's why I could successfully ensurepip later on. I'm surprised the manual runtime installation was necessary. Between windows updates and installers for other programs I should already have it installed. Perhaps it got corrupted? That's out of scope for this issue anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:37:25 2017 From: report at bugs.python.org (Michael Haubenwallner) Date: Mon, 20 Feb 2017 13:37:25 +0000 Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and later) In-Reply-To: <1486155163.13.0.690023990803.issue27435@psf.upfronthosting.co.za> Message-ID: Michael Haubenwallner added the comment: On 02/03/2017 09:52 PM, Michael Felt wrote: >> Anyway: >> Unfortunately, there is no concept of embedding something like ELF's DT_SONAME tag into the Shared Object. >> The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the linker is recorded into the just-linked executable (or Shared Object). >> This implies that the runtime loader does search for the very same filename (and member eventually) as the linker (at linktime). > > I assume this is why there are many systems besides AIX that do not > support/use DT_SONAME. Except for Windows, I'm not sure which "many systems besides AIX" you're talking here about, that "do not use/support DT_SONAME". > At least I see many references to "Shared > Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with > the latter three being symbolic links to the first). When a system happens to find these symlinks useful, then it actually _does_ support embedding DT_SONAME (or something similar) into its binary file format. > Another issue is support for what I believe MacOS calls "fat" objects - > that support both 32-bit and 64-bit applications - rather than /XXX/lib > for 32-bit objects and /XXX/lib/lib64 or /XXX/lib64 for 64-bit objects. Yes, the AIX Archive Libraries supporting different bitwidths for members is quite similar to MacOS fat objects. However - although related, the creation of "fat" AIX archives is a different topic. But yes, Python ctypes.find_library+dlopen should know how to deal with them. > b) One of the difficulties I faced is trying to guess what version -lFOO > should find when there is more than one version available. Exactly. There is an idea below (the symbol->member map). >> But still, how to get ctypes.find_library() working - ideally for each variant, is another story. Right now it does not work for any variant, > Do you mean all systems, or specific to AIX - I am assuming you mean AIX. Yes - find_library currently does not work for any variant on *AIX*. >> but I guess that search algorithm should follow how the linker discovers the (PATH,BASE,MEMBER) values to > I am not a tool builder. My comments are based on observations and > experience from when I was a developer 25+ years ago. The AIX linker is > not interested in the member name - it seems to go through the > PATH/libBASE.a looking for the first object it can find to resolve a > symbol. The name of the object it finds becomes the MEMBER it records in > it's internal table of where to look later when the application runs. Exactly. >> write into just-linked executables, combined with how the runtime loader finds the Shared Object to actually load. > I worked on a patch - to do all that - taking into consideration the way > libtool names .so files/members and then looking into/at "legacy" aka > IBM dev ways they did things before the libtool model was so prominent. > > My algorithm - attempts to solve the (PATH, BASE, MEMBER) problem as > "dynamically" as possible. PATH and BASE are fairly straight forward - > but MEMBER is clearly more complex. > > PATH: start by looking at the python executable - As far as I can tell, any executable can actually link against the Python interpreter. > and looking at it's "blibpath" - There also is the loadquery() subroutine in AIX, see https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf1/loadquery.htm loadquery(L_GETLIBPATH) "Returns the library path that was used at process exec time.", which includes both the environment variable LIBPATH (or LD_LIBRARY_PATH if LIBPATH is unset) and the executable's "blibpath" value. > and using that as the default colon separated list of PATHs Question is if we do want to consider _current_ values of environment variable LIBPATH (or LD_LIBRARY_PATH) in addition to the "library path at process exec time"? > to search for BASE.a archive. Once a BASE.a file is found it is examined > for a MEMBER. If all PATH/BASE.a do not find a potential MEMBER then the > PATHs are examined again for PATH/BASE.so. Erm, nope, the AIX linker has a different algorithm (for -lNAME): Iterating over the "library path", the first path entry containing any matching filename (either libNAME.a or libNAME.so) will be used, and no further library path iteration is performed. This one found PATH/filename does have to provide the requested symbol in one way or another. > When a .so file is found that > is returned - versioning must be accomplished via a symbolic link to a > versioned library. The linker does not perform such a check, nor does it feel necessary for ctypes.find_library+dlopen as long as it does search similar to the linker. > The program "dump -H" provides this information for both executables and > archive (aka BASE) members. Eventually we might want to avoid spawning the 'dump' program, but implement reading the XCOFF Object File Format within _ctypes module instead. At least AIX does provide the necessary headers: https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/XCOFF.htm > Starting from the "blibpath" values in the executable mean a cpython > packager can add a specific PATH by adding it to > LDFLAGS="-L/my/special/libdir:$LDFLAGS". Note that AIX archives also > have their own "blibpath" - so libraries dynamically loaded may also > follow additional paths that the executable is not aware of (nor need to > be). There is no need for the ctypes module to search libpaths from other Shared Objects than the main executable (and current env vars). > So - once the PATHS are determined the system is examined looking for > ${PATH}/BASE.a. If a target BASE.a is found, it is examined for a MEMBER > is set to BASE.so (now used a MEMBER.so) . If MEMBER.so is not found > then look for the "highest X[.Y[.Z]] aka MEMBER.so.X[.Y[.Z]] name. If > that is not found check AIX legacy names (mainly shr.o or shr_64.o, > although there are also certain key libraries that have additional > variations (boring)). When ctypes.dlopen is asked to load an Archive Library (either .a or .so) without a specific member, it probably should not immediately dlopen a specific member, but fetch the list of symbols provided by useable members (either Shared Objects without the F_LOADONLY flag, as well as specified in Import Files), and return the handle to some internal symbol->member map instead. Then, really loading a shared archive member is done by subsequent ctypes.dlsym - where it becomes clear which archive member to load. > Again, if PATH, BASE, MEMBER is not located as a .a archive - look for > libFOO.so in all the PATH directories known to the executable. Nope, see above - please iterate over a libpath list only _once_, and search for each filename while at one path list entry. However, I'm not sure yet how to identify if we should search for .a or .so first (before .so and .a, respectively): This depends on whether the current executable actually does use runtime linking or not, but I have no idea yet how to figure that out. But probably we may want to use how the Python interpreter (libpython.a or libpython.so) was built. Uhm, ultimative solution feels complex already, while still some things to decide... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:48:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 13:48:12 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487598492.81.0.954814359292.issue24274@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 1b8df107f867fb05ff39ebee7c55f0a907e7ad5f by GitHub in branch 'master': bpo-24274: fix erroneous comment in dictobject.c (GH-196) https://github.com/python/cpython/commit/1b8df107f867fb05ff39ebee7c55f0a907e7ad5f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:50:55 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 13:50:55 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487598655.34.0.875666012145.issue24274@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +167 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:58:13 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 13:58:13 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487599093.77.0.479365862363.issue24274@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset ce552e2d5c4ff90218fb41847e8ffb1fd3ba3b2d by GitHub in branch '3.6': bpo-24274: fix erroneous comment in dictobject.c (GH-200) https://github.com/python/cpython/commit/ce552e2d5c4ff90218fb41847e8ffb1fd3ba3b2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:59:35 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Feb 2017 13:59:35 +0000 Subject: [issue24274] erroneous comments in dictobject.c In-Reply-To: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> Message-ID: <1487599175.49.0.239776083842.issue24274@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:00:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 14:00:07 +0000 Subject: [issue12450] Use the Grisu algorithms to convert floats to strings In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za> Message-ID: <1487599207.26.0.301982991782.issue12450@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: enhancement -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:04:28 2017 From: report at bugs.python.org (Armin Rigo) Date: Mon, 20 Feb 2017 14:04:28 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487599468.77.0.789296199765.issue29602@psf.upfronthosting.co.za> Armin Rigo added the comment: CPython 2.7 and 3.5 have issues with the sign of zeroes even without any custom class: >>> -(0j) # this is -(0+0j) (-0-0j) >>> (-0-0j) # but this equals to the difference between 0 and 0+0j 0j >>> (-0.0-0j) # this is the difference between -0.0 and 0+0j (-0+0j) >>> -0j -0j # <- on CPython 2.7 (-0-0j) # <- on CPython 3.5 It's unclear if the signs of the two potential zeroes in a complex number have a meaning, but the C standard considers these cases for all functions in the complex number's header. ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:11:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 14:11:04 +0000 Subject: [issue26382] List object memory allocator In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za> Message-ID: <1487599864.42.0.572462160196.issue26382@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the Python 3.6 change in PyMem_Malloc() required to implement a new complex check on the GIL. Search for "PyMem_Malloc() now fails if the GIL is not held" in my following blog post: https://haypo.github.io/contrib-cpython-2016q1.html Requiring that the GIL is held is a backward incompatible change. I suggest to run your code with PYTHONMALLOC=debug on Python 3.6 ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:18:28 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 14:18:28 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487600308.84.0.480995738928.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: Armin: that's a separate issue, and is expected behaviour. >>> -(0j) # this is -(0+0j) (-0-0j) Yes: 0j is complex(0.0, 0.0); negating negates both the real and imaginary parts. >>> (-0-0j) # but this equals to the difference between 0 and 0+0j 0j This is an operation between an integer (note that the initial negation is a no-op) and a complex. Here the integer gets promoted to complex(0.0, 0.0), and we do complex(0.0, 0.0) - complex(0.0, 0.0), which gives complex(0.0, 0.0). >>> (-0.0-0j) # this is the difference between -0.0 and 0+0j (-0+0j) This is complex(-0.0, 0.0) - complex(0.0, 0.0). The real and imaginary parts are operated on separately, and in keeping with IEEE 754, the real part is evaluated as -0.0 - 0.0, which is -0.0. >>> -0j -0j # <- on CPython 2.7 (-0-0j) # <- on CPython 3.5 The Python 3 behaviour here is correct. The Python 2 behaviour is the result of an unfortunate AST optimization designed to ensure that - is an int rather than a long. None of the above is a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:20:26 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 14:20:26 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487600426.68.0.966524299934.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It's unclear if the signs of the two potential zeroes in a complex number have a meaning Yes, very much so. The signs are important in determining which side of a branch cut to use in the various cmath functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:21:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 14:21:01 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487600461.29.0.268917313693.issue22807@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand well this change. What am I supposed to do with an UUID with safe=False? Should I loop on the function until I get safe==True? "safe for multiprocessing applications" Does it mean unique on the whole system? I looked at uuid_generate_time_safe(3) manual page which mention "synchronization mechanisms (see above)" but they are not documented. http://manpages.ubuntu.com/manpages/zesty/en/man3/uuid_generate.3.html > I'm classifying this as a security issue, (...) This issue was only fixed in Python 3.7. Does it mean that it's no more considered as as security vulnerability? ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:40:36 2017 From: report at bugs.python.org (Armin Rigo) Date: Mon, 20 Feb 2017 14:40:36 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487601636.19.0.751806454665.issue29602@psf.upfronthosting.co.za> Armin Rigo added the comment: Maybe I should be more explicit: what seems strange to me is that some complex numbers have a repr that, when entered in the source, produces a different result. For example, if you want the result ``(-0-0j)`` you have to enter something different. However, I missed the fact that calling explicitly ``complex(a, b)`` with a and b being floats always gives exactly a+bj with the correct signs. So I retract my comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:43:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 14:43:14 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487601794.98.0.554109926583.issue29602@psf.upfronthosting.co.za> STINNER Victor added the comment: IMHO it would be less surprising if repr(complex) would return 'complex(..., ...)': it would be possible to copy/paste and get the result value. I was bitten multiple time by the zero sign with complex numbers... ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 09:47:04 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 14:47:04 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487602024.16.0.659518027303.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: Armin, Victor: please open other issues for these discussions; they're unrelated to the bug reported here. Also, see #27363, #17336, #22548, #25839. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:14:00 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 15:14:00 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1487600461.29.0.268917313693.issue22807@psf.upfronthosting.co.za> Message-ID: <20170220101355.43e6a95d@presto.wooz.org> Barry A. Warsaw added the comment: On Feb 20, 2017, at 02:21 PM, STINNER Victor wrote: >What am I supposed to do with an UUID with safe=False? Should I loop on the >function until I get safe==True? It would be an application dependent response. It might be that you would check some other attributes of your platform (e.g. are the OS packages that should be installed to give you safe UUIDs?). Or your application may not care that much, or your application may refuse to continue to run on platforms without safe UUIDs, or you might use some application-level synchronization methods to guarantee safe UUIDs (e.g. store the unsafe or unknown ones in a database and check that new ones are not already used). The point of this change is that it provides information to the application creating UUIDs that wasn't previously available. >"safe for multiprocessing applications" > >Does it mean unique on the whole system? > >I looked at uuid_generate_time_safe(3) manual page which mention >"synchronization mechanisms (see above)" but they are not documented. >http://manpages.ubuntu.com/manpages/zesty/en/man3/uuid_generate.3.html I believe some systems at least use interprocess communication with a daemon to provide the synchronization. Yes, it would be system-wide. >> I'm classifying this as a security issue, (...) > >This issue was only fixed in Python 3.7. Does it mean that it's no more >considered as as security vulnerability? I should remove that tag. While this could have an impact on application security, it's not a security issue *in Python* itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:14:27 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 15:14:27 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487603667.63.0.440547505212.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- keywords: -security_issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:15:25 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 15:15:25 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487603725.81.0.099547338116.issue22807@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:16:11 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 15:16:11 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487603771.53.0.227558629235.issue22807@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Oh, and because the fix is an API change, I don't believe it should be applied to earlier versions. So I think adding the API in 3.7 is all the fix needed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:45:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Feb 2017 15:45:53 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za> Message-ID: <1487605553.47.0.176568433941.issue22807@psf.upfronthosting.co.za> STINNER Victor added the comment: >>> import uuid >>> u=uuid.uuid4() >>> u.is_safe Can't we consider that UUID4 is always safe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 10:53:06 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Feb 2017 15:53:06 +0000 Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available In-Reply-To: <1487605553.47.0.176568433941.issue22807@psf.upfronthosting.co.za> Message-ID: <20170220105301.75f8ea5d@presto.wooz.org> Barry A. Warsaw added the comment: On Feb 20, 2017, at 03:45 PM, STINNER Victor wrote: >Can't we consider that UUID4 is always safe? It's not a guarantee made by the underlying platform, so I chose to use the default SafeUUID.unknown value there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:31:16 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Feb 2017 16:31:16 +0000 Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback() of _asynciomodule.c In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za> Message-ID: <1487608276.31.0.432426147169.issue28963@psf.upfronthosting.co.za> Yury Selivanov added the comment: I will in a couple of days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:32:42 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Feb 2017 16:32:42 +0000 Subject: [issue29605] platform.architecture() with Python2.7-32 misreports architecture on macOS. In-Reply-To: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> Message-ID: <1487608362.79.0.774507498857.issue29605@psf.upfronthosting.co.za> Ned Deily added the comment: platform.architecture() is documented as giving unreliable results with macOS universal files; see https://docs.python.org/2/library/platform.html#platform.architecture. The difference in behavior between Python 2.7 and 3.x for the example you show is due to the difference in the value of sys.executable between them on macOS. On 2.7, sys.executable points to the actual Python interpreter binary, which is a universal binary. On 3.x, the behavior was changed to not to resolve to the interpreter binary but rather the stub launcher binary and the "-32" launcher has only 32-bit executables: $ /usr/local/bin/python2.7-32 -c 'import sys;print(sys.executable)' /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python $ /usr/local/bin/python3.6-32 -c 'import sys;print(sys.executable)' /usr/local/bin/python3.6-32 Because platform.architecture() uses the "file" utility to examine the contents of the file pointed to by sys.executable, this change in 3.x has the side effect of producing the expected "32bit" value on 3.x when Python is invoked in this manner. However, that doesn't cover all cases. For example: $ arch -i386 /usr/local/bin/python3.6 -c 'import sys,platform;print(platform.architecture(), sys.maxsize > 2**32)' ('64bit', '') False So the 3.x platform.architecture can still produce incorrect results. One can argue about what value(s) platform.architecture() should return for multi-architecture binaries; languishing Issue10735 covers that. One could also argue that the value of sys.executable on 2.7 should be changed to behave like 3.x but it's very late in the life of 2.7 to be making a change like that and that change alone would not produce correct results for all cases, like "arch -i386" above. ---------- assignee: -> lemburg nosy: +lemburg title: Python2.7-32 misreports architecture on macOS. -> platform.architecture() with Python2.7-32 misreports architecture on macOS. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:32:47 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Feb 2017 16:32:47 +0000 Subject: [issue10735] platform.architecture() gives misleading results for OS X multi-architecture executables In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za> Message-ID: <1487608367.9.0.969464334002.issue10735@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: ronaldoussoren -> lemburg versions: +Python 3.6, Python 3.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:49:02 2017 From: report at bugs.python.org (ecbftw) Date: Mon, 20 Feb 2017 16:49:02 +0000 Subject: [issue29606] urllib FTP protocol stream injection Message-ID: <1487609342.46.0.653185585548.issue29606@psf.upfronthosting.co.za> New submission from ecbftw: Please see: http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html This was reported to security at python dot org, but as far as I can tell, they sat on it for a year. I don't think there is a proper way to encode newlines in CWD commands, according the FTP RFC. If that is the case, then I suggest throwing an exception on any URLs that contain one of '\r\n\0' or any other characters that the FTP protocol simply can't support. ---------- messages: 288219 nosy: ecbftw priority: normal severity: normal status: open title: urllib FTP protocol stream injection type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:57:23 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 20 Feb 2017 16:57:23 +0000 Subject: [issue29605] platform.architecture() with Python2.7-32 misreports architecture on macOS. In-Reply-To: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> Message-ID: <1487609843.64.0.919406673968.issue29605@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks for the report, but there really isn't much we can do, since the API is not geared up for handling executables which contain binaries for multiple architectures. AFAIK, the Python 3 binaries available from python.org are no longer built as universal binaries, so the problem doesn't show with those. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 12:10:22 2017 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 20 Feb 2017 17:10:22 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487610622.75.0.856244545957.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for spelling it out for me, that's helpful. But I'm still confused about a couple of things: I can't find classify_argument in the Python source tree other than in Modules/_ctypes/libffi_osx/x86/x86-ffi64.c Is that the file you referred to as ffi64.c? I assumed this is only used on OS X. Do we just use the system libffi on Linux? I also note that if I use the following: typedef struct { int foo; int bar; unsigned char data[8]; } Test; which is certainly the same size of struct, there's no abort and the sum is correctly calculated and returned as 28, which is printed by the Python script. If I swap things around so that the array comes first in the structure, that also works. If I increase the array size back to 16 (giving a total structure size of 24), that also works. If I then comment out the 'int foo' and 'int bar' fields in both C and Python, the abort reappears. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 12:48:35 2017 From: report at bugs.python.org (John W.) Date: Mon, 20 Feb 2017 17:48:35 +0000 Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in two same calls In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za> Message-ID: <1487612915.35.0.30401745685.issue26752@psf.upfronthosting.co.za> John W. added the comment: This got a little discussion over at http://lists.idyll.org/pipermail/testing-in-python/2017-February/007012.html The current evidence seem to indicate this is indeed a bug in the implementation of assert_has_calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 13:00:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 18:00:10 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487613610.29.0.962278423999.issue29602@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch fixes constructing complex from complex. But in future versions perhaps it is worth to disallow passing complex argument to two-arguments complex constructor. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file46653/complex-constructor-from-complex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 13:07:30 2017 From: report at bugs.python.org (Armin Rigo) Date: Mon, 20 Feb 2017 18:07:30 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487614050.16.0.204719418711.issue29602@psf.upfronthosting.co.za> Armin Rigo added the comment: 4 lines before the new "ci.real = cr.imag;", we have "cr.imag = 0.0; /* Shut up compiler warning */". The comment is now wrong: we really need to set cr.imag to 0.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 13:18:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 18:18:14 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487614694.86.0.712594367451.issue29602@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file46654/complex-constructor-from-complex2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 13:34:30 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Feb 2017 18:34:30 +0000 Subject: [issue29605] platform.architecture() with Python2.7-32 misreports architecture on macOS. In-Reply-To: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> Message-ID: <1487615670.55.0.902942239879.issue29605@psf.upfronthosting.co.za> Ned Deily added the comment: > AFAIK, the Python 3 binaries available from python.org are no longer built as universal binaries, so the problem doesn't show with those. All python.org Mac binaries are built as universal. For example: $ file /usr/local/bin/python3.6 /usr/local/bin/python3.6: Mach-O universal binary with 2 architectures: [i386: Mach-O executable i386] [x86_64: Mach-O 64-bit executable x86_64] /usr/local/bin/python3.6 (for architecture i386): Mach-O executable i386 /usr/local/bin/python3.6 (for architecture x86_64): Mach-O 64-bit executable x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:00:09 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 20 Feb 2017 19:00:09 +0000 Subject: [issue29605] platform.architecture() with Python2.7-32 misreports architecture on macOS. In-Reply-To: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> Message-ID: <1487617209.41.0.00793462989589.issue29605@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Ok, thanks for the clarification. So if I understand correctly, the main change in Python 3 is that points to the stub launcher, not the binary itself. In any case, a new function would have to be added to the platform module to query multiple architectures available in a binary and probably another one to return the architecture that Python runs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:17:13 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 20 Feb 2017 19:17:13 +0000 Subject: [issue10735] platform.architecture() gives misleading results for OS X multi-architecture executables In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za> Message-ID: <1487618233.04.0.564227180292.issue10735@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think there's a misunderstanding in what platform.architecture() is meant for. The purpose is to find out more details about the executable you pass to it, e.g. whether it's a 32-bit or 64-bit binary, or whether it's an ELF or PE binary. And it's a best effort API, just as most other platform APIs - this is also the reason why most of them have parameters available to modify the default return values. It doesn't work with multi-architecture executables. We'd need a new API for this. Regarding returning multiple architectures in the linkage return value: I'm not sure whether that's a good idea. The architectures are not necessarily of different linkage types. In fact on Macs, the correct values is "Mach-O". The API should probably return this instead of the default empty string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:21:51 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 20 Feb 2017 19:21:51 +0000 Subject: [issue10735] platform.architecture() gives misleading results for OS X multi-architecture executables In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za> Message-ID: <1487618511.92.0.766163371463.issue10735@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The term "linkage" is probably a misnomer... "execformat" would be more correct: * https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats Too late to change, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:27:22 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 19:27:22 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487618842.21.0.604646584118.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: complex-constructor-from-complex2.patch looks good to me. What happens now? I presume we can no longer push to hg.python.org? So one of us needs to make a PR on GitHub and another review it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:50:39 2017 From: report at bugs.python.org (Matthieu Dartiailh) Date: Mon, 20 Feb 2017 19:50:39 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX Message-ID: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> New submission from Matthieu Dartiailh: The computation of the stack_effect of the CALL_FUNCTION_EX does not reflect the use of the argument to the opcode. Currently stack_effect expect two flags (one on 0x01 and one on 0x02) corresponding to whether positional arguments and keyword arguments are being passed. However in the current implementation the argument of CALL_FUNCTION_EX is either 0 or 1 depending on the presence of keyword arguments. According to Serhiy Storchaka, the behavior of stack_effect is a left-over of the previous implementation and should be fixed. ---------- components: Interpreter Core messages: 288230 nosy: mdartiailh priority: normal severity: normal status: open title: Broken stack_effect for CALL_FUNCTION_EX type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:54:18 2017 From: report at bugs.python.org (Matthieu Dartiailh) Date: Mon, 20 Feb 2017 19:54:18 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487620458.84.0.868284938569.issue29607@psf.upfronthosting.co.za> Changes by Matthieu Dartiailh : ---------- pull_requests: +168 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:54:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 19:54:36 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487620476.97.0.449293388263.issue29602@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I pushed changes to my fork but when try to create a pull request it contains unrelated changes. Seems I do something wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:03:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 20:03:06 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487620986.78.0.175398282814.issue29607@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The fix LGTM. Please add the Misc/NEWS entry. ---------- assignee: -> serhiy.storchaka nosy: +Demur Rumed, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:09:23 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 20:09:23 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487621363.95.0.243845595895.issue29602@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- pull_requests: +169 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:10:23 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 20:10:23 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487621423.47.0.219149063134.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: Created https://github.com/python/cpython/pull/203, but I feel bad for having my name on the commits. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:12:38 2017 From: report at bugs.python.org (Lisa Roach) Date: Mon, 20 Feb 2017 20:12:38 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487621558.01.0.944272096545.issue29549@psf.upfronthosting.co.za> Lisa Roach added the comment: I tried to have a go at making the str.index Argument Clinic compatible, Serhiy can you take a look at my commits and let me know if this is the correct way of doing it: https://github.com/python/cpython/compare/master...lisroach:master If it looks good I will make a pull request. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:24:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 20:24:18 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487622258.43.0.210926552568.issue29549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No need to add Argument Clinic code. Just make docstrings in the style of of Argument Clinic descriptions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:28:17 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 20:28:17 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487622497.97.0.219345730235.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset 112ec38c15b388fe025ccb85369a584d218b1160 by GitHub in branch 'master': bpo-29602: fix signed zero handling in complex constructor. (#203) https://github.com/python/cpython/commit/112ec38c15b388fe025ccb85369a584d218b1160 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:34:17 2017 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 20 Feb 2017 20:34:17 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487622857.02.0.601242130276.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Possibly also relevant: #16575 and https://github.com/libffi/libffi/issues/33 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:35:01 2017 From: report at bugs.python.org (Shyam Sunder) Date: Mon, 20 Feb 2017 20:35:01 +0000 Subject: [issue29608] pip_gui Message-ID: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> New submission from Shyam Sunder: I am not able see the text of the radio button clearly in the welcome page of search and install packages ---------- components: Tkinter files: Screenshot (70).png messages: 288238 nosy: Shyam Sunder, dstufft, lorenzogotuned, ncoghlan, ned.deily, r.david.murray, rhettinger, terry.reedy, upendra-k14 priority: normal pull_requests: 170 severity: normal status: open title: pip_gui type: performance versions: Python 2.7 Added file: http://bugs.python.org/file46655/Screenshot (70).png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:48:21 2017 From: report at bugs.python.org (Eryk Sun) Date: Mon, 20 Feb 2017 20:48:21 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487623701.81.0.478183543078.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: classify_argument is in Modules/_ctypes/libffi/src/x86/ffi64.c. This file is for the 64-bit Unix ABI. libffi doesn't use it for 64-bit Windows. Some (all?) Linux distros link ctypes to the system libffi. In my experience, building 3.6 on Linux defaults to the system libffi, and I don't personally know how to override this. Configuring "--without-system-ffi" seems to be ignored. Regarding your Test struct example, it's ok in this particular case to classify an 8-byte integer array the same as an 8-byte pointer. It doesn't abort() because the 2nd word isn't left unclassified (i.e. X86_64_NO_CLASS). import ctypes class Test(ctypes.Structure): _fields_ = (('foo', ctypes.c_int), ('bar', ctypes.c_int), ('data', ctypes.c_uint8 * 8)) @ctypes.CFUNCTYPE(None, Test) def func(t): print('foo:', t.foo) print('bar:', t.bar) print('data:', t.data[:]) t = Test(5, 10, tuple(range(8))) >>> hex(id(Test)) '0x9d8ad8' The ctypes Structure has 3 elements. The first two are ffi_type_sint32 (FFI_TYPE_SINT32 == 10), and the third is ffi_type_pointer (FFI_TYPE_POINTER == 14): (gdb) set $dict = (StgDictObject *)(((PyTypeObject *)0x9d8ad8)->tp_dict) (gdb) p *$dict->ffi_type_pointer->elements[0] $1 = {size = 4, alignment = 4, type = 10, elements = 0x0} (gdb) p *$dict->ffi_type_pointer->elements[1] $2 = {size = 4, alignment = 4, type = 10, elements = 0x0} (gdb) p *$dict->ffi_type_pointer->elements[2] $3 = {size = 8, alignment = 8, type = 14, elements = 0x0} (gdb) p $dict->ffi_type_pointer->elements[3] $4 = (struct _ffi_type *) 0x0 classify_argument() recursively classifies and merges these elements. The first two get merged as X86_64_INTEGER_CLASS, and the 'pointer' (actually an array) is X86_64_INTEGER_CLASS. >>> func(t) Breakpoint 1, ffi_call (cif=cif at entry=0x7fffffffd570, fn=fn at entry=0x7ffff7fee010, rvalue=rvalue at entry=0x7fffffffd630, avalue=avalue at entry=0x7fffffffd610) at ../src/x86/ffi64.c:424 [...snip...] 458 for (i = 0; i < avn; ++i) (gdb) 462 n = examine_argument (arg_types[i], classes, 0, &ngpr, &nsse); (gdb) 463 if (n == 0 (gdb) p n $6 = 2 (gdb) p ngpr $7 = 2 (gdb) p classes[0] $8 = X86_64_INTEGER_CLASS (gdb) p classes[1] $9 = X86_64_INTEGER_CLASS The struct is passed in two general-purpose integer registers, rdi and rsi: Breakpoint 2, ffi_call_unix64 () at ../src/x86/unix64.S:49 49 movq (%rsp), %r10 /* Load return address. */ [...snip...] 76 call *%r11 (gdb) p/x $rdi $10 = 0xa00000005 (gdb) p/x $rsi $11 = 0x706050403020100 (gdb) c Continuing. foo: 5 bar: 10 data: [0, 1, 2, 3, 4, 5, 6, 7] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:49:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 20:49:33 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487623773.57.0.98934926561.issue29602@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +171 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:57:57 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 20:57:57 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487624277.47.0.865000870927.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset 4ddd89780fdb823f427c743ea7326a3c958a2f4b by Mark Dickinson in branch 'bpo-29549-backport': bpo-29602: fix signed zero handling in complex constructor https://github.com/python/cpython/commit/4ddd89780fdb823f427c743ea7326a3c958a2f4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:59:58 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 20:59:58 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487624398.09.0.200534681811.issue29549@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- pull_requests: +172 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:04:01 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:04:01 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487624641.28.0.0892219885274.issue29602@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- pull_requests: +173 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:05:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Feb 2017 21:05:33 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487624733.35.0.0442981224915.issue29602@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: -171 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:08:37 2017 From: report at bugs.python.org (Eryk Sun) Date: Mon, 20 Feb 2017 21:08:37 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487624917.81.0.406417319411.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: I see now why you couldn't find ffi64.c. I've been using a 3.6 worktree. The libffi sources have been removed from master. For the union and bitfield problem, also see the crash reported in #26628. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:12:49 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:12:49 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487625169.21.0.177106051788.issue29602@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- pull_requests: +174 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:13:25 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:13:25 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487625205.59.0.655577214693.issue29602@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- pull_requests: +175 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:14:55 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:14:55 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487625295.07.0.598403708626.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset c0b336e0ada74b1242b9ef10c19eb87b0a21d106 by GitHub in branch '2.7': bpo-29602: fix signed zero handling in complex constructor (#204) https://github.com/python/cpython/commit/c0b336e0ada74b1242b9ef10c19eb87b0a21d106 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:21:58 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Mon, 20 Feb 2017 21:21:58 +0000 Subject: [issue8525] Display exception's subclasses in help() In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za> Message-ID: <1487625718.3.0.586611438089.issue8525@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Hi, It seems that it hasn't been worked upon from quite a long time and the patch would also need changes. May I work on this? ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:36:07 2017 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 20 Feb 2017 21:36:07 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487626567.43.0.305795146185.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm learning a bit about Linux calling conventions :-) But it also works when a 16-byte array is followed by 2 ints; if the two ints are removed, then it fails again. ctypes sets elements up in the first case to be a FFI_TYPE_POINTER slot followed by two slots of FFI_TYPE_SINT32, and classify_argument seemingly does the right thing. But remove the two integers, and classify_argument seems to not do the right thing. Isn't this looking like a problem in classify_argument? In the first case: p *stgdict->ffi_type_pointer.elements[0] $3 = {size = 8, alignment = 8, type = 14, elements = 0x0} p *stgdict->ffi_type_pointer.elements[1] $4 = {size = 4, alignment = 4, type = 10, elements = 0x0} p *stgdict->ffi_type_pointer.elements[2] $5 = {size = 4, alignment = 4, type = 10, elements = 0x0} p stgdict->ffi_type_pointer.elements[3] $6 = (struct _ffi_type *) 0x0 and the second case: p *stgdict->ffi_type_pointer.elements[0] $2 = {size = 8, alignment = 8, type = 14, elements = 0x0} p stgdict->ffi_type_pointer.elements[1] $3 = (struct _ffi_type *) 0x0 It's like this on the way into ffi_call (can't step into it at the moment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:50:51 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:50:51 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487627451.8.0.635522759167.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset 0936a00fe035e3e52c30bcbc59668dc0f519ced6 by GitHub in branch '3.5': bpo-29602: fix signed zero handling in complex constructor. (#203) (#205) https://github.com/python/cpython/commit/0936a00fe035e3e52c30bcbc59668dc0f519ced6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 16:59:32 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 21:59:32 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487627972.25.0.355789287582.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: New changeset d9b3cdd137239a5913de2252c3ce269e35ac63d2 by GitHub in branch '3.6': bpo-29602: fix signed zero handling in complex constructor. (#203) (#206) https://github.com/python/cpython/commit/d9b3cdd137239a5913de2252c3ce269e35ac63d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:04:35 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Feb 2017 22:04:35 +0000 Subject: [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part In-Reply-To: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> Message-ID: <1487628275.31.0.138480136251.issue29602@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm a bit puzzled about where the commit 4ddd89780fdb823f427c743ea7326a3c958a2f4b came from, but as far as I can tell the changes to 2.7, 3.5, 3.6 and master are all okay. All fixed. Thanks for the report! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:26:19 2017 From: report at bugs.python.org (Carol Willing) Date: Mon, 20 Feb 2017 22:26:19 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487629579.71.0.626359939217.issue29355@psf.upfronthosting.co.za> Carol Willing added the comment: Another report of sqlite3 not compiling correctly on RHEL6 (https://github.com/jupyterhub/jupyterhub/issues/991). Is there currently a solution to build Python 3.6 with sqlite3 support? ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:54:45 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Feb 2017 22:54:45 +0000 Subject: [issue29608] pip_gui In-Reply-To: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> Message-ID: <1487631285.14.0.987108673265.issue29608@psf.upfronthosting.co.za> Berker Peksag added the comment: pip_gui is not part of the Python standard library. Please use https://github.com/upendra-k14/pip_gui/issues to report your problem. ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:55:03 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Feb 2017 22:55:03 +0000 Subject: [issue29608] pip_gui In-Reply-To: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> Message-ID: <1487631303.07.0.779847459476.issue29608@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- type: performance -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:55:12 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Feb 2017 22:55:12 +0000 Subject: [issue29608] pip_gui In-Reply-To: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> Message-ID: <1487631312.26.0.557027616601.issue29608@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 17:57:44 2017 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 20 Feb 2017 22:57:44 +0000 Subject: [issue29608] pip_gui In-Reply-To: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> Message-ID: <1487631464.33.0.773483550703.issue29608@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- pull_requests: -170 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 18:28:52 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 20 Feb 2017 23:28:52 +0000 Subject: [issue29592] abs_paths() in site.py is slow In-Reply-To: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> Message-ID: <1487633332.08.0.784359773233.issue29592@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 18:28:55 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 20 Feb 2017 23:28:55 +0000 Subject: [issue29585] site.py imports relatively large `sysconfig` module. In-Reply-To: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> Message-ID: <1487633335.12.0.924676348527.issue29585@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 19:46:41 2017 From: report at bugs.python.org (pyguy) Date: Tue, 21 Feb 2017 00:46:41 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X Message-ID: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> New submission from pyguy: When I use the subprocess module to run a another process, I expect to be able to read the STDOUT and STDERR of the other process. This is not possible on Mac OS X. The attached test program has been tested on Linux and Windows and does work as expected. It pauses at the process.stdout.readline() line of code every time on Mac OS X. ---------- components: macOS files: testwrapper.py messages: 288250 nosy: ned.deily, pyguy, ronaldoussoren priority: normal severity: normal status: open title: Receiving messages from subprocess does not work on Mac OS X type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file46656/testwrapper.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 19:55:35 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Feb 2017 00:55:35 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487638535.35.0.071974458124.issue29609@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, your program works for me on macOS 10.12.3 with the current python.org 2.7.13, the Apple-supplied system Python 2.7.10, and, with adding a decode to the readline, with 3.6.0. ---------- resolution: -> works for me status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 20:05:20 2017 From: report at bugs.python.org (pyguy) Date: Tue, 21 Feb 2017 01:05:20 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487639120.69.0.83289562359.issue29609@psf.upfronthosting.co.za> pyguy added the comment: The program failed for me on Mac OS 10.4.11 using Python 2.7.12 and Mac OS 10.6.8 using Python 2.7.13. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 20:42:28 2017 From: report at bugs.python.org (Davin Potts) Date: Tue, 21 Feb 2017 01:42:28 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic In-Reply-To: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> Message-ID: <1487641348.84.0.844683633239.issue29575@psf.upfronthosting.co.za> Davin Potts added the comment: When passing judgement on what is "too basic", the initial example should be so basic as to be immediately digestible by as many people as possible. Some background: All too many examples mislead newcomers into believing that the number of processes should (a) match the number of processor cores, or (b) match the number of inputs to be processed. This example currently attempts to dispel both notions. In practice, and this depends upon what specific code is to be performed in parallel, it is not uncommon to find that slightly over-scheduling the number of processes versus the number of available cores can achieve superior throughput and performance. In other cases, slightly under-scheduling may provide a win. To help subtly encourage the newcomer, this example uses 5 processes as opposed to something which might be mistaken for a common number of cores available on current multi-core processors. Likewise, the number of distinct inputs to be processed deliberately does not match the number of processes nor a multiple of the number of processes. This hopefully encourages the newcomer to not feel obligated to only accept inputs of a particular size or multiple. Granted, optimizing for performance motivates tuning such things but this is the first example / first glance at what functionality is available. Considering the suggested change: * range(20) will likely produce more output than can be comfortably accommodated and easily read in the available browser window where most will see this * the addition of execution time measurement is an interesting choice here given how computationally trivial the f(x) function is, which is perhaps what motivated the introduction of a time.sleep(1) inside that function; a ThreadPool would be more appropriate for a sleepy function such as this Ultimately these changes complicate the example while potentially undermining its value. An interesting improvement to this example might be to introduce a computationally taxing function which more clearly demonstrates the benefit of using a process Pool but still achieving the ideal of being immediately digestible and understood by the largest reading audience. Some of the topics/variations in the proposed change might be better introduced and addressed later in the documentation rather than unnecessarily complicating the first example. ---------- resolution: -> works for me stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 20:52:15 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Feb 2017 01:52:15 +0000 Subject: [issue28879] smtplib send_message should add Date header if it is missing, per RFC5322 In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za> Message-ID: <1487641935.64.0.0224191547499.issue28879@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 21:06:51 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Feb 2017 02:06:51 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487642811.91.0.105962059388.issue29609@psf.upfronthosting.co.za> Ned Deily added the comment: There certainly could be differences in behavior considering how old 10.6.8 and 10.4.11 are. I'm not a subprocess expert but it seems to me that, if your program hangs doing a readline from process.stdout, chances are you are running into a pipe buffer deadlock as warned about in the subprocess module documentation: "Warning - Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process." https://docs.python.org/dev/library/subprocess.html#popen-objects ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:05:42 2017 From: report at bugs.python.org (Kevin Shweh) Date: Tue, 21 Feb 2017 03:05:42 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487646342.27.0.610273949445.issue29581@psf.upfronthosting.co.za> Kevin Shweh added the comment: Doesn't that ignore_extra_args thing prevent InitX.__init_subclass__ from receiving the x argument it wanted? It doesn't seem like a solution. ---------- nosy: +Kevin Shweh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:19:17 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 03:19:17 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487647157.04.0.147072585854.issue27660@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It was a little mind-numbing to check this code, but it looks correct. Please fix two nits for better readability. For review purposes, it was nice to have changes stand-out, but for the final code I would like to combine the two comments and the two new_allocated assignments into a single comment and single assignment: /* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ... Note: new_allocated won't overflow because the largest possible value is PY_SSIZE_T_MAX * (9 / 8) + 6 which always fits in a size_t. */ new_allocated = (size_t)newsize + (newsize >> 3) + (newsize < 9 ? 3 : 6); Secondly, please rename the "size" variable to something like "num_allocated_bytes". It is confusing to have "newsize" mean the number of elements actually used while having "size" mean the number of bytes actually allocated (including the overallocation). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:20:14 2017 From: report at bugs.python.org (pyguy) Date: Tue, 21 Feb 2017 03:20:14 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487647214.72.0.523962286263.issue29609@psf.upfronthosting.co.za> pyguy added the comment: Using communicate fixed the problem. Here is the program that works for me on Mac OS 10.4.11 with Python 2.7.12: import subprocess import time print("Launch started") program_name = "top" list = [program_name] process = subprocess.Popen(list) while process.poll() == None: print("subprocess still running") print("Value = " + process.communicate()) time.sleep(0.1) print("Exit") Thank you Ned. ---------- resolution: works for me -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:25:47 2017 From: report at bugs.python.org (Ma Lin) Date: Tue, 21 Feb 2017 03:25:47 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487647547.5.0.789658472141.issue29355@psf.upfronthosting.co.za> Ma Lin added the comment: > Is there currently a solution to build Python 3.6 with sqlite3 support? I installed SQLite 3.16.2 on a Debian-based system with this way: http://stackoverflow.com/questions/26261080 No idea whether it will work on RHEL 6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:29:07 2017 From: report at bugs.python.org (Phus Lu) Date: Tue, 21 Feb 2017 03:29:07 +0000 Subject: [issue29610] ssl do_handshake fails on https-proxy (aka. https over https-proxy) Message-ID: <1487647747.15.0.370290912125.issue29610@psf.upfronthosting.co.za> New submission from Phus Lu: Background: I'm working on adding https-proxy[1] support to python-requests https://github.com/phuslu/requests_httpsproxy Issue: ssl module(python 2.7) counld establish ssl handshakes over a https-proxy Reproduce Steps: I setup a https-proxy in bwg.phus.lu:443 >>> import socket,ssl >>> sock = ssl.wrap_socket(socket.create_connection(('bwg.phus.lu', 443))) >>> sock.sendall('CONNECT httpbin.org:443 HTTP/1.0\r\n\r\n') 36 >>> sock.recv() 'HTTP/1.1 200 OK\r\n\r\n' >>> ssl.wrap_socket(sock) Traceback (most recent call last): File "", line 1, in ssl.wrap_socket(sock) File "/usr/lib/python2.7/ssl.py", line 943, in wrap_socket ciphers=ciphers) File "/usr/lib/python2.7/ssl.py", line 611, in __init__ self.do_handshake() File "/usr/lib/python2.7/ssl.py", line 840, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: UNKNOWN_ALERT_TYPE] unknown alert type (_ssl.c:661) [1] https://www.chromium.org/developers/design-documents/secure-web-proxy ---------- messages: 288259 nosy: Phus Lu priority: normal severity: normal status: open title: ssl do_handshake fails on https-proxy (aka. https over https-proxy) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:36:39 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 21 Feb 2017 03:36:39 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487648199.33.0.333974773646.issue27660@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your time Raymond. :-) I applied your suggestions in the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:56:52 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 03:56:52 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487649412.47.0.983080265918.issue29603@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I'm sure that exposing the number of unfinished tasks > (unfinished_tasks class variable) can be very useful in many situations Sorry, but I don't share your certainty of the usefulness of this method. Since the task_done/join API was added many years ago, I've not seen any use cases arise where we needed to quantify the number of unfinished tasks. Have you seen an actual need in real code or is this PR more of an intuitive guess that the extra method might be useful? In the examples of task_done/join that I've seen, the number of unfinished tasks is typically in the range: qsize() plus between zero and the number of parallel consumers. Where the actual value it falls this range doesn't seem very useful. One the queue is empty, join() just waits to the parallel consumers to complete their one final task that is already under way. Also, I'm reluctant to expand the API for several reasons. Keeping it small makes it more intelligible (giving users additional options for things theh rarely need makes it more difficult to make correct decisions in the common cases). Also, it would be nice to avoid a ripple effect into the other APIs such as multiprocessing which are supersets of this API. And lastly, I'm disinclined to have another informational method like empty, full, and qsize which have to be documented as potentially introducing unexpected race conditions in user code (all three methods return information that may be completely out-of-date or wrong by the time the caller sees the result). ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:03:54 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Feb 2017 04:03:54 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487649834.95.0.517970677779.issue29609@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: fixed -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:07:46 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 04:07:46 +0000 Subject: [issue10701] Error pickling objects with mutating __getstate__ In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1487650066.92.0.378928809158.issue10701@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I agree with Antoine that, "As the name suggests, __getstate__ should probably not mutate anything." Unless a problematic non-mutating example can be found, I suggest this be closed. For the most part, our rule has been that pure python code doesn't have to (and possibly cannot) defend itself against mid-stream mutation, while C code only has to defend itself to the point of avoiding a segfault. IMO, "RuntimeError: dictionary changed size during iteration" is an informative error message in this case. ---------- nosy: +rhettinger status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:10:48 2017 From: report at bugs.python.org (pyguy) Date: Tue, 21 Feb 2017 04:10:48 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487650248.97.0.335604428124.issue29609@psf.upfronthosting.co.za> pyguy added the comment: The program does not work the way I wanted it to. I want the output of the top command to be seen only by the python program. The program I made causes the top command to print its output to the terminal. Using subprocess.Popen() with stdout=subprocess.PIPE does prevent the top command's output from being printed to the terminal. Now I need a way to actually work with that output. Would you know a way to do this? I can't use the communicate() function because it blocks until the top command quits. ---------- resolution: not a bug -> works for me status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:18:38 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 04:18:38 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487650718.67.0.87517807893.issue27660@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Mariatta, would you like to run this against the test suite and then apply it. I don't think a MISC/NEWS entry is needed (it is just a code simplification) and Xiang is already in MISC/ACKS. ---------- assignee: rhettinger -> Mariatta nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:26:46 2017 From: report at bugs.python.org (Phus Lu) Date: Tue, 21 Feb 2017 04:26:46 +0000 Subject: [issue29610] ssl do_handshake fails on https-proxy (aka. https over https-proxy) In-Reply-To: <1487647747.15.0.370290912125.issue29610@psf.upfronthosting.co.za> Message-ID: <1487651206.89.0.787721168947.issue29610@psf.upfronthosting.co.za> Changes by Phus Lu : ---------- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:29:41 2017 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Feb 2017 04:29:41 +0000 Subject: [issue29394] Cannot tunnel TLS connection through TLS connection In-Reply-To: <1485847183.69.0.499542154053.issue29394@psf.upfronthosting.co.za> Message-ID: <1487651381.15.0.279232604079.issue29394@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> needs patch versions: +Python 2.7, Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:30:22 2017 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Feb 2017 04:30:22 +0000 Subject: [issue29610] ssl do_handshake fails on https-proxy (aka. https over https-proxy) In-Reply-To: <1487647747.15.0.370290912125.issue29610@psf.upfronthosting.co.za> Message-ID: <1487651422.86.0.405068537651.issue29610@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like you are trying to tunnel one SSL or TLS connection through another SSL/TLS connection (instead of through a plain OS socket). There is already a bug recently opened about this: Issue 29394. Basically, the SSL module doesn?t support this, and the documentation should be clarified to say something like wrap_socket() only accepts basic socket.socket() objects, not subclasses. However, in Python 3.5+ I think you could use the BIO layer to hook in your intermediate SSL socket (or any other transport). ---------- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Cannot tunnel TLS connection through TLS connection _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 23:53:41 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 21 Feb 2017 04:53:41 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487652821.43.0.408680636807.issue27660@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry, I have the commit bit and know what to do with a commit. So I assign it to myself and wait someone approve the PR on GitHub. ---------- assignee: Mariatta -> xiang.zhang stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:26:36 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 05:26:36 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487654796.09.0.797447856521.issue29554@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:30:02 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 05:30:02 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487655002.91.0.848386374193.issue29554@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 8fb1f6e039cbdeb333d83b7a62f0f37af4ce6e02 by Berker Peksag in branch 'master': bpo-29554: Improve docs for pstat module and profile. (#88) https://github.com/python/cpython/commit/8fb1f6e039cbdeb333d83b7a62f0f37af4ce6e02 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:34:18 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 05:34:18 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487655258.59.0.272233133985.issue27660@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay, go ahead. I was hoping to give Mariatta some practice applying C patches (she's new). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:41:22 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 05:41:22 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487655682.91.0.428615181818.issue29603@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Raymond. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:53:55 2017 From: report at bugs.python.org (Saida Dhanavath) Date: Tue, 21 Feb 2017 05:53:55 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487656435.62.0.158045975688.issue29347@psf.upfronthosting.co.za> Saida Dhanavath added the comment: Hi Xiang, Sorry for the delay. I have not checked my inbox since last week. The proposed fix works for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 00:54:59 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 21 Feb 2017 05:54:59 +0000 Subject: [issue29347] Python could crash while creating weakref for a given object In-Reply-To: <1485141841.25.0.0993319189306.issue29347@psf.upfronthosting.co.za> Message-ID: <1487656499.47.0.717602952354.issue29347@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your confirmation Saida! :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:07:49 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 06:07:49 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487657269.11.0.565735818718.issue11572@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +176 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:08:51 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 06:08:51 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487657331.53.0.886655673091.issue11572@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:20:26 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 06:20:26 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487658026.04.0.905643933315.issue29453@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 32e8f9bdfd4324f1aa4fbbdf1ed8536f2b00cabb by Mariatta in branch 'master': bpo-29453: Remove reference to undefined dictionary ordering in Tutorial (GH-140) https://github.com/python/cpython/commit/32e8f9bdfd4324f1aa4fbbdf1ed8536f2b00cabb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:25:03 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 06:25:03 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487658303.39.0.261444598342.issue29453@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +177 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:25:22 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 06:25:22 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487658322.65.0.484166964591.issue29532@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +178 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 01:33:05 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 06:33:05 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1487658785.22.0.889316681571.issue10938@psf.upfronthosting.co.za> Berker Peksag added the comment: I agree with Jim's review comment at https://github.com/python/cpython/pull/155#pullrequestreview-22646534 Those links will quickly get outdated and I'm sure that we will get reports like "this link doesn't work for my $PLATFORM $PLATFORM_VERSION". I suggest to close this as 'rejected'. ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 02:18:36 2017 From: report at bugs.python.org (Joachim) Date: Tue, 21 Feb 2017 07:18:36 +0000 Subject: [issue29575] your closing of issue29575 In-Reply-To: <1487641348.84.0.844683633239.issue29575@psf.upfronthosting.co.za> Message-ID: <5a9b5aea-422e-db0e-2bfb-eaa4ab360358@fz-juelich.de> Joachim added the comment: Dear Davin, since I am new to the Python bug tracker, I have to asked a stupid question: are you the benevolent dictator of the Python Standard Library? Otherwise, how can it be that one and the same person in one and the same intervention adds new arguments to the debate, conclude that theses arguments are winning, declares that the current state ?works for me?, and closes the issue, thereby cutting short any further debate? I have several other issues with the current Python documentation, but if defenders of the status quo are acting that boldly, I would only waste my time to raise them. With best regards, Joachim ---------- title: doc 17.2.1: basic Pool example is too basic -> your closing of issue29575 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 02:33:48 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 07:33:48 +0000 Subject: [issue29609] Receiving messages from subprocess does not work on Mac OS X In-Reply-To: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> Message-ID: <1487662428.24.0.484461356407.issue29609@psf.upfronthosting.co.za> Berker Peksag added the comment: Please use Stack Overflow or python-list for usage questions (and please do not reopen this issue again) ---------- nosy: +berker.peksag resolution: works for me -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 02:39:39 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 07:39:39 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487662779.06.0.334473307261.issue28814@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 02:54:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 07:54:34 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487663674.1.0.920642635958.issue29165@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +179 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 03:07:10 2017 From: report at bugs.python.org (irdb) Date: Tue, 21 Feb 2017 08:07:10 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1487664430.05.0.830640101892.issue14551@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 03:14:14 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 08:14:14 +0000 Subject: [issue29575] your closing of issue29575 In-Reply-To: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> Message-ID: <1487664854.03.0.294028845685.issue29575@psf.upfronthosting.co.za> INADA Naoki added the comment: I like current, minimum example to describe API. No need to make it complex only for checking it's really executed in parallel. Adding more and more "may be useful for someone" code in the doc make the document long, hard and tedious to read for everyone. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 03:25:26 2017 From: report at bugs.python.org (slytomcat) Date: Tue, 21 Feb 2017 08:25:26 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487665526.55.0.187648411778.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: Raymond, Serhiy, thanks for your opinions. I agree that this method like empty, full, and qsize returns information that may be out-of-date in time of its usage. But like those empty, full, and qsize it provides information that helps to make some decisions. What I disagree that this information can be correctly estimated based on qsize and number of parallel consumers as there is no information what exactly consumers do at the moment. Such estimation will be absolutely useless for a decision making. In the example (see https://github.com/slytomcat/cpython/commit/ea313986d86c083e81624fbc8a7ab6a75784e15d) we need to estimate the number of unfinished tasks and comparing it to the number of active threads we can decide: should we create a new thread or not. There is no reason to wait until all tasks done (via join) we need to make decision in working conditions. Actually I've implemented this solution (Queue.unfinished + modified concurrent.futures.ThreadPoolExecutor) in my project (see https://github.com/slytomcat/yandex-disk-client) and it works perfectly: the number of working threads is increasing only on massive flow of tasks, while weak flow of tasks keeps low number of working threads. And even when Queue.unfinished gives wrong (outdated) information, it can lead to creation one new thread that is not really required at the moment. That is not a big mistake, I suppose (comparing to creation all N threads during placing first N tasks in queue without considering the volume of concurrent tasks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 03:44:58 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 08:44:58 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1487666698.61.0.329682854189.issue24340@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:04:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 09:04:53 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic In-Reply-To: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> Message-ID: <1487667893.83.0.347164365226.issue29575@psf.upfronthosting.co.za> Berker Peksag added the comment: I agree with and Davin and Inada. Note that multiprocessing documentation is already too long and we'd like to be careful before adding another example. If you could create a "multiprocessing cookbook" on wiki.python.org I'm pretty sure we'd be happy to consider adding a link to it in the documentation. ---------- nosy: +berker.peksag title: your closing of issue29575 -> doc 17.2.1: basic Pool example is too basic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:11:39 2017 From: report at bugs.python.org (Joachim) Date: Tue, 21 Feb 2017 09:11:39 +0000 Subject: [issue29575] doc 17.2.1: basic Pool example is too basic In-Reply-To: <1487667893.83.0.347164365226.issue29575@psf.upfronthosting.co.za> Message-ID: <7fc0c475-c8ca-0317-a043-0a1ced6620f1@fz-juelich.de> Joachim added the comment: I never proposed to add a second example, but to make the one example more meaningful. As a minimal solution, could we replace the numbers 3 (input data) and 5 (threads) by a slightly more plausible choice? Davin explained why numbers should be incommensurate. So what about 10 data, 3 threads? ---------- Added file: http://bugs.python.org/file46657/smime.p7s _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: not available URL: From report at bugs.python.org Tue Feb 21 04:33:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 09:33:44 +0000 Subject: [issue11572] bring Lib/copy.py to 100% coverage In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za> Message-ID: <1487669624.23.0.550849757689.issue11572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: copy and pickle use the same protocol. The copy module shouldn't be changed independently, the changes should be synchronised with both implementations of the pickle module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:50:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 09:50:10 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487670610.42.0.607248116425.issue29165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyVarObject_HEAD_INIT() is more used in Python 3 code, but the code with PyObject_HEAD_INIT() doesn't look incompatible with Python 3. I don't see a need of this change. PyObject_HEAD_INIT() also is used in .c files in Doc/includes/. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:50:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 09:50:54 +0000 Subject: [issue29611] TextIOWrapper's write_through option behave differently between C and pure Python implementation. Message-ID: <1487670654.12.0.413723829989.issue29611@psf.upfronthosting.co.za> New submission from INADA Naoki: In C implementation, write() calls underlaying flush() method when write_through=True. https://github.com/python/cpython/blob/3.6/Modules/_io/textio.c if (self->write_through) text_needflush = 1; if (self->line_buffering && (haslf || PyUnicode_FindChar(text, '\r', 0, PyUnicode_GET_LENGTH(text), 1) != -1)) needflush = 1; But pure Python implementation doesn't care write_through option at all. https://github.com/python/cpython/blob/3.6/Lib/_pyio.py self.buffer.write(b) if self._line_buffering and (haslf or "\r" in s): self.flush() When PyPy 3.5 is released, this difference may affects PyPy users. (I hadn't checked how PyPy provide io module.) ---------- components: IO messages: 288282 nosy: inada.naoki priority: normal severity: normal status: open title: TextIOWrapper's write_through option behave differently between C and pure Python implementation. type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:51:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 09:51:04 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1487670664.87.0.53755636298.issue24340@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:59:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 09:59:25 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487671165.01.0.676776346187.issue29165@psf.upfronthosting.co.za> INADA Naoki added the comment: > but the code with PyObject_HEAD_INIT() doesn't look incompatible with Python 3. It's incompatible actually. https://github.com/python/cpython/blob/2.7/Include/object.h /* PyObject_HEAD defines the initial segment of every PyObject. */ #define PyObject_HEAD_INIT(type) \ _PyObject_EXTRA_INIT \ 1, type, https://github.com/python/cpython/blob/3.5/Include/object.h #define PyObject_HEAD_INIT(type) \ { _PyObject_EXTRA_INIT \ 1, type }, I noticed PyVarObject_HEAD_INIT is compatible, and simplified an extension I maintain. https://github.com/PyMySQL/mysqlclient-python/commit/2feb5ed6850a3905edf0333e0cd11ea6218f0f4f This small doc change helps people who writing Python 2's extension module now, and port it to Python 3 later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:10:46 2017 From: report at bugs.python.org (Jussi Judin) Date: Tue, 21 Feb 2017 10:10:46 +0000 Subject: [issue29612] TarFile.extract() suffers from hard links inside tarball Message-ID: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za> New submission from Jussi Judin: I managed to create a tarball that brought out quite nasty behavior with tarfile.TarFile.extract() and tarfile.TarFile.extractall() functions when there are hard links inside a tarball that point to themselves with a file that is included in the tarball. In Python 2.7 it leads to an exception and with Python 3.4-3.6 it extracts the same file from the tarball multiple times. First we create a tarball that causes this behavior: $ mkdir -p tardata/1/2/3/4/5/6/7/8/9 $ dd if=/dev/zero of=tardata/1/2/3/4/5/6/7/8/9/zeros.data bs=1000000 count=500 # tar by default adds all directories recursively multiple times to the archive, but duplicates are created as hard links: $ find tardata | xargs tar cvfz tardata.tar.gz Then let's extract the tarball with tarfile module Let following commands demonstrate what happens with the attached tartest.py file $ python2.7.13 tartest.py noskip tardata.tar.gz /tmp/tardata-python-2.7.13 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data ... tardata/1/2/3/4/5/6/7/8/9/zeros.data Traceback (most recent call last): File "tartest.py", line 17, in unarchive(skip, archive, dest) File "tartest.py", line 12, in unarchive tar_fd.extract(info, dest) File "python/2.7.13/lib/python2.7/tarfile.py", line 2118, in extract self._extract_member(tarinfo, os.path.join(path, tarinfo.name)) File "python/2.7.13/lib/python2.7/tarfile.py", line 2202, in _extract_member self.makelink(tarinfo, targetpath) File "python/2.7.13/lib/python2.7/tarfile.py", line 2286, in makelink os.link(tarinfo._link_target, targetpath) OSError: [Errno 2] No such file or directory And with Python 3.6.0 (and earlier Python 3 series based Pythons that I have tested): $ time python3.6.0 tartest.py noskip tardata.tar.gz /tmp/tardata-python-3.6.0 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- this is extracted 11 times ... real 0m42.747s user 0m17.564s sys 0m6.144s If we then make the tarfile skip extraction of hard links that point to themselves: $ time python3.6.0 tartest.py skip tardata.tar.gz /tmp/tardata-python-3.6.0 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- this is extracted once ... Skipping tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- skipped hard links 10 times ... real 0m2.688s user 0m1.816s sys 0m0.532s >From the used user CPU time it's obvious that there is happening a lot of unneeded decompression when we compare Python 3.6 results. If I use TarFile.extractall(), it behaves similarly as using TarFile.extract() individually on TarInfo objects. GNU tar seems to behave in such fashion that it skips over the extraction of the actual file data when it encounters this situation. ---------- components: Library (Lib) files: tartest.py messages: 288284 nosy: Jussi Judin priority: normal severity: normal status: open title: TarFile.extract() suffers from hard links inside tarball type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46658/tartest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:17:30 2017 From: report at bugs.python.org (Ratnadeep Debnath) Date: Tue, 21 Feb 2017 10:17:30 +0000 Subject: [issue29237] Create enum for pstats sorting options In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za> Message-ID: <1487672250.59.0.350101682511.issue29237@psf.upfronthosting.co.za> Ratnadeep Debnath added the comment: It's good to hear that you're working on it. You can go ahead with this. Anyways, I will be around to see and learn how you fix this issue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:32:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 10:32:32 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487673152.54.0.892134199679.issue29165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, now I see. I think sample C files in Doc/includes/ should be updated too. And it seems to me that Doc/includes/shoddy.c in Python 3 is not correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:34:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 10:34:03 +0000 Subject: [issue29611] TextIOWrapper's write_through option behave differently between C and pure Python implementation. In-Reply-To: <1487670654.12.0.413723829989.issue29611@psf.upfronthosting.co.za> Message-ID: <1487673243.25.0.316350627827.issue29611@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, serhiy.storchaka, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:54:31 2017 From: report at bugs.python.org (Akash Shende) Date: Tue, 21 Feb 2017 10:54:31 +0000 Subject: [issue29613] Support for SameSite Cookies Message-ID: <1487674471.93.0.248753692479.issue29613@psf.upfronthosting.co.za> New submission from Akash Shende: Right now Morsel dont accept cookie setting outside of reserved words defined in http/cookies.py ---------- components: Library (Lib) messages: 288287 nosy: akash0x53 priority: normal severity: normal status: open title: Support for SameSite Cookies type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:58:46 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Feb 2017 10:58:46 +0000 Subject: [issue29613] Support for SameSite Cookies In-Reply-To: <1487674471.93.0.248753692479.issue29613@psf.upfronthosting.co.za> Message-ID: <1487674726.01.0.866552618198.issue29613@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +180 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 06:58:49 2017 From: report at bugs.python.org (Dima Zhukov) Date: Tue, 21 Feb 2017 11:58:49 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed In-Reply-To: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> Message-ID: <1487678329.25.0.561588039519.issue29589@psf.upfronthosting.co.za> Dima Zhukov added the comment: Just tried with 3.4.6 version. Same test failed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 07:12:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 12:12:05 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487679125.55.0.408410430249.issue29165@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 9436bbd87b7eed18dec4c32f25b88452fe282e1c by GitHub in branch '2.7': bpo-29165: doc: make extending/newtypes more Python 3 friendly (GH-211) https://github.com/python/cpython/commit/9436bbd87b7eed18dec4c32f25b88452fe282e1c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 07:12:30 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 12:12:30 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487679150.02.0.0660173327417.issue29165@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 07:14:16 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 12:14:16 +0000 Subject: [issue29165] Use forward compatible macro in example code for creating new type In-Reply-To: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za> Message-ID: <1487679256.94.0.708207339252.issue29165@psf.upfronthosting.co.za> INADA Naoki added the comment: > And it seems to me that Doc/includes/shoddy.c in Python 3 is not correct. I created another pull request PR 215. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 07:49:56 2017 From: report at bugs.python.org (=?utf-8?b?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Tue, 21 Feb 2017 12:49:56 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487681396.65.0.849544896066.issue29157@psf.upfronthosting.co.za> Vladim?r ?un?t added the comment: Why was there no backporting e.g. to 3.4 branch? I thought you implied that 3.3 and 3.4 are unaffected, but our build farm says otherwise, getting a segfault in bin/python3.4m (3.4.6) and printing "Fatal Python error: getentropy() failed" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 07:54:17 2017 From: report at bugs.python.org (Matthieu Dartiailh) Date: Tue, 21 Feb 2017 12:54:17 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487681657.83.0.272305303173.issue29607@psf.upfronthosting.co.za> Matthieu Dartiailh added the comment: I added the Misc/NEWS entry under Python 3.7. I guess it will be backported to 3.6 when cherry-pinking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:00:31 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 21 Feb 2017 13:00:31 +0000 Subject: [issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183) In-Reply-To: <1472046228.4.0.176948453237.issue27850@psf.upfronthosting.co.za> Message-ID: <1487682031.55.0.0593440150472.issue27850@psf.upfronthosting.co.za> Christian Heimes added the comment: Victor found out that Python is considered as affect by CVE-2016-2183, https://www.cvedetails.com/cve/CVE-2016-2183/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:09:23 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Feb 2017 13:09:23 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487682563.69.0.515875831441.issue29603@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Should avoid creating new threads if there are more # idle threads than items in the work queue. Shouldn't this just check to see if qsize() is greater than zero? That would mean that there are no idle threads. I'm not seeing why there would be any idle threads if there is work in the queue (the queue unblocks idle threads). I don't think "unfinished() - num_threads" makes sense. The meaning of "unfinished() - qsize()" is the number of non-idle worker threads (work is taken out of the queue but has not yet reported that the task is done). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:10:31 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 21 Feb 2017 13:10:31 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487682631.73.0.840977728433.issue29157@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 3.3 and 3.4 are in security-fix-only mode. Technically this fix does not count as security fix. It's a compatibility fix. https://docs.python.org/devguide/#status-of-python-branches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:19:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Feb 2017 13:19:13 +0000 Subject: [issue29591] Various security vulnerabilities in bundled expat (CVE-2016-0718 and CVE-2016-4472) In-Reply-To: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> Message-ID: <1487683153.85.0.968791244437.issue29591@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm working on a new documentation of Python vulnerabilities to help to handle such issue: http://python-security.readthedocs.io/en/latest/vulnerabilities.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:24:20 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 13:24:20 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1487683460.03.0.95768661006.issue23670@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:25:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 13:25:24 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487683524.18.0.0485148987343.issue29607@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 3a9ac827c7c87dffc60c4200323948551bcb6662 by Serhiy Storchaka in branch 'master': bpo-29607: Fix stack_effect computation for CALL_FUNCTION_EX (#202) https://github.com/python/cpython/commit/3a9ac827c7c87dffc60c4200323948551bcb6662 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:27:59 2017 From: report at bugs.python.org (Eryk Sun) Date: Tue, 21 Feb 2017 13:27:59 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487683679.19.0.474624022716.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: The 24-byte struct gets passed on the stack, as it should be. In this case ffi_call doesn't abort() because examine_argument returns 0, which is due to the following code in classify_argument: if (words > 2) { /* When size > 16 bytes, if the first one isn't X86_64_SSE_CLASS or any other ones aren't X86_64_SSEUP_CLASS, everything should be passed in memory. */ if (classes[0] != X86_64_SSE_CLASS) return 0; for (i = 1; i < words; i++) if (classes[i] != X86_64_SSEUP_CLASS) return 0; } It looks like X86_64_SSEUP_CLASS is never actually assigned by classify_argument(), in which case libffi never uses registers to pass structs that are larger than 16 bytes. Regarding floating-point values, we get a similar abort for passing a struct containing an array of two doubles because ctypes passes one ffi_type_pointer element instead of two ffi_type_double elements. Also, a struct with an array of one double (weird but should be supported) doesn't abort, but instead gets passed incorrectly like a pointer, i.e. as an integer in register rdi, instead of in the expected xmm0 register. The call thus uses whatever garbage value is currently in xmm0. You have to use a test lib to reproduce this. It's not apparent with a ctypes callback because ffi_closure_unix64 (unix64.S) and ffi_closure_unix64_inner (ffi64.c) use the same incorrect classification before calling ctypes closure_fcn and _CallPythonObject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:28:29 2017 From: report at bugs.python.org (Jan Vorwerk) Date: Tue, 21 Feb 2017 13:28:29 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487683709.82.0.907454912969.issue26789@psf.upfronthosting.co.za> Jan Vorwerk added the comment: Indeed, the error message is quite... surprising and misleading. To reproduce, please run the attached (admittedly wrong) program that I could simplify a lot. It seems to occur when a exception is raised at the wrong time... I hope this helps nail down (at least) one use case. 'pip install aiohttp' is required Best regards ---------- nosy: +JanVok Added file: http://bugs.python.org/file46659/error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 08:36:11 2017 From: report at bugs.python.org (Matthieu Dartiailh) Date: Tue, 21 Feb 2017 13:36:11 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1487684171.04.0.52577177559.issue28810@psf.upfronthosting.co.za> Matthieu Dartiailh added the comment: Anyone to review this. Working on bytecode manipulation for different projects I wish I had known this existed before. ---------- nosy: +mdartiailh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 09:36:13 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 21 Feb 2017 14:36:13 +0000 Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za> Message-ID: <1487687773.69.0.897819445135.issue26970@psf.upfronthosting.co.za> Christian Heimes added the comment: Let's not overcomplicate Python's ssl module any more. I was part of an effort to provide an osrandom engine for PyCA cryptography. I'm going to port the engine to OpenSSL. ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 09:39:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Feb 2017 14:39:20 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487687960.38.0.156682977417.issue26789@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please do not log during shutdown These logs are supposed to help you to find bugs in your application. Sadly, it's hard to log errors during Python shutdown because Pyhon is destroying its world: many basic functions are broken during shutdown. We already fixed many errors, but not that one. IMHO it's worth it to repair the logging module to be able to log during shutdown. The logging module should be be enhanced to handle more nicely such error during Python finalization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 09:55:09 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 21 Feb 2017 14:55:09 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487688909.86.0.772643275349.issue29176@psf.upfronthosting.co.za> Christian Heimes added the comment: How about https://linux.die.net/man/3/tmpfile instead? The tmpfile() function opens a unique temporary file in binary read/write (w+b) mode. The file will be automatically deleted when it is closed or the program terminates. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 09:57:27 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 14:57:27 +0000 Subject: [issue29509] redundant interning in PyObject_GetAttrString In-Reply-To: <1486626523.7.0.635584720165.issue29509@psf.upfronthosting.co.za> Message-ID: <1487689047.97.0.41640059525.issue29509@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 3e8d6cb1892377394e4b11819c33fbac728ea9e0 by GitHub in branch 'master': bpo-29509: skip redundant intern (GH-197) https://github.com/python/cpython/commit/3e8d6cb1892377394e4b11819c33fbac728ea9e0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 09:57:51 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 14:57:51 +0000 Subject: [issue29509] redundant interning in PyObject_GetAttrString In-Reply-To: <1486626523.7.0.635584720165.issue29509@psf.upfronthosting.co.za> Message-ID: <1487689071.27.0.988124571743.issue29509@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:02:43 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Feb 2017 15:02:43 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1487689363.77.0.170481777892.issue29598@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +182 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:02:45 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 15:02:45 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487689365.31.0.0421440238026.issue29607@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +183 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:38:22 2017 From: report at bugs.python.org (slytomcat) Date: Tue, 21 Feb 2017 15:38:22 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487691502.29.0.890690731004.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: Not exactly.... there are 3 cases: If qsize <> 0 it means there is no idle consumers threads, all of them must be busy: we need to create one more. No doubt. If qsize = 0 it means one of two cases: - all consumers threads are busy: we need to create one more - some or all consumers threads are idle: no need create new one. But there is no way to distinguish two last cases. That's why I consider that (unfinished() <= num_threads) gives clear key for decision. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:39:45 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Feb 2017 15:39:45 +0000 Subject: [issue29612] TarFile.extract() suffers from hard links inside tarball In-Reply-To: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za> Message-ID: <1487691585.02.0.730127312524.issue29612@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:55:12 2017 From: report at bugs.python.org (slytomcat) Date: Tue, 21 Feb 2017 15:55:12 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487692512.32.0.778431192756.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: One more problem that adjusting of number of threads is performed exactly after placing the new task in the queue. In in some cases we can find that qsuze <> 0 but it doesn't mean that there is no idle threads. It can be equal to 1 (just queued task) as no threads manage to get it yet (don't forgot about GIL). So even qsuze <> 0 dosn't mean that we need to create a new thread. But (unfinished() <= num_threads) works perfect in this case also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 10:59:50 2017 From: report at bugs.python.org (slytomcat) Date: Tue, 21 Feb 2017 15:59:50 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487692790.07.0.0721888468923.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: num_threads - unfinished() = the estimation for number of idle threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 11:03:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Feb 2017 16:03:53 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1487688909.86.0.772643275349.issue29176@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Is tmpfile() available on Android? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 11:18:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 16:18:31 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487693911.11.0.10505095199.issue29532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset e48fd93bbb36c6d80aa4eb6af09f58c69d8cf965 by GitHub in branch '3.6': bpo-29532: Altering a kwarg dictionary passed to functools.partial() no longer affects a partial object after creation. (#209) https://github.com/python/cpython/commit/e48fd93bbb36c6d80aa4eb6af09f58c69d8cf965 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 11:28:02 2017 From: report at bugs.python.org (=?utf-8?b?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Tue, 21 Feb 2017 16:28:02 +0000 Subject: [issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux In-Reply-To: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za> Message-ID: <1487694482.56.0.710422945722.issue29157@psf.upfronthosting.co.za> Vladim?r ?un?t added the comment: Thanks, I see now. From my point of view it is related to security, but I/we will deal with it somehow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 11:36:50 2017 From: report at bugs.python.org (Emily Morehouse) Date: Tue, 21 Feb 2017 16:36:50 +0000 Subject: [issue28121] If module starts with comment or empty line then frame.f_code.co_firstlineno is inconsistent with inspect.findsource In-Reply-To: <1473755914.89.0.262835652716.issue28121@psf.upfronthosting.co.za> Message-ID: <1487695010.39.0.523065352547.issue28121@psf.upfronthosting.co.za> Changes by Emily Morehouse : ---------- nosy: +emilyemorehouse _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 11:37:00 2017 From: report at bugs.python.org (Emily Morehouse) Date: Tue, 21 Feb 2017 16:37:00 +0000 Subject: [issue26890] inspect.getsource gets source copy on disk even when module has not been reloaded In-Reply-To: <1461987187.54.0.900828586529.issue26890@psf.upfronthosting.co.za> Message-ID: <1487695020.44.0.475260950512.issue26890@psf.upfronthosting.co.za> Changes by Emily Morehouse : ---------- nosy: +emilyemorehouse _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 12:33:26 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 17:33:26 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487698406.92.0.155916798927.issue29607@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 3ab24bdd47fdd9d45719ad49f93d3878d4442d7e by GitHub in branch '3.6': bpo-29607: Fix stack_effect computation for CALL_FUNCTION_EX (GH-219) https://github.com/python/cpython/commit/3ab24bdd47fdd9d45719ad49f93d3878d4442d7e ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 12:34:36 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 17:34:36 +0000 Subject: [issue29607] Broken stack_effect for CALL_FUNCTION_EX In-Reply-To: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> Message-ID: <1487698476.74.0.333572167142.issue29607@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks, Matthieu. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 13:04:49 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 18:04:49 +0000 Subject: [issue29613] Support for SameSite Cookies In-Reply-To: <1487674471.93.0.248753692479.issue29613@psf.upfronthosting.co.za> Message-ID: <1487700289.39.0.468484445312.issue29613@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 13:30:10 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 18:30:10 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487701810.25.0.528842052416.issue29453@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 9b49133082ec23b67e84d2589e66d7810018e424 by GitHub in branch '3.6': bpo-29453: Remove reference to undefined dictionary ordering in Tutorial (GH-140) (#208) https://github.com/python/cpython/commit/9b49133082ec23b67e84d2589e66d7810018e424 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 13:32:35 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 18:32:35 +0000 Subject: [issue29453] Remove reference to undefined dictionary ordering in Tutorial In-Reply-To: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> Message-ID: <1487701955.99.0.132116745115.issue29453@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks everyone. PR has been merged and backported to 3.6 :) Closing this issue. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 13:43:49 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 21 Feb 2017 18:43:49 +0000 Subject: [issue28909] Adding LTTng-UST tracing support In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za> Message-ID: <1487702629.86.0.123449764178.issue28909@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for working on this! A few thoughts. 1. Keep the existing names. "PyTrace" is already a name in use for a different purpose. I understand the itch to make the name more "right" but I am in general not a fan of renaming "PyDTrace" to anything else now. It was a placeholder from day one (SystemTap uses it, too, after all). So, looking closer at the patch now I'd prefer us to keep all existing names and add LTTng as another alternative engine here. That will make the patch much shorter. A nit: the name LTTng-UST is rather unfriendly, especially when used without the dash and in all lowercase characters. Given that we're using "dtrace" and "systemtap", it would be simpler to just use "lttng" (drop the "-ust"). 2. DTrace vs SystemTap vs LTTng. It's impossible to have DTrace and SystemTap at the same time, so it was natural to choose to auto-detect the engine. With LTTng it becomes less obvious what the configure options should be. Should it be possible at all to have *both* LTTng and SystemTap compiled in at the same time? Does this make sense? If yes, then keeping --with-dtrace and --with-lttng as separate options makes sense to me. If it doesn't, we should change the option to look like this: `--with(out)-dtrace=[=detect]`. This way people could pass the following: --without-dtrace (the default) --with-dtrace (detects DTrace or SystemTap or LTTng, in that order) --with-dtrace=detect (like the one above) --with-dtrace=dtrace (assumes DTrace, fails if cannot proceed) --with-dtrace=systemtap (assumes SystemTap, fails if cannot proceed) --with-dtrace=lttng (assumes LTTng, fails if cannot proceed) 3. Other questions. > Clang on macOS gives `warning: code will never be executed` warnings on the various arms of the `if (PyTraceEnabled(...))` statements, and GCC on Linux warn about unused variables `lineno`, `funcname` and `filename` in `pytrace_function_{entry,return}`, since the actual use of those variables as arguments is preprocessed out of existance. Do you get unused code warnings without your patch applied? I don't. > I would be happy to re-post this to GitHub issues if so desired. CPython is not using GitHub issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 14:16:05 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 21 Feb 2017 19:16:05 +0000 Subject: [issue29613] Support for SameSite Cookies In-Reply-To: <1487674471.93.0.248753692479.issue29613@psf.upfronthosting.co.za> Message-ID: <1487704565.87.0.649970840146.issue29613@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 14:34:10 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 21 Feb 2017 19:34:10 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487705650.24.0.047693922413.issue26789@psf.upfronthosting.co.za> Vinay Sajip added the comment: > The logging module should be be enhanced to handle more nicely such error during Python finalization. How does a particular piece of logging package code know it's being called during Python finalization? This sort of problem (exceptions caused by disappearing builtins, for example) isn't confined to logging, surely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 14:36:22 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 21 Feb 2017 19:36:22 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487705782.29.0.00736522922602.issue26789@psf.upfronthosting.co.za> Vinay Sajip added the comment: Calling logging.shutdown() when you know you're about to exit should eliminate some of the issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 14:44:40 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 21 Feb 2017 19:44:40 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487706280.77.0.524429407638.issue29565@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- pull_requests: +184 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 14:47:51 2017 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 21 Feb 2017 19:47:51 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487706471.74.0.241125275769.issue29565@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- pull_requests: +185 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:27:20 2017 From: report at bugs.python.org (Kirk Cieszkiewicz Jr.) Date: Tue, 21 Feb 2017 20:27:20 +0000 Subject: [issue29614] Additional implementation alternative to DictReader Message-ID: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> New submission from Kirk Cieszkiewicz Jr.: As discussed in the following: https://bugs.python.org/issue17537 https://mail.python.org/pipermail/python-ideas/2013-January/018844.html DictReader has a feature that will destroy data without warning if fieldnames had duplicate values (manual or automatic entries) Proposing renaming and re-implementation of DictReader class to instead return enumerate style output with a child class of DictReader to specifically return a dict object. ---------- components: Library (Lib) messages: 288318 nosy: Kirk Cieszkiewicz Jr. priority: normal severity: normal status: open title: Additional implementation alternative to DictReader type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:30:25 2017 From: report at bugs.python.org (Petr MOTEJLEK) Date: Tue, 21 Feb 2017 20:30:25 +0000 Subject: [issue29615] SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch Message-ID: <1487709025.37.0.198613157816.issue29615@psf.upfronthosting.co.za> New submission from Petr MOTEJLEK: Hello, We discovered that SimpleXMLRPCDispatcher mangles tracebacks printed from within the invoked RPC methods when an object that has _dispatch(method, params) defined has been registered with it Steps to reproduce - use https://docs.python.org/3.4/library/xmlrpc.server.html#xmlrpc.server.SimpleXMLRPCServer.register_instance and register within SimpleXMLRPCDispatcher an object with the _dispatch(method, params) method defined - invoke any RPC method that prints a traceback (perhaps raise an exception in it, catch it and use logging.exception to log it) --> the traceback will display a very strange looking KeyError (its value being the name of the invoked method) and then the actual exception that was fed into logging.exception The reason for this is that SimpleXMLRPCDispatcher._dispatch first attempts to acquire the function to invoke by reading from the functions registered with the dispatcher. When this attempt fails, KeyError is raised. During its handling different approaches are taken to acquire the function and for all but one when the function is acquired, handling of the KeyError ends and the function is called properly, outside of the except block However, in the case of objects that define the _dispatch(method, params) function, the _dispatch(method, params) function is called straight away, still within the except block handling the KeyError, and this leads to the mangled traceback This behavior is neither documented, nor expected (we believe) and thus the code should be changed Will submit a PR (incl. tests) for this later on ---------- components: Library (Lib) messages: 288319 nosy: petr at motejlek.net priority: normal severity: normal status: open title: SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:42:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 20:42:50 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487709770.68.0.48514914169.issue29532@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +186 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:43:40 2017 From: report at bugs.python.org (foxfluff) Date: Tue, 21 Feb 2017 20:43:40 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487709820.8.0.783579711639.issue29614@psf.upfronthosting.co.za> Changes by foxfluff : ---------- pull_requests: +187 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:56:26 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Feb 2017 20:56:26 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487710586.69.0.361006729442.issue26789@psf.upfronthosting.co.za> R. David Murray added the comment: If I understand correctly, the logging during shutdown coming out of asyncio helps debug errors in asyncio programs, and this logging can't happen before shutdown starts (so the application calling logging.shutdown would just hide the errors, I think). Yes, the general problem affects more than just logging, and when it is reasonable to do so we try to fix (or at least cleanly report) these shutdown issues in stdlib code. Whether it is reasonable to do so in this case I don't know. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 16:10:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Feb 2017 21:10:31 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487711431.85.0.0832852944103.issue26789@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > How does a particular piece of logging package code know it's being called during Python finalization? sys.is_finalizing() ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 16:36:54 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 21 Feb 2017 21:36:54 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487713014.53.0.34548715315.issue29565@psf.upfronthosting.co.za> Steve Dower added the comment: I approved the two backports. Thanks Vinay! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 16:42:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Feb 2017 21:42:50 +0000 Subject: [issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183) In-Reply-To: <1472046228.4.0.176948453237.issue27850@psf.upfronthosting.co.za> Message-ID: <1487713370.94.0.00986708218898.issue27850@psf.upfronthosting.co.za> STINNER Victor added the comment: Larry: "I agree completely Jim. The problem is that OpenSSL regularly discovers face-meltingly bad security bugs, so it frequently pulls the "security exception" lever." We chose to maintain our own cipher list, and so we have to maintain it. I created a pull request to backport the fix to Python 3.4. ---------- nosy: +haypo pull_requests: +189 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 17:29:58 2017 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 21 Feb 2017 22:29:58 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487716198.53.0.522365125481.issue26789@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 18:25:54 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 23:25:54 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487719554.61.0.0948527974815.issue29554@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +190 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 18:27:42 2017 From: report at bugs.python.org (Juan) Date: Tue, 21 Feb 2017 23:27:42 +0000 Subject: [issue29616] input() after restarting causes bug Message-ID: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> New submission from Juan: This bug can be recreated by opening a file whose content is "input()" with IDLE, press F5 and the shell opens as expected. Without making the input in the shell stop, press F5 in the script again. In Python 3.5 IDLE only take input until another F5 (or Ctrl+F6) in the script. In Python 3.6 IDLE only take input until an Enter is pressed or another F5 (or Ctrl+F6) in the script. ---------- assignee: terry.reedy components: IDLE messages: 288324 nosy: Juan, terry.reedy priority: normal severity: normal status: open title: input() after restarting causes bug type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 18:28:20 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Feb 2017 23:28:20 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487719700.87.0.275544133426.issue29554@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +191 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 18:56:26 2017 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 21 Feb 2017 23:56:26 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1487721386.53.0.816465782892.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- pull_requests: +192 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 20:55:05 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 01:55:05 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487728505.95.0.728793863305.issue29554@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 6336f0d156feec0f109a8d01da108cf96e3d9c60 by GitHub in branch '3.5': bpo-29554: Improve docs for pstat module and profile. (#88) (#228) https://github.com/python/cpython/commit/6336f0d156feec0f109a8d01da108cf96e3d9c60 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 20:55:35 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 01:55:35 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487728535.42.0.235800363947.issue29554@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset b067a5eef7fdf69264d3578654996fc3755df4ea by GitHub in branch '3.6': bpo-29554: Improve docs for pstat module and profile. (#88) (#227) https://github.com/python/cpython/commit/b067a5eef7fdf69264d3578654996fc3755df4ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 20:56:40 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 01:56:40 +0000 Subject: [issue29554] profile/pstat doc clariification In-Reply-To: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> Message-ID: <1487728600.02.0.651327099871.issue29554@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 21:06:01 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 02:06:01 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1487729161.54.0.336885728762.issue16011@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 21:26:04 2017 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 22 Feb 2017 02:26:04 +0000 Subject: [issue22087] asyncio: support multiprocessing (support fork) In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1487730364.92.0.27396169679.issue22087@psf.upfronthosting.co.za> Alexander Mohr added the comment: I believe this is now worse due to https://github.com/python/asyncio/pull/452 before I was able to simply create a new run loop from sub-processes however you will now get the error "Cannot run the event loop while another loop is running". The state of the run loop should not be preserved in sub-processes either. ---------- nosy: +thehesiod versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 23:32:32 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 04:32:32 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487737952.68.0.619264855814.issue27660@psf.upfronthosting.co.za> Xiang Zhang added the comment: New changeset 4cee049f5b6864066b8315e9b54de955e5487dfc by GitHub in branch 'master': bpo-27660: remove unnecessary overflow checks in list_resize (GH-189) https://github.com/python/cpython/commit/4cee049f5b6864066b8315e9b54de955e5487dfc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 23:32:53 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 04:32:53 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1487737973.5.0.76637822112.issue27660@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 23:38:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 04:38:54 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487738334.58.0.0264967567853.issue26789@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm -1 on suppress log silently. While error message is bit surprising, Traceback (most recent call last): File "/usr/lib/python3.5/asyncio/tasks.py", line 93, in __del__ File "/usr/lib/python3.5/asyncio/base_events.py", line 1160, in call_exception_handler ... File "/usr/lib/python3.5/logging/__init__.py", line 1037, in _open NameError: name 'open' is not defined This traceback is very meaningful. You can read tasks.py:93, and find there are pending task remains. Implementing fallback mechanism make potential risk to miss such very important traceback. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 23:58:30 2017 From: report at bugs.python.org (Aaron Gallagher) Date: Wed, 22 Feb 2017 04:58:30 +0000 Subject: [issue29403] mock's autospec's behavior on method-bound builtin functions is broken In-Reply-To: <1485903715.23.0.569013669104.issue29403@psf.upfronthosting.co.za> Message-ID: <1487739510.44.0.361637562444.issue29403@psf.upfronthosting.co.za> Changes by Aaron Gallagher : ---------- pull_requests: +193 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:01:38 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Feb 2017 05:01:38 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487739698.16.0.684842705198.issue29616@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am not sure what you mean by 'this bug'. I presume by 'take input' you mean 'display keystrokes on the input line'. If so, the behavior you describe for 3.6 is the correct behavior and not a bug: accept kestrokes until 'Enter' is pressed or until the process awaiting input is killed. F5 kills the current user code execution process, as opposed to the IDLE GUI interaction process, and starts a new one. That is what 'Restart' means. Experimenting with IDLE on 3.5 and 3.6 on Windows 10, I experienced the (correct) behavior described above. It does not make any difference whether there was any unsent input before hitting F5 or not. I did not notice any difference between the two versions. In both, hitting 'Enter' terminates input. Unless you can provide more details that convince me otherwise, I will close this as 'not a bug'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:08:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 05:08:42 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487740122.33.0.707163189346.issue29614@psf.upfronthosting.co.za> INADA Naoki added the comment: I don't feel TableReader is really useful. Would you show some realistic example when TableReader is better than normal csv.Reader? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:24:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 05:24:05 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487741045.66.0.931302474053.issue29616@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:29:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 05:29:18 +0000 Subject: [issue10701] Error pickling objects with mutating __getstate__ In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1487741358.13.0.341916410324.issue10701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:35:26 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 05:35:26 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1487741726.14.0.221373835152.issue7769@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +194 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:37:49 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 05:37:49 +0000 Subject: [issue29617] Drop Python 3.4 support from asyncio Message-ID: <1487741869.94.0.0732011694463.issue29617@psf.upfronthosting.co.za> New submission from INADA Naoki: asyncio for Python 3.3 has not been released for two years. https://pypi.python.org/pypi/asyncio We have many code in asyncio for support Python 3.3. How about removing them? ---------- components: asyncio messages: 288332 nosy: gvanrossum, inada.naoki, yselivanov priority: normal severity: normal status: open title: Drop Python 3.4 support from asyncio versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:45:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 05:45:53 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487742353.69.0.367023440675.issue28814@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 0899b9809547ec2894dcf88cf4bba732c5d47d0d by Berker Peksag in branch 'master': bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) https://github.com/python/cpython/commit/0899b9809547ec2894dcf88cf4bba732c5d47d0d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:45:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 05:45:53 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1487742353.86.0.251896472373.issue20438@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 0899b9809547ec2894dcf88cf4bba732c5d47d0d by Berker Peksag in branch 'master': bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) https://github.com/python/cpython/commit/0899b9809547ec2894dcf88cf4bba732c5d47d0d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:48:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 05:48:44 +0000 Subject: [issue29617] Drop Python 3.4 support from asyncio In-Reply-To: <1487741869.94.0.0732011694463.issue29617@psf.upfronthosting.co.za> Message-ID: <1487742524.54.0.601076850407.issue29617@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +195 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:51:02 2017 From: report at bugs.python.org (Marcel Widjaja) Date: Wed, 22 Feb 2017 05:51:02 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed In-Reply-To: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> Message-ID: <1487742662.85.0.291657335497.issue29589@psf.upfronthosting.co.za> Marcel Widjaja added the comment: Both test_asyncio & test_multiprocessing_forkserver work for me. I'm on the latest 3.6 and Mac OS 10.11.6 ---------- nosy: +mawidjaj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 01:19:58 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 06:19:58 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487744398.01.0.170680297501.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset 8fa7e22134ac9626b2188ff877f6aeecd3c9e618 by GitHub in branch '3.5': Fixed bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64. (#168) (#221) https://github.com/python/cpython/commit/8fa7e22134ac9626b2188ff877f6aeecd3c9e618 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 01:21:19 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 06:21:19 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487744479.82.0.708171584305.issue29565@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset 3cc5817cfaf5663645f4ee447eaed603d2ad290a by GitHub in branch '3.6': Fixed bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64. (#168) (#220) https://github.com/python/cpython/commit/3cc5817cfaf5663645f4ee447eaed603d2ad290a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 01:21:39 2017 From: report at bugs.python.org (Louie Lu) Date: Wed, 22 Feb 2017 06:21:39 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed In-Reply-To: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> Message-ID: <1487744499.96.0.207476920507.issue29589@psf.upfronthosting.co.za> Louie Lu added the comment: Both test_asyncio & test_multiprocessing_forkserver passed on latest 3.6 and 4.8.3-1-ARCH. ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 01:26:07 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 06:26:07 +0000 Subject: [issue29589] test_asyncio & test_multiprocessing_forkserver failed In-Reply-To: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> Message-ID: <1487744767.11.0.658405007152.issue29589@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, it seems not Python's fault. I can't reproduce the failure either. So I am going to close this issue. ---------- resolution: -> works for me stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 02:23:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 07:23:33 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1487748213.32.0.772701262676.issue29110@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 03f68b60e17b57f6f13729ff73245dbb37b30a4c by INADA Naoki in branch 'master': bpo-29110: Fix file object leak in `aifc.open` when given invalid AIFF file. (GH-162) https://github.com/python/cpython/commit/03f68b60e17b57f6f13729ff73245dbb37b30a4c ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 02:36:07 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 07:36:07 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487748967.16.0.721441298926.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Patch attached, including tests. If it looks halfway sensible, I can work up a PR. ---------- Added file: http://bugs.python.org/file46660/fix-22273-02.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 02:36:37 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 07:36:37 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487748996.99.0.0408942782939.issue22273@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 02:37:02 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 07:37:02 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` In-Reply-To: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> Message-ID: <1487749022.72.0.297694786092.issue28624@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 02:53:45 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 07:53:45 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487750025.59.0.500770559363.issue26789@psf.upfronthosting.co.za> Vinay Sajip added the comment: > sys.is_finalizing() Good to know. Is the "sys" binding guaranteed to be around even when other builtins like "open" aren't available? In order to handle things "nicely" during shutdown, what guarantees can logging code rely on in terms of what's available? I'm assuming handling things nicely doesn't mean just swallowing any exceptions raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 03:14:04 2017 From: report at bugs.python.org (Pauli Sundberg) Date: Wed, 22 Feb 2017 08:14:04 +0000 Subject: =?utf-8?q?=5Bissue29618=5D_Making_a_Tuple_or_Dict_with_Callable=5B_=2E=2E?= =?utf-8?b?LiwgeHh4wqBdIGdpdmVzIGVycm9y?= Message-ID: <1487751244.2.0.980199684208.issue29618@psf.upfronthosting.co.za> New submission from Pauli Sundberg: Hi all. I tried asking this on IRC channel, but ended up with no answear. Simple example: from typing import Dict, Callable CmdFun = Callable[ ... , int ] CmdFull = Dict[ str, CmdFun ] Gives error: pauli at HPauli-U1604 ~ % python3 /tmp/silly.py Traceback (most recent call last): File "/tmp/silly.py", line 5, in CmdFull = Dict[ str, CmdFun ] File "/usr/lib/python3.5/typing.py", line 1025, in __getitem__ tvars = _type_vars(params) File "/usr/lib/python3.5/typing.py", line 284, in _type_vars _get_type_vars(types, tvars) File "/usr/lib/python3.5/typing.py", line 279, in _get_type_vars t._get_type_vars(tvars) File "/usr/lib/python3.5/typing.py", line 786, in _get_type_vars _get_type_vars(self.__args__, tvars) File "/usr/lib/python3.5/typing.py", line 277, in _get_type_vars for t in types: TypeError: 'ellipsis' object is not iterable The python intrepretter is the one shipped with ubuntu16.04 currently: Python 3.5.2 Based on the documentation i think this should be valid statement. The similar issue raises if the Dict is replaced with Tuple, but i did not try any other combinations. ---------- components: Library (Lib) messages: 288343 nosy: Pauli Sundberg priority: normal severity: normal status: open title: Making a Tuple or Dict with Callable[ ..., xxx?] gives error type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 03:18:50 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 08:18:50 +0000 Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> Message-ID: <1487751530.25.0.369367786807.issue29565@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 03:35:00 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 08:35:00 +0000 Subject: [issue10938] Provide links to system specific strftime/ptime docs In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za> Message-ID: <1487752500.46.0.567887380841.issue10938@psf.upfronthosting.co.za> Xiang Zhang added the comment: I agree with Berker and Jim here. I think the current doc is clear enough so mark this as rejected. :-( ---------- nosy: +xiang.zhang resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 03:51:45 2017 From: report at bugs.python.org (Pauli Salmenrinne) Date: Wed, 22 Feb 2017 08:51:45 +0000 Subject: =?utf-8?q?=5Bissue29618=5D_Making_a_Tuple_or_Dict_with_Callable=5B_=2E=2E?= =?utf-8?b?LiwgeHh4wqBdIGdpdmVzIGVycm9y?= In-Reply-To: <1487751244.2.0.980199684208.issue29618@psf.upfronthosting.co.za> Message-ID: <1487753505.34.0.296556460521.issue29618@psf.upfronthosting.co.za> Pauli Salmenrinne added the comment: I tried to reproduce the issue with 3.5 branch from the current github, and the issue seems to be fixed. Closing this as fixed, sorry for the trouble. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 04:14:17 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 22 Feb 2017 09:14:17 +0000 Subject: [issue26213] Document BUILD_*_UNPACK opcodes In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za> Message-ID: <1487754857.66.0.420602110604.issue26213@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 04:30:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 09:30:18 +0000 Subject: [issue26789] Please do not log during shutdown In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za> Message-ID: <1487755818.49.0.0110802787039.issue26789@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are no guaranties. But in recent Python versions the order of finalising is more predicable. It is hard to reproduce a case when some builtins or sys member is not available (with some exceptions). The order of clearing (see PyImport_Cleanup() in Python/import.c): 1. Clear builtins._ and selected sys members (in particular this breaks import). Restore standard IO streams. 2. Clear sys.modules and all modules that don't have external references. 3. Restore builtins to its initial state (in particular builtins.open no longer available). 4. Clear the content of still alive modules except sys and builtins. 5. Clear sys. 6. Clear builtins. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 04:46:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 09:46:35 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487756795.27.0.312179658552.issue29532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 5010a77a4da76d8d3fd861a63a7f1ce8f0e9c520 by GitHub in branch '3.5': [3.5] bpo-29532: Altering a kwarg dictionary passed to functools.partial() no longer affects a partial object after creation. (#222) https://github.com/python/cpython/commit/5010a77a4da76d8d3fd861a63a7f1ce8f0e9c520 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 04:53:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 09:53:25 +0000 Subject: [issue29532] functools.partial is not compatible between 2.7 and 3.5 In-Reply-To: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> Message-ID: <1487757205.91.0.855302096645.issue29532@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:06:02 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 22 Feb 2017 10:06:02 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487757962.39.0.441121421384.issue29176@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: > Is tmpfile() available on Android? Yes. Just tried it with Android NDK r13 with clang and API 21 (Android 5.0). Here's the source code test.c: #include int main() { FILE *fp = NULL; char c = '\0'; fp = tmpfile(); fprintf(fp, "123\n"); scanf("%c", &c); fclose(fp); return 0; } Compilation command: /opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target aarch64-none-android-linux -gcc-toolchain /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot /opt/android-ndk/platforms/android-21/arch-arm64/usr -pie test.c (didn't test gcc as it's declared as 'deprecated' in NDK) Before scanf() returns, the temporary file is already deleted: shell at ASUS_Z00E_2:/ $ ls -l /proc/19300/fd lrwx------ shell shell 2017-02-22 15:21 0 -> /dev/pts/0 lrwx------ shell shell 2017-02-22 15:21 1 -> /dev/pts/0 lrwx------ shell shell 2017-02-22 15:21 2 -> /dev/pts/0 lrwx------ shell shell 2017-02-22 15:20 3 -> /data/local/tmp/tmp.VguNf9sqcW (deleted) lr-x------ shell shell 2017-02-22 15:21 9 -> /dev/__properties__ For interested, here's its implementation: https://android.googlesource.com/platform/bionic/+/android-5.0.0_r1/libc/bionic/tmpfile.cpp ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:11:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 10:11:38 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1487758298.22.0.976581196144.issue29598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better to move all tests for internal functions in separate TestCase class. It should be clear that this is testing of implementation details and we are free to change tests when change the implementation. There are some tests for find_function(). They should be moved too. Note that there is a bug in find_function() (it opens a file with default encoding). Tests for internal functions don't free us from testing the same functionality as a part of high level functions. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:12:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 10:12:36 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1487758356.52.0.362255127486.issue29598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:38:21 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 22 Feb 2017 10:38:21 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487759901.19.0.683267071789.issue29176@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- pull_requests: +196 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:53:27 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 10:53:27 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1487760807.6.0.299233344167.issue29376@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +197 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:53:46 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 22 Feb 2017 10:53:46 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487760826.69.0.819393015107.issue29176@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks Chi Hsuan Yen, I have created a new PR that replaces mkstemp() with tmpfile(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:55:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 10:55:18 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487760918.32.0.134746277595.issue29176@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- pull_requests: +198 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 05:59:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 10:59:52 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487761192.65.0.837115837452.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: I created https://github.com/python/cpython/pull/237 using tmpfile(). The patch is simpler than my previous PR using Python tempfile. Oh... I didn't see that Christian wrote almost the same change 20 min before me :-D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 06:22:43 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 22 Feb 2017 11:22:43 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487762563.01.0.938519781333.issue29549@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: CuriousLearner, I see that you have PRs against this issue. The issue is currently assigned to Lisa. I respectfully request that you choose a different issue to work on and to withdraw your pull request. Please choose an issue that is not currently assigned to anyone. If an issue is assigned, please ask first before working on it. Thank you. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 06:29:41 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Wed, 22 Feb 2017 11:29:41 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487762981.59.0.979055647962.issue29549@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Mariatta, I apologize for this. I completely missed to see that this was already assigned to someone else. I've withdrawn my PR. Thanks. ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 07:24:02 2017 From: report at bugs.python.org (Mba) Date: Wed, 22 Feb 2017 12:24:02 +0000 Subject: [issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat Message-ID: <1487766242.34.0.703380697066.issue29619@psf.upfronthosting.co.za> New submission from Mba: ino_t is of type 'unsigned long' or 'unsigned long long'. Casting it to signed type means that negative values are incorrectly returned for large inodes. ---------- components: Library (Lib) messages: 288355 nosy: mba priority: normal severity: normal status: open title: st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 07:39:48 2017 From: report at bugs.python.org (Mba) Date: Wed, 22 Feb 2017 12:39:48 +0000 Subject: [issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat In-Reply-To: <1487766242.34.0.703380697066.issue29619@psf.upfronthosting.co.za> Message-ID: <1487767188.8.0.153304055647.issue29619@psf.upfronthosting.co.za> Changes by Mba : ---------- components: -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 07:48:44 2017 From: report at bugs.python.org (Arne de Laat) Date: Wed, 22 Feb 2017 12:48:44 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za> Message-ID: <1487767724.1.0.772948992008.issue28911@psf.upfronthosting.co.za> Arne de Laat added the comment: *ping* Is this patch acceptable as is? Perhaps a new issue can be made for a method to check at most one call with a specific signature i.e. `assert_one_call_with`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 07:55:43 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 12:55:43 +0000 Subject: [issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat In-Reply-To: <1487766242.34.0.703380697066.issue29619@psf.upfronthosting.co.za> Message-ID: <1487768143.81.0.929391927187.issue29619@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 08:32:54 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 22 Feb 2017 13:32:54 +0000 Subject: [issue26213] Document BUILD_*_UNPACK opcodes In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za> Message-ID: <1487770374.09.0.923333433839.issue26213@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- pull_requests: +200 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 08:54:25 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 22 Feb 2017 13:54:25 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487771665.5.0.278243338805.issue29553@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:01:17 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 22 Feb 2017 14:01:17 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487772077.01.0.487193815259.issue29603@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > And even when Queue.unfinished gives wrong (outdated) information, > it can lead to creation one new thread that is not really required > at the moment. That is not a big mistake, I suppose (comparing to > creation all N threads during placing first N tasks in queue > without considering the volume of concurrent tasks). IMO, this isn't worth expanding the Queue API. The thread pool concept explicitly allows up to poolsize threads and occasionally having one extra thread within the allowed poolsize isn't important. Also, it is unclear why a new thread is being launched if there in nothing in the work queue (unfinished tasks is only interesting when qsize==0). For other users, the new method is problematic because it is distracting and prone to misuse (potentially out-of-date upon return and potentially meaningless if task_done isn't being used). I believe the new method will cause more problems than it fixes. Also, I really don't like the mission creep. Queue objects are primarily about managing a queue of inputs. Monitoring and managing consumers is another (mostly orthogonal) realm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:15:21 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 22 Feb 2017 14:15:21 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1487772921.2.0.217267370655.issue28810@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- pull_requests: +201 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:23:29 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 14:23:29 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1487773409.13.0.929990563707.issue28810@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patches Ivan. Feel free to rewrite my patch, I'm sure it uses poor English. ---------- dependencies: +Document BUILD_*_UNPACK opcodes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:37:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 14:37:18 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487774238.97.0.0416606896039.issue29176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The manpage of tmpfile contains the note: POSIX.1-2001 specifies: an error message may be written to stdout if the stream cannot be opened. Did you tested tmpfile() with readonly temporary files directory or overfull file system? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:46:14 2017 From: report at bugs.python.org (Juan) Date: Wed, 22 Feb 2017 14:46:14 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487774774.25.0.181231673135.issue29616@psf.upfronthosting.co.za> Juan added the comment: What I meant was: 1. Open a file whose content is "input()" with IDLE 2. F5 3. Type something but without pressing Enter. 4. Come back to the script (with input() still responding to keystrokes on the input line) 5. F5 6. Bug. (Results vary even on the same machine by closing and opening Python again, sometimes whatever you pressed in step 3 disappears, sometimes it just takes input, doesn't respond to commands similar (not equal) to "while(1): pass") ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:51:42 2017 From: report at bugs.python.org (Juan) Date: Wed, 22 Feb 2017 14:51:42 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487775102.65.0.94481227506.issue29616@psf.upfronthosting.co.za> Juan added the comment: *doesn't respond to commands. I mean something similar to (not equal) "while(1): pass") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 09:56:45 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Feb 2017 14:56:45 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487775405.05.0.394521430454.issue29614@psf.upfronthosting.co.za> R. David Murray added the comment: Inada: I believe the goal is to be able to handle CSV files that have columns with duplicate names. However, in that case one could just use the regular reader class. The only advantage TableReader gives over the regular reader that I can see is that it automatically reads the header line and sets fieldnames. I'm not sure that is enough motivation for introducing a whole new class. It also doesn't address the issue the OP mentions, that columns are overwritten silently by DictReader. However, that is a characteristic of dicts in Python in general, so I'm not sure I even see that as a bug. Overall, I'm -1 on this proposal. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 10:08:42 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Feb 2017 15:08:42 +0000 Subject: [issue29546] A more helpful ImportError message In-Reply-To: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> Message-ID: <1487776122.4.0.783476214824.issue29546@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 10:20:05 2017 From: report at bugs.python.org (foxfluff) Date: Wed, 22 Feb 2017 15:20:05 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487776805.29.0.678061267955.issue29614@psf.upfronthosting.co.za> foxfluff added the comment: David: You are correct that the goal is to handle CSVs with duplicate headers, and that the main intention is to have some of the behavior of DictReader without the destruction of data (such as the auto population of field names as you stated). It is not the intention of this to change the behavior of DictReader, as stated in issue 17537. It is instead covering a problem that was discussed later in the thread and would offer an alternative solution with non destructive behavior to DictReader while maintaining backwards compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 10:21:42 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 15:21:42 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1487767724.1.0.772948992008.issue28911@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Can you please try to write a pull request? https://docs.python.org/devguide/pullrequest.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 10:37:55 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Feb 2017 15:37:55 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487777875.86.0.938126200673.issue29614@psf.upfronthosting.co.za> R. David Murray added the comment: My opinion stated in that issue is still the same: I don't think this is a bug. I don't think automatic handling of fieldnames when no other dictionary features are retained is worth the complication to the API. So I'm still -1. We'll see what other people think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:05:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 16:05:17 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487779517.37.0.0706882283911.issue29614@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm with Inada and David. This use case looks very specific. If you need to handle a CSV file with duplicated header, you can use the regular reader or implement your own specialised reader. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:12:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Feb 2017 16:12:52 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487779972.29.0.360814462492.issue29614@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Or use DictReader with an explicit fieldnames argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:22:51 2017 From: report at bugs.python.org (kernc) Date: Wed, 22 Feb 2017 16:22:51 +0000 Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size Message-ID: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za> New submission from kernc: If any of the objects in sys.modules is a module-like object that performs some additional imports in its __getattribute__ (as appropriate) handler, the following simple unit test test case: import unittest import warnings ... # Ensure one of the imported modules is a module-like object as above class Case(unittest.TestCase): def test_assertWarns(self): with self.assertWarns(UserWarning): warnings.warn('Some warning') fails with: ====================================================================== ERROR: test_assertWarns (example.Case) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/example.py", line 9, in test_assertWarns with self.assertWarns(UserWarning): File "/usr/lib/python3.4/unittest/case.py", line 205, in __enter__ for v in sys.modules.values(): RuntimeError: dictionary changed size during iteration ---------------------------------------------------------------------- The problem is in the iteration over sys.modules in unittest.case._AssertWarnsContext.__enter__() and accessing every module's __warningregistry__ attribute. On this access, the module-like objects may perform arbitrary actions including importing of further modules which extends sys.modules. https://github.com/python/cpython/blob/16ea19fc6653ee4ec1be7cd0206073962119ac08/Lib/unittest/case.py#L226-L227 The simple proposed fix with no foreseen side-effects is to wrap sys.modules.values() call as a tuple(). ---------- components: Library (Lib) messages: 288370 nosy: kernc priority: normal severity: normal status: open title: unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:35:21 2017 From: report at bugs.python.org (John Hagen) Date: Wed, 22 Feb 2017 16:35:21 +0000 Subject: [issue29621] telnetlib.Telnet.write gives confusing error message when a string is passed in Message-ID: <1487781321.4.0.45367640243.issue29621@psf.upfronthosting.co.za> New submission from John Hagen: I was recently helping someone learn Python 3 from Python 2 and they were confused by error resulting from the following easy-to-make mistake: import telnetlib tn = telnetlib.Telnet('localhost') tn.write('hello') Traceback (most recent call last): File "/Users/user/PycharmProjects/python-test/main.py", line 4, in tn.write('hello') File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/telnetlib.py", line 287, in write if IAC in buffer: TypeError: 'in ' requires string as left operand, not bytes What is confusing is that the solution is to pass in `bytes`, not a `str`, but the place where this manifests is in an `in` operator with the first argument as a `bytes` (telnetlib.IAC). Perhaps a simple isinstance(buffer, bytes) could be used to throw a `TypeError` or something a bit more helpful. It also doesn't help that for some reason Googling "python telnet" only seems to bring up the Python 2 docs link, rather than Python 3 or both. ---------- components: Library (Lib) messages: 288371 nosy: John Hagen priority: normal severity: normal status: open title: telnetlib.Telnet.write gives confusing error message when a string is passed in type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:48:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 16:48:32 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl Message-ID: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> New submission from STINNER Victor: The _ast.AST constructor requires a tuple with the same number of items than the fields list. Example with Raise: ASDL: Raise(expr? exc, expr? cause) >>> import _ast >>> _ast.Raise() <_ast.Raise object at 0x7fc2ca7dee90> >>> _ast.Raise(1) Traceback (most recent call last): File "", line 1, in TypeError: Raise constructor takes either 0 or 2 positional arguments >>> _ast.Raise(1, 2) <_ast.Raise object at 0x7fc2ca7def60> The cause field is optional in the ASDL, but required in the _ast module. A tradeoff would be to add the minimum and maximum number of fields to _ast.AST. This issue should prevent API breakage caused by the new docstring attribute added by issue #29463. ---------- messages: 288372 nosy: haypo, inada.naoki priority: normal severity: normal status: open title: ast module doesn't support optional fields of Parser/Python.asdl type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:51:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 16:51:09 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1487782269.45.0.00917471162678.issue29463@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue broke the ast API. Copy of the following comment on the PR: https://github.com/python/cpython/pull/46#issuecomment-281721296 --- Carreau: Thanks for this ! Improvement to the AST are welcome ! Would it have been possible to make the docstring optional ? (It's already breaking things, like IPython). Should I comment on upstream bpo ? --- I created the issue #29622 to fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:53:35 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 22 Feb 2017 16:53:35 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1487782415.52.0.647582230183.issue29463@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: thank you for your work on the AST, I know many developers are looking forward to improvement and stabilisation with the hope of having it stable (and documented) in the stdlib at some point. The recent change in PR 46 now change (at least) the constructor of `ast.Module` to take a second mandatory parameter (the docstring). I know the ast is autogenerated and "use at your own risk". But IPython for example, use `mod = ast.Module([nodes])`, with the second mandatory parameter added to Module that make it incompatible with current Python 3.7. Well it's long until it's released, and we can patch things, but I'm sure we are not the only one in this case, and we'd like older version of IPython to still be compatible with Python 3.7, so if `Module()`'s second parameter (the docstring) could be optional, that would be great. I would be happy if it raise a deprecation warning that it will be required in the future. I'm of course speaking about `Module` because that's the first error I encountered, but I'm guessing it applies to other changed AST nodes. Thanks. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:54:54 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 22 Feb 2017 16:54:54 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487782494.09.0.518068455266.issue29622@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Duplicating my comment of 29463 who was in a race condition with this issue: ---- thank you for your work on the AST, I know many developers are looking forward to improvement and stabilisation with the hope of having it stable (and documented) in the stdlib at some point. The recent change in PR 46 now change (at least) the constructor of `ast.Module` to take a second mandatory parameter (the docstring). I know the ast is autogenerated and "use at your own risk". But IPython for example, use `mod = ast.Module([nodes])`, with the second mandatory parameter added to Module that make it incompatible with current Python 3.7. Well it's long until it's released, and we can patch things, but I'm sure we are not the only one in this case, and we'd like older version of IPython to still be compatible with Python 3.7, so if `Module()`'s second parameter (the docstring) could be optional, that would be great. I would be happy if it raise a deprecation warning that it will be required in the future. I'm of course speaking about `Module` because that's the first error I encountered, but I'm guessing it applies to other changed AST nodes. Thanks. --- ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 12:51:41 2017 From: report at bugs.python.org (slytomcat) Date: Wed, 22 Feb 2017 17:51:41 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487785901.66.0.967628726206.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: I can't fully agree with this: >Queue objects are primarily about managing a queue of inputs. >Monitoring and managing consumers is another (mostly orthogonal) realm. Monitoring of consumers is already added via task_done() and join() methods. At least this two methods allows to understand that all consumers are in idle state. The unfinished() - is just functional extension to this existing functionality. >For other users, the new method is problematic because it is distracting >and prone to misuse (potentially out-of-date upon return and potentially >meaningless if task_done isn't being used). I believe the new method >will cause more problems than it fixes. This sounds reasonable because I also understand that this method is not usable in all cases as in most cases task_done is not used. Probably my idea for method unfinished is really not so good... Actually I've manage to find unpublished Queue.unfinished_tasks variable just in several minutes when I tried to find solution for threaded PoolExecutor. Hope that any curious developer can find it too. I don't mind if you close this CR. Thanks for pleasant discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 12:54:15 2017 From: report at bugs.python.org (slytomcat) Date: Wed, 22 Feb 2017 17:54:15 +0000 Subject: [issue29603] More informative Queue class: new method that returns number of unfinished tasks In-Reply-To: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> Message-ID: <1487786055.27.0.339358698337.issue29603@psf.upfronthosting.co.za> slytomcat added the comment: I've closed pull request on GitHub. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 13:48:55 2017 From: report at bugs.python.org (David Ellis) Date: Wed, 22 Feb 2017 18:48:55 +0000 Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib path as a single argument. Message-ID: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za> New submission from David Ellis: Trying to use configparser.ConfigParser.read on a pathlib object results in a TypeError. If supplied in a list it works as expected. Repro: >>> import pathlib, configparser >>> configparser.ConfigParser().read(pathlib.Path('some.ini')) TypeError: 'PosixPath' object is not iterable The issue appears to be line 690 which checks for str before attempting to iterate and doesn't check for os.PathLike (or bytes?). This was actually mentioned as an example where pathlib did not work here: https://bugs.python.org/issue22570 ---------- components: Library (Lib) messages: 288378 nosy: David Ellis priority: normal severity: normal status: open title: configparser.ConfigParser.read() does not accept Pathlib path as a single argument. type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:20:28 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 22 Feb 2017 19:20:28 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher Message-ID: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> New submission from Steve Dower: For some reason, the install bootstrapper for 3.5.3 x86 embedded the wrong hash value for launcher.msi. As a result, it will fail to download the file and install will be aborted. The workaround is to deselect the launcher from being installed, and use the 64-bit installer to install the launcher. Or alternatively, install Python 3.6 to get the later version of the installer, which will then automatically skip it for the 3.5 installer. Python 3.6 is unaffected, so this may just have been a build glitch, but it needs investigation and testing so it doesn't happen again. (Adding a /layout test after uploading is an easy way to test this.) ---------- assignee: steve.dower components: Windows messages: 288379 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: critical severity: normal stage: test needed status: open title: Python 3.5.3 x86 web installer cannot install launcher type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:31:31 2017 From: report at bugs.python.org (Will Pittman) Date: Wed, 22 Feb 2017 19:31:31 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) Message-ID: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> New submission from Will Pittman: colorsys.rgb_to_hsv appears to be broken on python2.7.13 (on archlinux). Saturation is always reported as 0. ex: import colorsys rgb_to_hsv( 127, 116, 18 ) >>> (0.16666666666666666, 0, 127) ---------- messages: 288380 nosy: Will Pittman priority: normal severity: normal status: open title: colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:42:11 2017 From: report at bugs.python.org (Will Pittman) Date: Wed, 22 Feb 2017 19:42:11 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) In-Reply-To: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> Message-ID: <1487792531.01.0.301258593233.issue29625@psf.upfronthosting.co.za> Will Pittman added the comment: The bug appears to be caused by the difference in division symbols between python3 vs python2. The issue appears to be resolved if you add the following line to the `/usr/lib/python2.7.13/colorsys.py` module (or if all arguments are converted to floats). from __future__ import division I noticed that this bug persists all the back to at least python2.7.10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:45:31 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 19:45:31 +0000 Subject: [issue28129] assertion failures in ctypes In-Reply-To: <1473779654.66.0.219445763591.issue28129@psf.upfronthosting.co.za> Message-ID: <1487792731.52.0.401527752098.issue28129@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:52:51 2017 From: report at bugs.python.org (Will Pittman) Date: Wed, 22 Feb 2017 19:52:51 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) In-Reply-To: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> Message-ID: <1487793171.75.0.469869082065.issue29625@psf.upfronthosting.co.za> Changes by Will Pittman : ---------- title: colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) -> colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 15:24:41 2017 From: report at bugs.python.org (paul j3) Date: Wed, 22 Feb 2017 20:24:41 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487795081.15.0.263185499268.issue29553@psf.upfronthosting.co.za> paul j3 added the comment: http://bugs.python.org/issue22047 "argparse improperly prints mutually exclusive options when they are in a group" is similar. ----- There are two issues: - the nesting of mutually exclusive groups - the formatting of the usage in such cases. Both have come up in one way or other in other bug reports. Yes, it is possible to add a group to an existing group. But from a testing standpoint the effect is the same as if you put all actions into one super group. More often people try to nest ArgumentGroups in MutuallyExclusiveGroups thinking that would give some sort of 'any' or 'and' logic within the 'xor' logic. I have explored that in http://bugs.python.org/issue11588. Defining nestable groups is relatively easy. Writing good usage is much harder. The usage formatter is brittle. It creates a big string, strips out 'excess' characters (the problem here), and then splits and reassembles the string (leading to assertion errors if the metavars contain funny characters). In http://bugs.python.org/issue11874 I submitted a patch that substantially rewrites the usage formatter. The idea was to keep the action strings separate until the last moment. While I haven't tested it with the current problem, I did use it in my nested-groups coding. While I'm not opposed to patching the usage formatting in bits and pieces, we should do so while fully aware of the big picture. Little patches tend to make brittle code even more brittle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 15:40:20 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 20:40:20 +0000 Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib path as a single argument. In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za> Message-ID: <1487796020.69.0.627577621528.issue29623@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 15:42:16 2017 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 22 Feb 2017 20:42:16 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) In-Reply-To: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> Message-ID: <1487796136.73.0.611608390171.issue29625@psf.upfronthosting.co.za> Mark Dickinson added the comment: The arguments to rgb_to_hsv are supposed to be floating-point numbers in the range 0.0 to 1.0. That's documented here: https://docs.python.org/2/library/colorsys.html > Coordinates in all of these color spaces are floating point values. In the YIQ space, the Y coordinate is between 0 and 1, but the I and Q coordinates can be positive or negative. In all other spaces, the coordinates are all between 0 and 1. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 15:45:14 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Feb 2017 20:45:14 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1487796314.44.0.830192108094.issue28686@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 15:54:43 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 22 Feb 2017 20:54:43 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1487796883.96.0.253226176817.issue27200@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +202 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:09:08 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 22 Feb 2017 21:09:08 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487797748.83.0.804005029553.issue29176@psf.upfronthosting.co.za> Christian Heimes added the comment: I think we can live with the fact some tmpfile() might write an error message if the system is broken. If user's tmp is not writeable, the user has more serious issues than a write to stdout inside curses module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:12:12 2017 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 22 Feb 2017 21:12:12 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487797932.08.0.963007744407.issue29622@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:34:27 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 22 Feb 2017 21:34:27 +0000 Subject: [issue22549] bug in accessing bytes, inconsistent with normal strings and python 2.7 In-Reply-To: <1412357790.8.0.103142585174.issue22549@psf.upfronthosting.co.za> Message-ID: <1487799267.39.0.898129532564.issue22549@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +203 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:34:27 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 22 Feb 2017 21:34:27 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1487799267.47.0.718658992024.issue22594@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +204 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:34:50 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 22 Feb 2017 21:34:50 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487799290.62.0.917753305816.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: Notes on fix-22273-02.diff: In the second pass over _fields_, you can (should) use dict->length and dict->proto for array types instead of the _length_ and _type_ attributes. When reassigning stgdict->ffi_type_pointer.elements, if use_broken_old_ctypes_semantics is false, then you also have to allocate space for and copy the elements from the base class if any (i.e. if basedict && basedict->length > 0). Regarding structs with bitfields and unions, we could add an stgdict flag to prevent passing them as arguments in the Unix X86_64 ABI -- e.g. add a flag named TYPEFLAG_NONARGTYPE (0x400). ConvParam (callproc.c) and converters_from_argtypes (_ctypes.c) would raise an ArgumentError or TypeError in this case. Subclasses of structs and unions would inherit this flag value in StructUnionType_new. The first pass in PyCStructUnionType_update_stgdict can set arrays_seen and bitfields_seen. Also, per the above suggestion, isArgType can be added. Moreover, since we don't have to worry about bitfields if we forbid passing structs with bitfields in this ABI, then MAX_ELEMENTS can be reduced to 8. For example: #ifdef X86_64 #define MAX_ELEMENTS 8 isArgType = (!(stgdict->flags & TYPEFLAG_NONARGTYPE) && isStruct && !bitfields_seen); if (!isArgType) { stgdict->flags |= TYPEFLAG_NONARGTYPE; } else if (size <= 16 && arrays_seen) { ffi_type *actual_types[MAX_ELEMENTS + 1]; int actual_type_index = 0; /* second pass over _fields_ */ } This is speculative based on how we address passing unions and structs with bitfields in the 64-bit Unix ABI. Raising a descriptive exception is at least an improvement over abruptly aborting the process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 16:37:50 2017 From: report at bugs.python.org (David Ellis) Date: Wed, 22 Feb 2017 21:37:50 +0000 Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib path as a single argument. In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za> Message-ID: <1487799470.74.0.546469528.issue29623@psf.upfronthosting.co.za> Changes by David Ellis : ---------- pull_requests: +205 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:02:33 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:02:33 +0000 Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib path as a single argument. In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za> Message-ID: <1487800953.83.0.908394020594.issue29623@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:08:02 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:08:02 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487801282.55.0.589401977989.issue28814@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +206 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:08:02 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:08:02 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1487801282.64.0.791730308744.issue20438@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +207 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:10:11 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:10:11 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487801411.66.0.161532413461.issue28814@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +208 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:10:11 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:10:11 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1487801411.78.0.811923476792.issue20438@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +209 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:14:08 2017 From: report at bugs.python.org (Will Pittman) Date: Wed, 22 Feb 2017 22:14:08 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) In-Reply-To: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> Message-ID: <1487801648.27.0.174475590372.issue29625@psf.upfronthosting.co.za> Will Pittman added the comment: oh, thank you very much and sorry for my negligence! ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:49:47 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:49:47 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1487803787.97.0.694798322421.issue28518@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +210 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:53:32 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:53:32 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487804012.05.0.484373181197.issue29355@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Ma. > We can use the old way in here, the old way is even better IMO. What do you mean by the old way? The use of switch statement? ---------- dependencies: +execute("begin immediate") throwing OperationalError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:56:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Feb 2017 22:56:53 +0000 Subject: [issue29098] document minimum sqlite version In-Reply-To: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za> Message-ID: <1487804213.2.0.859334368388.issue29098@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- dependencies: +sqlite3: remove sqlite3_stmt_readonly() type: -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 17:57:44 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Feb 2017 22:57:44 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487804264.85.0.220781585879.issue29616@psf.upfronthosting.co.za> Terry J. Reedy added the comment: What OS are you using? > 6. Bug. This does not tell me what you think the bug is. > sometimes whatever you pressed in step 3 disappears, When Shell is restarted by whatever means, any pending input, whether in response to '>>>' or user input(), is cancelled and *should* disappear and not be left to look as if it were processed. It consistently does for me. > doesn't respond to commands When a user-coded input() is active, anything typed *should* be treated as text and not interpreted as a command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 18:00:55 2017 From: report at bugs.python.org (Falguniben Jhaveri) Date: Wed, 22 Feb 2017 23:00:55 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help Message-ID: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> New submission from Falguniben Jhaveri: When I use argparse the optional arguments with character "-p" and "-s" has improper spacing while using help/usage command. Sample out put from argparse module: usage: cli node list [-h] [-p] [-o] Lists nodes in your current project. optional arguments: -h, --help show this help message and exit // extra space after p -p , --projectid -o, --org (For administrators only) Lists all the nodes in ---------- components: Library (Lib) messages: 288389 nosy: falu2010 priority: normal severity: normal status: open title: Issue with spacing in argparse module while using help versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 18:07:11 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Feb 2017 23:07:11 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1487804831.37.0.101043529198.issue15657@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I think this bug has been fixed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 18:10:44 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Feb 2017 23:10:44 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487805044.84.0.895631520365.issue25008@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: aiosmtpd is coming along nicely: http://aiosmtpd.readthedocs.io/en/latest/ We'll soon have a 1.0 release. Still, I don't think it's worth pulling this into the stdlib. But we could silently deprecate it and point to aiosmtpd in the docs. ---------- assignee: -> barry components: +Documentation -Library (Lib) title: Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio -> Deprecate smtpd (based on deprecated asyncore/asynchat) versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 18:14:41 2017 From: report at bugs.python.org (Juan) Date: Wed, 22 Feb 2017 23:14:41 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487805281.19.0.896904385299.issue29616@psf.upfronthosting.co.za> Juan added the comment: I am using Windows 10 64-bit. >> sometimes whatever you pressed in step 3 disappears, > > When Shell is restarted by whatever means, any pending input, whether in response to '>>>' or user input(), is cancelled and > *should* disappear and not be left to look as if it were processed. It consistently does for me. It doesn't for me. > > doesn't respond to commands > > When a user-coded input() is active, anything typed *should* be treated as text and not interpreted as a command. Even before enters? At the comments of http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/ I found someone having the same problem as me, MrValdez () This is a relevant part of his comment: > ANNOYANCE: input() doesn't play well when re-running a script when the script is already running. > > Here's a use case. A student types this program in IDLE: > > -- > > x = input("Typ a word:") > print (x) > > -- > > They run the code. In the shell window, the student would notice the mispelling. Without exiting the shell window, > they would go edit the code and then press F5. > > The shell would still be running the previous code instead of restarting. > > In some of my exercises, the students would sometimes think their code are broken when in reality, they already > got the solution. They were just running the older instance. > > This becomes common enough that I ask my students to exit the shell window before running their scripts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 19:06:36 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 Feb 2017 00:06:36 +0000 Subject: [issue29614] Additional implementation alternative to DictReader In-Reply-To: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> Message-ID: <1487808396.21.0.0497382778117.issue29614@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Serhiy, David, and Inada Marking this as closed. ---------- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 19:08:04 2017 From: report at bugs.python.org (David Ellis) Date: Thu, 23 Feb 2017 00:08:04 +0000 Subject: [issue29627] configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path. Message-ID: <1487808484.96.0.332923797285.issue29627@psf.upfronthosting.co.za> New submission from David Ellis: Related: https://github.com/python/cpython/pull/242 https://bugs.python.org/issue29623 In the discussion over my PR for bpo-29623 it became clear that bytestring paths were also unsupported and it was suggested that that should be a separate issue (currently the PR adds checks for both types). There is some possible odd behaviour as when given a bytestring path the method attempts to open the integer file descriptors for each character in the bytestring. This will most likely fail silently but if it does find an actual file descriptor it will attempt to read and then close the file. Example from the discussion on the PR: >>> import os >>> import configparser >>> k = os.open('/home/david/develop/cpython/Lib/test/cfgparser.1', os.O_RDONLY) >>> k 3 >>> c = configparser.ConfigParser() >>> c.read(b'\x03') [3] >>> list(c) ['DEFAULT', 'Foo Bar'] >>> os.close(k) # File has already been closed OSError: [Errno 9] Bad file descriptor Currently bytestrings do work correctly when provided as part of a list. ---------- components: Library (Lib) messages: 288394 nosy: David Ellis priority: normal severity: normal status: open title: configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path. type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 20:16:16 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 Feb 2017 01:16:16 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487812576.7.0.547339793897.issue29594@psf.upfronthosting.co.za> Ethan Furman added the comment: @Julian: Giving flag combinations their own name can be useful. For example, instead of seeing Color.GREEN|RED one can see Color.YELLOW . @Marc: I'm not convinced this is a needed change as it doesn't seem to be a common method, nor one that cannot be easily implemented independently (perhaps as a recipe in the docs). Are you aware of other enumerations that take this approach? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 20:20:44 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 Feb 2017 01:20:44 +0000 Subject: [issue29594] implementation of __or__ in enum.auto In-Reply-To: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> Message-ID: <1487812844.72.0.534159219444.issue29594@psf.upfronthosting.co.za> Ethan Furman added the comment: I also think using leading underscores is a better way to signal that a particular value is "weird". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 21:33:59 2017 From: report at bugs.python.org (Ma Lin) Date: Thu, 23 Feb 2017 02:33:59 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487817239.8.0.143317968486.issue29355@psf.upfronthosting.co.za> Ma Lin added the comment: The "old way" is not using sqlite3_stmt_readonly(). Before 3.6.0, we only count rowcount for INSERT, UPDATE, DELETE, REPLACE: https://hg.python.org/cpython/file/3.5/Modules/_sqlite/cursor.c#l689 These four statements can be representd by is_dml in PR 245: https://github.com/python/cpython/pull/245/commits/cbeabf4044e9e1563d228e359b0e7952f369b42a#diff-5a6abb9997d51e693f3b24986659c857R88 So only change this line is ok, then restore the behavior before 3.6.0 exactly: - if (!sqlite3_stmt_readonly(self->statement->st)) { + if (self->statement->is_dml) { self->rowcount += (long)sqlite3_changes(self->connection->db); } else { self->rowcount= -1L; } Why it's better? sqlite3_changes() only works for INSERT, UPDATE, DELETE. see: https://sqlite.org/c3ref/changes.html So using sqlite3_stmt_readonly() to determine statements is not necessary at all. In addition, we can add a comment for code safe in statement.c. + /* is_dml is used in two sites: + 1, determine statements for implicit BEGIN. + 2, determine statements for counting rowcount */ self->is_dml = (PyOS_strnicmp(p, "insert ", 7) == 0) || (PyOS_strnicmp(p, "update ", 7) == 0) || (PyOS_strnicmp(p, "delete ", 7) == 0) || (PyOS_strnicmp(p, "replace ", 8) == 0); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 22:14:54 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 Feb 2017 03:14:54 +0000 Subject: [issue29569] threading.Timer class: Continue periodical execution till action returns True In-Reply-To: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> Message-ID: <1487819694.13.0.608460782682.issue29569@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Ideally, proposed API expansions should be based on a demonstrated user need. This API is over decade old and I don't recall a single user request for this functionality. A quick scan of StackOverflow didn't turn-up any questions or answers on the subject. I don't see anything intrinsically wrong with the idea, but in the absence of demonstrated need, it is likely to become unused cruft with it attendant burden on maintenance and cognitive load. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 22:36:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 03:36:33 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1487820993.78.0.315770049762.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: OK, let's continue on #29522, and close this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 22:37:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 03:37:21 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1487821041.09.0.339157032562.issue29463@psf.upfronthosting.co.za> INADA Naoki added the comment: s/ #29522 / #29622 / ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 22:55:46 2017 From: report at bugs.python.org (mesheb82) Date: Thu, 23 Feb 2017 03:55:46 +0000 Subject: [issue29628] struct objects can no longer be pickled Message-ID: <1487822146.07.0.247102500299.issue29628@psf.upfronthosting.co.za> New submission from mesheb82: When I run the following code on Windows/Linux for < Python 3.6, I have no problems. When I run in Python 3.6.0, I get the subsequent traceback. I checked the release notes and only saw the following struct module note related to half-floats: Issue #11734 from struct import Struct import copy this_fails = Struct(' copy.deepcopy(this_fails) File "F:\Anaconda\envs\py36\lib\copy.py", line 169, in deepcopy rv = reductor(4) TypeError: can't pickle Struct objects To be clear, I'm copying struct objects as part of a larger class. As I'm running many function calls where I create the same struct objects, saving the common struct objects allows me to get a factor of 2x speedup on my code. Deleting the saved struct objects at the end of file reading (and before the deepcopy takes place) fixes the problem. ---------- components: Windows messages: 288401 nosy: mesheb82, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: struct objects can no longer be pickled type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 23:42:21 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 Feb 2017 04:42:21 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487824941.78.0.858190749667.issue29549@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, I'm not sure what you're referring to by "Just make docstrings in the style of of Argument Clinic descriptions". For the time being, I would like the docstring to match that of str.find(). The point of the patch is to decouple the two. AC issues and migrations can wait. At this point, AC adoption has been more disruptive that helpful in a number of cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 23:43:24 2017 From: report at bugs.python.org (paul j3) Date: Thu, 23 Feb 2017 04:43:24 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1487825004.79.0.158026680047.issue29626@psf.upfronthosting.co.za> paul j3 added the comment: We need to see the parser setup as well. I've never seen a bug like this before. The `usage` line suggests that you are using subparsers. It might be better if you asked this on StackOverFlow with a repeatable code example. That's a better place to get debugging help of your own code. Come back here if others think this is a problem with `argparse` itself rather than your own setup. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:03:23 2017 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 23 Feb 2017 05:03:23 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487826203.09.0.897875343516.issue29549@psf.upfronthosting.co.za> Xiang Zhang added the comment: Lisa, could you make a PR? It could let more developers see your patch. ---------- nosy: +xiang.zhang stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:20:12 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 Feb 2017 05:20:12 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487827212.57.0.735126593741.issue29549@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please everyone. Ease up. This is a very simple patch. Copy what is done in str.find to str.index. It doesn't need infinite discussion and debate. I assigned this to Lisa to give her practice. It wasn't intended to have five developers jump in and shove it back and forth. Let's let simple things be simple and not waste the time of new contributors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:22:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 05:22:51 +0000 Subject: [issue29628] struct objects can no longer be pickled In-Reply-To: <1487822146.07.0.247102500299.issue29628@psf.upfronthosting.co.za> Message-ID: <1487827371.48.0.617420512659.issue29628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > When I run the following code on Windows/Linux for < Python 3.6, I have no problems. You have a problem. Did you try to use the copied object? It is a broken Struct object. >>> copied = copy.deepcopy(this_fails) >>> copied.format >>> copied.size -1 >>> copied.pack(42) Traceback (most recent call last): File "", line 1, in struct.error: pack expected -1 items for packing (got 1) >>> copied.unpack(b'abcd') Traceback (most recent call last): File "", line 1, in struct.error: unpack requires a bytes object of length -1 Copying Struct object never worked. Now it raises an error rather than silently creating a broken object. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:27:22 2017 From: report at bugs.python.org (mesheb82) Date: Thu, 23 Feb 2017 05:27:22 +0000 Subject: [issue29628] struct objects can no longer be pickled In-Reply-To: <1487827371.48.0.617420512659.issue29628@psf.upfronthosting.co.za> Message-ID: mesheb82 added the comment: Thank you. On Wed, Feb 22, 2017 at 9:22 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > > When I run the following code on Windows/Linux for < Python 3.6, I have > no problems. > > You have a problem. Did you try to use the copied object? It is a broken > Struct object. > > >>> copied = copy.deepcopy(this_fails) > >>> copied.format > >>> copied.size > -1 > >>> copied.pack(42) > Traceback (most recent call last): > File "", line 1, in > struct.error: pack expected -1 items for packing (got 1) > >>> copied.unpack(b'abcd') > Traceback (most recent call last): > File "", line 1, in > struct.error: unpack requires a bytes object of length -1 > > Copying Struct object never worked. Now it raises an error rather than > silently creating a broken object. > > ---------- > nosy: +serhiy.storchaka > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:42:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 05:42:36 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487828556.83.0.930703614468.issue29549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I mean that this work is useless since it will be lost when convert str.index to Argument Clinic. Well, even when don't use Argument Clinic, but make str.index() be supported by inspect.signature(), the docstring should be significantly rewritten. I think there are many other easy documentation issues for practicing. And all proposed PRs change only the docstring of str.index. They don't touch docstrings of str.rindex, bytes.index, bytes.rindex, bytearray.index and bytearray.rindex. I can't approve such changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:53:56 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Feb 2017 05:53:56 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1487829236.6.0.38705731985.issue29355@psf.upfronthosting.co.za> Berker Peksag added the comment: > - if (!sqlite3_stmt_readonly(self->statement->st)) { > + if (self->statement->is_dml) { Ah, yes now I understand what do you mean! :) I agree and this is already in my local branch to fix issue 28518. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:55:34 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 05:55:34 +0000 Subject: [issue29629] rgb_to_hls to colorsys.py Message-ID: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> New submission from Madhavendra Sharma: Calculations in rgb_to_hls at line number 67 in python version 2.7.3 for "h" the hue component are not correct according reference mentioned in the same source file "en.wikipedia.org/wiki/HSV_color_space". code snippet: if r == maxc: #h = (bc-gc) #current code h = (bc-gc)%6 # suggestion elif g == maxc: h = 2.0+rc-bc else: #h = 4.0+gc-rc #current code h = 4.0+rc-gc # suggestion #h = (h/6.0) % 1.0 not required # h = 60 *h # component should be multiplied by 60 but it depends on user ---------- messages: 288410 nosy: madhavendra.sharma priority: normal severity: normal status: open title: rgb_to_hls to colorsys.py type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:56:40 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 05:56:40 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487829400.09.0.180139676026.issue29629@psf.upfronthosting.co.za> Changes by Madhavendra Sharma : ---------- title: rgb_to_hls to colorsys.py -> rgb_to_hls in colorsys.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:59:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 05:59:53 +0000 Subject: [issue29628] struct objects can no longer be pickled In-Reply-To: <1487822146.07.0.247102500299.issue29628@psf.upfronthosting.co.za> Message-ID: <1487829593.97.0.806389165541.issue29628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As a workaround you can make Struct pickleable: from struct import Struct import copy, copyreg def pickle_struct(s): return Struct, (s.format,) copyreg.pickle(Struct, pickle_struct) s1 = Struct(' _______________________________________ From report at bugs.python.org Thu Feb 23 01:18:09 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Feb 2017 06:18:09 +0000 Subject: [issue29627] configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path. In-Reply-To: <1487808484.96.0.332923797285.issue29627@psf.upfronthosting.co.za> Message-ID: <1487830689.14.0.520381641568.issue29627@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:19:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 06:19:15 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487830755.34.0.904096103642.issue29629@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All coordinates in RGB and HSV spaces are floating point numbers between 0.0 and 1.0. In Wikipedia article h is a degree value between 0? and 360?. Could you provide an example of rgb_to_hls() returning invalid result? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:21:02 2017 From: report at bugs.python.org (Julia Dolgova) Date: Thu, 23 Feb 2017 06:21:02 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487830862.12.0.433472730667.issue29533@psf.upfronthosting.co.za> Julia Dolgova added the comment: I added variable smart_proxy_bypass into request module. If it's False then checking IP and FQDN of the host is skipped in proxy_bypass_registry function. I set the default value to False, because I think it's better when the behaviour of urllib corresponds to IE rather than previous versions of urllib. This will affect only NT-systems. ---------- Added file: http://bugs.python.org/file46661/request.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:21:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 06:21:42 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487830902.7.0.871818005132.issue29622@psf.upfronthosting.co.za> INADA Naoki added the comment: AST type doesn't have any information about optional fields. And I don't know it's worth enough to add it. When AST is instantiated by keyword arguments, there are no check about absence of some fields. I suppose we can just loosen positional arguments too. current: if (PyTuple_GET_SIZE(args) > 0) { if (numfields != PyTuple_GET_SIZE(args)) { PyErr_Format(PyExc_TypeError, "%.400s constructor takes %s" "%zd positional argument%s", Py_TYPE(self)->tp_name, numfields == 0 ? "" : "either 0 or ", numfields, numfields == 1 ? "" : "s"); will be: if (PyTuple_GET_SIZE(args) > 0) { if (numfields > PyTuple_GET_SIZE(args)) { PyErr_Format(PyExc_TypeError, "%.400s constructor takes at most " "%zd positional argument%s", Py_TYPE(self)->tp_name, numfields, numfields == 1 ? "" : "s"); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:32:21 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 23 Feb 2017 06:32:21 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487831541.92.0.0354941294711.issue27788@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +211 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:40:36 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Feb 2017 06:40:36 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487832036.04.0.208627089914.issue29616@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Characters typed before Enter are never sent the the execution process, so there are not even interpreted as a string, let alone a command. Do you see exactly the following when you start IDLE? Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 If so, there must either be something different about your system, or you are doing something other than what I understand you to have done. The 5 1/2-year-old report in not completely clear to me. The behavior reported could have been affected by subsequent patches. The only restart glitch I have noticed is that previous output very occasionally show up after the >>> prompt. In any case, I cannot (intentionally) fix what I cannot see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:40:40 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 06:40:40 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487832040.79.0.597376284792.issue29629@psf.upfronthosting.co.za> Madhavendra Sharma added the comment: Please check examples in en.wikipedia.org/wiki/HSL_and_HSV I picked one of them for R = .750, B=0.250, G=0.750 corresponding HLS value are H= 300 = (5.0 * 60) , L = .5, S=.5 but colorsys.rgb_to_hls(0.75 , 0.25, 0.75) gives following output (0.8333333333333334, 0.5, 0.5) h*60 = 0.8333333333333334 * 60 is not equal to 300 correct out put should be (5.0, 0.5, 0.5) or if h is multiplied by 60 then (300, 0.5, 0.5) Thank you. Madhavendra Sharma ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 01:42:14 2017 From: report at bugs.python.org (Julia Dolgova) Date: Thu, 23 Feb 2017 06:42:14 +0000 Subject: [issue29533] urllib2 works slowly with proxy on windows In-Reply-To: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> Message-ID: <1487832134.96.0.0479339871939.issue29533@psf.upfronthosting.co.za> Changes by Julia Dolgova : ---------- pull_requests: +212 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 02:01:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 07:01:25 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487833285.27.0.79727829329.issue29629@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 0.8333333333333334 * 360 is equivalent to 300. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 02:03:01 2017 From: report at bugs.python.org (paul j3) Date: Thu, 23 Feb 2017 07:03:01 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1487833381.17.0.0993966275189.issue29553@psf.upfronthosting.co.za> paul j3 added the comment: I played around with the patch 117. I was wrong in thinking this was another case of excess brackets being wrongly purged. The fix works by adding ending ] that were missing the original. And it does add a symmetry to the code. But it is easy to construct a set of Actions that creates further errors. For the 'inserts' to work correctly the mutually exclusive Actions have to be defined together. So all the actions of the nested group have to be defined after the non nest actions of the parent group. An optional positional can also cause problems. This whole _format_actions_usage method was not written with nested groups in mind. While this patch fixes one or two cases, it isn't robust. I also don't like the idea of enshrining group nesting in the test_argparse.py file. That fact that it works as well as it does is an accident, a feature, not an intentional behavior. I haven't tested PR120 yet. Dropping the inner brackets gives a cleaner display. The nested brackets of 117 are hard to read, even if they are correct. Note that in http://bugs.python.org/issue22047 I proposed blocking nested groups, by raising an error. The reason why it is possible to add either kind of group to a _MutuallyExclusiveGroup is because it inherits the add methods from _ActionsContainer. Normally those group add methods are used by ArgumentParser which also inherits from _ActionsContainer. It is possible to add a MutuallyExclusiveGroup to an ArgumentGroup, and that is somewhat useful. It doesn't change the usage, but does let you group that set of Actions in the help lines. But this nesting is not fully developed, as hinted at by a commeent in the method that copies 'parents': def _add_container_actions # add container's mutually exclusive groups # NOTE: if add_mutually_exclusive_group ever gains title= and # description= then this code will need to be expanded as above ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 02:04:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 07:04:33 +0000 Subject: [issue29616] input() after restarting causes bug In-Reply-To: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> Message-ID: <1487833473.11.0.935424617825.issue29616@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The implementation of standard input/output in IDLE was significantly changed in recent years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 02:48:25 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 23 Feb 2017 07:48:25 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487836105.71.0.704270387461.issue27788@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 02:57:44 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 23 Feb 2017 07:57:44 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1487836664.06.0.212403864355.issue22594@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:11:32 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 08:11:32 +0000 Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union arguments In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za> Message-ID: <1487837492.43.0.0387214301731.issue26628@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:14:27 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 08:14:27 +0000 Subject: [issue29630] REPL tab-completion triggers code execution Message-ID: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> New submission from Francisco Demartino: On the REPL, when autocompleting with the TAB key, getattr is called, potentially triggering code execution. This took me by surprise. Until you press RETURN, it should be pretty safe to go around autocompleting with certainty that you won't run any code. But that might be just my opinion. What do you think? ---------- components: Interpreter Core files: wat.py messages: 288420 nosy: Francisco Demartino priority: normal severity: normal status: open title: REPL tab-completion triggers code execution versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46662/wat.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:18:33 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 08:18:33 +0000 Subject: [issue16575] ctypes: unions as arguments In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za> Message-ID: <1487837913.12.0.918191425398.issue16575@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:18:38 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 08:18:38 +0000 Subject: [issue16576] ctypes: structure with bitfields as argument In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za> Message-ID: <1487837918.69.0.455447899155.issue16576@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:27:57 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 08:27:57 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487838477.56.0.328803447978.issue29630@psf.upfronthosting.co.za> Louie Lu added the comment: I can reproduce the problem in Python 3.7. ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:31:43 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 08:31:43 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487838703.78.0.889441881392.issue29630@psf.upfronthosting.co.za> Louie Lu added the comment: Could it be the problem from readline? Using python 2 with readline trigger same behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:36:33 2017 From: report at bugs.python.org (Tim Golden) Date: Thu, 23 Feb 2017 08:36:33 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <4d5d328c-b105-117c-557c-a47608b5f0be@timgolden.me.uk> Tim Golden added the comment: Since the webmaster@ address tends to bear the brunt of these, can I make sure I understand the situation? * The only installers affected are those for x86/32-bit Windows 3.5.3 * By default [I just checked] the launcher checkbox is not checked * If it *is* checked by the user, the entire install will abort * If it is left unchecked, the install will succeed and it is then possible to run the x64 installer and select only the installer option. Is there a possibility of producing a repaired installer? And/or should we hide that specific set of installers for the moment? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:42:00 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 08:42:00 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487839320.83.0.161580724136.issue29630@psf.upfronthosting.co.za> Francisco Demartino added the comment: This branch (working on the PR) fixes it: https://github.com/franciscod/cpython/tree/bpo-29630 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:44:20 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 08:44:20 +0000 Subject: [issue28121] If module starts with comment or empty line then frame.f_code.co_firstlineno is inconsistent with inspect.findsource In-Reply-To: <1473755914.89.0.262835652716.issue28121@psf.upfronthosting.co.za> Message-ID: <1487839460.49.0.0275811736062.issue28121@psf.upfronthosting.co.za> Louie Lu added the comment: Sorry, but I can't reproduce at 3.7, 3.5, or 2.7. the result shows me that inspect does respect comment line. ? cpython git:(350) ? ./python /tmp/main.py 2 (['# First line\n', 'import inspect\n', 'frame = inspect.currentframe()\n', 'print(frame.f_code.co_firstlineno)\n', 'print(inspect.findsource(frame.f_code))\n'], 0) ? /tmp python2 main.py 2 (['# First line\n', 'import inspect\n', 'frame = inspect.currentframe()\n', 'print(frame.f_code.co_firstlineno)\n', 'print(inspect.findsource(frame.f_code))\n'], 0) ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:04:28 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 09:04:28 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487840668.23.0.76049338719.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for the comments. Using your suggestions simplifies things quite a bit. Still finding my way around :-) > Regarding structs with bitfields and unions, we could add an stgdict flag to prevent passing them as arguments in the Unix X86_64 ABI Is this to deal with issues #16575, #16576 and #26628? Issue #26628 seems to be a duplicate of #16575. I can add the flag and set it here, but the checks should probably be in a separate patch. > if we forbid passing structs with bitfields in this ABI, then MAX_ELEMENTS can be reduced to 8. Not sure that's the case. For example, if we have to handle typedef struct { unsigned char data[12]; } Test; that would use up 12 slots for the unrolled array. Perhaps you mean 16 rather than 8? Updated patch attached. ---------- Added file: http://bugs.python.org/file46663/fix-22273-03.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:21:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 09:21:37 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487841697.75.0.567898827637.issue29630@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is how Python works. Accessing an attribute (and even checking that the attribute exists) can trigger code executing. Changes in https://github.com/franciscod/cpython/tree/bpo-29630 break autocompliting of proxy objects. And in any case it triggers code execution due to calling eval(). I think this is not a bug and changing current behavior can decrease usability. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:24:18 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Feb 2017 09:24:18 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487841858.84.0.108591118286.issue29630@psf.upfronthosting.co.za> Christian Heimes added the comment: I agree with Serhiy. There is no way to safely inspect any Python object without triggering some dunder functions like __getattr__, __getattribute__ or __dir__. ---------- nosy: +christian.heimes resolution: -> not a bug stage: -> resolved status: open -> pending type: -> behavior versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:32:10 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 09:32:10 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487842330.97.0.152870736864.issue29630@psf.upfronthosting.co.za> Changes by Francisco Demartino : ---------- pull_requests: +213 status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:36:59 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 09:36:59 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487842619.66.0.989395792302.issue29630@psf.upfronthosting.co.za> Francisco Demartino added the comment: I've updated that branch and made a pull request (https://github.com/python/cpython/pull/248) I think this is a good compromise: inspect.getattr_static can tell if it's a property, and in that case we don't call getattr on it to prevent code execution on the completion. If it isn't a property, the current codepath is preserved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:38:54 2017 From: report at bugs.python.org (Aivar Annamaa) Date: Thu, 23 Feb 2017 09:38:54 +0000 Subject: [issue28121] If module starts with comment or empty line then frame.f_code.co_firstlineno is inconsistent with inspect.findsource In-Reply-To: <1473755914.89.0.262835652716.issue28121@psf.upfronthosting.co.za> Message-ID: <1487842734.9.0.597969507774.issue28121@psf.upfronthosting.co.za> Aivar Annamaa added the comment: Looks like I misinderstood inspect.findsource. I thought it is supposed to give only the code for argument object (eg. only def code when given a function), but looks like it is giving the whole file. Unfortunately inspect.findsource is not documented in https://docs.python.org/3/library/inspect.html and inspect.getsource can't be used as replacement, because it doesn't work with modules. ---------- stage: -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:43:21 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Feb 2017 09:43:21 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487843001.77.0.234186014505.issue29630@psf.upfronthosting.co.za> Christian Heimes added the comment: Your change is not backwards compatible and makes auto-completion less useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:52:36 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 09:52:36 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487843556.71.0.792572414748.issue29629@psf.upfronthosting.co.za> Madhavendra Sharma added the comment: OK, That's fine. Thanks for the clarification. But most of the calculations I found for the conversion from RGB to HLS contains H = 60 * h' that's why I could not interpret it properly. Even on the same wiki page calculations specific to RGB to HLS were that way only. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 04:52:54 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 09:52:54 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487843574.04.0.938758170364.issue29630@psf.upfronthosting.co.za> Francisco Demartino added the comment: > There is no way to safely inspect any Python object without triggering some dunder functions like __getattr__, __getattribute__ or __dir__. But somehow inspect.getattr_static can do it? > Your change is not backwards compatible and makes auto-completion less useful. Why is it less useful? The only change is not executing property getters when showing completion options. It's removing a surprising code execution before the newline is received. Should CPython keep backwards compatibility of this execution-on-completion at the REPL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:01:26 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 10:01:26 +0000 Subject: [issue29629] rgb_to_hls in colorsys.py In-Reply-To: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> Message-ID: <1487844086.07.0.407122478805.issue29629@psf.upfronthosting.co.za> Changes by Madhavendra Sharma : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:01:42 2017 From: report at bugs.python.org (Karen) Date: Thu, 23 Feb 2017 10:01:42 +0000 Subject: =?utf-8?q?=5Bissue29631=5D_Error_=E2=80=9Cimportlib=2Eh=2C_importlib=5Fex?= =?utf-8?q?ternal=2Eh_updated=2E_You_will_need_to_rebuild_pythoncore_to_se?= =?utf-8?q?e_the_changes=2E=E2=80=9D_is_reported_when_build_Python_on_Wino?= =?utf-8?q?dws?= Message-ID: <1487844100.2.0.365499340143.issue29631@psf.upfronthosting.co.za> New submission from Karen: We use VS2015 to build Python(branch 3.6)on Windows. It failed with error "importlib.h, importlib_external.h updated. You will need to rebuild pythoncore to see the changes". This error is reported from Python 3.6 branch revision 3ab24bd. The detailed error log file is attached. Could you please help to take a look? Thank you so much! Here is repro steps: 1. git clone -b "3.6" -c core.autocrlf=true https://github.com/python/cpython.git D:\Python3\src 2. checkout the revision to 3ab24bd. 3. build -e -r -v ---------- components: Build files: Python3_x86_build.log messages: 288436 nosy: Karen priority: normal severity: normal status: open title: Error ?importlib.h, importlib_external.h updated. You will need to rebuild pythoncore to see the changes.? is reported when build Python on Winodws type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file46664/Python3_x86_build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:06:08 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 23 Feb 2017 10:06:08 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487844368.73.0.612866886176.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: > Perhaps you mean 16 rather than 8? Sorry, that was a misfire. It should be 16. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:08:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 10:08:18 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487844498.31.0.0184528695792.issue29630@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is less useful because don't work with dynamic attributes (with __getattar__ and __getattribute__). And if executing property getters is an issue (I don't think it is), this change doesn't fix it completely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:09:22 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 10:09:22 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487844562.2.0.715588767208.issue29622@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +216 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:14:03 2017 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Feb 2017 10:14:03 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487844843.05.0.45118051291.issue29630@psf.upfronthosting.co.za> Christian Heimes added the comment: inspect.getattr_static *tries* to get attributes without triggering dunder methods. It's neither fully compatible to getattr() nor does it guarantee that no code is triggered. The function may or may not be secure. Surprise or not surprise is a matter of perspective. I don't find it surprising. It's incompatible because it gives different results: >>> class Example: ... @property ... def example(self): ... def func(): pass ... return func ... >>> e = Example() >>> e.exa >>> e.example( with your patch, I'm getting: >>> e.exa >>> e.example Do you notice the difference? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:47:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 10:47:14 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487846834.41.0.551006297176.issue29176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I hope that this never happen in real world, but in theory this change can introduce regression. That is why I think it should be documented in Misc/NEWS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 06:00:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Feb 2017 11:00:20 +0000 Subject: [issue29176] /tmp does not exist on Android and is used by curses.window.putwin() In-Reply-To: <1483699620.77.0.827616599041.issue29176@psf.upfronthosting.co.za> Message-ID: <1487847620.31.0.414771845361.issue29176@psf.upfronthosting.co.za> STINNER Victor added the comment: > POSIX.1-2001 specifies: an error message may be written to stdout if the stream cannot be opened. At least, I don't see such message in the Android implementation: https://android.googlesource.com/platform/bionic/+/android-5.0.0_r1/libc/bionic/tmpfile.cpp ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 06:21:35 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 11:21:35 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487848895.44.0.246380445747.issue29622@psf.upfronthosting.co.za> INADA Naoki added the comment: Now trailing optional fields are optional arguments of AST type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 06:38:10 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 11:38:10 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487849890.75.0.451733646059.issue29622@psf.upfronthosting.co.za> INADA Naoki added the comment: @mbussonn With PR 249, "import os" and "%timeit" works fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 07:44:37 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 12:44:37 +0000 Subject: [issue29630] REPL tab-completion triggers code execution In-Reply-To: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> Message-ID: <1487853877.69.0.539361742757.issue29630@psf.upfronthosting.co.za> Francisco Demartino added the comment: Serhiy, Chris, thank you for your additional comments. They surely helped me understand why my solution to this "problem?" isn't that good (also I slept on it a bit and maybe that helped). I still ponder for a way to get autocompletion while guarranteeing no code will run, but a) any getter code is meant to run in that way, and b) it would somehow need to know the result of running that code without running it (Tricky, huh?). Thanks again for your patience. I feel enlightened :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:05:43 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 23 Feb 2017 13:05:43 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1487855143.71.0.933576893087.issue28810@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- pull_requests: +217 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:29:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 13:29:17 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1487856557.89.0.00407585419366.issue28598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: -57 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:31:07 2017 From: report at bugs.python.org (Pedro) Date: Thu, 23 Feb 2017 13:31:07 +0000 Subject: [issue29632] argparse values for action in add_argument() should be flags instead of (or in addition to) strings Message-ID: <1487856667.94.0.619514979386.issue29632@psf.upfronthosting.co.za> New submission from Pedro: The possible values for action are currently: 'store' 'store_true' 'store_false' 'store_const' 'append' 'append_const' 'count' 'help' 'version' a subclass of argparse.Action The string values are evidently for backward compatibility with optparse. However, adding the ability to specify these options as flags would make argparse code more maintainable (e.g. IDEs are better at refactoring symbols than strings), bring it in line with other places where a module has built-in flags, like the regex module (re.MULTILINE, re.IGNORECASE, etc.), and expand the use of flags that already exist in argparse (e.g. argparse.SUPPRESS, argparse.REMAINDER). The string values need not be immediately deprecated, but can be made available as the preferred option for new development. See, for example, getName() and setName() in the threading module, which are documented as follows: "Old getter/setter API for name; use it directly as a property instead." A similar suggestion can be provided for argparse flags: "Old action values for backward compatibility; use the flags instead." ---------- messages: 288445 nosy: pgacv2 priority: normal severity: normal status: open title: argparse values for action in add_argument() should be flags instead of (or in addition to) strings type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:32:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 13:32:10 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1487856730.32.0.43842257691.issue28598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +218 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:42:44 2017 From: report at bugs.python.org (Arne de Laat) Date: Thu, 23 Feb 2017 13:42:44 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za> Message-ID: <1487857364.26.0.254348025246.issue28911@psf.upfronthosting.co.za> Changes by Arne de Laat : ---------- pull_requests: +219 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 09:19:15 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 14:19:15 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <1487859555.39.0.29643508789.issue29624@psf.upfronthosting.co.za> Steve Dower added the comment: Creating a repaired installer is possible, though risky (it's easy when I still have the original build handy, but at this stage a rebuild will produce different hashes and make things worse). But I intend to look into that as soon as I can. If the launcher is not already installed, or if an older version is installed, it will be selected by default. So it's a little harder to avoid, and more likely to cause problems for people who don't have 3.6. There's a command line option to just install the launcher (LauncherOnly=1), but nothing in the UI. However, if you install and then uninstall Python, the launcher is left behind (must be uninstalled separately), so that's one way to get it. I'd suggest add/remove Python 3.6, as that will get the latest version of the launcher. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 09:41:58 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 14:41:58 +0000 Subject: [issue18423] Document limitations on -m In-Reply-To: <1373461112.24.0.280779659137.issue18423@psf.upfronthosting.co.za> Message-ID: <1487860918.05.0.937444115896.issue18423@psf.upfronthosting.co.za> Nick Coghlan added the comment: The limitation noted in #18422 was specific to 3.3, as the missing API was added to NamespaceLoader in 3.4. So the current documentation is accurate for recent versions of Python. ---------- nosy: +ncoghlan resolution: -> out of date stage: needs patch -> resolved status: open -> closed versions: +Python 3.3 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 09:56:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Feb 2017 14:56:32 +0000 Subject: [issue29606] urllib FTP protocol stream injection In-Reply-To: <1487609342.46.0.653185585548.issue29606@psf.upfronthosting.co.za> Message-ID: <1487861792.41.0.800642651198.issue29606@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +christian.heimes, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:00:47 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 15:00:47 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487862047.83.0.649938680779.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Just a thought - the TYPEFLAG_NONARGTYPE needs to be copied from the base class if set there, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:12:14 2017 From: report at bugs.python.org (Arne de Laat) Date: Thu, 23 Feb 2017 15:12:14 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za> Message-ID: <1487862734.83.0.231770085415.issue28911@psf.upfronthosting.co.za> Changes by Arne de Laat : ---------- pull_requests: +220 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:15:29 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:15:29 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487862929.7.0.811589576655.issue23890@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:20:20 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:20:20 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1487863220.21.0.541421501523.issue23890@psf.upfronthosting.co.za> Nick Coghlan added the comment: Victor's PR takes a more pragmatic approach to address this problem: rather than adding the ability to clear the frames for an arbitrary exception tree, it just uses a try/finally in a couple of key unittest function definitions to clear the offending circular references by setting them to None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:25:36 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:25:36 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487863536.95.0.848726904186.issue29581@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, the filtering is only applied to the __new__ and __init__ calls on the metaclass, not to the __init_subclass__ call. Showing the last part of an interactive session where I ran the above commands: =========== >>> class AbstractWithInit(ignore_extra_args(Abstract), InitX, x=1): ... pass ... x >>> AbstractWithInit() <__main__.AbstractWithInit object at 0x7f9086694a58> >>> =========== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:29:23 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:29:23 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487863763.07.0.755337461163.issue29581@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, and now I see the typo in the example code, it seems you're right. I was misremembering an earlier more decorator-like variant of the design where we didn't rely on passing the __init_subclass__ arguments through the metaclass constructor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:30:17 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:30:17 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487863817.65.0.574382113948.issue29581@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +Martin.Teichmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:32:34 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 23 Feb 2017 15:32:34 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487863954.92.0.179656831807.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: I had suggested inheriting the TYPEFLAG_NONARGTYPE flag in StructUnionType_new. It requires a minor change to get basedict unconditionally, and then assign if (basedict) dict->flags |= basedict->flags & TYPEFLAG_NONARGTYPE; We need more feedback on this suggested flag, especially to stay consistent with CFFI if possible. Do you know whether CFFI supports passing unions and structs with bitfields in its ABI mode for 64-bit Unix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:38:23 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:38:23 +0000 Subject: [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) In-Reply-To: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> Message-ID: <1487864303.66.0.0584594145683.issue29581@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that the publisher side workaround for this is relatively straightforward: __init_subclass__ implementations that want to be compatible with arbitrary metaclasses will need to take any additional parameters as class attributes (which they may delete), rather than as class header keyword arguments. For 3.7 though, it probably makes sense to update abc.ABCMeta to pass along arbitrary keyword arguments based on the same rationale as used in PEP 487 to justify making this change for type itself: by default, type.__init_subclass__ will still complain about it, but if someone overrides __init_subclass__ to accept additional keyword arguments, doing so will just work. ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:40:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Feb 2017 15:40:30 +0000 Subject: [issue27840] functools.partial: don't copy keywoard arguments in partial_call()? In-Reply-To: <1471962843.41.0.64844621448.issue27840@psf.upfronthosting.co.za> Message-ID: <1487864430.9.0.955543096631.issue27840@psf.upfronthosting.co.za> STINNER Victor added the comment: I reopen the issue to propose to add a comment explaining why the dictionary must always be copied: https://github.com/python/cpython/pull/253 ---------- pull_requests: +221 resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:44:32 2017 From: report at bugs.python.org (Arne de Laat) Date: Thu, 23 Feb 2017 15:44:32 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za> Message-ID: <1487864672.25.0.62664332293.issue28911@psf.upfronthosting.co.za> Changes by Arne de Laat : ---------- pull_requests: +222 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:46:14 2017 From: report at bugs.python.org (aldehoff) Date: Thu, 23 Feb 2017 15:46:14 +0000 Subject: [issue29633] MSI installer does not pass values as SecureProperty from UI Message-ID: <1487864774.78.0.845992185721.issue29633@psf.upfronthosting.co.za> New submission from aldehoff: This is a revival of issue 1298962 (http://bugs.python.org/issue1298962) from 2009. I can reproduce the problem with an MSI created by cx_Freeze and bdist_msi on a Windows 7 64bit system in a company domain. Python is at version 3.6.0, cx_Freeze is at 5.0.1. I am a user with elevated user rights but not an admin. When installing the MSI, the files are always copied to C:\, whether I have changed the installation directory in GUI or stuck to the default path 'C:\Program Files (x86)\foo'. The program is executable and runs fine. The Uninstaller removes all files without a trace. Following the suggestions from issue 1298962 I have modified the MSI tables in Orca by adding a new Property entry with key 'SecureCustomProperties' and value 'TARGETDIR' fixes the MSI. It now installs into the desired directory. I can reproduce this on multiple builds. ---------- components: Installation, Windows messages: 288455 nosy: aldehoff, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: MSI installer does not pass values as SecureProperty from UI type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:46:55 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Feb 2017 15:46:55 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487864815.86.0.809682515028.issue28814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks mbusson, berker.peksag! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:51:11 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Feb 2017 15:51:11 +0000 Subject: [issue29632] argparse values for action in add_argument() should be flags instead of (or in addition to) strings In-Reply-To: <1487856667.94.0.619514979386.issue29632@psf.upfronthosting.co.za> Message-ID: <1487865071.95.0.343590599803.issue29632@psf.upfronthosting.co.za> R. David Murray added the comment: The obvious thing to do would be to make the Action subclasses have public names. I personally would continue to use the strings, though, as they are easier to type. (The same would be true if an enum were introduced (that I'd continue to use the stings because they are easier to type :), since they would need to be namespaced (argparse.action.store_true, for example).) I can see some potential value in exposing the action subclasses, but I'm not sure if it is worth it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:55:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Feb 2017 15:55:50 +0000 Subject: [issue29465] Modify _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1487865350.37.0.745703865394.issue29465@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Add _PyObject_FastCall() to reduce stack consumption -> Modify _PyObject_FastCall() to reduce stack consumption _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:00:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Feb 2017 16:00:47 +0000 Subject: [issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects In-Reply-To: <1484310274.99.0.832491900546.issue29259@psf.upfronthosting.co.za> Message-ID: <1487865647.58.0.58858551485.issue29259@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't completely reject the issue. I may come back later if I find a way to make it even more efficient. But I prefer to close the issue as REJECTED to make it clear that right now with the current implementation and benchmark results, it's not worth it. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:38:51 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 23 Feb 2017 16:38:51 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1487867931.73.0.62574474993.issue29598@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Note that there is a bug in find_function() (it opens a file with default encoding). Please open an issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:39:23 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 16:39:23 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 Message-ID: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> New submission from Louie Lu: There is a XXX in v3.5.0 shows that need to dealing with deque maxlen setting case in deque_repeat. Although there have common case for deque size 1 with maxlen, other size of deque with maxlen still using for-loop to extend the deque, without any detection. Adding this fast break will reduce the execution speed when repeat deque with maxlen. --- $ cat tests.py from collections import deque for _ in range(10: d = deque(maxlen=100_000) d.insert(0, 0) d.insert(0, 10) d * 10_000_000 $ time ./python_with_patch tests.py $ time ./python tests.py ---------- components: Extension Modules messages: 288460 nosy: louielu priority: normal severity: normal status: open title: Reduce deque repeat execution when maxlen exist and size is not 1 type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:44:46 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 16:44:46 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487868286.91.0.321367815332.issue29634@psf.upfronthosting.co.za> Changes by Louie Lu : ---------- pull_requests: +223 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:52:07 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 16:52:07 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487868727.03.0.801782249078.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: > We need more feedback on this suggested flag, especially to stay consistent with CFFI if possible. Undoubtedly, more feedback would be very helpful. I'm not sure using this flag impacts on consistency with CFFI particularly, since it's an internal implementation detail. Its main purpose would be for ctypes to raise exceptions rather than leading to crashes or undefined behaviour, as we have at the moment. > Do you know whether CFFI supports passing unions and structs with bitfields in its ABI mode for 64-bit Unix? I don't believe so, but I'm relatively new to this area. I'm not sure if things have changed recently, but an analogous CFFI issue was closed as WONTFIX in 2015, citing lack of support in libffi: https://bitbucket.org/cffi/cffi/issues/150/structs-with-bit-fields-as-arguments Also, the latest CFFI documentation, near the bottom of this section: https://cffi.readthedocs.io/en/latest/using.html#function-calls says: "The limitations are that you cannot pass directly as argument or return type: * a union (but a pointer to a union is fine); * a struct which uses bitfields (but a pointer to such a struct is fine);" The documentation applies these limitations regardless of any specific ABI (presumably to provide consistency). So, I would guess that, as with ctypes, lack of libffi support is the main obstacle. I suppose one would have to seriously consider contributing there to make much headway here. In this still-open issue from 2013: https://github.com/libffi/libffi/issues/33 Anthony Green of libffi said he'd welcome a patch, in response to a question by Eli Bendersky. Of course, it may be hard for individual contributors to support this for the range of architectures that libffi covers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:56:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 16:56:24 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487868984.78.0.712369568166.issue29634@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wouldn't be better to update the number of repeats before the loop rather than checking at every iteration? if (deque->maxlen >= 0 && n * size > deque->maxlen) n = (deque->maxlen + size - 1) / size; ---------- assignee: -> rhettinger nosy: +rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:58:48 2017 From: report at bugs.python.org (Lisa Roach) Date: Thu, 23 Feb 2017 16:58:48 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487869128.98.0.226796937961.issue29549@psf.upfronthosting.co.za> Changes by Lisa Roach : ---------- pull_requests: +225 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 12:01:30 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 17:01:30 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487869290.7.0.513398885382.issue29634@psf.upfronthosting.co.za> Louie Lu added the comment: Serhiy: yes, your advice is better than checking inside the loop. I have updated this to the commit, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 12:02:00 2017 From: report at bugs.python.org (Lisa Roach) Date: Thu, 23 Feb 2017 17:02:00 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487869320.35.0.112114449724.issue29549@psf.upfronthosting.co.za> Lisa Roach added the comment: I'll just go ahead and make my PR, let me know what else needs to be done. Serhiy, if you could point me in the direction of how to write the docstring so that it is in the Argument Clinic style I would be happy to take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 12:09:07 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 23 Feb 2017 17:09:07 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect In-Reply-To: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> Message-ID: <1487869747.93.0.300823781377.issue28814@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Thanks Nick for finding this ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 12:48:48 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Feb 2017 17:48:48 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487872128.56.0.176013872924.issue29622@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 13:22:57 2017 From: report at bugs.python.org (Garvit) Date: Thu, 23 Feb 2017 18:22:57 +0000 Subject: [issue24024] str.__doc__ needs an update In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> Message-ID: <1487874177.25.0.0358144410201.issue24024@psf.upfronthosting.co.za> Changes by Garvit : ---------- pull_requests: +227 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 13:31:00 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 18:31:00 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks Message-ID: <1487874660.16.0.665818668363.issue29635@psf.upfronthosting.co.za> Changes by Fabien Dubosson : ---------- components: Interpreter Core nosy: StreakyCobra priority: normal severity: normal status: open title: os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 13:40:29 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 18:40:29 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks Message-ID: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> New submission from Fabien Dubosson: When using bash, the `cd` function does not follow symlinks by default, but `cd -P` does. The `os.chdir` function behaves like `cd -P` preventing to be able to change directory to a symlink folder. Initial setup (make a `/tmp/to/dst` symlink pointing to `/tmp/from/src`): cd /tmp mkdir from from/src to ln -s ../from/src to/dst Here is an example, when using python's `os.chdir` function: [fabien at asus ~]$ python >>> import os >>> os.chdir('/tmp/to/dst') >>> os.system('/usr/bin/pwd') /tmp/from/src 0 >>> os.system('/usr/bin/pwd -P') /tmp/from/src 0 >>> os.system('/usr/bin/pwd -L') /tmp/from/src 0 >>> os.getcwd() '/tmp/from/src' >>> And here is an example when the folder is first changed with bash: [fabien at asus ~]$ cd /tmp/to/dst/ [fabien at asus dst]$ python >>> import os >>> os.system('/usr/bin/pwd') /tmp/from/src 0 >>> os.system('/usr/bin/pwd -P') /tmp/from/src 0 >>> os.system('/usr/bin/pwd -L') /tmp/to/dst 0 >>> os.getcwd() '/tmp/from/src' >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 13:49:34 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 18:49:34 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487875774.14.0.770574732307.issue29635@psf.upfronthosting.co.za> Fabien Dubosson added the comment: The previous example (sorry, first time using this platform, I'm a little bit messy here), shows that `os.chdir` resolves symlinks by default, as opposed to what `cd` does in bash. This means it is not possible to change the directory to a symlink folder. A solution would be a keyword argument in `os.chdir` and `os.getcwd` that would mimic the `-P` and `-L` arguments of `cd` and `pwd`, like: os.chdir(logical=False) # or follow_symlinks=True maybe os.getcwd(logical=False) I don't know what should be the default values for these args, but at least having an option to change the behavior would be nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:20:45 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Feb 2017 19:20:45 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487877645.61.0.779737908065.issue29635@psf.upfronthosting.co.za> R. David Murray added the comment: The function is chdir, not cd. The 'cd' man page says that 'cd -P' should "perform actions equivalent to the chdir() function". So, you are asking for a different function, which should *not* be named 'os.chdir'. You'll have to make a case for it being useful enough to add. The same applies to getcwd, which is also a wrapper for the posix function, not an emulation of the shell's pwd. ---------- components: +Library (Lib) -Interpreter Core nosy: +r.david.murray versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:21:09 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 23 Feb 2017 19:21:09 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487877669.43.0.696726731285.issue29549@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for the PR, Lisa. Serhiy, Raymond, could you both review this? Thanks. I can do the merge and backport once it gets both of your approval :) Also,should this be applied to 3.5 too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:21:20 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Feb 2017 19:21:20 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487877680.86.0.545363584364.issue29635@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:26:24 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 23 Feb 2017 19:26:24 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487877984.15.0.0938984303775.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: > I'm not sure using this flag impacts on consistency with CFFI I meant consistency with respect to supported argument types. If someone contributed a workaround to CFFI, then I would rather port it, but it looks like they're also waiting for this to be addressed upstream. It occurs to me that in the 1st pass, it also needs to propagate the non-argument flag from any field that has it set. This should be done for all platforms, not just X86_64. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:28:53 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 19:28:53 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <1487878133.68.0.177845622557.issue29624@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +228 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:29:23 2017 From: report at bugs.python.org (Garvit Khatri) Date: Thu, 23 Feb 2017 19:29:23 +0000 Subject: [issue10379] locale.format() input regression In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za> Message-ID: <1487878163.49.0.473486811383.issue10379@psf.upfronthosting.co.za> Changes by Garvit Khatri : ---------- pull_requests: +229 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:30:31 2017 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 23 Feb 2017 19:30:31 +0000 Subject: [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) In-Reply-To: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> Message-ID: <1487878231.7.0.572557062154.issue29625@psf.upfronthosting.co.za> Mark Dickinson added the comment: No problem. I did spend some time wondering whether `rgb_to_hsv` still gives the correct results if any of the inputs happens to be an integer (though still in the range [0, 1]). It looks as though it does, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:44:46 2017 From: report at bugs.python.org (John Florian) Date: Thu, 23 Feb 2017 19:44:46 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487879086.93.0.981652111016.issue14243@psf.upfronthosting.co.za> John Florian added the comment: I just stumbled onto this though I'm not writing for Windows. Instead, I'm on Fedora 25 with Python 3.5.2 and I went nearly crazy tracing down what seemed to be inconsistent behavior. My use case has Python using NamedTemporaryFile(delete=True) in a CM to produce content fed into a subprocess. The code had been reliably working and then it just didn't. The only thing changing was the content being written, an rendered Jinja2 template. I believe the fate is determined by the content length. In debugging another problem, I'd been trivializing the template and once it got down to about 3k (rendered) the subprocess began seeing a file whose length was 0 bytes. Make the template bigger and all works again. Calling close() resolves the issue, but of course requires delete=False which removed much of the value of this object. Preliminary testing looks like flush() may also resolve the issue. Have I just been naive and getting lucky all along because this is expected or is there something else fishy here worth investigation? ---------- nosy: +John Florian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:52:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 19:52:06 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487879526.23.0.110879396617.issue29635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 'cd' is not an external command and has no manpage. It is a shell builtin command. Most os functions are thin wrappers around system calls. There is no system call that works as 'cd' without '-P'. If you implement a shell in Python, you perhaps need an implementation of the 'cd' command. But I have doubts that this is needed in the stdlib. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 14:59:18 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 19:59:18 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487879958.31.0.968292212813.issue29635@psf.upfronthosting.co.za> Fabien Dubosson added the comment: Thanks for the additional information! > The 'cd' man page says that 'cd -P' should "perform actions equivalent to the chdir() function". Just wondering, do you know what is the function called by `cd`/`cd -L` then? It doesn't seems to be a bash internal tweak because `/usr/bin/pwd -L` is able to get the symlink path, and this binary is not part of bash. > You'll have to make a case for it being useful enough to add. The use case is for shells written in Python, like for instance `xonsh` [1,2]. Being powered by Python, the only way to change directory is by using `os.chdir()`. It is then not possible to mimic the bash `cd` function without using workarounds, like for instance storing the symlink path in a variable, and even this doesn't allow to use `/usr/bin/pwd -L` in scripts because it would always returns the physical location. Having such described functions (yet to be named) would permit python shells to offer users differentiated `cd` and `cd -P` commands, as well as having `pwd -L` in scripts behaving the same than in traditional shells. [1] http://xon.sh/ [2] https://github.com/xonsh/xonsh ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:01:24 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Feb 2017 20:01:24 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487880084.8.0.75762967646.issue29635@psf.upfronthosting.co.za> R. David Murray added the comment: Since yours is the itch, I'm afraid you are going to have to be the one to figure out how this could be implemented :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:02:43 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 20:02:43 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <1487880163.97.0.637452027517.issue29624@psf.upfronthosting.co.za> Steve Dower added the comment: I have built an updated web installer which should allow us to replace just the one file on the server to fix the issue. The only downside is that it is not compatible with existing installs of 3.5.3 (that is, you can't run the executable to Modify/Repair/Remove an existing install, but unless you've corrupted your machine you can do those through Programs and Features). If anyone would like to test it, I've attached the file here. I've done one test on my own machine (separate from the build machine) including installing the launcher and all optional components and it was fine, but some more validation before I replace the existing executable would be nice. (Added RM Larry as FYI. This doesn't affect anything else.) AFAICT so far, it appears to have been a build glitch where the launcher MSI was rebuilt in between 32-bit and 64-bit builds (the weird part here is that the rebuild was correct and the initial build was wrong, which is backwards from what I'd expect...). The upload included the rebuilt MSI but the bootstrapper was expecting the initial build. I'm still trying to track down why that happened, but in the meantime I've added a test (PR 258) to my upload script that will detect problems like this before we announce the release. ---------- nosy: +larry Added file: http://bugs.python.org/file46665/python-3.5.3-webinstall.exe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:05:48 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 20:05:48 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487880348.74.0.288670601617.issue29635@psf.upfronthosting.co.za> Fabien Dubosson added the comment: > Most os functions are thin wrappers around system calls. There is no system call that works as 'cd' without '-P'. I would like to believe in this, but then if `cd` is some bash internal, how does `/usr/bin/pwd -L` find it back? > Since yours is the itch, I'm afraid you are going to have to be the one to figure out how this could be implemented :) Once I'll have figured out how all this is working, maybe. Not sure it would me in my competencies though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:05:57 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Thu, 23 Feb 2017 20:05:57 +0000 Subject: [issue29636] Specifying indent in the json.tool command Message-ID: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> New submission from Daniel Himmelstein: The utility of `python -m json.tool` would increase if users could specify the indent level. Example use case: newlines in a JSON document are important for readability and the ability to open in a text editor. However, if the file is large, you can save space by decreasing the indent level. I added an --indent argument to json.tool in https://github.com/python/cpython/pull/201. However, design discussion is required since indent can take an int, string, or None. In addition, a indent string is a tab, which is difficult to pass via a command line argument. Currently, I added the following function to convert the indent option to the indent parameter of json.dump: ``` def parse_indent(indent): """Parse the argparse indent argument.""" if indent == 'None': return None if indent == r'\t': return '\t' try: return int(indent) except ValueError: return indent ``` @inada.naoki mentioned the special casing is undesirable. I agree, but can't think of an alternative. Advice appreciated. ---------- components: IO messages: 288479 nosy: dhimmel, inada.naoki priority: normal pull_requests: 230 severity: normal status: open title: Specifying indent in the json.tool command type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:07:01 2017 From: report at bugs.python.org (Petr MOTEJLEK) Date: Thu, 23 Feb 2017 20:07:01 +0000 Subject: [issue29615] SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch In-Reply-To: <1487709025.37.0.198613157816.issue29615@psf.upfronthosting.co.za> Message-ID: <1487880421.47.0.599146417172.issue29615@psf.upfronthosting.co.za> Changes by Petr MOTEJLEK : ---------- pull_requests: +231 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:07:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 20:07:16 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487880436.28.0.741573330943.issue29635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Just wondering, do you know what is the function called by `cd`/`cd -L` then? It doesn't seems to be a bash internal tweak because `/usr/bin/pwd -L` is able to get the symlink path, and this binary is not part of bash. See shells sources. According to the manpage `pwd -L` just uses PWD from environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:10:42 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Thu, 23 Feb 2017 20:10:42 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1487880642.79.0.878904800514.issue27413@psf.upfronthosting.co.za> Changes by Daniel Himmelstein : ---------- pull_requests: +232 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:13:27 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Feb 2017 20:13:27 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487880807.52.0.289647915425.issue29635@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, that should all be implementable from your python shell, then, no need for support in the os module. For reference, when I said 'cd man page', this is what I was referring to: http://www.unix.com/man-page/posix/1posix/cd/ I'm going to close this issue. If you find you do need access to some system interface the os module doesn't currently provide, you can open a specific issue for that. ---------- resolution: -> rejected stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:16:01 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 20:16:01 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487880961.74.0.571636764363.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: > It occurs to me that in the 1st pass, it also needs to propagate the non-argument flag from any field that has it set. So does that mean disallowing a structure which contains a union? What about if the final structure is large enough to require passing in memory rather than registers, so that libffi doesn't need to do any clever marshalling, even if some part of the structure wouldn't by itself be able to be passed as an argument in a call? Won't that end up being too restrictive? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:20:29 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 20:20:29 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487881229.28.0.255612965686.issue29635@psf.upfronthosting.co.za> Fabien Dubosson added the comment: > I'm going to close this issue. I was doing to do so, here was my message: -------------------------------------------- > See shells sources. According to the manpage `pwd -L` just uses PWD from environment. I looked directly at `pwd` sources, and indeed it is using $PWD [1]. [1] http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/pwd.c?id=509152bdd47a278dc00ddaf3200ac65044b836b1#n305 So it looks like `cd -L` is just some bash internal dealing with $PWD. Probably not something useful enough to be in the standard library, closing it then. Sorry for the incovenience ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:31:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 20:31:00 +0000 Subject: [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks In-Reply-To: <1487875229.83.0.0508905375261.issue29635@psf.upfronthosting.co.za> Message-ID: <1487881860.35.0.0589244796523.issue29635@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:06:00 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 23 Feb 2017 21:06:00 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation In-Reply-To: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> Message-ID: <1487883960.13.0.503692937848.issue29455@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +233 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:08:45 2017 From: report at bugs.python.org (Mo Jia) Date: Thu, 23 Feb 2017 21:08:45 +0000 Subject: [issue29191] liblzma is missing from pcbuild.sln In-Reply-To: <1483778935.32.0.9795840646.issue29191@psf.upfronthosting.co.za> Message-ID: <1487884125.54.0.10718092241.issue29191@psf.upfronthosting.co.za> Mo Jia added the comment: I think let user add the liblzma project by hand is not good enough. While the build.bat don't have this problem. So they should work similar. ---------- nosy: +Mo.Jia versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:10:58 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 23 Feb 2017 21:10:58 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1487884258.1.0.224134100907.issue29414@psf.upfronthosting.co.za> Marco Buttu added the comment: Hello Jim, do you have the time to make a pull request? Let me know, otherwise I will do it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:32:14 2017 From: report at bugs.python.org (Marco Buttu) Date: Thu, 23 Feb 2017 21:32:14 +0000 Subject: [issue16355] inspect.getcomments() does not work in the interactive shell In-Reply-To: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za> Message-ID: <1487885534.78.0.884042962771.issue16355@psf.upfronthosting.co.za> Marco Buttu added the comment: Hello Vajrasky, the doc patch LGTM. Looking at the David's comment in Rietveld, it seems that he does not want the test patch to be applyed. Can you please make a pull request? Thank you very much ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:50:11 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 23 Feb 2017 21:50:11 +0000 Subject: [issue29637] ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' Message-ID: <1487886611.55.0.299835659711.issue29637@psf.upfronthosting.co.za> New submission from Jakub Wilk: With git master (4c78c527d215c37472145152cb0e95f196cdddc9) I get this: >>> import ast >>> ast.get_docstring(ast.parse('')) Traceback (most recent call last): File "", line 1, in File "/home/jwilk/opt/lib/python3.7/ast.py", line 203, in get_docstring text = inspect.cleandoc(text) File "/home/jwilk/opt/lib/python3.7/inspect.py", line 590, in cleandoc lines = doc.expandtabs().split('\n') AttributeError: 'NoneType' object has no attribute 'expandtabs' ---------- messages: 288488 nosy: inada.naoki, jwilk priority: normal severity: normal status: open title: ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:53:13 2017 From: report at bugs.python.org (Francis Deslauriers) Date: Thu, 23 Feb 2017 21:53:13 +0000 Subject: [issue28909] Adding LTTng-UST tracing support In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za> Message-ID: <1487886793.32.0.305824819736.issue28909@psf.upfronthosting.co.za> Francis Deslauriers added the comment: I am finally having the time to work in this. > A nit: the name LTTng-UST is rather unfriendly, especially when used without the dash and in all lowercase characters. Given that we're using "dtrace" and "systemtap", it would be simpler to just use "lttng" (drop the "-ust"). We can certainly drop the "-ust" and have the name in lowercase. > It's impossible to have DTrace and SystemTap at the same time, so it was natural to choose to auto-detect the engine. With LTTng it becomes less obvious what the configure options should be. > Should it be possible at all to have *both* LTTng and SystemTap compiled in at the same time? Does this make sense? It's possible to have both SystemTap and LTTng in the same binary. LTTng-UST has a configure option `--with-sdt` to include a SystemTap SDT probe alongside each LTTng-UST tracepoint. I don't have a specific usecase in mind but I can picture a setup where a binary is instrumented with both frameworks and the users either decide to use the low overhead tracing of LTTng or the versatile runtime aggregation of SystemTap depending on the problem they are trying to diagnose. So I think keeping both configure options makes sense. > Do you get unused code warnings without your patch applied? I don't. I am getting those errors too on Linux with GCC. I will make sure to fix them in the next round. I am currently working on the tests and documentation and I hope to submit patches for review early next week. Thank you, Francis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:12:10 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 23 Feb 2017 22:12:10 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487887930.4.0.982867480759.issue14243@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:12:31 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 22:12:31 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1487887951.92.0.411449890882.issue27593@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +234 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:13:17 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 22:13:17 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1487887997.57.0.991305373471.issue27593@psf.upfronthosting.co.za> Steve Dower added the comment: It looks to me like we want: branch=`git name-rev --name-only HEAD` revision=`git rev-parse HEAD` tag=`git name-rev --tags --name-only HEAD` Unless we're planning on leaving out the tag? My PR 262 makes the Windows build changes in master, but doesn't change getbuildinfo.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:14:44 2017 From: report at bugs.python.org (Carson Lam) Date: Thu, 23 Feb 2017 22:14:44 +0000 Subject: [issue29514] Add a test case that prevents magic number changes in minor releases In-Reply-To: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> Message-ID: <1487888084.0.0.515087897751.issue29514@psf.upfronthosting.co.za> Changes by Carson Lam : ---------- nosy: +Carson Lam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:14:53 2017 From: report at bugs.python.org (Eryk Sun) Date: Thu, 23 Feb 2017 22:14:53 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487888092.98.0.565348036965.issue22273@psf.upfronthosting.co.za> Eryk Sun added the comment: Perhaps it should instead use two specific flags, TYPEFLAG_HASBITFIELD and TYPEFLAG_HASUNION, which are propagated unconditionally from the base class and fields. As a base case, a union itself is flagged TYPEFLAG_HASUNION. Arrays are unrolled on X86_64 only if neither flag is present and the size is 16 bytes or less. If ConvParam or converters_from_argtypes see either flag on X86_64 and the size is 16 bytes or less, then they raise an exception. As before, this rejects some call signatures that would actually succeed. We're not accounting for the case in which the limited number of registers forces an argument to be passed on the stack even though it's small enough to be passed in registers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:19:06 2017 From: report at bugs.python.org (Peter McCormick) Date: Thu, 23 Feb 2017 22:19:06 +0000 Subject: [issue28909] Adding LTTng-UST tracing support In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za> Message-ID: <1487888346.72.0.604869964422.issue28909@psf.upfronthosting.co.za> Peter McCormick added the comment: Hi ?ukasz, thank you for the feedback! > "PyTrace" is already a name in use for a different purpose. I understand the > itch to make the name more "right" but I am in general not a fan of renaming > "PyDTrace" to anything else now. It was a placeholder from day one (SystemTap > uses it, too, after all). So, looking closer at the patch now I'd prefer us > to keep all existing names and add LTTng as another alternative engine here. > That will make the patch much shorter. What about `PyProbe`? Given the multitude of tools and techniques in this space, wouldn't it be worthwhile to clarify things before adding this? I think conflating `dtrace` and `lttng` would only lead to more confusion for users as they really are distinct technologies. Apart from the `--with{out)-dtrace` configure options, are these terms exposed to users anywhere else? I agree that those options shouldn't be changed now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:19:34 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 22:19:34 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <1487888374.03.0.101847349291.issue29624@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +235 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:19:48 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 22:19:48 +0000 Subject: [issue29624] Python 3.5.3 x86 web installer cannot install launcher In-Reply-To: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> Message-ID: <1487888388.69.0.881440750376.issue29624@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- pull_requests: +236 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:22:56 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 23 Feb 2017 22:22:56 +0000 Subject: [issue29191] liblzma is missing from pcbuild.sln In-Reply-To: <1483778935.32.0.9795840646.issue29191@psf.upfronthosting.co.za> Message-ID: <1487888576.24.0.207762822284.issue29191@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 17:46:07 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Feb 2017 22:46:07 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1487889967.98.0.669175213484.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Perhaps it should instead use two specific flags, TYPEFLAG_HASBITFIELD and TYPEFLAG_HASUNION This seems better at first sight. It's not making any suitability decisions (apart from doing the unrolling), and the meaning of these flags will be less volatile than TYPEFLAG_NONARGTYPE because that assessment depends on current limitations, and those limitations might change over time. I'm going into a period of two weeks where I may not have much time to work on this due to other time commitments, so if you want to press on with it, go right ahead :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:30:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Feb 2017 23:30:03 +0000 Subject: [issue29549] Improve docstring for str.index In-Reply-To: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> Message-ID: <1487892603.95.0.601865180791.issue29549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Write docstrings in following style: "index($self, sub, start=0, end=sys.maxsize, /)\n" "--\n" "\n" "\n" "\n" "" Extract the summary line. Don't use the metavariable "S" since it no longer defined in the signature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:34:37 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 23 Feb 2017 23:34:37 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1487892877.84.0.0191217975718.issue28556@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- pull_requests: +237 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:47:47 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 23 Feb 2017 23:47:47 +0000 Subject: [issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported Message-ID: <1487893667.97.0.185214523378.issue29638@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: This command: ./python -c 'import runpy, typing; runpy.run_module("test")' -R 5:5 test_collections Sometimes gives spurious failures like this: test_collections leaked [0, 0, 3, -3, 3] memory blocks, sum=3 I think this is because ABC caches of typing.ChainMap, typing.Counter, and typing.DefaultDict are not cleared by refleak.py/dash_R_cleanup (presumably because inspect.isabstract returns False on those) Adding a manual clean-up of these cashes to cleanup_cashes() fixes the "leak". ---------- assignee: levkivskyi components: Tests messages: 288495 nosy: gvanrossum, levkivskyi priority: normal severity: normal status: open title: Spurious failures in test_collections in releak hunting mode after typing is imported type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:49:55 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 Feb 2017 23:49:55 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487893795.93.0.835370953985.issue29634@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The code looks fine. Please change the comment to something like: /* Reduce the number of repetitions when maxlen would be exceeded */ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:52:24 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 23 Feb 2017 23:52:24 +0000 Subject: [issue29637] ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' In-Reply-To: <1487886611.55.0.299835659711.issue29637@psf.upfronthosting.co.za> Message-ID: <1487893944.58.0.70292869701.issue29637@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 19:58:15 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 24 Feb 2017 00:58:15 +0000 Subject: [issue29463] Add `docstring` field to AST nodes In-Reply-To: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> Message-ID: <1487897895.34.0.464558554524.issue29463@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +238 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 19:58:16 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 24 Feb 2017 00:58:16 +0000 Subject: [issue29637] ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' In-Reply-To: <1487886611.55.0.299835659711.issue29637@psf.upfronthosting.co.za> Message-ID: <1487897896.43.0.370483952144.issue29637@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +239 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 19:58:16 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 24 Feb 2017 00:58:16 +0000 Subject: [issue29622] ast module doesn't support optional fields of Parser/Python.asdl In-Reply-To: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> Message-ID: <1487897896.65.0.433939062456.issue29622@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +240 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 20:09:15 2017 From: report at bugs.python.org (paul j3) Date: Fri, 24 Feb 2017 01:09:15 +0000 Subject: [issue29632] argparse values for action in add_argument() should be flags instead of (or in addition to) strings In-Reply-To: <1487856667.94.0.619514979386.issue29632@psf.upfronthosting.co.za> Message-ID: <1487898555.72.0.531133632371.issue29632@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 20:29:52 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Feb 2017 01:29:52 +0000 Subject: [issue18792] test_ftplib timeouts In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za> Message-ID: <1487899792.53.0.913852424219.issue18792@psf.upfronthosting.co.za> Gregory P. Smith added the comment: FYI - hardcoding these addresses is now causing me problems as I try to get our test suite passing on IPv6 only hosts. "localhost" is correct. IMNSHO if for some reason a system cannot resolve "localhost" into a correct address, it should be banned from running any form of networking related test. :/ I should not have to write messy conditional code to try and determine which type of socket I will likely need to bind to to determine which format of IP address string I need to supply as the localhost bind address. That is backwards! ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 20:34:57 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Feb 2017 01:34:57 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 Message-ID: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I am working on fixing our test suite to run on IPv6 only hosts (which are becoming a reality). Many failures today occur because of hard coded 127.0.0.1 values. This is wrong. We should refer to "localhost" The "solution" to https://bugs.python.org/issue18792 moved us backwards towards hard coding IP version type specific addresses claiming that windows cannot handle resolving localhost reliably. On any windows system where that is the case we should declare the system broken and simply not run any networking related tests. ---------- components: Tests messages: 288498 nosy: gregory.p.smith priority: normal severity: normal status: open title: test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 20:35:26 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Feb 2017 01:35:26 +0000 Subject: [issue18792] test_ftplib timeouts In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za> Message-ID: <1487900126.82.0.0945363811943.issue18792@psf.upfronthosting.co.za> Gregory P. Smith added the comment: https://bugs.python.org/issue29639 opened to track undoing this when appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 21:08:13 2017 From: report at bugs.python.org (paul j3) Date: Fri, 24 Feb 2017 02:08:13 +0000 Subject: [issue29632] argparse values for action in add_argument() should be flags instead of (or in addition to) strings In-Reply-To: <1487856667.94.0.619514979386.issue29632@psf.upfronthosting.co.za> Message-ID: <1487902093.48.0.614888486992.issue29632@psf.upfronthosting.co.za> paul j3 added the comment: Those strings are defined in a 'parser.registry' dictionary, with expressions like self.register('action', 'store', _StoreAction) (Users can also register their own custom classes. The registry can also be used for the 'type' attribute.) So you can already do: parser.add_argument('--foo', action=argparse._StoreAction) So I don't think we need another mapping like argparse.STORE_ACTION = argparse._StoreAction I think these Action subclasses are not part of the API because users should never instantiate one directly. It should always be done via the 'add_argument' method. But on occasion it is handy to grab one of the Action objects when it is returned by add_argument, and display or even modify one of its attributes. Some users are reluctant to do so because that's not documented. Some of the `nargs` values have constants names in addition to the string values. argparse.REMAINDER = '...' argparse.OPTIONAL = '?' so on for '+', '*', and even '+...'. Users almost always use the strings, while the code always uses the constant. But because `argparse._StoreAction` is a class, with its own defined methods, there's never a need to test for its 'value' or identity. So the code does not need a `argparse.STORE_ACTION flag. So for end users, and for internal code use, the current use of subclasses and the registry is works, and doesn't need to be changed just to look more like other modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 21:30:35 2017 From: report at bugs.python.org (Louie Lu) Date: Fri, 24 Feb 2017 02:30:35 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487903435.37.0.0391098124169.issue29634@psf.upfronthosting.co.za> Louie Lu added the comment: Raymond: comment has changed, pushed on to GitHub. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 22:07:26 2017 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 Feb 2017 03:07:26 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487905646.73.0.869021839102.issue14243@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 22:11:01 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 24 Feb 2017 03:11:01 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1487905861.35.0.703148925332.issue28556@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +241 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 22:15:00 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 24 Feb 2017 03:15:00 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1487906100.22.0.158873960394.issue28556@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +242 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 22:59:36 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 24 Feb 2017 03:59:36 +0000 Subject: [issue26184] raise an error when create_module() is not defined by exec_module() is for loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1487908776.7.0.253409700114.issue26184@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: should be closed by #28026, it now raises an ImportError. I think this can be closed. Unless one want to change the text in Starting in Python 3.6 it will be an error > Starting in Python 3.6 it will be an error To use the past tense. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 23:00:41 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 24 Feb 2017 04:00:41 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487908841.08.0.485738878883.issue29634@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 23:50:21 2017 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Feb 2017 04:50:21 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487911821.0.0.734395237207.issue27788@psf.upfronthosting.co.za> Berker Peksag added the comment: Perhaps it's now time to drop that __version__ attribute in 3.7? We've removed the __version__ attribute from the email module in issue 22508. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 02:04:09 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 07:04:09 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487919849.21.0.86667934839.issue14243@psf.upfronthosting.co.za> Nick Coghlan added the comment: John, your problem sounds different - if you're opening the files in binary mode, then you'll be getting a default buffer that's probably 4k or 8k in size, so if you're writing less content than that, the subprocess won't see anything until you explicitly flush() the buffer to disk (and even if you're writing more than that, the subprocess may see a truncated version without an explicit flush()). By contrast, the issue here relates to the fact that on Windows it's currently necessary to do the following in order to get multiple handles to a NamedTemporaryFile: 1. Open the file in the current process 2. Write content to the file 3*. Close the file in the current process 4. Open the file by name in another process (or the current process) 5. Read content from the file 6. Close the second file handle 7*. Delete the file *On POSIX systems, you can just skip step 3 and leave closing the original file handle until step 7, and that's the design that the current NamedTemporaryFile is built around. Most of the discussion above is about figuring out how to make that same approach "just work" on Windows (perhaps with some additional flags used in step 4), rather than providing a third option beyond the current delete-on-close and delete-manually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 02:07:11 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 07:07:11 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1487920031.54.0.0889003621671.issue26184@psf.upfronthosting.co.za> Nick Coghlan added the comment: That should actually be a versionchanged note now - converting this to an easy documentation issue to cover that change. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core keywords: +easy nosy: +docs at python stage: test needed -> needs patch title: raise an error when create_module() is not defined by exec_module() is for loaders -> Add versionchanged note for error when create_module() is not defined by loaders versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 02:08:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 07:08:46 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487920126.29.0.626280516911.issue29537@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 02:09:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 07:09:02 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487920142.23.0.705909174448.issue29537@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 02:17:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 07:17:30 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487920650.89.0.868850217015.issue29537@psf.upfronthosting.co.za> Nick Coghlan added the comment: For easier cross-referencing, note that http://bugs.python.org/issue29514 is the issue proposing a test case that ensures future maintainers are aware of the practical problems created by bumping the bytecode magic number in a maintenance release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 03:10:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Feb 2017 08:10:05 +0000 Subject: [issue29615] SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch In-Reply-To: <1487709025.37.0.198613157816.issue29615@psf.upfronthosting.co.za> Message-ID: <1487923805.36.0.424034341706.issue29615@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +loewis, serhiy.storchaka stage: -> patch review type: -> behavior versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 03:15:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Feb 2017 08:15:54 +0000 Subject: [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 In-Reply-To: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> Message-ID: <1487924154.62.0.330422627133.issue29634@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is an opportunity of further optimisation. For example deque(range(100000), maxlen=100001) *= 2 copies 100000 elements while it is enough to copy just 1 element. But I don't know whether it is worth to optimise this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 03:23:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 08:23:37 +0000 Subject: [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 In-Reply-To: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> Message-ID: <1487924617.57.0.610943227002.issue29537@psf.upfronthosting.co.za> Nick Coghlan added the comment: I updated the PR to cover both Serhiy's change to make the legacy bytecode safe to interpret, and a tweaked version of Petr's change to allow the legacy bytecode to be imported. The main tweaks to the latter were: - more in depth comments explaining the changes - switching the C level changes to rely on a couple of extern variables exported from import.c rather than scattering the backwards compatibility numbers throughout the code I'm also cc'ing Larry into the discussion as 3.5 release manager. Larry, most of the context for this change is actually in http://bugs.python.org/issue29514 where we reported the problems with the magic number change that prompted Petr to create a downstream patch for Fedora to restore compatibility with the legacy bytecode magic number. While the answer for 3.6+ is "Let's try to avoid ever doing this again", it turns out this is tricky enough to handle that it would be nice to have a shared solution upstream in 3.5.4+ that redistributors can collectively adopt, rather than everyone needing to come up with their own workaround for the problem. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 03:44:52 2017 From: report at bugs.python.org (Michael Haubenwallner) Date: Fri, 24 Feb 2017 08:44:52 +0000 Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and later) In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> Message-ID: <1487925892.39.0.284188562445.issue27435@psf.upfronthosting.co.za> Michael Haubenwallner added the comment: Let's switch to github-based patches to discuss about: https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7 For the library search path I prefer to use loadquery(L_GETLIBPATH), available via new _ctypes_aix module now, but also used with L_GETINFO in Python/dynload_aix.c already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 03:54:29 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 24 Feb 2017 08:54:29 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1487926469.49.0.142912792294.issue28556@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- pull_requests: +243 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 04:03:58 2017 From: report at bugs.python.org (=?utf-8?b?SsOhbiBTdGFuxI1law==?=) Date: Fri, 24 Feb 2017 09:03:58 +0000 Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent key list Message-ID: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za> New submission from J?n Stan?ek: Following crash is sporadically observed in RHEL7 anaconda: (gdb) f 0 #0 PyThread_ReInitTLS () at /usr/src/debug/Python-2.7.5/Python/thread.c:411 411 if (p->id != id) { (gdb) list 406 keymutex = PyThread_allocate_lock(); 407 408 /* Delete all keys which do not match the current thread id */ 409 q = &keyhead; 410 while ((p = *q) != NULL) { 411 if (p->id != id) { 412 *q = p->next; 413 free((void *)p); 414 /* NB This does *not* free p->value! */ 415 } (gdb) p p $1 = (struct key *) 0x3333333333333333 (gdb) p keyhead $2 = (struct key *) 0x3333333333333333 key list is protected by keymutex (except for PyThread_ReInitTLS), but there doesn't seem to be any protection against concurrent fork(). What seems to happen is fork() at the moment when key list is not consistent. For example, if I initialize new key to 0xfe: static struct key *find_key(int key, void *value) // find_key with extra memset() ... p = (struct key *)malloc(sizeof(struct key)); memset(p, 0xfe, sizeof(struct key)); if (p != NULL) { p->id = id; p->key = key; p->value = value; p->next = keyhead; keyhead = p; } ... Looking at disassembly, compiler reordered last 2 writes: 0x00000000004fcb50 <+272>: callq 0x413d10 0x00000000004fcb55 <+277>: movabs $0xfefefefefefefefe,%rcx 0x00000000004fcb5f <+287>: test %rax,%rax 0x00000000004fcb62 <+290>: mov %rcx,(%rax) 0x00000000004fcb65 <+293>: mov %rcx,0x8(%rax) 0x00000000004fcb69 <+297>: mov %rcx,0x10(%rax) 0x00000000004fcb6d <+301>: mov %rcx,0x18(%rax) 0x00000000004fcb71 <+305>: je 0x4fcaff 0x00000000004fcb73 <+307>: mov 0x2f1e26(%rip),%rdx # 0x7ee9a0 0x00000000004fcb7a <+314>: mov 0x2f1dff(%rip),%rdi # 0x7ee980 0x00000000004fcb81 <+321>: xor %r14d,%r14d 0x00000000004fcb84 <+324>: mov %rbp,0x8(%rax) 0x00000000004fcb88 <+328>: mov %r12d,0x10(%rax) 0x00000000004fcb8c <+332>: mov %r13,0x18(%rax) 0x00000000004fcb90 <+336>: mov %rax,0x2f1e09(%rip) # 0x7ee9a0 0x00000000004fcb97 <+343>: mov %rdx,(%rax) Now consider what happens, when different threads call fork() in between these 2 writes: we updated keyhead, but keyhead->next has not been updated yet. Now when anaconda hangs, I get: (gdb) list 407 keymutex = PyThread_allocate_lock(); 408 409 /* Delete all keys which do not match the current thread id */ 410 q = &keyhead; 411 while ((p = *q) != NULL) { 412 if (p->id != id) { 413 *q = p->next; 414 free((void *)p); 415 /* NB This does *not* free p->value! */ 416 } (gdb) p p $1 = (struct key *) 0xfefefefefefefefe (gdb) p keyhead $2 = (struct key *) 0xfefefefefefefefe Here's how I think we get into this state: -------------------------> thread 1 # has GIL Thread.start _start_new_thread(self.__bootstrap, ()) PyThread_start_new_thread(t_bootstrap) # spawns thread 3 -------------------------> thread 2 ... # waiting for GIL -------------------------> thread 3 t_bootstrap _PyThreadState_Init # does not have GIL yet at this point _PyGILState_NoteThreadState PyThread_set_key_value(autoTLSkey, (void *)tstate) find_key # key list is temporarily not consistent # due to compiler reordering couple writes in find_key -------------------------> thread 1 continuing Thread.start self.__started.wait() Event.wait() self.__cond.wait Condition.wait() waiter = _allocate_lock() waiter.acquire() lock_PyThread_acquire_lock Py_BEGIN_ALLOW_THREADS PyEval_SaveThread PyThread_release_lock(interpreter_lock); -------------------------> thread 2 ... # acquired GIL os.fork() # forks inconsistent list -------------------------> child PyOS_AfterFork() PyThread_ReInitTLS() SIGSEGV Attached patch for python makes it easier to reproduce, by adding delays to couple places to make window key list is not consistent larger. ---------- components: Interpreter Core files: bz1268226_reproducer2.tar.gz messages: 288510 nosy: J?n Stan?ek priority: normal severity: normal status: open title: _PyThreadState_Init and fork race leads to inconsistent key list type: crash versions: Python 2.7 Added file: http://bugs.python.org/file46666/bz1268226_reproducer2.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 04:33:20 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Fri, 24 Feb 2017 09:33:20 +0000 Subject: [issue29104] Left bracket remains in format string result when '\' preceeds it In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za> Message-ID: <1487928800.33.0.982998585015.issue29104@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Serhiy, since review activity has dropped on b.p.o now that the move to github was made, would you like to make this into a pull request to get it reviewed and merged faster? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 04:35:02 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Fri, 24 Feb 2017 09:35:02 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1487928902.89.0.103373458463.issue29414@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Go ahead with making the PR, marco. I'll take a look at it too when you do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 04:45:23 2017 From: report at bugs.python.org (Jacob Mansfield) Date: Fri, 24 Feb 2017 09:45:23 +0000 Subject: [issue1230540] sys.excepthook doesn't work in threads Message-ID: <1487929523.91.0.203788324441.issue1230540@psf.upfronthosting.co.za> Jacob Mansfield added the comment: Does this affect threads started with the multiprocessing library as well? ---------- nosy: +Jacob Mansfield _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:05:50 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 24 Feb 2017 10:05:50 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1487930750.8.0.916701862029.issue20916@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:05:54 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 24 Feb 2017 10:05:54 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1487930754.9.0.0675047545747.issue28747@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:33:39 2017 From: report at bugs.python.org (CyberJacob) Date: Fri, 24 Feb 2017 10:33:39 +0000 Subject: [issue1230540] sys.excepthook doesn't work in threads Message-ID: <1487932419.29.0.323516205291.issue1230540@psf.upfronthosting.co.za> CyberJacob added the comment: Just confirmed, this does affect multiprocessing. script to reproduce: import sys, multiprocessing def log_exception(*args): print 'got exception %s' % (args,) sys.excepthook = log_exception def foo(): a = 1 / 0 multiprocessing.Process(target=foo).start() again, just a normal traceback instead of "got exception" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:37:59 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Fri, 24 Feb 2017 10:37:59 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1487932679.85.0.201851558305.issue24905@psf.upfronthosting.co.za> Changes by Aviv Palivoda : ---------- pull_requests: +244 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:40:29 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Fri, 24 Feb 2017 10:40:29 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1487932829.41.0.110023298397.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: I opened a PR in github. I tagged some other developers if that will not start a discussion on the API I will post in the python-ideas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:45:52 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Feb 2017 10:45:52 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487933152.49.0.267529374062.issue27788@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The purpose of __version__ in the platform module is to be able to use it with other Python as well (and then detect which version is available in applications). So I think it's good to keep it around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:48:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Feb 2017 10:48:18 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1487933298.59.0.556187557681.issue24905@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is there similar API in other databases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:48:27 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Feb 2017 10:48:27 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487933307.09.0.485905298646.issue27788@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- assignee: -> lemburg resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 05:49:26 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Feb 2017 10:49:26 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1487933366.15.0.376497540542.issue27788@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Hmm, not sure why the merge is not showing up on the ticket. Here's the link: https://github.com/python/cpython/commit/6059ce45aa96f52fa0150e68ea655fbfdc25609a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 06:14:51 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Fri, 24 Feb 2017 11:14:51 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1487934891.69.0.912573823242.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: I am not a DB expert but from a quick search I couldn't find a similar API. I did find a few API's in other programming languages to sqlite blob: 1. https://jgallagher.github.io/rusqlite/rusqlite/blob/index.html 2. https://godoc.org/github.com/mxk/go-sqlite/sqlite3 3. http://www.ch-werner.de/javasqlite/SQLite/Blob.html It seems like most of them give the same API as apsw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:21:20 2017 From: report at bugs.python.org (John Florian) Date: Fri, 24 Feb 2017 12:21:20 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487938880.43.0.205261801415.issue14243@psf.upfronthosting.co.za> John Florian added the comment: Okay Nick. Thanks for the detailed info. I suspected buffering was a factor, but wasn't certain. Would it be worthwhile pursuing a note in the docs or would that constitute clutter over what should be a standard assumption? I was thrown off course for all the prior uses without issues, but in hindsight I don't know offhand how many involved a subprocess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:28:05 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Feb 2017 12:28:05 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487939285.28.0.337917786178.issue14243@psf.upfronthosting.co.za> Nick Coghlan added the comment: John: I don't think it would be clutter to have an explicit reminder about that point in the NamedTemporaryFile documentation, so feel free to file a separate enhancement issue for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:34:03 2017 From: report at bugs.python.org (Louie Lu) Date: Fri, 24 Feb 2017 12:34:03 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1487939643.04.0.118088956731.issue9285@psf.upfronthosting.co.za> Louie Lu added the comment: Ping. Is there any reason why this patch doesn't accept? ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:46:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 12:46:45 +0000 Subject: [issue29641] Missing _sysconfig_data when building+installating Python using PGO+LTO Message-ID: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> New submission from STINNER Victor: Hi, I compiled Python 3.7 using PGO+LTO with "make && make install", but it seems like it lacks the _sysconfigdata module. Moreover, I don't see any "Makefile" file in the installed directory, so the "~/installed/3.7/bin/python3 -S -m sysconfig --generate-posix-vars" command fails on trying to import _sysconfigdata_m_linux_x86_64-linux-gnu ... $ find /home/haypo/installed/3.7 -name "Makefile" Is it correct to use "make && make install" using PGO? cd ~/cpython make distclean ||: ./configure --enable-optimizations --with-lto --prefix=/home/haypo/installed/3.7 make clean make make install haypo at speed-python$ ~/installed/3.7/bin/python3 Failed to import the site module Traceback (most recent call last): File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 544, in main() File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 530, in main known_paths = addusersitepackages(known_paths) File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 282, in addusersitepackages user_site = getusersitepackages() File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 258, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 248, in getuserbase USER_BASE = get_config_var('userbase') File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 601, in get_config_var return get_config_vars().get(name) File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 550, in get_config_vars _init_posix(_CONFIG_VARS) File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 421, in _init_posix _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0) ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu' ---------- components: Build messages: 288523 nosy: haypo priority: normal severity: normal status: open title: Missing _sysconfig_data when building+installating Python using PGO+LTO versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:58:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 12:58:32 +0000 Subject: [issue29641] Missing _sysconfig_data when building+installating Python using PGO+LTO In-Reply-To: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> Message-ID: <1487941112.76.0.700926861649.issue29641@psf.upfronthosting.co.za> STINNER Victor added the comment: PGO compilation uses "make profile-removal", maybe my issue is linked to that? I'm sure that PGO compilation + "make install" worked two months, but using: make profile-opt && make install. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 08:03:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 13:03:05 +0000 Subject: [issue29641] Missing _sysconfig_data when building+installating Python using PGO+LTO In-Reply-To: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> Message-ID: <1487941385.55.0.560823697916.issue29641@psf.upfronthosting.co.za> STINNER Victor added the comment: The --enable-optimizations option of ./configure was added by the issue #26359 (first named --with-optimizations, it was recalled to --enable-optimizations later). See also: * issue #28032: "never imply --with-lto as part of --with-optimizations" * issue #28605: Fix the help and What's New entry for --with-optimizations ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 10:23:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 15:23:19 +0000 Subject: [issue29465] Modify _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1487949799.48.0.818566908095.issue29465@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, code to call functions changed a lot recently, and other issues already enhanced the stack usage. I should measure the stack usage to check if it's still worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 10:33:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 15:33:31 +0000 Subject: [issue29641] Missing _sysconfig_data when building+installating Python using PGO+LTO In-Reply-To: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> Message-ID: <1487950411.61.0.708195882756.issue29641@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I confirm that it's possible to compile and install Python using PGO+LTO without --enable-optimizatioins: cd ~/cpython make distclean ||: ./configure --with-lto --prefix=/home/haypo/installed/3.7 make clean make profile-opt make install ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 10:34:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 15:34:27 +0000 Subject: [issue29641] make install failure when using ./configure --enable-optimizations In-Reply-To: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> Message-ID: <1487950467.76.0.0838108516378.issue29641@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Missing _sysconfig_data when building+installating Python using PGO+LTO -> make install failure when using ./configure --enable-optimizations _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 10:35:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 15:35:00 +0000 Subject: [issue26359] CPython build options for out-of-the box performance In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za> Message-ID: <1487950500.47.0.369376780197.issue26359@psf.upfronthosting.co.za> STINNER Victor added the comment: It seems like it's not possible to install Python configured with --enable-optimizations: see my issue #29641, "make install failure when using ./configure --enable-optimizations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 10:56:38 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 24 Feb 2017 15:56:38 +0000 Subject: [issue29640] _PyThreadState_Init and fork race leads to inconsistent key list In-Reply-To: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za> Message-ID: <1487951798.13.0.926536994088.issue29640@psf.upfronthosting.co.za> Changes by Charalampos Stratakis : ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:05:14 2017 From: report at bugs.python.org (Jonas Jelten) Date: Fri, 24 Feb 2017 16:05:14 +0000 Subject: [issue26532] build fails with address sanitizer In-Reply-To: <1457640165.38.0.124294976796.issue26532@psf.upfronthosting.co.za> Message-ID: <1487952314.96.0.370512129325.issue26532@psf.upfronthosting.co.za> Changes by Jonas Jelten : ---------- nosy: +jj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:08:00 2017 From: report at bugs.python.org (Marco Buttu) Date: Fri, 24 Feb 2017 16:08:00 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1487952480.81.0.349504438201.issue29414@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +245 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:48:45 2017 From: report at bugs.python.org (Andrei Fokau) Date: Fri, 24 Feb 2017 16:48:45 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? Message-ID: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> New submission from Andrei Fokau: Hi, As far as I see, unittest.TestLoader doesn't search in PEP-420 packages, i.e. packages without __init__.py files. Is there some motivation behind this, or the loader was just not yet adapted for Implicit Namespace Packages? ---------- components: Tests messages: 288529 nosy: Andrei Fokau priority: normal severity: normal status: open title: Why does unittest.TestLoader.discover still rely on existence of __init__.py files? type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:52:51 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 16:52:51 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487955171.52.0.577555468305.issue29642@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:59:22 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 16:59:22 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487955562.51.0.572346500861.issue25008@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- pull_requests: +246 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 13:30:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 18:30:40 +0000 Subject: [issue29318] Optimize _PyFunction_FastCallDict() for **kwargs In-Reply-To: <1484825581.48.0.790581995103.issue29318@psf.upfronthosting.co.za> Message-ID: <1487961040.87.0.747244734097.issue29318@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: fixed -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 13:41:09 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 24 Feb 2017 18:41:09 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1487961669.01.0.113730916007.issue9285@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 13:43:42 2017 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 24 Feb 2017 18:43:42 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1487961822.9.0.811307387429.issue9285@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: The original patch is basically blocked by the cryptic assertion error reported above. It's not clear what it means or how to work around it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:08:28 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 24 Feb 2017 20:08:28 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1487966908.98.0.157932789281.issue26184@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +247 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:17:00 2017 From: report at bugs.python.org (Andrei Fokau) Date: Fri, 24 Feb 2017 20:17:00 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487967420.04.0.20803739138.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Ok, it's actually not so hard to work around (for Python 3.6, at least): import os from unittest import TestLoader class CustomTestLoader(TestLoader): def _find_test_path(self, full_path, pattern, namespace=False): original_isfile = os.path.isfile def patched_isfile(path): return str(path).endswith('__init__.py') or original_isfile(path) os.path.isfile = patched_isfile result = super()._find_test_path(full_path=full_path, pattern=pattern, namespace=namespace) os.path.isfile = original_isfile return result I'll try to submit a pull request if it can be resolved properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:19:31 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 20:19:31 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487967571.98.0.826514761487.issue25008@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- pull_requests: +248 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:23:17 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 20:23:17 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487967797.49.0.448729816773.issue25008@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- pull_requests: +249 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:26:49 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 20:26:49 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487968009.6.0.138601217005.issue25008@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- pull_requests: +250 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:32:41 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 24 Feb 2017 20:32:41 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat) In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1487968361.18.0.509862995714.issue25008@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 15:33:42 2017 From: report at bugs.python.org (Steven Rumbalski) Date: Fri, 24 Feb 2017 20:33:42 +0000 Subject: [issue29596] Unfinished sentense in howto/clinic.rst In-Reply-To: <1487380332.64.0.682733186171.issue29596@psf.upfronthosting.co.za> Message-ID: <1487968422.29.0.767960923105.issue29596@psf.upfronthosting.co.za> Steven Rumbalski added the comment: Truncated sentence was always truncated. Introduced on commit bebf73511a1250fc768bcb7192b5b3c3fd04d8f2 from Issue #20287: Argument Clinic's output is now configurable, allowing delaying its output or even redirecting it to a separate file. https://github.com/python/cpython/commit/bebf73511a1250fc768bcb7192b5b3c3fd04d8f2 Another issue from the same commit that still exists today: buffer Save up all most of the output from Clinic, to be written into your file near the end. ^^^^^^^^ Perhaps what was meant was 'almost all'? ---------- nosy: +Steven Rumbalski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 16:56:07 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Feb 2017 21:56:07 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487973367.47.0.955695405709.issue29642@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +251 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 16:59:13 2017 From: report at bugs.python.org (Andrei Fokau) Date: Fri, 24 Feb 2017 21:59:13 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487973553.07.0.199253049075.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Alright, I made an initial fix in #282. I believe that I still need to update the docs and run it with something big, e.g. Django. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 17:19:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Feb 2017 22:19:37 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487974777.32.0.604526576266.issue29642@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, michael.foord, rbcollins stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 18:20:10 2017 From: report at bugs.python.org (Alex Wang) Date: Fri, 24 Feb 2017 23:20:10 +0000 Subject: [issue29643] --enable-optimizations compiler flag has no effect Message-ID: <1487978410.86.0.66468070718.issue29643@psf.upfronthosting.co.za> New submission from Alex Wang: PR submitted here: https://github.com/python/cpython/pull/129 ---------- components: Build messages: 288535 nosy: awang priority: normal severity: normal status: open title: --enable-optimizations compiler flag has no effect type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 18:20:21 2017 From: report at bugs.python.org (Alex Wang) Date: Fri, 24 Feb 2017 23:20:21 +0000 Subject: [issue29643] --enable-optimizations compiler flag has no effect In-Reply-To: <1487978410.86.0.66468070718.issue29643@psf.upfronthosting.co.za> Message-ID: <1487978421.82.0.329893525154.issue29643@psf.upfronthosting.co.za> Changes by Alex Wang : ---------- pull_requests: +253 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 18:35:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 23:35:04 +0000 Subject: [issue29643] --enable-optimizations compiler flag has no effect In-Reply-To: <1487978410.86.0.66468070718.issue29643@psf.upfronthosting.co.za> Message-ID: <1487979304.45.0.0425375587062.issue29643@psf.upfronthosting.co.za> STINNER Victor added the comment: The flag has an effect, I tested it today ;-) Can you please elaborate why you consider that the flag has no effect? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 18:39:02 2017 From: report at bugs.python.org (Alex Wang) Date: Fri, 24 Feb 2017 23:39:02 +0000 Subject: [issue29643] --enable-optimizations compiler flag has no effect In-Reply-To: <1487978410.86.0.66468070718.issue29643@psf.upfronthosting.co.za> Message-ID: <1487979542.27.0.0632777041569.issue29643@psf.upfronthosting.co.za> Alex Wang added the comment: At least when I last built Python, configure always said that optimizations were not enabled regardless of whether I passed in the flag. >From what it looked like to me, it's because configure uses the $enableval variable to store the result of the check for --enable-optimizations, but the script checks $withval ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 20:50:07 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 01:50:07 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1487987407.73.0.246863252704.issue29642@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 22:38:45 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 03:38:45 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1487993925.97.0.267129325152.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +254 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 22:42:27 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 03:42:27 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1487994147.37.0.507577693315.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +255 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 22:46:16 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 03:46:16 +0000 Subject: [issue28929] Provide a link from documentation back to its source file In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za> Message-ID: <1487994376.11.0.667837780565.issue28929@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +256 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 23:49:40 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 25 Feb 2017 04:49:40 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487998180.56.0.420405675955.issue14243@psf.upfronthosting.co.za> Eryk Sun added the comment: Nick wrote: > 1. Open the file in the current process > 2. Write content to the file > 3*. Close the file in the current process In step 1, do you mean calling NamedTemporaryFile with delete=False? In that case there's no immediate problem with opening the file again in Windows. If you mean calling NamedTemporaryFile with delete=True, then step 3 deletes the file. Adding support for Windows share modes would be useful in general and would help within the current process. However, users may also need to open the temporary file in another process. Most programs don't open their files with shared delete access. There's a workaround to allow the file to be opened normally, but it involves setting the delete disposition and then clearing it in a pointless dance. It would be better to implement an option such as delete=AFTER_CM_EXIT, to try to remove the file without relying on O_TEMPORARY. The downside is that the file won't be deleted if the interpreter crashes, gets terminated or if another process has the file open without delete sharing. ---------- nosy: +eryksun versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 23:58:32 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 04:58:32 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487998712.72.0.964404598701.issue24241@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:00:33 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 05:00:33 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1487998833.44.0.561834894104.issue24241@psf.upfronthosting.co.za> Nick Coghlan added the comment: To summarise the changes that were made during the PR review, here's the eventual commit message for the merged PR: ============ bpo-24241: Improve preferred webbrowser handling (#85) - Add 'preferred' argument to webbrowser.register - Use xdg-settings to specify preferred X browser The first change replaces the existing undocumented tri-state 'try_order' parameter with the documented boolean keyword-only 'preferred' parameter. Setting it to True places the browser at the front of the list, preferring it as the return to a subsequent get() call. The second change adds a private `_os_preferred_browser` setting and then uses that to make the default browser reported by `xdg-settings` first in the try list when running under X (or another environment that sets the `DISPLAY` variable). This avoids the problem where the first entry in the tryorder queue otherwise defaults to xdg-open, which doesn't support the "new window" option. ============ ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:18:30 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 25 Feb 2017 05:18:30 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1487999910.13.0.488525666876.issue14243@psf.upfronthosting.co.za> Eryk Sun added the comment: Richard wrote: > while a handle is open with share mode X, you can only reopen > the file if you also use share mode X To clarify, the share mode is not a property of a handle. It's a property of a File object. A handle is a generic reference to any kind of kernel object, not just a File. The following is a brief discussion about access sharing and the way file deletion works in Windows. Both of these tend to frustrate Unix programmers who end up supporting Windows. In this discussion, a "File", with an uppercase 'F', is the Windows kernel object type that references an open device or file-system directory, file, or stream. A "file", with a lowercase 'f', is a data file. Shared access is implemented for File objects [1] and tracked in a SHARE_ACCESS record. When opening a file or directory, its shared access state is updated by the kernel function IoCheckShareAccess [2]. Discretionary shared access is primarily a concern for file systems, but volume devices and disk devices (e.g. \\.\C: and \\.\PhysicalDrive0) also use it. Devices that are flagged for mandatory exclusive access [3] (e.g. \\.\COM1) generally ignore the share mode. Some non-exclusive devices also ignore the share mode (e.g. \\.NUL and \\.CON). If it's not ignored, the share mode affects delete, write, read, and execute access. The following File access rights are affected: DELETE, FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_READ_DATA, and FILE_EXECUTE. The share mode thus affects any combination of generic access -- GENERIC_ALL, GENERIC_WRITE, GENERIC_READ, GENERIC_EXECUTE. A File object's requested sharing is stored in its SharedDelete, SharedWrite, and SharedRead members. The granted access that's relevant to the share mode is stored in the DeleteAccess, WriteAccess (write/append), and ReadAccess (read/execute) members. Given these values, checking for a sharing violation and updating the shared access counts uses the following logic: RequireSharedDelete = DeleteAccessCount > 0; RequireSharedWrite = WriteAccessCount > 0; RequireSharedRead = ReadAccessCount > 0; DenyDeleteAccess = SharedDeleteCount < OpenCount; DenyWriteAccess = SharedWriteCount < OpenCount; DenyReadAccess = SharedReadCount < OpenCount; if (RequireSharedDelete && !SharedDelete || RequireSharedWrite && !SharedWrite || RequireSharedRead && !SharedRead || DenyDeleteAccess && DeleteAccess || DenyWriteAccess && WriteAccess || DenyReadAccess && ReadAccess) { return STATUS_SHARING_VIOLATION; } OpenCount++; DeleteAccessCount += DeleteAccess; WriteAccessCount += WriteAccess; ReadAccessCount += ReadAccess; SharedDeleteCount += SharedDelete; SharedWriteCount += SharedWrite; SharedReadCount += SharedRead; For example, to be granted delete access, all existing File object references must share delete access. However, if a file is opened with delete sharing but delete access hasn't been granted, then it can be opened again without delete sharing. The SHARE_ACCESS structure is usually stored in a file (or stream) control block (FCB/SCB), which is a structure that coordinates access to a file or directory across multiple File objects. The FsContext member of a File object points at the FCB. A file system stores its private state for a File in a context control block (CCB), to which the File's FsContext2 member points. The CCB is where a file system tracks, for example, whether the file should be deleted when the object is closed. Deleting a file sets a delete disposition in the FCB/SCB (or LCB if hard links are supported). The file can't be unlinked until all referencing File objects have been closed and the underlying FCB/SCB/LCB is closing. Until then a 'deleted' file is still linked in the parent directory and prevents the directory from being deleted. A deleted but still referenced file is in a semi-zombie state. Windows file systems don't allow opening such a file for any access, but it can still be accessed via existing objects. If one of these File objects has delete access, it can be used to unset the delete disposition (e.g. via SetFileInformationByHandle) to make the file accessible again. [1]: https://msdn.microsoft.com/en-us/library/ff545834 [2]: https://msdn.microsoft.com/en-us/library/ff548341 [3]: https://msdn.microsoft.com/en-us/library/ff563827 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:45:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 05:45:02 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1488001502.81.0.898581530592.issue24241@psf.upfronthosting.co.za> Nick Coghlan added the comment: After merging this, I belatedly realised that codecov's complaint about the lack of code coverage for the diff was actually valid: now that "preferred" is a public API, it should have a cross-platform test case. That should be a fairly straightforward test to write, as it can just use an arbitrary string, and then poke around in _tryorder directly to make sure it is updated as expected - it doesn't need to use a valid browser reference. ---------- stage: resolved -> test needed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:45:20 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 05:45:20 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1488001520.93.0.447552266361.issue24241@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:59:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 05:59:09 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr Message-ID: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Importing webbrowser has a side effect. It outputs a message on stderr. >>> import webbrowser /usr/bin/xdg-settings: 1: /usr/bin/xdg-settings: kreadconfig5: not found This is a regression introduced in issue24241. ---------- components: Library (Lib) messages: 288542 nosy: daves, ncoghlan, serhiy.storchaka priority: normal severity: normal status: open title: Importing webbrowser outputs a message on stderr type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 01:56:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 06:56:21 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488005781.03.0.962722488239.issue29644@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think an appropriate way of handling this would be to route both stdout and stderr in the subprocess to subprocess.DEVNULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:32:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 07:32:07 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488007927.82.0.0450801464387.issue29644@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just stderr. stdout contains the requested value. And I think that an external program shouldn't be ran at import time. It would be better to defer its run until its output is required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:32:43 2017 From: report at bugs.python.org (Andrei Fokau) Date: Sat, 25 Feb 2017 07:32:43 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488007963.92.0.228696906335.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Docs promise already support for namespace packages, so just a minor clarification was done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:35:23 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 07:35:23 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1488008122.98.0.820957128131.issue9285@psf.upfronthosting.co.za> Louie Lu added the comment: giampaolo: it seems that contextmanager will somehow make a bad return in `trace_dispatch_return`: $ ./python tests.py # logging.fatal('%r %r' % (frame.f_code.co_name, self.cur[-3])) CRITICAL:root:'runblock' '' ('profile', 0, '') CRITICAL:root:'__enter__' '' ('profile', 0, '') Traceback (most recent call last): File "tests.py", line 18, in with p.runblock(): File "/home/grd/Python/cpython/Lib/contextlib.py", line 82, in __enter__ return next(self.gen) File "/home/grd/Python/cpython/Lib/profile.py", line 256, in trace_dispatch_i if self.dispatch[event](self, frame, t): File "/home/grd/Python/cpython/Lib/profile.py", line 346, in trace_dispatch_return raise AssertionError("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile', 0, '')) I make a workaround in GitHub PR, that skip the assert when self.cur[-3] is ('profile', 0, ''), and this work fine with your test cases. p.s. I'm not very sure about the assertion of bad return, maybe this workaround may cause some side affact I didn't notice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:40:19 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 07:40:19 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1488008419.76.0.0799966382937.issue9285@psf.upfronthosting.co.za> Changes by Louie Lu : ---------- pull_requests: +257 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:41:13 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 07:41:13 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488008473.47.0.822264430154.issue29644@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, and I think I'm not seeing this locally because I have both Gtk and KDE components installed (my main desktop is KDE, but Firefox and various other components are still Gtk apps). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:49:29 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 07:49:29 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1488008969.29.0.834332004427.issue24241@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +258 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:49:45 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 07:49:45 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488008985.14.0.018605770734.issue29644@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +259 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:51:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 07:51:04 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488009064.25.0.573093136542.issue29644@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I see this because my main desktop is KDE, but optional libkf5config-bin package is not installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 02:56:53 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 07:56:53 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488009413.31.0.0358980154649.issue29644@psf.upfronthosting.co.za> Nick Coghlan added the comment: I considered that problem of "subprocess invocation as a side-effect of import", but in this case the output is needed by the immediately following "register_X_browsers()" call, as it affects how those browsers get inserted into webbrowser._tryorder. That means there isn't any obvious way to delay it without a fairly significant refactoring of how the module works :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 03:15:11 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 08:15:11 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1488010511.08.0.0649802434282.issue24241@psf.upfronthosting.co.za> Nick Coghlan added the comment: Second PR merged with the missing test case. ---------- stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 03:23:45 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 08:23:45 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1488011025.53.0.118502240243.issue16285@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 03:23:56 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 08:23:56 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1488011036.61.0.924471075368.issue16285@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 04:00:58 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 09:00:58 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1488013258.42.0.464986075602.issue16285@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 04:26:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 09:26:58 +0000 Subject: [issue29645] webbrowser module import has heavy side effects Message-ID: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: `import webbrowser` has heavy side effects. It searches a number of executables. On X Window it also runs external program xdg-settings. Cold start: $ time ./python -c '' real 0m1.719s user 0m0.088s sys 0m0.036s $ time ./python -c 'import webbrowser' real 0m5.713s user 0m0.308s sys 0m0.196s Hot start: $ time ./python -c '' real 0m0.094s user 0m0.072s sys 0m0.020s $ time ./python -c 'import webbrowser' real 0m1.026s user 0m0.284s sys 0m0.100s ---------- components: Library (Lib) messages: 288551 nosy: serhiy.storchaka priority: normal severity: normal status: open title: webbrowser module import has heavy side effects type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 04:56:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 09:56:30 +0000 Subject: [issue29644] Importing webbrowser outputs a message on stderr In-Reply-To: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> Message-ID: <1488016590.69.0.122405991918.issue29644@psf.upfronthosting.co.za> Nick Coghlan added the comment: The specific problem reported has been resolved, so closing this one. If anyone's able to figure out a way to defer this to post-import somehow, I think that would make a good enhancement proposal. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:11:14 2017 From: report at bugs.python.org (ProgVal) Date: Sat, 25 Feb 2017 10:11:14 +0000 Subject: [issue29646] ast.parse parses string literals as docstrings Message-ID: <1488017474.82.0.510705451236.issue29646@psf.upfronthosting.co.za> New submission from ProgVal: Since commit cb41b2766de646435743b6af7dd152751b54e73f (Python 3.7a0), string literals are not parsed the same way. ast.parse("'test'").body used to be a list with one item containing 'test'; but now it is an empty list: Python 3.5.2+ (default, Dec 13 2016, 14:16:35) [GCC 6.2.1 20161124] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> print(ast.parse("'test'")) <_ast.Module object at 0x7fa37ae4c630> >>> print(ast.parse("'test'").body) [<_ast.Expr object at 0x7fa37ae4c630>] >>> print(ast.parse("'test'").docstring) Traceback (most recent call last): File "", line 1, in AttributeError: 'Module' object has no attribute 'docstring' Python 3.7.0a0 (default, Feb 24 2017, 21:38:30) [GCC 6.3.0 20170205] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> print(ast.parse("'test'")) <_ast.Module object at 0x7fe2aa415eb8> >>> print(ast.parse("'test'").body) [] >>> print(ast.parse("'test'").docstring) test ---------- components: Interpreter Core messages: 288553 nosy: Valentin.Lorentz, inada.naoki priority: normal severity: normal status: open title: ast.parse parses string literals as docstrings versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:13:15 2017 From: report at bugs.python.org (ProgVal) Date: Sat, 25 Feb 2017 10:13:15 +0000 Subject: [issue29646] ast.parse parses string literals as docstrings In-Reply-To: <1488017474.82.0.510705451236.issue29646@psf.upfronthosting.co.za> Message-ID: <1488017595.38.0.969876541992.issue29646@psf.upfronthosting.co.za> ProgVal added the comment: (Oops, submitted too soon.) I understand the rational of this change, so I am not sure if this is actually a bug. However, if someone wants to parse a simple expression that may be a string, they need to add a special handling in case it's a string interpreted as a module docstring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:18:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 10:18:17 +0000 Subject: [issue29646] ast.parse parses string literals as docstrings In-Reply-To: <1488017474.82.0.510705451236.issue29646@psf.upfronthosting.co.za> Message-ID: <1488017897.44.0.687651614841.issue29646@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If someone wants to parse a simple expression that may be a string he should use the "eval" mode. >>> ast.dump(ast.parse("'test'")) "Module(body=[], docstring='test')" >>> ast.dump(ast.parse("'test'", mode='eval')) "Expression(body=Str(s='test'))" ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:34:29 2017 From: report at bugs.python.org (ProgVal) Date: Sat, 25 Feb 2017 10:34:29 +0000 Subject: [issue29646] ast.parse parses string literals as docstrings In-Reply-To: <1488017474.82.0.510705451236.issue29646@psf.upfronthosting.co.za> Message-ID: <1488018869.81.0.701890487534.issue29646@psf.upfronthosting.co.za> ProgVal added the comment: Indeed, thanks. I should have done that when I migrated from compiler.parse. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:44:46 2017 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Sat, 25 Feb 2017 10:44:46 +0000 Subject: [issue29647] Python 3.6.0 Message-ID: <1488019486.61.0.519104192043.issue29647@psf.upfronthosting.co.za> New submission from Bo?tjan Mejak: I managed to create an app that crashes the latest stable version of Python, that is 3.6.0 at the time of this writing. My application is written in Python using wxPython Phoenix 3rd-party GUI library/toolkit. I am running Windows 10 Home 64-bit version OS, the latest version of it, the Anniversary Edition with all its updates. How I did it? Well, I made an event in my GUI app where clicking the X button puts up a message dialog to the user, saying "Do you really wanna close this app?" and the "Yes" button destroys the whole object, thus exiting the application. But now the catch! I also made a taskbar icon which includes a menu item to also exit the application: same message dialog with Yes/No buttons. Let's crash this baby! If you click the X button and not choosing either "Yes" or "No" but instead have this message dialog wait and in the mean time you right-click the taskbar icon and choose the "Exit" menu item and choose "Yes". Then click another "Yes" of that waiting message dialog and BOOM! Voila, we have killed PYthon interpreter. Is that a bug in my code or does Python have a weakness? ---------- components: Interpreter Core messages: 288557 nosy: Pikec, gvanrossum priority: normal severity: normal status: open title: Python 3.6.0 type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:48:17 2017 From: report at bugs.python.org (Andrei Fokau) Date: Sat, 25 Feb 2017 10:48:17 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488019697.75.0.670384963814.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Ok, testing with Django was a bad idea due to compatibility with 3.7. I could apply it to 3.6.x and test Django with it. Is there a better idea how to trial the test discovery? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:54:15 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Sat, 25 Feb 2017 10:54:15 +0000 Subject: [issue9285] Add a profile decorator to profile and cProfile In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za> Message-ID: <1488020055.27.0.894972418698.issue9285@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- nosy: -fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:14:44 2017 From: report at bugs.python.org (Christoph Reiter) Date: Sat, 25 Feb 2017 11:14:44 +0000 Subject: [issue29647] Python 3.6.0 In-Reply-To: <1488019486.61.0.519104192043.issue29647@psf.upfronthosting.co.za> Message-ID: <1488021284.16.0.324509486071.issue29647@psf.upfronthosting.co.za> Christoph Reiter added the comment: That sounds like a problem with wxPython which you should report to them: http://trac.wxwidgets.org/ When you do, try to attach a minimal code example with your instructions so others can reproduce the error. ---------- nosy: +lazka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:22:08 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 25 Feb 2017 11:22:08 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) Message-ID: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> New submission from Marco Buttu: In the first `versionadded` of the Loader section [1] of Doc/reference/import.rst, there is no reference to `create_module()`: .. versionadded:: 3.4 The create_module() method of loaders. It should be: .. versionadded:: 3.4 The :meth:`~importlib.abc.Loader.create_module` method of loaders. I will make a PR. [1] https://docs.python.org/3/reference/import.html#loaders ---------- messages: 288560 nosy: marco.buttu priority: normal severity: normal status: open title: Missed reference to create_module() in versionadded (import.rst) versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:24:48 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 11:24:48 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488021888.34.0.997325344059.issue29648@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +260 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:38:23 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 11:38:23 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488022703.75.0.388864532114.issue29645@psf.upfronthosting.co.za> Louie Lu added the comment: What is the different of Cold start and Hot start? It that CPU speed or something else. In Linux 4.9.11 with i7-2k, I can't reproduce the significant real time you gave: # CPU gov powersave $ time ./python -c 'import webbrowser' 0.16s user 0.02s system 93% cpu 0.200 total # CPU gov performance $ time ./python -c 'import webbrowser' 0.08s user 0.00s system 82% cpu 0.093 total ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:47:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 11:47:58 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488023278.84.0.912526272245.issue29645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch makes searching of all platform browsers delayed until it is needed. In addition it makes webbrowser.register() thread safe. Cold start: $ time ./python -c 'import webbrowser' real 0m2.851s user 0m0.224s sys 0m0.056s Hot start: $ time ./python -c 'import webbrowser' real 0m0.259s user 0m0.232s sys 0m0.024s ---------- nosy: +ncoghlan stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:48:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 11:48:58 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488023338.25.0.885062924815.issue29645@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file46667/webbrowser-delayed-initialization.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:55:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 11:55:16 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488023716.84.0.23673318377.issue29645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > What is the different of Cold start and Hot start? Disk caches are dropped before cold start. $ echo 3 | sudo tee /proc/sys/vm/drop_caches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:56:18 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 25 Feb 2017 11:56:18 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488023778.64.0.047529857862.issue29648@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- pull_requests: +261 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 08:53:04 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 13:53:04 +0000 Subject: [issue29649] struct.pack_into check boundary error message didn't respect offset Message-ID: <1488030784.09.0.674246877605.issue29649@psf.upfronthosting.co.za> New submission from Louie Lu: For this situation, check boundary error message didn't correctly show out. >>> import struct >>> import ctypes >>> byte_list = ctypes.create_string_buffer(1) >>> struct.pack_into('b', byte_list, 5, 1) Traceback (most recent call last): File "", line 1, in struct.error: pack_into requires a buffer of at least 1 bytes Since offset is setting at 5, it should at least need `offset + soself->s_size` bytes to store it. ---------- components: Extension Modules messages: 288564 nosy: louielu priority: normal severity: normal status: open title: struct.pack_into check boundary error message didn't respect offset versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 09:10:03 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 14:10:03 +0000 Subject: [issue23578] struct.pack error messages do not indicate which argument was invalid In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za> Message-ID: <1488031803.67.0.66209278673.issue23578@psf.upfronthosting.co.za> Changes by Louie Lu : ---------- pull_requests: +262 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 09:11:12 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 14:11:12 +0000 Subject: [issue23578] struct.pack error messages do not indicate which argument was invalid In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za> Message-ID: <1488031872.9.0.652171300353.issue23578@psf.upfronthosting.co.za> Louie Lu added the comment: Adding PyErr_SetString and PyErr_Format wrapper, with a global offset variable to handle this. struct.pack('!h', 0x8FFFF) Traceback (most recent call last): File "tests.py", line 5, in struct.pack('!h', 0x8FFFF) struct.error: Raise at offset 1, 'h' format requires -32768 <= number <= 32767 ---------- nosy: +louielu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 09:52:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 14:52:10 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488034330.74.0.151318685231.issue29645@psf.upfronthosting.co.za> Nick Coghlan added the comment: Nice, this is much cleaner than the current approach! The one thing I would suggest is a new test case that: - asserts webbrowser._tryorder is None - asserts webbrowser._browsers is empty - calls webbrowser.get() - asserts webbrowser._tryorder is non-empty - asserts webbrowser._browsers is non-empty I wouldn't worry about explicitly testing the thread safety. That's just a normal double-checked locking pattern, so I think code review is sufficient to address that - the only way for it to break is for something to go horribly wrong in threading.RLock(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 10:00:45 2017 From: report at bugs.python.org (Andrei Fokau) Date: Sat, 25 Feb 2017 15:00:45 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488034845.03.0.98029872485.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Testing with Django seems indicated an issue. I did the following with 3.6 patch (cherry-pick to bea9d2f64) on macOS with OpenSSL installed via Homebrew: $ cd /Users/andrei/Python/cpython/ $ export CFLAGS="-I/usr/local/opt/openssl/include" $ export LDFLAGS="-L/usr/local/opt/openssl/lib" $ ./configure --with-pydebug --prefix=/Users/andrei/Python/installed/ $ make -j $ make install Then in Django (master, b427f0d674): $ cd /Users/andrei/Python/django/ $ ../../installed/bin/pip3.6 install -r ./requirements/py3.txt $ PYTHONPATH=.. DJANGO_SETTINGS_MODULE=test_sqlite ../../installed/bin/python3.6 ./runtests.py That produced one error: ====================================================================== ERROR: auth_tests.test_hashers (unittest.loader._FailedTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/andrei/Python/installed/lib/python3.6/unittest/case.py", line 59, in testPartExecutor yield File "/Users/andrei/Python/installed/lib/python3.6/unittest/case.py", line 601, in run testMethod() File "/Users/andrei/Python/installed/lib/python3.6/unittest/loader.py", line 34, in testFailure raise self._exception ImportError: Failed to import test module: auth_tests.test_hashers Traceback (most recent call last): File "/Users/andrei/Python/installed/lib/python3.6/unittest/loader.py", line 426, in _find_test_path module = self._get_module_from_name(name) File "/Users/andrei/Python/installed/lib/python3.6/unittest/loader.py", line 367, in _get_module_from_name __import__(name) File "/Users/andrei/Python/django/tests/auth_tests/test_hashers.py", line 20, in if crypt.crypt('', '') is None: File "/Users/andrei/Python/installed/lib/python3.6/crypt.py", line 47, in crypt return _crypt.crypt(word, salt) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfb in position 1: invalid start byte Ran 11695 tests in 259.390s FAILED (errors=1, skipped=1149, expected failures=4) Then I ran the same tests in 3.6.0 virtualenv installed via pyenv: $ pyenv virtualenv 3.6.0 djtest $ pyenv shell djtest $ pip install -r ./requirements/py3.txt $ PYTHONPATH=.. DJANGO_SETTINGS_MODULE=test_sqlite python ./runtests.py and they went fine: Ran 11723 tests in 87.369s OK (skipped=1149, expected failures=4) So the patch causes 1 error and misses 28 tests. I'll try to figure out the problem with failing test and what tests are missing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 10:03:04 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 15:03:04 +0000 Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za> Message-ID: <1488034984.06.0.804143751453.issue26128@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 10:03:29 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Feb 2017 15:03:29 +0000 Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za> Message-ID: <1488035009.15.0.470144826207.issue26128@psf.upfronthosting.co.za> Nick Coghlan added the comment: Subhendu's PR has been merged. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 10:10:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 15:10:39 +0000 Subject: [issue23578] struct.pack error messages do not indicate which argument was invalid In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za> Message-ID: <1488035439.42.0.0723622393576.issue23578@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1. Using global variable doesn't look good to me. 2. "at offset 1" looks confusing to me. What is offset? Is this an offset of packed item in created bytes object? The you shouldn't get the odd number for the '!h' format. I think it would be better to report the number of the packed item. struct.pack() already formats similar errors when pass unsuitable number of items. >>> struct.pack('", line 1, in struct.error: pack expected 2 items for packing (got 1) >>> struct.pack('", line 1, in struct.error: pack expected 2 items for packing (got 3) 3. It is not safe to use the fixed length array for formatting error message. Once the underlying error message can be changed and will overflow the buffer. The "%zd" format in sprintf() is not portable. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 10:49:08 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 15:49:08 +0000 Subject: [issue23578] struct.pack error messages do not indicate which argument was invalid In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za> Message-ID: <1488037748.6.0.342665248156.issue23578@psf.upfronthosting.co.za> Louie Lu added the comment: > 1. Using global variable doesn't look good to me. That's true, but I'm not sure if there have other methods to do this. If not using global variable, we will need to change a bunch of the function arguments. Since the arguments didn't contain the information about which item is in the process and raise the error. > 2. "at offset 1" looks confusing to me. What is offset? Make the change to: >>> struct.pack('hh', , 0x7FFFF, 0x8FFFF) struct.error: 'h' format requires -32768 <= number <= 32767, got bad value at item 2 (or probably, "got bad value at index 2") > 3. It is not safe to use the fixed length array for formatting error message. Once the underlying error message can be changed and will overflow the buffer. Change to snprintf. > The "%zd" format in sprintf() is not portable. Change to "%ld" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 11:46:46 2017 From: report at bugs.python.org (chrysn) Date: Sat, 25 Feb 2017 16:46:46 +0000 Subject: [issue29650] abstractmethod does not work when deriving from Exception Message-ID: <1488041206.17.0.0120524792135.issue29650@psf.upfronthosting.co.za> New submission from chrysn: The "TypeError: Can't instantiate abstract class C with abstract methods x" exception does not get raised when when the involved ABCMeta class is derived from an Exception. The attached file shows that a class without an implementation of an abstractmethod can get instanciated; replacing the derivation from Exception with a derivation from another class (say, A) makes the instanciation throw the proper TypeError. ---------- files: demo.py messages: 288571 nosy: chrysn priority: normal severity: normal status: open title: abstractmethod does not work when deriving from Exception type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46668/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 11:58:34 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 16:58:34 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488041914.94.0.446547033419.issue29648@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Marco. Your change looks good to me. I'm now wondering if this should have been 'versionchanged' instead of 'versionadded'. Perhaps other core devs can confirm this. Thanks :) ---------- assignee: -> docs at python components: +Documentation nosy: +Mariatta, docs at python stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 12:52:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 25 Feb 2017 17:52:34 +0000 Subject: [issue29637] ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' In-Reply-To: <1487886611.55.0.299835659711.issue29637@psf.upfronthosting.co.za> Message-ID: <1488045154.2.0.413016754434.issue29637@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 12:53:11 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 25 Feb 2017 17:53:11 +0000 Subject: [issue29647] Python 3.6.0 In-Reply-To: <1488019486.61.0.519104192043.issue29647@psf.upfronthosting.co.za> Message-ID: <1488045191.36.0.819161163044.issue29647@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed with Christoph. If the wxPython team finds there really is a bug in cpython itself triggering this, they (or you) can open a new issue with specifics. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 13:05:05 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 Feb 2017 18:05:05 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1488045905.47.0.275497856135.issue27593@psf.upfronthosting.co.za> Brett Cannon added the comment: I purposefully left the tag out because I don't think it's useful (a tag is just a conveniently named hash and all of our tags are version numbers and that's already available in other parts of the sys module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 13:21:28 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 25 Feb 2017 18:21:28 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488046888.61.0.675438491405.issue29110@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +263 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 13:25:00 2017 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Feb 2017 18:25:00 +0000 Subject: [issue29647] Python 3.6.0 In-Reply-To: <1488019486.61.0.519104192043.issue29647@psf.upfronthosting.co.za> Message-ID: <1488047100.49.0.672431106484.issue29647@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 13:47:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 25 Feb 2017 18:47:06 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1488048426.66.0.170011759897.issue28663@psf.upfronthosting.co.za> INADA Naoki added the comment: I close this issue, because there are no enough evidence it's Python's issue. When hit ulimit is just a OS's detail. Please ping or file a new issue when memory usage is really grown. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 14:35:56 2017 From: report at bugs.python.org (Andrei Fokau) Date: Sat, 25 Feb 2017 19:35:56 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488051356.54.0.973331482225.issue29642@psf.upfronthosting.co.za> Andrei Fokau added the comment: Removing `--with-pydebug` parameter helped to avoid issue with _crypto extension. Testing Django with that build produced result identical to 3.6.0: Ran 11723 tests in 83.897s OK (skipped=1149, expected failures=4) The patch is ready for review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 14:45:27 2017 From: report at bugs.python.org (Vasiliy Faronov) Date: Sat, 25 Feb 2017 19:45:27 +0000 Subject: [issue29651] Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs Message-ID: <1488051927.22.0.367579438822.issue29651@psf.upfronthosting.co.za> New submission from Vasiliy Faronov: There is a problem with the standard library's urlsplit and urlparse functions, in Python 2.7 (module urlparse) and 3.2+ (module urllib.parse). The documentation for these functions [1] does not explain how they behave when given an invalid URL. One could try invoking them manually and conclude that they tolerate anything thrown at them: >>> urlparse('http:////::\\\\!!::!!++///') ParseResult(scheme='http', netloc='', path='//::\\\\!!::!!++///', params='', query='', fragment='') >>> urlparse(os.urandom(32).decode('latin-1')) ParseResult(scheme='', netloc='', path='\x7f??1gd??6\x82', params='', query='', fragment='\n\xadJ\x18+fli\x9c?\x9ak*??\x02?F\x85?\x18') Without studying the source code, it is impossible to know that there is a very narrow class of inputs on which they raise ValueError [2]: >>> urlparse('http://[') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/urllib/parse.py", line 295, in urlparse splitresult = urlsplit(url, scheme, allow_fragments) File "/usr/lib/python3.5/urllib/parse.py", line 345, in urlsplit raise ValueError("Invalid IPv6 URL") ValueError: Invalid IPv6 URL This could be viewed as a documentation issue. But it could also be viewed as an implementation issue. Instead of raising ValueError on those square brackets, urlsplit could simply consider them *invalid* parts of an RFC 3986 reg-name, and lump them into netloc, as it already does with other *invalid* characters: >>> urlparse('http://\0\0??\n/') ParseResult(scheme='http', netloc='\x00\x00??\n', path='/', params='', query='', fragment='') Note that the raising behavior was introduced in Python 2.7/3.2. See also issue 8721 [3]. [1] https://docs.python.org/3/library/urllib.parse.html [2] https://github.com/python/cpython/blob/e32ec93/Lib/urllib/parse.py#L406-L408 [3] http://bugs.python.org/issue8721 ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 288577 nosy: docs at python, vfaronov priority: normal severity: normal status: open title: Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 14:54:43 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 25 Feb 2017 19:54:43 +0000 Subject: [issue29652] Fix evaluation order of keys/values in dict comprehensions Message-ID: <1488052483.04.0.021043093911.issue29652@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: Reported from [1] and similar to issue11205 Currently the evaluation order for keys and values in a dictionary comprehension follows that of assignments. The values get evaluated first and then the keys: def printer(v): print(v, end=' ') return v d = {printer(i): printer(j) for i, j in [(1, 2), (3, 4)]} # 2 1 4 3 This seems to conflict with the semantics as described in the Semantics section of PEP 274 [2] and according to my interpretation of the reference manual (I'd expect the evaluation to be similar to dict-displays). How should this be addressed? Fix the evaluation order or specify this edge case an "Implementation detail" in the reference manual? I already have a fix for this lying around (changes to `compiler_sync_comprehension_generator`, `compiler_sync_comprehension_generator` and a switch in `MAP_ADD`) and can make a pull request if required. I'm not sure if this is classified as a bug per-se so I only tagged Py3.7 for it. [1] http://stackoverflow.com/questions/42201932/order-of-operations-in-a-dictionary-comprehension [2] https://www.python.org/dev/peps/pep-0274/#semantics ---------- components: Interpreter Core messages: 288578 nosy: Jim Fasarakis-Hilliard priority: normal severity: normal status: open title: Fix evaluation order of keys/values in dict comprehensions type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 15:28:35 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 Feb 2017 20:28:35 +0000 Subject: [issue28279] setuptools failing to read from setup.cfg only in Python 3.6 In-Reply-To: <1474909538.67.0.328004494878.issue28279@psf.upfronthosting.co.za> Message-ID: <1488054515.58.0.390426430356.issue28279@psf.upfronthosting.co.za> Brett Cannon added the comment: Closing as this should be a setuptools issue (if it still is). ---------- nosy: +brett.cannon resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 15:34:32 2017 From: report at bugs.python.org (assume_away) Date: Sat, 25 Feb 2017 20:34:32 +0000 Subject: [issue29653] IDLE - call tips show wrapper's argpsec instead of wrapped Message-ID: <1488054872.48.0.0975525232786.issue29653@psf.upfronthosting.co.za> New submission from assume_away: Many wrappers use the famous (*args, **kwargs) argspec, which is less than helpful for a function that uses some positional arguments and maybe a few keyword only arguments, ie (x, y, z=10). Other IDEs have the capability of showing the wrapped functions argspec in a calltip, so why shouldn't IDLE? ---------- assignee: terry.reedy components: IDLE files: calltips.py messages: 288580 nosy: assume_away, terry.reedy priority: normal severity: normal status: open title: IDLE - call tips show wrapper's argpsec instead of wrapped type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file46669/calltips.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:20:35 2017 From: report at bugs.python.org (Pierre Quentel) Date: Sat, 25 Feb 2017 21:20:35 +0000 Subject: [issue29654] SimpleHTTPRequestHandler should support browser cache Message-ID: <1488057635.77.0.128841709763.issue29654@psf.upfronthosting.co.za> New submission from Pierre Quentel: SimpleHTTPServer send a Last-Modified response header, but doesn't take into account the If-Modified-Since header if it was sent by the user agent. If a url matches a file and this file was not modified after the value of the If-Modified-Since header, the server should return HTTP status 304 (Not Modified). ---------- components: Library (Lib) messages: 288581 nosy: quentel priority: normal severity: normal status: open title: SimpleHTTPRequestHandler should support browser cache type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:25:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Feb 2017 21:25:33 +0000 Subject: [issue29654] SimpleHTTPRequestHandler should support browser cache In-Reply-To: <1488057635.77.0.128841709763.issue29654@psf.upfronthosting.co.za> Message-ID: <1488057933.8.0.988803773721.issue29654@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +264 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:26:53 2017 From: report at bugs.python.org (Peter Cawley) Date: Sat, 25 Feb 2017 21:26:53 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference Message-ID: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> New submission from Peter Cawley: In the implementation of the IMPORT_STAR opcode, if the call to PyFrame_FastToLocalsWithError fails, or f_locals is NULL, then control flow jumps to the error handler without performing a decref on the "from" variable. As the "from" variable is initialised by POPping from the stack, the reference is leaked. ---------- components: Interpreter Core messages: 288582 nosy: Peter Cawley priority: normal severity: normal status: open title: Certain errors during IMPORT_STAR can leak a reference type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:38:15 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 21:38:15 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1488058695.13.0.933451746542.issue28587@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +266 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:40:23 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 25 Feb 2017 21:40:23 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1488058823.89.0.642674981868.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: I backported these changes to 3.5 branch. Please let me know if this is ok. Thanks. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:49:19 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sat, 25 Feb 2017 21:49:19 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488059359.76.0.830148812311.issue29655@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:49:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 21:49:58 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488059398.13.0.325620821516.issue29655@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> needs patch type: behavior -> resource usage versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 17:50:10 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Feb 2017 22:50:10 +0000 Subject: [issue29653] IDLE - call tips show wrapper's argpsec instead of wrapped In-Reply-To: <1488054872.48.0.0975525232786.issue29653@psf.upfronthosting.co.za> Message-ID: <1488063010.31.0.836502838682.issue29653@psf.upfronthosting.co.za> Terry J. Reedy added the comment: We usually prefer diffs rather than revised files, but I know not everyone can provide them. Did you change anything other than add the following? elif hasattr(ob, '__wrapped__') and callable(ob.__wrapped__): fob = ob.__wrapped__ I am all for accurate calltips. However, your patch will not work for the stdlib wrapper functools.partial. It does not add a __wrapped__ attribute. Instead it had args, func, and kwargs attributes. I plan on switching calltips from using inspect.getfullargspec to inspect.signature (#19903). The latter defaults to follow_wrapped=True, in which case, it should follow callable.__wrapped__. https://docs.python.org/3/library/inspect.html#inspect.signature. It also is documented to work with partials and in my test, it indeed followed .func to get the original signature and remove the parameters set in the partial call. So this request is a duplicate in that it will be fixed by the existing issue. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Idle: Use inspect.signature for calltips _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 17:50:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 22:50:54 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488063054.53.0.0543206449117.issue29645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added tests. ---------- Added file: http://bugs.python.org/file46670/webbrowser-delayed-initialization-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 17:55:51 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Feb 2017 22:55:51 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1488063351.43.0.438186541535.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Several builtin functions have recently gotten the Arg clinic treatment. So I think it is now time to switch. Before closing #29653 as a duplicate, I discovered that inspect.signature also handles functools.partials correctly, while the other inspect functions do not. ---------- versions: +Python 3.6, Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 20:28:54 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 26 Feb 2017 01:28:54 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488072534.95.0.442784170452.issue29655@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +267 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 22:43:29 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 03:43:29 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488080609.32.0.184874203883.issue29645@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch LGTM. Serhiy, did you want to take this as a chance to run through the new GitHub PR workflow? Current details are at https://docs.python.org/devguide/pullrequest.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 23:52:17 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 04:52:17 +0000 Subject: [issue29656] Change "make patchcheck" to be branch aware? Message-ID: <1488084737.09.0.284465642742.issue29656@psf.upfronthosting.co.za> New submission from Nick Coghlan: With the switch to a PR based workflow, I'm finding the current incarnation of "make patchcheck" less helpful than it used to be, as it only checks uncommitted changes, rather than all changes relative to the base branch. Looking at Tools/scripts/patchcheck.py, it seems like it should be possible to use sys.version_info to calculate a suitable base branch ('master' if the release is alpha, '{major}.{minor}' otherwise), but things get a bit trickier from there: - the local branches may not be up to date if the PR branch is based directly on a remote branch, so we can't rely on those - figuring out which remote to use isn't immediately obvious, but we could probably go with an approach of using "upstream/{branch}" if an "upstream" remote is defined, and "origin/{branch}" otherwise - once we have a base branch to use, then `git diff --name-status {branch}` should give us the file list in a similar format to the current `git status --porcelain` I'll put together a PR for this approach. ---------- assignee: ncoghlan messages: 288588 nosy: brett.cannon, ncoghlan priority: normal severity: normal status: open title: Change "make patchcheck" to be branch aware? type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 23:52:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 04:52:30 +0000 Subject: [issue29656] Change "make patchcheck" to be branch aware In-Reply-To: <1488084737.09.0.284465642742.issue29656@psf.upfronthosting.co.za> Message-ID: <1488084750.01.0.789887991445.issue29656@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: Change "make patchcheck" to be branch aware? -> Change "make patchcheck" to be branch aware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 00:54:50 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 05:54:50 +0000 Subject: [issue29656] Change "make patchcheck" to be branch aware In-Reply-To: <1488084737.09.0.284465642742.issue29656@psf.upfronthosting.co.za> Message-ID: <1488088490.95.0.720907757539.issue29656@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- pull_requests: +268 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 02:14:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 07:14:06 +0000 Subject: [issue29645] webbrowser module import has heavy side effects In-Reply-To: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> Message-ID: <1488093246.26.0.200288429156.issue29645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The new GitHub PR workflow still looks cumbersome and unclear to me. It needs using a lot of git commands different for different branches (and some command are failed or don't work as I expected when I try to repeat sequences from the devguide). How to convert a patch to a pull request? How to get a list of added and modified files? What is the best way to revert all changes and changes in selected files? How to retrieve changes from pull request for local testing? Is there a way to edit otherpeople's pull request (add an entry in Misc/NEWS, etc) before merging it in the main repository? I wait until the devguide be more comprehensive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 02:31:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 07:31:42 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488094302.03.0.963841300159.issue29648@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 02:33:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 07:33:44 +0000 Subject: [issue23578] struct.pack error messages do not indicate which argument was invalid In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za> Message-ID: <1488094424.28.0.536185443523.issue23578@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka priority: normal -> low stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 02:49:41 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 26 Feb 2017 07:49:41 +0000 Subject: [issue29650] abstractmethod does not work when deriving from Exception In-Reply-To: <1488041206.17.0.0120524792135.issue29650@psf.upfronthosting.co.za> Message-ID: <1488095381.41.0.665320296475.issue29650@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes. This is the case for builtin types which usually get their own __new__ methods. See #5996. ---------- dependencies: +abstract class instantiable when subclassing dict nosy: +xiang.zhang versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 03:06:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 08:06:38 +0000 Subject: [issue29650] abstractmethod does not work when deriving from Exception In-Reply-To: <1488041206.17.0.0120524792135.issue29650@psf.upfronthosting.co.za> Message-ID: <1488096398.92.0.714512194411.issue29650@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -abstract class instantiable when subclassing dict resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> abstract class instantiable when subclassing dict _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 03:52:24 2017 From: report at bugs.python.org (Wolfgang Rohdewald) Date: Sun, 26 Feb 2017 08:52:24 +0000 Subject: [issue29657] os.symlink: FileExistsError shows wrong message Message-ID: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za> New submission from Wolfgang Rohdewald: execute the attached script. It should return FileExistsError: [Errno 17] File exists: 'a_link' -> 'a' but it returns FileExistsError: [Errno 17] File exists: 'a' -> 'a_link' ---------- components: Library (Lib) files: x.py messages: 288591 nosy: wrohdewald priority: normal severity: normal status: open title: os.symlink: FileExistsError shows wrong message versions: Python 3.5 Added file: http://bugs.python.org/file46671/x.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 05:10:30 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 10:10:30 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488103830.18.0.530179598357.issue29110@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: serhiy.storchaka -> inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 05:41:34 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 26 Feb 2017 10:41:34 +0000 Subject: [issue29657] os.symlink: FileExistsError shows wrong message In-Reply-To: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za> Message-ID: <1488105694.19.0.603687625623.issue29657@psf.upfronthosting.co.za> Xiang Zhang added the comment: I concur the current message is misleading. OSError makes the string "file1 -> file2". This also affects other methods calling `path_error2()` such as os.link(). ---------- nosy: +xiang.zhang versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 06:23:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 11:23:54 +0000 Subject: [issue29598] Write unit tests for pdb module In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za> Message-ID: <1488108234.37.0.0249320602166.issue29598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And decorate this test class with test.support.cpython_only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 06:39:21 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 11:39:21 +0000 Subject: [issue28961] unittest.mock._Call ignores `name` parameter In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za> Message-ID: <1488109161.57.0.581021679929.issue28961@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +269 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 06:42:13 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 11:42:13 +0000 Subject: [issue28961] unittest.mock._Call ignores `name` parameter In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za> Message-ID: <1488109333.07.0.233510221131.issue28961@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +270 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 07:42:22 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 26 Feb 2017 12:42:22 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488112942.28.0.499147122845.issue29110@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +271 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 07:43:13 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 26 Feb 2017 12:43:13 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488112993.42.0.402348982415.issue29110@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +272 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:06:44 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 13:06:44 +0000 Subject: [issue28961] unittest.mock._Call ignores `name` parameter In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za> Message-ID: <1488114404.03.0.894304967918.issue28961@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:14:41 2017 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 26 Feb 2017 13:14:41 +0000 Subject: [issue29652] Fix evaluation order of keys/values in dict comprehensions In-Reply-To: <1488052483.04.0.021043093911.issue29652@psf.upfronthosting.co.za> Message-ID: <1488114881.87.0.45728974487.issue29652@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:26:00 2017 From: report at bugs.python.org (Sayan Chowdhury) Date: Sun, 26 Feb 2017 13:26:00 +0000 Subject: [issue29657] os.symlink: FileExistsError shows wrong message In-Reply-To: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za> Message-ID: <1488115560.75.0.0655078135613.issue29657@psf.upfronthosting.co.za> Changes by Sayan Chowdhury : ---------- nosy: +sayanchowdhury _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:48:30 2017 From: report at bugs.python.org (djstrong) Date: Sun, 26 Feb 2017 13:48:30 +0000 Subject: [issue29658] Process hangs (sometimes) Message-ID: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> New submission from djstrong: I have this code, which sometimes hangs (1 of 5 runs): # -*- coding: utf-8 -*- import sys import threading import multiprocessing mpl = multiprocessing.log_to_stderr() mpl.setLevel(1) class A(threading.Thread): def __init__(self): super(A, self).__init__() def run(self): print(self.name, 'RUN') for line in sys.stdin: #increases probability of hanging pass print(self.name, 'STOP') class B(multiprocessing.Process): def __init__(self): super(B, self).__init__() def run(self): print(self.name, 'RUN') a = A() a.start() b = B() b.start() print('B started', b, b.is_alive(), b.pid) print('A', a) a.join() b.join() print('FINISHED') I am running it on Ubuntu with command: echo "" | python3 time_test4.py Output is: Thread-1 RUN B started True 31439 A Thread-1 STOP ---------- messages: 288594 nosy: djstrong priority: normal severity: normal status: open title: Process hangs (sometimes) type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:49:23 2017 From: report at bugs.python.org (djstrong) Date: Sun, 26 Feb 2017 13:49:23 +0000 Subject: [issue29658] Combining thread and process, process hangs (sometimes) In-Reply-To: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> Message-ID: <1488116963.5.0.420151500783.issue29658@psf.upfronthosting.co.za> Changes by djstrong : ---------- title: Process hangs (sometimes) -> Combining thread and process, process hangs (sometimes) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:58:23 2017 From: report at bugs.python.org (djstrong) Date: Sun, 26 Feb 2017 13:58:23 +0000 Subject: [issue29658] Combining thread and process, process hangs (sometimes) In-Reply-To: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> Message-ID: <1488117503.16.0.40103911342.issue29658@psf.upfronthosting.co.za> djstrong added the comment: Sometimes the output is: Thread-1 RUN Thread-1 STOP B started True 20187 A [INFO/B-1] child process calling self.run() but "print" in "run" method of process is not executed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 09:12:56 2017 From: report at bugs.python.org (Sayan Chowdhury) Date: Sun, 26 Feb 2017 14:12:56 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1488118376.32.0.32344286052.issue25452@psf.upfronthosting.co.za> Changes by Sayan Chowdhury : ---------- pull_requests: +273 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 09:20:42 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 14:20:42 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488118842.0.0.542644073216.issue29648@psf.upfronthosting.co.za> Nick Coghlan added the comment: Version added is correct here, as the "create_module()" methods are all new in 3.4, and the traditional granularity for deciding "addition or change?" is that new functions, methods, and attributes are always additions, even if they're being added to a class definition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:12:37 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 15:12:37 +0000 Subject: [issue29121] sqlite3 Controlling Transactions documentation not updated In-Reply-To: <1483200295.1.0.801871810477.issue29121@psf.upfronthosting.co.za> Message-ID: <1488121957.73.0.953990806959.issue29121@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +274 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:23:46 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:23:46 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488122626.58.0.161796246788.issue29648@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +275 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:24:33 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:24:33 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488122673.94.0.453013714803.issue29648@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +276 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:29:33 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:29:33 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1488122973.74.0.836053402243.issue22594@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +277 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:30:05 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:30:05 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1488123005.2.0.785674789166.issue22594@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +278 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:30:12 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 15:30:12 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1488123012.03.0.224575048183.issue28518@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +279 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:34:20 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 15:34:20 +0000 Subject: [issue29121] sqlite3 Controlling Transactions documentation not updated In-Reply-To: <1483200295.1.0.801871810477.issue29121@psf.upfronthosting.co.za> Message-ID: <1488123260.67.0.867457735367.issue29121@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +280 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:38:53 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:38:53 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1488123533.29.0.895177092148.issue26184@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +281 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:41:55 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:41:55 +0000 Subject: [issue29648] Missed reference to create_module() in versionadded (import.rst) In-Reply-To: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> Message-ID: <1488123715.7.0.315043037991.issue29648@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for the clarification, Nick :) Marco, I merged your PR, and backported to 3.5 and 3.6 branches. Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 10:48:23 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 15:48:23 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1488124103.58.0.866129548685.issue22594@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +282 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 11:04:48 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 16:04:48 +0000 Subject: [issue29121] sqlite3 Controlling Transactions documentation not updated In-Reply-To: <1483200295.1.0.801871810477.issue29121@psf.upfronthosting.co.za> Message-ID: <1488125088.9.0.774875668346.issue29121@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Aviv! ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 11:09:49 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 16:09:49 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1488125389.18.0.960375534868.issue28518@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you everyone! This should be fixed now. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 11:11:55 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 16:11:55 +0000 Subject: [issue29355] sqlite3: remove sqlite3_stmt_readonly() In-Reply-To: <1485232693.83.0.291296040478.issue29355@psf.upfronthosting.co.za> Message-ID: <1488125515.95.0.161886676135.issue29355@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch for issue 28518 has been merged and it doesn't contain any use of sqlite3_stmt_readonly(). Closing this as 'out of date'. Thanks again Ma! ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 11:14:07 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 16:14:07 +0000 Subject: [issue29098] document minimum sqlite version In-Reply-To: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za> Message-ID: <1488125647.0.0.577359976176.issue29098@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Carl! The patch for issue 28518 has been lifted the requirement for sqlite3_stmt_readonly() so you can now use and compile Python 3.6.1 without a warning at compile time. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:00:13 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 17:00:13 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488128413.77.0.389491511872.issue28231@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +283 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:05:02 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 17:05:02 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488128702.68.0.806213899459.issue28231@psf.upfronthosting.co.za> Berker Peksag added the comment: PR 322 should make the example in msg284754 work: >>> import pathlib, zipfile >>> f = pathlib.Path('spam.zip') >>> with zipfile.ZipFile(f) as zf: ... zf.namelist() ... ['LICENSE'] It doesn't implement full PathLike support, but it at least covers the use cases of Jeremy and Steve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:09:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Feb 2017 17:09:59 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1488128999.1.0.218133241872.issue25452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure that it is worth to implement the __bool__() method. This doesn't add much in comparison with checking the returncode attribute. The change can break existing code that uses boolean testing instead of checking for None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:11:17 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 17:11:17 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` In-Reply-To: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> Message-ID: <1488129077.02.0.224109484443.issue28624@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +284 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:21:40 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 17:21:40 +0000 Subject: [issue28230] tarfile does not support pathlib In-Reply-To: <1476104684.24.0.949542495586.issue28230@psf.upfronthosting.co.za> Message-ID: <1488129700.55.0.19945185215.issue28230@psf.upfronthosting.co.za> Berker Peksag added the comment: Serhiy's patch looks good to me, but it would be nice to document the support for PathLike objects in the tarfile documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 12:39:04 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Feb 2017 17:39:04 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` In-Reply-To: <1487418512.16.0.401961352482.issue28624@psf.upfronthosting.co.za> Message-ID: <1488130744.33.0.649399002451.issue28624@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Sayan! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 13:04:42 2017 From: report at bugs.python.org (paul j3) Date: Sun, 26 Feb 2017 18:04:42 +0000 Subject: [issue25882] argparse help error: arguments created by add_mutually_exclusive_group() are shown outside their parent group created by add_argument_group() In-Reply-To: <1450271683.16.0.602190712987.issue25882@psf.upfronthosting.co.za> Message-ID: <1488132282.69.0.0728585965551.issue25882@psf.upfronthosting.co.za> paul j3 added the comment: Earlier issue on the same topic - passing a mutually exclusive group via parents http://bugs.python.org/issue16807 Can they be consolidated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 13:15:36 2017 From: report at bugs.python.org (paul j3) Date: Sun, 26 Feb 2017 18:15:36 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1488132936.12.0.434199060448.issue29553@psf.upfronthosting.co.za> paul j3 added the comment: The PR117 patch adds an apparent symmetry. There's a if/else for 'start', so shouldn't there also be one for 'end'? if start in inserts: inserts[start] += ' [' else: inserts[start] = '[' But why the '+=' case? It's needed for cases like this: usage: prog [-h] [-A | -B] [-C | -D] It ensures that the insert between B and C is '] [', as opposed to just '['. Without any groups usage for the 4 Actions is usage: prog [-h] [-A] [-B] [-C] [-D] Adding the first group adds a '[','|', and ']' (the inner [] will be deleted later). The second group also wants to add '[','|',']', but its '[' has to be concatenated to the existing ']', rather than replace it. ----- To understand what's happening when we nest groups, we have to look at the resulting groups. Usage is created with formatter.add_usage(self.usage, self._actions, self._mutually_exclusive_groups) In christofsteel's original example, the parser._mutually_exclusive_groups is a len 3 list. Each group has a list of '_group_actions'. In [13]: [len(g._group_actions) for g in parser._mutually_exclusive_groups] Out[13]: [6, 4, 2] The first, outermost group, contains all the defined Actions, including the ones defined in the nested groups. It doesn't contain 2 actions and a group. The link between child and parent group is one way. The child knows its 'container', but the parent has not information about 'children'. Usage using just the 1st group produces: usage: ipython3 [-h] [-a A | -b B | -c C | -d D | -e E | -f F] With 2 groups: usage: ipython3 [-h] [-a A | -b B | [-c C | -d D | -e E | -f F] The second group has added it's '[ | | | ]' on top of the first group's inserts. The '[' was appended, the others over write. That's more apparent if I change the 2nd group to be 'required': usage: ipython3 [-h] [-a A | -b B | (-c C | -d D | -e E | -f F) The final ']' (from the 1st group) has been replaced with a ')'. The patch ensures that the new ']' is appended to the existing ']'. But if the 2nd group is required, the patch will produce: | -f F]) not | -f F)] as would be expected if the groups were really nested. In sum, patching brittle code to do something it wasn't designed to do in the first place isn't the solution. Disabling nesting as recommended in http://bugs.python.org/issue22047, is, I think a better solution. --- An old (2011) issue tries to put an action in 2 or more groups: http://bugs.python.org/issue10984 'argparse add_mutually_exclusive_group should accept existing arguments to register conflicts' Adding an existing action to a new group is relatively easy. But usage display runs into the same issues. I had to recommend a total rewrite that ditches the 'inserts' approach entirely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 13:20:35 2017 From: report at bugs.python.org (Aaron Whitehouse) Date: Sun, 26 Feb 2017 18:20:35 +0000 Subject: [issue28718] '*' matches entire path in fnmatch In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za> Message-ID: <1488133235.82.0.840528272019.issue28718@psf.upfronthosting.co.za> Aaron Whitehouse added the comment: Note that somebody has forked the standard library to implement this: https://github.com/kianxineki/python-wildcard This shows that the actual changes would be pretty small (though pywildcard is based on 2.x code and does not handle the cross-platform slashes you have been discussing). It is also worth noting that the glob standard library: https://docs.python.org/3.7/library/glob.html implements a "recursive" option that has similar behaviour (* does not span path separators whereas ** does) and essentially builds this on top of fnmatch for the actual filename matching. I do not think we can change the default behaviour of fnmatch at this point, but I would like to see this behaviour triggered by an optional argument to the various functions, e.g.: fnmatch.fnmatch(filename, pattern, glob_asterisks=False) fnmatch.fnmatchcase(filename, pattern, glob_asterisks=False) fnmatch.filter(names, pattern, glob_asterisks=False) fnmatch.translate(pattern, glob_asterisks=False) In each case, if glob_asterisks (or whatever other name we came up with) is true, the behaviour would match the pywildcard behaviour, i.e.: ** matches everything * matches in one path level I look after the glob matching code in duplicity and would like to start using the standard library to do filename matching for us, but we need the above behaviour. I am happy to do the patching if there is a realistic chance of it being accepted. ---------- nosy: +aaron-whitehouse title: '*' matches entire path in fnmatch.translate -> '*' matches entire path in fnmatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 14:15:41 2017 From: report at bugs.python.org (paul j3) Date: Sun, 26 Feb 2017 19:15:41 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1488136541.81.0.323938300425.issue29553@psf.upfronthosting.co.za> paul j3 added the comment: I should probably give PR 120 more credit. By checking the group's container it in effect eliminates this overlapping action problem. Nested groups aren't used in the usage, just the union xor. Maybe the question is, which is better for the user? To tell them up front that nesting is not allowed, or to display the union group without further comment? Does allowing nesting on the input give them a false sense of control? More often on StackOverFlow users try to nest ArgumentGroups in a mutually exclusive one, thinking that this will give some sort of 'any-of' logic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 14:17:52 2017 From: report at bugs.python.org (djstrong) Date: Sun, 26 Feb 2017 19:17:52 +0000 Subject: [issue29658] Combining thread and process, process hangs (sometimes) In-Reply-To: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> Message-ID: <1488136672.09.0.126035646376.issue29658@psf.upfronthosting.co.za> djstrong added the comment: It is confirmed with other hardware with Python 3.5.2. Process is forked, but method "run" is not executing. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 14:50:39 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 26 Feb 2017 19:50:39 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488138639.57.0.091662481647.issue29110@psf.upfronthosting.co.za> INADA Naoki added the comment: Anyone mind Python 2.7? Since Python 2.7 doesn't have mock and check_no_resource_warning context manager, I can't cherry-pick easily. Backporting is bother to me, and the issue doesn't seem so critical. Can I just close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 16:04:16 2017 From: report at bugs.python.org (Andrew Nester) Date: Sun, 26 Feb 2017 21:04:16 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted In-Reply-To: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> Message-ID: <1488143056.87.0.625137326813.issue29573@psf.upfronthosting.co.za> Andrew Nester added the comment: some updates? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 16:06:33 2017 From: report at bugs.python.org (Andrew Nester) Date: Sun, 26 Feb 2017 21:06:33 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1488143193.75.0.163521959486.issue29553@psf.upfronthosting.co.za> Andrew Nester added the comment: JFYI, from my perspective as a developer PR 120 is more preferred one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 16:08:47 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 21:08:47 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1488143327.15.0.808283209644.issue26184@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +285 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 16:25:59 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 21:25:59 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1488144359.86.0.713803983317.issue26184@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +286 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 16:39:41 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 26 Feb 2017 21:39:41 +0000 Subject: [issue26184] Add versionchanged note for error when create_module() is not defined by loaders In-Reply-To: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za> Message-ID: <1488145181.92.0.261937442831.issue26184@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Merged and backported to 3.6. Closing this issue :) Thanks. ---------- nosy: +Mariatta resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 19:18:55 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 00:18:55 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488154735.6.0.874647538489.issue26389@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Just came across that with wanting to use print_exception and got the same idea. It seem like in print_exception, and format_exception, etype is already ignored and `type(value)` is used, so I think we could also "just" also ignore tb (unless set) and use `value.__traceback__`. Leaving the API to function(None, exception) I don't see any clean way to migrate to a new API (IMHO a forced `exc kwarg` is not discoverable enough vs a (None, e, e.__traceback__) A possibility, as `etype` is already unused, would be replace it with etype_or_exception, and in case it's a full exception use it as the sole parameter from which type and tb get extracted. Though that feels weird as well, and the Deprecation Cycles would need to be long. Already emitting deprecation warnings (that etype is ignored) would be good. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 19:57:24 2017 From: report at bugs.python.org (tyler) Date: Mon, 27 Feb 2017 00:57:24 +0000 Subject: [issue29659] Expose the `length` arg from shutil.copyfileobj for public use Message-ID: <1488157044.73.0.933925559387.issue29659@psf.upfronthosting.co.za> New submission from tyler: It would be handy to be able to pass the `length` default argument defined by `shutil.copyfileobj()` to other public functions througout the module. When copying very large files (1GB +), increasing the memory buffer can divide the copy time in half and currently the only way to accomplish this is by overriding the needed function(s) which call `shutil.copyfileobj()`. I propose a simple non-invasive change where the following functions will also expose the `length` kwarg and pass it downwards to `copyfileobj`: - copyfile - copy - copy2 ---------- messages: 288616 nosy: goodboy priority: normal severity: normal status: open title: Expose the `length` arg from shutil.copyfileobj for public use versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 20:14:23 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 01:14:23 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488158063.46.0.531868386531.issue26389@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +287 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 20:19:32 2017 From: report at bugs.python.org (Tyler Goodlet) Date: Mon, 27 Feb 2017 01:19:32 +0000 Subject: [issue29659] Expose the `length` arg from shutil.copyfileobj for public use In-Reply-To: <1488157044.73.0.933925559387.issue29659@psf.upfronthosting.co.za> Message-ID: <1488158372.51.0.156844978187.issue29659@psf.upfronthosting.co.za> Changes by Tyler Goodlet : ---------- pull_requests: +288 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 20:21:39 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 01:21:39 +0000 Subject: [issue29660] Document that print/format_exception ignore etype Message-ID: <1488158499.0.0.645448196253.issue29660@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: As far as I can tell, http://bugs.python.org/issue17911 made a couple of function in traceback ignore their first arguments (etype) and infer the type from the second one (evalue). (In git 6bc2c1e7 and 2f0441f0 respectively). At least print_exception and format_exception are affected. This likely affect http://bugs.python.org/issue26389 (who wish to expand same API to remove these parameters). And inconsistency with `format_exception_only` which does need `etype` should be checked. If etype is a deprecated parameter it should be noted, and should likely raise a DeprecationWarning as well when set. ---------- assignee: docs at python components: Documentation messages: 288617 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Document that print/format_exception ignore etype versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 20:24:20 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 01:24:20 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488158660.23.0.313698764624.issue26389@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: I've attempted a Pull-request trying to implement what Brett is describing. See https://github.com/python/cpython/pull/327, and opened http://bugs.python.org/issue29660 to document that etype is ignored and decide wether it should emit DeprecationWarning when used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 22:16:29 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 03:16:29 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1488165389.1.0.100416439774.issue29376@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +289 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 22:17:08 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 03:17:08 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1488165428.61.0.357821060244.issue29376@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +290 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 22:47:40 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 03:47:40 +0000 Subject: [issue29376] threading._DummyThread.__repr__ raises AssertionError In-Reply-To: <1485385808.95.0.00162143215773.issue29376@psf.upfronthosting.co.za> Message-ID: <1488167260.7.0.632265622196.issue29376@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 23:02:11 2017 From: report at bugs.python.org (Antony Lee) Date: Mon, 27 Feb 2017 04:02:11 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange Message-ID: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> New submission from Antony Lee: The docstring of timeit.Timer.autorange currently reads | Return the number of loops so that total time >= 0.2. | | Calls the timeit method with *number* set to successive powers of | ten (10, 100, 1000, ...) up to a maximum of one billion, until | the time taken is at least 0.2 second, or the maximum is reached. | Returns ``(number, time_taken)``. | | If *callback* is given and is not None, it will be called after | each trial with two arguments: ``callback(number, time_taken)``. Note the contradiction between the return values documented in the first and second paragraphs (the second one is correct). ---------- components: Library (Lib) messages: 288619 nosy: Antony.Lee priority: normal severity: normal status: open title: Typo in the docstring of timeit.Timer.autorange versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 23:02:39 2017 From: report at bugs.python.org (Antony Lee) Date: Mon, 27 Feb 2017 04:02:39 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488168159.31.0.88763491359.issue29661@psf.upfronthosting.co.za> Changes by Antony Lee : ---------- nosy: -Antony.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 23:56:35 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 04:56:35 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488171395.93.0.0957667424407.issue29661@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +291 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:01:40 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:01:40 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488171700.96.0.625110727597.issue29661@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- assignee: -> xiang.zhang nosy: +xiang.zhang stage: -> patch review versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:08:33 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:08:33 +0000 Subject: [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488172113.69.0.408752605345.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- assignee: xiang.zhang components: Documentation nosy: xiang.zhang priority: normal severity: normal stage: patch review status: open title: Fix wrong indentation of timeit.Timer's documenation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:08:48 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:08:48 +0000 Subject: [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488172128.29.0.960538403301.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:10:37 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:10:37 +0000 Subject: [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488172237.94.0.816463326724.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +292 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:49:26 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:49:26 +0000 Subject: [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488174566.8.0.044667251571.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +293 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:55:48 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:55:48 +0000 Subject: [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488174948.56.0.226971253266.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 02:09:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 07:09:57 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488179397.71.0.830854048787.issue28231@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have different path. It adds the support of path-like objects for all external paths. ---------- type: behavior -> enhancement versions: -Python 3.6 Added file: http://bugs.python.org/file46672/zipfile-pathlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 02:31:36 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Feb 2017 07:31:36 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488180696.37.0.173765173015.issue26389@psf.upfronthosting.co.za> Martin Panter added the comment: Matthias?s proposal adds support for a new keyword-only ?exc? argument: print_exception(exc=exception_instance) I still think it is worth supporting a single positional argument as well: print_exception(exception_instance) Another point is that it may be better to keep the existing parameter name ?value?, rather than (eventually?) replacing it with ?exc?. I think both of these things could be accomplished by juggling the ?value? and ?etype? parameters: def print_exception(etype=None, value=None, tb=None, ...): if value is None: # Assume value passed as first positional argument value = etype etype = None if etype is tb is None: # Only value passed etype = type(value) tb = value.__traceback__ # Existing code using (etype, value, tb) The disadvantage of any of these changes is that we may want to maintain support for the old signature while Python 2 remains alive. ---------- stage: test needed -> patch review versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 03:11:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 08:11:06 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488183066.28.0.535723304838.issue29110@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: test.support.swap_attr() provides the functionality similar to mock. check_no_resource_warning() can be backported to 2.7. But if there are problems with testing in 2.7 you can backport without tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 03:39:13 2017 From: report at bugs.python.org (Evangelos Kounis) Date: Mon, 27 Feb 2017 08:39:13 +0000 Subject: [issue29652] Fix evaluation order of keys/values in dict comprehensions In-Reply-To: <1488052483.04.0.021043093911.issue29652@psf.upfronthosting.co.za> Message-ID: <1488184753.68.0.658848407822.issue29652@psf.upfronthosting.co.za> Changes by Evangelos Kounis : ---------- nosy: +EvKounis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 04:35:03 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Feb 2017 09:35:03 +0000 Subject: [issue29652] Fix evaluation order of keys/values in dict comprehensions In-Reply-To: <1488052483.04.0.021043093911.issue29652@psf.upfronthosting.co.za> Message-ID: <1488188103.39.0.873813542322.issue29652@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think the current behavior is correct and desirable (as you say, it follows the order that would take place in an assignment, making it easy to roll-up existing for-loop code into a dict comprehension or to unroll and existing comprehension). Also, I think changing the behavior might risk introducing bugs into existing code that may have unconsciously relied on the existing order. My recommendation is to document the current value-first behavior. For the other issue, 11205, I agree with the discussion there that key-first-value-second makes more sense in the context of literals which are normally evaluated left-to-right. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 04:39:44 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Feb 2017 09:39:44 +0000 Subject: [issue29658] Combining thread and process, process hangs (sometimes) In-Reply-To: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> Message-ID: <1488188384.1.0.249834484818.issue29658@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unless I'm misreading what you're trying to do, this doesn't seem like a bug to me. In general, when combining threading with multiple processes, the rule is to fork first and then launch threads (so that none of the thread ids or locks accidentally get shared across processes). ---------- assignee: -> davin nosy: +davin, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 04:44:52 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Feb 2017 09:44:52 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488188692.96.0.162085245367.issue29661@psf.upfronthosting.co.za> Raymond Hettinger added the comment: How about: Return the number of loops and time taken so that total time >= 0.2. Instead of: Return the number of loops so that total time >= 0.2. The proposed "calculate" instead of "return" isn't really correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 04:47:49 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Feb 2017 09:47:49 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1488188869.73.0.990097465049.issue25452@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > The change can break existing code that uses boolean testing > instead of checking for None. For this reason, I think Guido would oppose this proposal. In the past he has objected to iterators having a True boolean value to indicate that there were more values available for iteration. I think similar reasoning applies here. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 04:50:17 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 09:50:17 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488189017.33.0.459779438251.issue29661@psf.upfronthosting.co.za> Xiang Zhang added the comment: Of course that is okay. I didn't do what you propose since I thought it's somewhat superfluous, what is returned is mentioned below. I choose 'calculate' when I see 'Automatically determine how many times to call timeit()' in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:13:57 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Feb 2017 10:13:57 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 In-Reply-To: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> Message-ID: <1488190437.1.0.863727982397.issue29639@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure how much of the original analysis was right. I've just fired up a network-less Windows VM and 'localhost' seems to resolve just fine: >>> socket.gethostbyname('localhost') '127.0.0.1' >>> socket.getaddrinfo('localhost', 80, socket.AF_UNSPEC, socket.SOCK_STREAM) [(, , 0, '', ('::1', 80, 0, 0)), (, , 0, '', ('127.0.0.1', 80))] But we should defer to our Windows experts on this. (also, perhaps we should simply mandate that buildbots have at least basic DNS functionality. This would lighten the maintenance load on the test suite slightly.) ---------- nosy: +paul.moore, pitrou, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:21:30 2017 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 27 Feb 2017 10:21:30 +0000 Subject: [issue29663] Make collections.deque json serializable Message-ID: <1488190890.97.0.257287797026.issue29663@psf.upfronthosting.co.za> New submission from Tarek Ziad?: collections.deque could be serialized in JSON as a simple array. The only thing we can lose in the process is the maxlen value, but I think it's a decent behaviour to ignore it when encoding and to set it to None when decoding. ---------- components: Library (Lib) messages: 288629 nosy: rhettinger, tarek priority: normal severity: normal status: open title: Make collections.deque json serializable versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:34:48 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Feb 2017 10:34:48 +0000 Subject: [issue29663] Make collections.deque json serializable In-Reply-To: <1488190890.97.0.257287797026.issue29663@psf.upfronthosting.co.za> Message-ID: <1488191688.34.0.561948541627.issue29663@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 This isn't really different that how we handle tuples and I can see that it would be useful to be able to dump a deque into JSON. I concur that it is reasonable to ignore maxlen because that is primarily a convenience feature (auto-popping on overflow) rather than something that is intrinsic to the semantics of data itself. ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:38:18 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:38:18 +0000 Subject: [issue29664] zip() python 3 documentation not working at all ! Message-ID: <1488191898.8.0.43175985321.issue29664@psf.upfronthosting.co.za> New submission from Muhammad Salem: this code from the python documentation itself not working! >>> x = [1, 2, 3] >>> y = [4, 5, 6] >>> zipped = zip(x, y) this code is copied from the python 3 official documentation itself even though it is working for me I am using python 3.5.2 on ubuntu 16.04 LTS ---------- components: Interpreter Core messages: 288631 nosy: Muhammad Salem priority: normal severity: normal status: open title: zip() python 3 documentation not working at all ! type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:40:38 2017 From: report at bugs.python.org (Lele Gaifax) Date: Mon, 27 Feb 2017 10:40:38 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1488192038.18.0.466905245574.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: Now that we are is officially on GH, would you welcome a PR rebasing this patch on top of the master branch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:47:29 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:47:29 +0000 Subject: [issue29664] zip() python 3 documentation not working at all ! In-Reply-To: <1488191898.8.0.43175985321.issue29664@psf.upfronthosting.co.za> Message-ID: <1488192449.26.0.263182801294.issue29664@psf.upfronthosting.co.za> Muhammad Salem added the comment: --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () 6 x = [1, 2, 3] 7 y = [4, 5, 6] ----> 8 zip(x, y) TypeError: 'tuple' object is not callable ---------- components: -Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:50:47 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:50:47 +0000 Subject: [issue29665] how to edit or delete issues created by me in bug tracker Message-ID: <1488192647.78.0.178839998452.issue29665@psf.upfronthosting.co.za> Changes by Muhammad Salem : ---------- nosy: Muhammad Salem priority: normal severity: normal status: open title: how to edit or delete issues created by me in bug tracker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:51:14 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:51:14 +0000 Subject: [issue29665] how to edit or delete issues created by me in bug tracker ?! Message-ID: <1488192674.39.0.524601734316.issue29665@psf.upfronthosting.co.za> Changes by Muhammad Salem : ---------- title: how to edit or delete issues created by me in bug tracker -> how to edit or delete issues created by me in bug tracker ?! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 06:04:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 11:04:40 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1488193480.71.0.220019679156.issue25452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue26748. Classes usually have True boolean value, but empty enum classes were False-y by accident. This was considered a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 06:08:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 11:08:31 +0000 Subject: [issue29663] Make collections.deque json serializable In-Reply-To: <1488190890.97.0.257287797026.issue29663@psf.upfronthosting.co.za> Message-ID: <1488193711.77.0.0788644870133.issue29663@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue20774. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> collections.deque should ship with a stdlib json serializer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 06:14:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 11:14:19 +0000 Subject: [issue29664] zip() python 3 documentation not working at all ! In-Reply-To: <1488191898.8.0.43175985321.issue29664@psf.upfronthosting.co.za> Message-ID: <1488194059.68.0.946004208874.issue29664@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Your example works for me. >>> x = [1, 2, 3] >>> y = [4, 5, 6] >>> zipped = zip(x, y) >>> print(zipped) >>> print(list(zipped)) [(1, 4), (2, 5), (3, 6)] I guess you have overridden the builtin function "zip" by setting the global variable "zip". >>> zip = (7, 8) >>> zipped = zip(x, y) Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' object is not callable ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 06:26:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Feb 2017 11:26:55 +0000 Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za> Message-ID: <1488194815.71.0.520387896523.issue25452@psf.upfronthosting.co.za> STINNER Victor added the comment: For all reasons alread given in the previous comment and my comment below, I reject the proposed change. Serhiy> See also issue26748. Classes usually have True boolean value, but empty enum classes were False-y by accident. This was considered a bug. Another example: issue #13936, "RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True". datetime.time was changed in Python 3.5 to always be true, especially for the time 00:00:00. It's the opposite of the proposed change for CompletedProcess. The problem is also that different users can expect a different answer from bool(CompletedProcess): non-zero return code, non-empty stdout, empty stderr, etc. CompleteProcess is a complex object with many attributes, it's not as simple as a tuple or a string, where the truthness is obvious. > Richard Neumann: "A useless use case is attached." "if subprocess.run(...):" Sorry, I'm not convinced that the need of breaking the backward compatibility for this "useless use case". It's trivial to split it in two lines: "cmd = subprocess.run(...); if cmd.returncode: (...)" By the way, it became common that I write such code, and in this case, I need the returncode value in the if block: "cmd = subprocess.run(...); if cmd.returncode: sys.exit(cmd.returncode)". So I need the CompletedProcess object anyway. ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 07:06:56 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 12:06:56 +0000 Subject: [issue28911] Clarify the behaviour of assert_called_once_with In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za> Message-ID: <1488197216.48.0.224419571961.issue28911@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -153957 resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 07:11:25 2017 From: report at bugs.python.org (Paul Moore) Date: Mon, 27 Feb 2017 12:11:25 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 In-Reply-To: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> Message-ID: <1488197485.94.0.639172490695.issue29639@psf.upfronthosting.co.za> Paul Moore added the comment: I have a vague recollection of once working on a (Windows) system that mis-resolved localhost. But it was a long time ago, and I'm 100% OK with calling such a system broken. +1 on using localhost ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 07:36:56 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 12:36:56 +0000 Subject: [issue27840] functools.partial: don't copy keywoard arguments in partial_call()? In-Reply-To: <1471962843.41.0.64844621448.issue27840@psf.upfronthosting.co.za> Message-ID: <1488199016.76.0.166850433073.issue27840@psf.upfronthosting.co.za> Berker Peksag added the comment: PR 253 has been merged. ---------- nosy: +berker.peksag resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 08:07:42 2017 From: report at bugs.python.org (Brian Curtin) Date: Mon, 27 Feb 2017 13:07:42 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 In-Reply-To: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> Message-ID: <1488200862.12.0.240830222461.issue29639@psf.upfronthosting.co.za> Brian Curtin added the comment: I echo Paul. I think the last time I would have seen a problem was on Windows 2000, which is unsupported per PEP-11. +1 to using localhost ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 08:39:57 2017 From: report at bugs.python.org (djstrong) Date: Mon, 27 Feb 2017 13:39:57 +0000 Subject: [issue29658] Combining thread and process, process hangs (sometimes) In-Reply-To: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> Message-ID: <1488202797.41.0.588798656001.issue29658@psf.upfronthosting.co.za> djstrong added the comment: Thank you! I couldn't find information about first forking then launching threads. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 08:48:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Feb 2017 13:48:31 +0000 Subject: [issue29666] Issue in enum documentation Message-ID: <1488203311.1.0.764284916797.issue29666@psf.upfronthosting.co.za> New submission from STINNER Victor: https://docs.python.org/dev/library/enum.html "This module defines four enumeration classes that can be used to define unique sets of names and values: Enum, IntEnum, and IntFlags" Enum, IntEnum, IntFlag: I count 3 classes, no 4? Moreover, the correct class name is IntFlag, not IntFlags. Or did I miss something? haypo at selma$ ./python Python 3.7.0a0 (default, Feb 25 2017, 04:30:32) >>> import enum >>> enum.IntFlags ... AttributeError: module 'enum' has no attribute 'IntFlags' ---------- assignee: docs at python components: Documentation keywords: easy messages: 288642 nosy: docs at python, haypo priority: normal severity: normal status: open title: Issue in enum documentation versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 08:56:47 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 13:56:47 +0000 Subject: [issue29665] how to edit or delete issues created by me in bug tracker ?! Message-ID: <1488203807.83.0.0673951175482.issue29665@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:08:53 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Mon, 27 Feb 2017 14:08:53 +0000 Subject: [issue29666] Issue in enum documentation In-Reply-To: <1488203311.1.0.764284916797.issue29666@psf.upfronthosting.co.za> Message-ID: <1488204533.36.0.616979596403.issue29666@psf.upfronthosting.co.za> Jim Fasarakis-Hilliard added the comment: Yup, `IntFlags` is a typo, that's why the reference to it doesn't show too. Also, the fourth enum must be `Flag` which must of been omitted when it was added in `3.6`. ---------- nosy: +Jim Fasarakis-Hilliard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:21:40 2017 From: report at bugs.python.org (Martijn Pieters) Date: Mon, 27 Feb 2017 14:21:40 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488205300.59.0.462634034127.issue28598@psf.upfronthosting.co.za> Changes by Martijn Pieters : ---------- pull_requests: +294 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:26:15 2017 From: report at bugs.python.org (Ben Hoyt) Date: Mon, 27 Feb 2017 14:26:15 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1488205575.5.0.523268452982.issue28609@psf.upfronthosting.co.za> Changes by Ben Hoyt : ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:27:30 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 14:27:30 +0000 Subject: [issue27788] platform module's version number doesn't match its docstring In-Reply-To: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za> Message-ID: <1488205650.66.0.6820234689.issue27788@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +295 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:39:47 2017 From: report at bugs.python.org (Ben Hoyt) Date: Mon, 27 Feb 2017 14:39:47 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1488206387.49.0.240009390824.issue28609@psf.upfronthosting.co.za> Ben Hoyt added the comment: I definitely agree with Reuben here -- I just ran into this issue while creating a "production quality" tool, and the help message produced by argparse with nargs='*' confused me too. It's pretty clear that this is a simple bug in argparse's production of that usage message: it says ARGUMENT is required, but it isn't. However, the workaround of specifying an (unused) default is a reasonable workaround in the meantime -- thanks Paul. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:40:51 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 14:40:51 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1488206451.81.0.748949522069.issue24241@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +296 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:49:38 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 14:49:38 +0000 Subject: [issue29455] Mention coverage.py in trace module documentation In-Reply-To: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> Message-ID: <1488206978.64.0.105662294201.issue29455@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:52:19 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 14:52:19 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1488207139.72.0.464923123868.issue29414@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 09:54:48 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 14:54:48 +0000 Subject: [issue22594] Add a link to the regex module in re documentation In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za> Message-ID: <1488207288.35.0.0571049867348.issue22594@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 10:37:37 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 15:37:37 +0000 Subject: [issue29660] Document that print/format_exception ignore etype In-Reply-To: <1488158499.0.0.645448196253.issue29660@psf.upfronthosting.co.za> Message-ID: <1488209857.25.0.226208150105.issue29660@psf.upfronthosting.co.za> Changes by Matthias Bussonnier : ---------- pull_requests: +297 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 10:37:42 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Mon, 27 Feb 2017 15:37:42 +0000 Subject: [issue29636] Specifying indent in the json.tool command In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> Message-ID: <1488209862.75.0.998050392484.issue29636@psf.upfronthosting.co.za> Changes by Daniel Himmelstein : ---------- pull_requests: +298 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 10:44:30 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 15:44:30 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488210270.75.0.177637293324.issue26389@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > Another point is that it may be better to keep the existing parameter name ?value?, rather than (eventually?) replacing it with ?exc?. I think both of these things could be accomplished by juggling the ?value? and ?etype? parameters: I agreed, and that what I would have done outside of CPython, but that felt like this kind of juggling was frowned upon. > The disadvantage of any of these changes is that we may want to maintain support for the old signature while Python 2 remains alive. Your example does not seem to break the old signature. Or I fail to see how. If that way would be accepted I'm happy to implement it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 10:50:17 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Mon, 27 Feb 2017 15:50:17 +0000 Subject: [issue29636] Specifying indent in the json.tool command In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> Message-ID: <1488210617.32.0.195517514837.issue29636@psf.upfronthosting.co.za> Changes by Daniel Himmelstein : ---------- pull_requests: -230 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 10:53:06 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Mon, 27 Feb 2017 15:53:06 +0000 Subject: [issue29636] Specifying indent in the json.tool command In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> Message-ID: <1488210786.36.0.581893769163.issue29636@psf.upfronthosting.co.za> Daniel Himmelstein added the comment: For discussion on how to implement this, see + https://github.com/python/cpython/pull/201#discussion_r102146742 + https://github.com/python/cpython/pull/201#discussion_r102840190 + https://github.com/python/cpython/pull/201#discussion_r102891428 Implementation now moved to https://github.com/python/cpython/issues/345 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:08:03 2017 From: report at bugs.python.org (Martijn Pieters) Date: Mon, 27 Feb 2017 16:08:03 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488211683.12.0.807869238566.issue28598@psf.upfronthosting.co.za> Changes by Martijn Pieters : ---------- pull_requests: +299 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:08:37 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 16:08:37 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488211717.33.0.955381064692.issue28598@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:08:46 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 16:08:46 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488211726.35.0.0650498057307.issue28598@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:17:12 2017 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Feb 2017 16:17:12 +0000 Subject: [issue29666] Issue in enum documentation In-Reply-To: <1488203311.1.0.764284916797.issue29666@psf.upfronthosting.co.za> Message-ID: <1488212232.05.0.406295942814.issue29666@psf.upfronthosting.co.za> Ethan Furman added the comment: `Flag` and `IntFlag` are indeed the correct (and missing) names. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:43:38 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 16:43:38 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488213818.35.0.459676462219.issue29655@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +300 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 11:45:34 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 16:45:34 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488213934.94.0.971257787827.issue29655@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- pull_requests: +301 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:11:41 2017 From: report at bugs.python.org (Bob Kline) Date: Mon, 27 Feb 2017 17:11:41 +0000 Subject: [issue29667] socket module sometimes loses response packets Message-ID: <1488215501.4.0.436225777411.issue29667@psf.upfronthosting.co.za> New submission from Bob Kline: The socket module does not always return response packets which are successfully delivered to the client host. We ran into this problem with an HTTP request for which socket.recv() raised an exception instead of returning the 301 redirection response which the web server sent back: socket.error: [Errno 10054] An existing connection was forcibly closed by the remote host We did some packet tracing, and saw that there were six packets exchanged for the connection: client: [SYN] server: [SYN,ACK] client: [ACK] client: GET /cam HTTP/1.1 ...\r\n\r\n server: HTTP/1.0 301 Moved Permanently ...\r\n\r\n server: [RST,ACK] The failure appears to be timing dependent. If the 301 response is processed quickly enough (the usual case), the socket.recv() call returns it successfully to the caller. If sufficient delay is introduced, however, the 301 response is discarded, and the exception is raised. This can happen, for example, if the socket library has to take the time to handle setting up a requested timeout. On a slow enough machine, the following code will reproduce the problem: import socket s = socket.create_connection(("www.cancer.gov", 80), timeout=5) s.sendall("GET /cam HTTP/1.1\r\nHost: www.cancer.gov\r\n\r\n") print s.recv(8192) You might have to stick a time.sleep(.5) call right in front of the s.recv() call if you can't find a slow enough machine to test on. This appears to be a Windows-specific problem, as I can't reproduce it on a Linux or OS X client, no matter how much of a delay is introduced. Platform: Windows (any version) with Python 2.7 or Python 3.6. ---------- components: Library (Lib) messages: 288648 nosy: bkline priority: normal severity: normal status: open title: socket module sometimes loses response packets type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:25:39 2017 From: report at bugs.python.org (Rafael Capucho) Date: Mon, 27 Feb 2017 17:25:39 +0000 Subject: [issue29668] f-strings don't change the values as expected. Message-ID: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> New submission from Rafael Capucho: In the attached file, the lines 4 and 6 have the same structure, the line 4 changes the value of {a} properly, the line 6 didn't. Thank you. ---------- components: Interpreter Core files: crazy.png messages: 288649 nosy: Rafael Capucho priority: normal severity: normal status: open title: f-strings don't change the values as expected. type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46673/crazy.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:27:59 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Feb 2017 17:27:59 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488216479.03.0.167120215839.issue28231@psf.upfronthosting.co.za> Steve Dower added the comment: Why can't we fix this in 3.6? We were meant to support pathlike in that version, and this is an oversight, not a new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:28:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 17:28:15 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488216495.63.0.521103213929.issue29668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please provide your example as a text. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:31:36 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Feb 2017 17:31:36 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 In-Reply-To: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> Message-ID: <1488216696.72.0.329690505952.issue29639@psf.upfronthosting.co.za> Steve Dower added the comment: As far as I recall, there's a hosts file that resolves localhost to 127.0.0.1 on Windows, which means a user could break their own configuration if they so desired. Definitely on all supported versions we should be able to assume localhost can be resolved. I haven't checked out how it deals with IPv6, but presumably there's a priority or another hosts file that will cover it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:36:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 17:36:17 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488216977.46.0.113403090664.issue28231@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I consider this a new feature. Some modules got the support of path-like objects for free after implementing the support of path-like objects in os, os.path and io modules. But others need additional work for implementing it, writing tests and documentation. In case of zipfile this work is significant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:37:10 2017 From: report at bugs.python.org (Rafael Capucho) Date: Mon, 27 Feb 2017 17:37:10 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488217030.78.0.211271937814.issue29668@psf.upfronthosting.co.za> Rafael Capucho added the comment: ``` a = "some_underscored_value" u = (f" hello `{a}` cruel world" " hi") print(u) query = (f"SELECT COUNT(*) " "FROM `{a}` entry " "WHERE entry.type == 'device' " "AND entry.instance == {a}") print(query) ``` ---------- Added file: http://bugs.python.org/file46674/file.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:46:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 17:46:08 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488217568.08.0.240396709992.issue29668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What you get? What you expect? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:47:21 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 17:47:21 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488217641.66.0.583524243217.issue28231@psf.upfronthosting.co.za> Berker Peksag added the comment: Note that Ned gave us a permission to get this into 3.6.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:48:50 2017 From: report at bugs.python.org (Rafael Capucho) Date: Mon, 27 Feb 2017 17:48:50 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488217730.15.0.936450157429.issue29668@psf.upfronthosting.co.za> Rafael Capucho added the comment: I got: SELECT COUNT(*) FROM `{a}` entry WHERE entry.type == 'device' AND entry.instance == {a} I expect the value of `{a}` changed, like: SELECT COUNT(*) FROM `some_underscored_value` entry WHERE entry.type == 'device' AND entry.instance == some_underscored_value ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:58:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 17:58:47 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488218327.7.0.885177995706.issue29668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The expression is a concatenation of f-string expression f"SELECT COUNT(*) " and three string literals. If you want to substitute the "a" value, convert string literals into f-string expressions: query = (f"SELECT COUNT(*) " f"FROM `{a}` entry " f"WHERE entry.type == 'device' " f"AND entry.instance == {a}") or query = ("SELECT COUNT(*) " f"FROM `{a}` entry " "WHERE entry.type == 'device' " f"AND entry.instance == {a}") But be aware that using f-string expressions for formatting SQL queries is not safe in general case. Instead, use the DB-API?s parameter substitution. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:15:17 2017 From: report at bugs.python.org (Rafael Capucho) Date: Mon, 27 Feb 2017 18:15:17 +0000 Subject: [issue29668] f-strings don't change the values as expected. In-Reply-To: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> Message-ID: <1488219317.79.0.158877511412.issue29668@psf.upfronthosting.co.za> Rafael Capucho added the comment: Serhiy Storchaka, Thank you for your explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:17:16 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Feb 2017 18:17:16 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488219436.19.0.227862336061.issue26389@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't think supporting both approaches is worth it; we should just choose one of them. As for which one, I'm torn. The single argument one is the most pragmatic, but changing types like has always bugged me. But as Martin points out, the `raise` syntax supports the class or an instance so there's precedent in regards to exceptions themselves. The parameter name is poorly named if we take it in for the first argument which is unfortunate. Basically I can't decide. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:25:59 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 18:25:59 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488219959.62.0.450640496433.issue29655@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:35:02 2017 From: report at bugs.python.org (lou1306) Date: Mon, 27 Feb 2017 18:35:02 +0000 Subject: [issue24700] array compare is hideously slow In-Reply-To: <1437692474.17.0.61027224315.issue24700@psf.upfronthosting.co.za> Message-ID: <1488220502.36.0.00274765839622.issue24700@psf.upfronthosting.co.za> lou1306 added the comment: I noticed the issue is still there in Python 3.6. But I can't see why array subclasses should be the reason for this implementation. By looking at getarrayitem, it looks like __getitem__ does not play any role in how the elements are accessed. Consider the attached example, where SubclassedArray.__getitem__ is overridden to always return 0: nonetheless, equality checks with an array.array containing the same elements always succeed. > For cases where the signedness and element size are identical, it's trivial to acquire readonly buffers for both arrays and directly compare the memory I would argue that _integerness_ sholud also be identical: otherwise array("l", range(10)) == array("f", range(10)) would evaluate to False, while it is True in the current implementation. ---------- nosy: +Luca Di Stefano Added file: http://bugs.python.org/file46675/subclass_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:52:26 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 27 Feb 2017 18:52:26 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1488221546.76.0.273570060156.issue28791@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Is this something we want to include for the upcoming 3.6.1 release? The latest sqlite version is 3.17.0. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:58:07 2017 From: report at bugs.python.org (Marco Buttu) Date: Mon, 27 Feb 2017 18:58:07 +0000 Subject: [issue29669] Missing import of bisect in the documentation examples Message-ID: <1488221887.03.0.391509219567.issue29669@psf.upfronthosting.co.za> New submission from Marco Buttu: There is no import of bisect.bisect() and bisect.bisect_left() in the documentation. IMHO the examples are clearer and more complete if we import these functions, as in the attached patch. ---------- assignee: docs at python components: Documentation files: import_bisect.patch keywords: patch messages: 288663 nosy: docs at python, marco.buttu priority: normal severity: normal status: open title: Missing import of bisect in the documentation examples type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46676/import_bisect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 14:06:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 19:06:55 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488222415.76.0.445624755133.issue28231@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 14:11:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Feb 2017 19:11:26 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488222686.56.0.918623898149.issue29655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that 2.7 has this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 14:16:23 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 27 Feb 2017 19:16:23 +0000 Subject: [issue29659] Expose the `length` arg from shutil.copyfileobj for public use In-Reply-To: <1488157044.73.0.933925559387.issue29659@psf.upfronthosting.co.za> Message-ID: <1488222983.88.0.0578910241311.issue29659@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 14:29:53 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Feb 2017 19:29:53 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488223793.92.0.350052278168.issue29655@psf.upfronthosting.co.za> Berker Peksag added the comment: I ignored 2.7 because you know... it's 2.7 :) And you said [1] that it doesn't have a big effect on real applications. [1] https://github.com/python/cpython/pull/301#issuecomment-282789185 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:21:01 2017 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 27 Feb 2017 20:21:01 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1488226861.63.0.0908338849053.issue17894@psf.upfronthosting.co.za> Ned Batchelder added the comment: I'm still interested in moving this forward. I can make a GitHub pull request if that would help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:33:10 2017 From: report at bugs.python.org (Matthew Hall) Date: Mon, 27 Feb 2017 20:33:10 +0000 Subject: [issue29670] argparse: does not respect required args pre-populated into namespace Message-ID: <1488227590.23.0.0462095560451.issue29670@psf.upfronthosting.co.za> New submission from Matthew Hall: I have some Python code which takes advantage of the ability to prepopulate the argparse Namespace before passing it to argparse. This allows me to read sensitive settings such as usernames and passwords from DBs, environment variables, etc. in addition to the CLI for security so they don't appear as process arguments anyone could see. Some of these scripts have usernames and passwords as required arguments since they cannot function without them. Unfortunately you hit this bug when you load them into the namespace yourself from some secure place of your choice and then pass them in: args = parser.parse_args(argv, namespace) The following argparse code which doesn't respect that they were present already and throws a fatal error. In addition, the parse_known_args function is 246 lines of code which uses ugly nested cheater functions, and the seen_actions variable is in the stack of the function not a member variable, so there is no way you can cleanly override or work around the behavior with a subclass, either by replacing the function (too massive) or by fixing up the seen_actions variable (can't get to it on the stack from outside). So, I suggest that this code should to be fixed so that it will respect any existing values in the Namespace if they are present: # make sure all required actions were present, and convert defaults. for action in self._actions: if action not in seen_actions: if action.required: name = _get_action_name(action) self.error(_('argument %s is required') % name) ---------- components: Library (Lib) messages: 288667 nosy: mhcptg priority: normal severity: normal status: open title: argparse: does not respect required args pre-populated into namespace type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:35:12 2017 From: report at bugs.python.org (Kevin Mills) Date: Mon, 27 Feb 2017 20:35:12 +0000 Subject: [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. Message-ID: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> New submission from Kevin Mills: The intro paragraph for the gc module's documentation says: > Since the collector supplements the reference counting already used in Python, you can disable the collector if you are sure your program does not create reference cycles. How would you ever be sure of that? While you can prevent reference cycles in your own code, what about your dependencies? You'd have to look through the code of all of your dependencies and transitive dependencies (including the standard library) to verify that none introduce reference cycles. And then you'd have to redo that work when upgrading any of them. I propose adding a function to the gc module that returns True if the gc has reclaimed at least one reference cycle in the course of the current program's execution. With that, it would be possible to, a program could, before it exits, force a collection and then check if any reference cycles were found over the program's lifetime, and then the programmer could use that information to decide whether they can safely turn off the gc or not. Obviously that wouldn't guarantee that you could safely turn of the gc (it's possible that garbage with reference cycles is created on other runs of the program) it would at least be some information. ---------- messages: 288668 nosy: Kevin Mills priority: normal severity: normal status: open title: Add function to gc module to check if any reference cycles have been reclaimed. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:44:57 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 27 Feb 2017 20:44:57 +0000 Subject: [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. In-Reply-To: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> Message-ID: <1488228297.76.0.105956979616.issue29671@psf.upfronthosting.co.za> Mark Dickinson added the comment: If I understand correctly, you can already achieve what you want by: 1. Disabling gc (with gc.disable()) at the beginning of your code, and possibly adding a `gc.collect()` immediately afterwards for good measure. 2. Doing a gc.collect() (and taking note of the return value) at the end of your code. 3. To be on the safe side, also check whether there's anything in `gc.garbage`. If no reference cycles were created, `gc.collect()` will return `0`, and `gc.garbage` will be empty. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:47:44 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 27 Feb 2017 20:47:44 +0000 Subject: [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. In-Reply-To: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> Message-ID: <1488228464.79.0.0904986322439.issue29671@psf.upfronthosting.co.za> Mark Dickinson added the comment: An addendum: I'd note that avoiding reference cycles altogether is hard in modern-day Python. For example, any dynamically-created class creates a reference cycle between the class and its MRO: >>> import gc >>> gc.disable() >>> gc.collect() 0 >>> class A(object): ... pass ... >>> del A >>> gc.collect() 6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:49:37 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Feb 2017 20:49:37 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488228577.55.0.845294495889.issue26389@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The print_exception API goes back to when exception values were (or at least, could be) strings. Its doc is incomplete as to the requirements on the args and, at least by 3.5, erroneous. To modify it, we need to understand how it actually works now. In 2.7, 'etype' can apparently by anything with an __str__ method. (Someone could check the 2.7 code.) At least Exception, 'abc', and None result in 'Exception', 'abc' or 'None' leading the last line. Example: >>> try: 1/0 except Exception as e: tb.print_exception(None, e, None) None: integer division or modulo by zero By at least 3.5, the etype arg can definitely be anything, because it is ignored. The printed exception type is already grabbed from the exception. Any patch should not change this. Note that this 3.x change already introduced an incompatibility. In 3.5, the above prints 'ZeroDivisionError' instead of 'None'. This holdover line in the doc "prints the exception etype and value after the stack trace" is wrong and should be corrected with a 'changed in 3.x' note if done after 3.0. In 2.7, value can at least be an exception, a string, or None (not documented). (Ditto for checking the code.) >>> try: 1/0 except Exception as e: tb.print_exception(None, 'zero-divive', tb=None) None: zero-divive >>> try: 1/0 except Exception as e: tb.print_exception(None, None, None) None In 3.?, value must be an exception instance (or compatible duck) (not documented). ... File "C:\Programs\Python36\lib\traceback.py", line 465, in __init__ if (exc_value and exc_value.__cause__ is not None AttributeError: 'str' object has no attribute '__cause__' So, more potential incompatibilities with 2.x. In 2.7, tb is needed to supply the traceback, or to suppress it. As a separate parameter, it allows a traceback to be modified before printing.* The option of a modified or omitted traceback (the ultimate modification) should be kept. *IDLE edits tracebacks before printing to delete artifacts introduced by IDLE internals. The attempt is to print what the console interpreter would. I don't currently know whether it replaces the original on the exception or not. There is also a proposal for the standard interpreter to edit tracebacks after recursion limit exceptions. So traceback editing is useful, and I see no need to force replacement of the semi-private e.__traceback__. My suggestions: tb: In 3.7, in the API, change 'tb' to 'tb=True'. If tb is left True, grab it from the exception. If tb is explicitly supplied, use it. If tb is set to False or (for back compatibility) None, suppress it. value: In 3.5+ document that it must be an exception. (Optional) Change 'value' to 'exc' in the API to reflect the 3.x restriction. Document 'value' as a deprecated synonym for keyword usage. Keep the synonym until after 2.7. etype: In 3.5+ document that it is an ignored dummy argument and that one can just pass 0, '', or None. (Optional) Deprecate the parameter and make it optional. This can be handled* in the code and would be like range having option 'start'. This is messy but would be temporary. Remove after 2.7. * 1 arg = exc/value, 3 args are etype, value, tb, 2 args are exc, tb or etype, exc depending on whether the type(first) is BaseException. I am inclined to go with both options, but even if the 3 of us agree, I might be inclined to post our intention on pydev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 16:00:16 2017 From: report at bugs.python.org (Kevin Mills) Date: Mon, 27 Feb 2017 21:00:16 +0000 Subject: [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. In-Reply-To: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> Message-ID: <1488229216.96.0.927017518424.issue29671@psf.upfronthosting.co.za> Kevin Mills added the comment: gc.disable() at the beginning and then analyzing the results of gc.collect() actually does do what I was wanting, thank you. Reference cycles in and of themselves aren't the problem. It's only a problem if garbage contains reference cycles. In a normal program, a class wouldn't generally ever become garbage, so it wouldn't be a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 16:03:09 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Feb 2017 21:03:09 +0000 Subject: [issue26389] Expand traceback module API to accept just an exception as an argument In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za> Message-ID: <1488229389.99.0.955366943588.issue26389@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Comments probably apply to format_exception and in part, format_exception_only (both also patched in PR237) but I have not checked behavior or code at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 16:57:15 2017 From: report at bugs.python.org (paul j3) Date: Mon, 27 Feb 2017 21:57:15 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488232635.85.0.175521350937.issue29626@psf.upfronthosting.co.za> paul j3 added the comment: With this setup import argparse parser=argparse.ArgumentParser(prog='cli') parser.add_argument('nodes') sp=parser.add_subparsers() p1 = sp.add_parser('list', description='Lists nodes in your current project') p1.add_argument('-p','--projectid', action='store_true') p1.add_argument('-o', '--org', action='store_true', help=' (For administrators only) Lists all the nodes in') parser.parse_args() this help looks normal 1354:~/mypy/argdev$ python3 issue29626.py nodes list -h usage: cli nodes list [-h] [-p] [-o] Lists nodes in your current project optional arguments: -h, --help show this help message and exit -p, --projectid -o, --org (For administrators only) Lists all the nodes in Without further feedback this issue should be closed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 16:57:25 2017 From: report at bugs.python.org (paul j3) Date: Mon, 27 Feb 2017 21:57:25 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488232645.96.0.218960222814.issue29626@psf.upfronthosting.co.za> Changes by paul j3 : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:01:49 2017 From: report at bugs.python.org (Big Stone) Date: Mon, 27 Feb 2017 22:01:49 +0000 Subject: [issue28791] update sqlite to 3.17.0 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1488232909.0.0.355455351754.issue28791@psf.upfronthosting.co.za> Big Stone added the comment: python-3.7 should include the latest stable sqlite, at the time of last alpha. ---------- title: update sqlite to 3.15.2 -> update sqlite to 3.17.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:07:31 2017 From: report at bugs.python.org (Falguniben Jhaveri) Date: Mon, 27 Feb 2017 22:07:31 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488233251.74.0.226744673512.issue29626@psf.upfronthosting.co.za> Falguniben Jhaveri added the comment: Sample code to repro this: import argparse parser = argparse.ArgumentParser(prog='cli') subparsers = parser.add_subparsers(dest="command") subparsers_user_delete = subparsers.add_parser("delete", help="Deletes a user in your organization.", description="Deletes a user in your organization.") subparsers_user_delete.add_argument("userid", help="The userid of user.", default=None, type=int) subparsers_user_delete.add_argument("-p", "--projectid", metavar="", help="Specify the project ID of project from where you want to delete" " the user or else user will be deleted from organization.", type=int, default=None) parser_nodes = subparsers.add_parser('nodes') sp = parser_nodes.add_subparsers() p1 = sp.add_parser('list', description='Lists nodes in your current project') p1.add_argument('-p', '--projectid', action='store_true') p1.add_argument('-o', '--org', action='store_true', help=' (For administrators only) Lists all the nodes in') parser.parse_args() Please run following command: $issue.py delete -h ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:29:56 2017 From: report at bugs.python.org (Gerrit Holl) Date: Mon, 27 Feb 2017 22:29:56 +0000 Subject: [issue29672] `catch_warnings` context manager causes warnings to be reprinted Message-ID: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> New submission from Gerrit Holl: Entering the `catch_warnings` context manager is causing warnings to be printed over and over again, rather than just once as it should. Without such a context manager, the behaviour is as expected: $ cat ./mwe.py #!/usr/bin/env python3.5 import warnings for i in range(3): try: print(i, __warningregistry__) except NameError: print(i, "first warning") warnings.warn("I don't like this.", UserWarning) print(i, __warningregistry__) # with warnings.catch_warnings(): # pass print(i, __warningregistry__) warnings.warn("I don't like this.", UserWarning) $ ./mwe.py 0 first warning ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 0 {'version': 0, ("I don't like this.", , 10): True} 0 {'version': 0, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} Uncommenting the context manager causes the warning to be printed every time: $ ./mwe.py 0 first warning ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 0 {'version': 0, ("I don't like this.", , 10): True} 0 {'version': 0, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 2, ("I don't like this.", , 15): True} ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 2, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 2, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 2 {'version': 4, ("I don't like this.", , 15): True} ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 2 {'version': 4, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 4, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) I think this is undesirable. There is code deep inside a module that I'm using that is using the context manager, and as a consequence, I get warnings printed every time that should be printed only once. See also on Stack Overflow: http://stackoverflow.com/q/42496579/974555 ---------- messages: 288677 nosy: Gerrit.Holl priority: normal severity: normal status: open title: `catch_warnings` context manager causes warnings to be reprinted versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:36:12 2017 From: report at bugs.python.org (Gerrit Holl) Date: Mon, 27 Feb 2017 22:36:12 +0000 Subject: [issue29672] `catch_warnings` context manager causes warnings to be reprinted In-Reply-To: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> Message-ID: <1488234972.67.0.146084136447.issue29672@psf.upfronthosting.co.za> Gerrit Holl added the comment: I suppose this is a consequence of the change in: http://bugs.python.org/issue4180 and although I can see why the warnings filter would be reset when entering the context manager, I don't think it is desirable to have side effects for modules that are entirely unrelated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:39:21 2017 From: report at bugs.python.org (paul j3) Date: Mon, 27 Feb 2017 22:39:21 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488235161.88.0.246740229246.issue29626@psf.upfronthosting.co.za> paul j3 added the comment: This help looks normal: 1427:~/mypy/argdev$ python3 issue29626.py delete -h usage: cli delete [-h] [-p] userid Deletes a user in your organization. positional arguments: userid The userid of user. optional arguments: -h, --help show this help message and exit -p , --projectid Specify the project ID of project from where you want to delete the user or else user will be deleted from organization. So does this help for the nested subparser: 1430:~/mypy/argdev$ python3 issue29626.py nodes list -h usage: cli nodes list [-h] [-p] [-o] Lists nodes in your current project optional arguments: -h, --help show this help message and exit -p, --projectid -o, --org (For administrators only) Lists all the nodes in This double layered subparsers is not common, and might not even be included in the unittest file. But provided you don't try anything too tricky it does work. I've seen a few questions along this line on StackOverflow. Note that the help line for '-p' in the second case is empty because you did not specify any help string (as you did for 'delete'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:42:24 2017 From: report at bugs.python.org (Gerrit Holl) Date: Mon, 27 Feb 2017 22:42:24 +0000 Subject: [issue29672] `catch_warnings` context manager causes warnings to be reprinted In-Reply-To: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> Message-ID: <1488235344.07.0.804313186203.issue29672@psf.upfronthosting.co.za> Gerrit Holl added the comment: To clarify, this behaviour crosses module boundaries. So even if some piece of code many layers deep buried in a module uses this context manager, it has global consequences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:44:31 2017 From: report at bugs.python.org (Falguniben Jhaveri) Date: Mon, 27 Feb 2017 22:44:31 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1488235161.88.0.246740229246.issue29626@psf.upfronthosting.co.za> Message-ID: Falguniben Jhaveri added the comment: There is an extra spacing here if you look carefully. I have commented above the code. Similarly it happens for "-o" too but not for other alphabets. 1427:~/mypy/argdev$ python3 issue29626.py delete -h usage: cli delete [-h] [-p] userid Deletes a user in your organization. positional arguments: userid The userid of user. optional arguments: -h, --help show this help message and exit // extra space after p and ",". -p , --projectid Specify the project ID of project from where you want to delete the user or else user will be deleted from organization. I saw this issue as I use argparse for my CLI usecase which has nested commands. On Mon, Feb 27, 2017 at 2:39 PM, paul j3 wrote: > > paul j3 added the comment: > > This help looks normal: > > 1427:~/mypy/argdev$ python3 issue29626.py delete -h > usage: cli delete [-h] [-p] userid > > Deletes a user in your organization. > > positional arguments: > userid The userid of user. > > optional arguments: > -h, --help show this help message and exit > -p , --projectid Specify the project ID of project from where you want > to > delete the user or else user will be deleted from > organization. > > So does this help for the nested subparser: > > 1430:~/mypy/argdev$ python3 issue29626.py nodes list -h > usage: cli nodes list [-h] [-p] [-o] > > Lists nodes in your current project > > optional arguments: > -h, --help show this help message and exit > -p, --projectid > -o, --org (For administrators only) Lists all the nodes in > > This double layered subparsers is not common, and might not even be > included in the unittest file. But provided you don't try anything too > tricky it does work. I've seen a few questions along this line on > StackOverflow. > > Note that the help line for '-p' in the second case is empty because you > did not specify any help string (as you did for 'delete'). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 18:46:13 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Feb 2017 23:46:13 +0000 Subject: [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 In-Reply-To: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> Message-ID: <1488239173.59.0.355546358698.issue29639@psf.upfronthosting.co.za> Gregory P. Smith added the comment: great! that makes me feel much less bad about fixing this in the way i desire. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 18:48:31 2017 From: report at bugs.python.org (paul j3) Date: Mon, 27 Feb 2017 23:48:31 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488239311.17.0.201013695315.issue29626@psf.upfronthosting.co.za> paul j3 added the comment: Sorry, I missed that. For some reason I looking something bigger. That's coming from the `metavar=""'. If I specify `metavar="xxx" that help line will have -p xxx, --projectid xxx Replace the 'xxx` with '', and you still have space between '-p' and ','. Now that I see it, it looks familiar. I noted it in passing in StackOverflow answer, http://stackoverflow.com/a/40497623/901925 I can't find a related bug/issue. It's a natural consequence of the formatting in HelpFormatter._format_action_invocation # if the Optional takes a value, format is: # -s ARGS, --long ARGS parts.append('%s %s' % (option_string, args_string)) There's no special handling for the case where ARGS is blank. That formatter method could be customized as suggested in http://stackoverflow.com/a/23941599/901925 Often people want a more compact invocation like: -s, --long ARG help Usage gets that space between option_string and args_string, but it gets striped out later. So the fix (not tested) would something like: def _format_action_invocation(self, action): .... for option_string in action.option_strings: if len(args_string)>0: parts.append('%s %s' % (option_string, args_string)) else: parts.append('%s' % option_string) .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 18:48:43 2017 From: report at bugs.python.org (paul j3) Date: Mon, 27 Feb 2017 23:48:43 +0000 Subject: [issue29626] Issue with spacing in argparse module while using help In-Reply-To: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> Message-ID: <1488239323.67.0.86369557218.issue29626@psf.upfronthosting.co.za> Changes by paul j3 : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 19:02:47 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 28 Feb 2017 00:02:47 +0000 Subject: [issue29673] Some gdb macros are broken in 3.6 Message-ID: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Some gdb macros defined in Misc/gdbinit got broken when _PyUnicode_AsString was renamed to PyUnicode_AsUTF8. (gdb) pystack No symbol "_PyUnicode_AsString" in current context. ---------- messages: 288684 nosy: belopolsky priority: normal severity: normal status: open title: Some gdb macros are broken in 3.6 versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 19:19:10 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 28 Feb 2017 00:19:10 +0000 Subject: [issue29673] Some gdb macros are broken in 3.6 In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za> Message-ID: <1488241150.02.0.705103761012.issue29673@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I tried to simply replace _PyUnicode_AsString with PyUnicode_AsUTF8, but it looks like code structure has changed and the pyframe and pystack macros don't work anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 19:46:23 2017 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 28 Feb 2017 00:46:23 +0000 Subject: [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted In-Reply-To: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> Message-ID: <1488242783.3.0.353565439002.issue29573@psf.upfronthosting.co.za> Jakub Wilk added the comment: Deleting non-existent files in /tmp is an indicator of a security hole. This kind of error must never pass silently. ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 21:00:00 2017 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 Feb 2017 02:00:00 +0000 Subject: [issue29673] Some gdb macros are broken in 3.6 In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za> Message-ID: <1488247200.59.0.942423515208.issue29673@psf.upfronthosting.co.za> Skip Montanaro added the comment: Note that these macros were always expected to be fragile. They depend to a great extent on the layout of the functions in Python/ceval.c. I've had to tweak them a couple times over the years. I'm pretty sure the gdb instance I have available to me at work wasn't configured --with-python, and corporate policies would prevent me from downloading the source and building my own private version. For me, Misc/gdbinit is likely to be the best I can do for the foreseeable future. If the layout of ceval.c has changed sufficiently between Python 2.x and 3.x, perhaps two versions of gdbinit are warranted, with the version delivered for Python 3 being appropriate for the current release. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 22:11:38 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 03:11:38 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488251498.98.0.708825628826.issue29661@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +302 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 22:30:15 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 03:30:15 +0000 Subject: [issue29661] Typo in the docstring of timeit.Timer.autorange In-Reply-To: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> Message-ID: <1488252615.24.0.153174877454.issue29661@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Raymond! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 23:15:18 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Feb 2017 04:15:18 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488255318.51.0.596351157481.issue28231@psf.upfronthosting.co.za> Ned Deily added the comment: > Note that Ned gave us a permission to get this into 3.6.1. I may have although I don't remember specifically discussing zipfile. In any case, I'm willing to consider it. I think you can make good arguments for and against. Yes, it could smell like adding a feature but, on the other add, one of the implicit goals of 3.6.0 was to make Path objects supported across the standard library as much as possible, so the lack of support in zipfile (and a few other similar modules) could be viewed as bug. Also, as far as I can tell, this should be a totally upwards-compatible change except in the presumably unlikely case something is counting on getting an exception when passing a Path object to zipfile. I say we invoke "practicality beats purity" for this as long as Serhiy is OK with having it cherry-picked to 3.6 and as long as no other core developer here has a strong objection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 23:20:45 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Feb 2017 04:20:45 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1488255645.48.0.438208635588.issue17894@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I will work on it thank you. ---------- versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 23:23:23 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Feb 2017 04:23:23 +0000 Subject: [issue29669] Missing import of bisect in the documentation examples In-Reply-To: <1488221887.03.0.391509219567.issue29669@psf.upfronthosting.co.za> Message-ID: <1488255803.62.0.590783928811.issue29669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, but I think this is a waste. A number of the example sections presume that the module under discussion has been imported. Also, these docs have been around for a long time without the slightest indication of confusion. ---------- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 23:46:46 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Feb 2017 04:46:46 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1488257206.21.0.0869476036878.issue7769@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 for the decorator idea. It feels very natural. A little off topic, I do not like the with-statement example that we currently have in the docs. I think it is bad design to put some much code inside with-block. In the micro-webframeworks, we register functions separately from launching the server. The same practice should apply here as well. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 01:02:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 06:02:31 +0000 Subject: [issue28231] zipfile does not support pathlib In-Reply-To: <1474445503.11.0.219964117103.issue28231@psf.upfronthosting.co.za> Message-ID: <1488261751.52.0.3316054314.issue28231@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is backported to 3.6.1. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file46677/zipfile-pathlib-3.6.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 01:13:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 06:13:33 +0000 Subject: [issue29655] Certain errors during IMPORT_STAR can leak a reference In-Reply-To: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> Message-ID: <1488262413.86.0.743126838841.issue29655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But it is *very easy* to fix this bug in 2.7. ---------- keywords: +patch resolution: fixed -> stage: resolved -> patch review status: closed -> open versions: +Python 2.7 -Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46678/issue29655-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 01:19:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 06:19:03 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488262743.56.0.645369900342.issue28598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is 2.7 free from this bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 01:46:01 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 06:46:01 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1488264361.26.0.448814884021.issue7769@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Raymond. I would like to keep the example style another issue, not this one. :-) And I hope someone is willing to review the PR. ---------- assignee: -> xiang.zhang stage: needs patch -> patch review versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 02:45:00 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 07:45:00 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488267900.8.0.317576633055.issue29642@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm afraid this change makes testloader searches unrelated directory contains massive files (like node_modules). I don't think loading all tests from whole namespace package is not usual use case. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 02:51:39 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 07:51:39 +0000 Subject: [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? In-Reply-To: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> Message-ID: <1488268299.65.0.0644632369783.issue29642@psf.upfronthosting.co.za> INADA Naoki added the comment: When using import, (namespace) package name is explicitly specified. Only specified name is searched. In test loader's case, there are no such limit. Loader may search millions of completely unrelated directories. It may include directories in NFS or samba over slow network. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 03:54:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Feb 2017 08:54:10 +0000 Subject: [issue29674] Use GCC __attribute__((alloc_size(x, y))) on PyMem_Malloc() functions Message-ID: <1488272050.61.0.409487721584.issue29674@psf.upfronthosting.co.za> New submission from STINNER Victor: GCC allows to get "size" parameters of functions allocating memory to emit better warning. For example, GCC 7 will detect implicit cast from signed to unsigned integer and emit a warning. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html Example of Python functions that can benefit of this attribute: * PyMem_RawMalloc(), PyMem_RawCalloc(), PyMem_RawRealloc() * PyMem_Malloc(), PyMem_Calloc(), PyMem_Realloc() * PyObject_Malloc(), PyObject_Calloc(), PyObject_Realloc() ---------- messages: 288699 nosy: haypo priority: normal severity: normal status: open title: Use GCC __attribute__((alloc_size(x,y))) on PyMem_Malloc() functions versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 03:56:20 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Feb 2017 08:56:20 +0000 Subject: [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. In-Reply-To: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> Message-ID: <1488272180.66.0.150713129111.issue29671@psf.upfronthosting.co.za> Mark Dickinson added the comment: > In a normal program, a class wouldn't generally ever become garbage, Right; it's only really a problem with dynamically-created classes. Some parts of the standard library (like ctypes), generate such classes. Okay to close this as rejected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 03:58:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Feb 2017 08:58:55 +0000 Subject: [issue29673] Some gdb macros are broken in 3.6 In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za> Message-ID: <1488272335.1.0.238223840371.issue29673@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 04:15:31 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 09:15:31 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1488273331.51.0.440201520721.issue7769@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks everyone involved! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:42:29 2017 From: report at bugs.python.org (Q) Date: Tue, 28 Feb 2017 10:42:29 +0000 Subject: [issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly Message-ID: <1488278549.76.0.307223036696.issue29675@psf.upfronthosting.co.za> New submission from Q: On Ubuntu LTS 16.04, SysLogHandler with a custom formatter does not seem to expand loglevel/levelno fields properly, when there are square brackets ( see the attached examples ). Instead, it seems to replace '[%(loglevel)s]' with a '[pid]', and '%(loglevel)s' with 'LOGLEVEL[pid]' . To test, run 'journalctl -f | grep test_test_test' on one console, and the attached files on another. The output for 'bad.py' looks as follows: === Feb 28 21:30:05 hostname [7117]: logging was configured for process <7117> === And should have looked like: === Feb 28 21:30:05 hostname [INFO]: logging was configured for process <7117> === For 'good.py', the output is as follows: === Feb 28 21:30:04 hostname INFO[7114]: logging was configured for process <7114> === and should have probably been: === Feb 28 21:30:04 hostname INFO: logging was configured for process <7114> === Kind regards, /t13 ---------- files: bad.py messages: 288702 nosy: thread13 priority: normal severity: normal status: open title: SysLogHandler does not seem to always expand %(loglevel)s properly versions: Python 2.7 Added file: http://bugs.python.org/file46679/bad.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:44:20 2017 From: report at bugs.python.org (Q) Date: Tue, 28 Feb 2017 10:44:20 +0000 Subject: [issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly In-Reply-To: <1488278549.76.0.307223036696.issue29675@psf.upfronthosting.co.za> Message-ID: <1488278660.74.0.393553254239.issue29675@psf.upfronthosting.co.za> Q added the comment: Attaching the other file mentioned. ---------- Added file: http://bugs.python.org/file46680/good.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:48:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 10:48:01 +0000 Subject: [issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly In-Reply-To: <1488278549.76.0.307223036696.issue29675@psf.upfronthosting.co.za> Message-ID: <1488278881.12.0.965964932338.issue29675@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:50:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 10:50:25 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488279025.73.0.901616312102.issue29110@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- pull_requests: +303 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:51:30 2017 From: report at bugs.python.org (Q) Date: Tue, 28 Feb 2017 10:51:30 +0000 Subject: [issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly In-Reply-To: <1488278549.76.0.307223036696.issue29675@psf.upfronthosting.co.za> Message-ID: <1488279090.17.0.356915100636.issue29675@psf.upfronthosting.co.za> Q added the comment: PS. I'm not sure if that is a systemd/journald issue, or indeed a Python bug. However, it would be nice to clear one possibility. For a StreamHandler, it all works as it should. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 06:14:34 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 11:14:34 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488280474.35.0.517258427759.issue29110@psf.upfronthosting.co.za> INADA Naoki added the comment: OK, since Aifc_write is harder to test, and the exception is very unlikely happens, I fixed only Aifc_read. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 06:18:51 2017 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Tue, 28 Feb 2017 11:18:51 +0000 Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1488280731.03.0.0745798699577.issue16113@psf.upfronthosting.co.za> Micha? G?rny added the comment: Christian, since the code is now integrated in Python 3.6+ (with some bugfixes AFAICS), could you consider updating your bitbucket package to match it? It would be helpful as a backport package for older Python versions. ---------- nosy: +mgorny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 06:34:24 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 11:34:24 +0000 Subject: [issue29676] verbose output of test_cprofile Message-ID: <1488281664.18.0.494134456081.issue29676@psf.upfronthosting.co.za> New submission from Xiang Zhang: Recently when I run the test suite test_cprofile always produces some verbose info but won't fail. This is not the case before. I am not sure this is a bug or not. git bisect tells me https://github.com/python/cpython/commit/5566bbb8d563646d83e8172410fa0c085e8233b1 is responsible. I also see the verbose info on some buildbots. [cpython]$ ./python -m test test_cprofile Run tests sequentially 0:00:00 [1/1] test_cprofile Stats.print_callers output for Profile doesn't fit expectation! --- +++ @@ -1,15 +1,16 @@ -profilee.py:110(__getattr__) <- 16 0.016 0.016 profilee.py:98(subhelper) -profilee.py:25(testfunc) <- 1 0.270 1.000 :1() -profilee.py:35(factorial) <- 1 0.014 0.130 profilee.py:25(testfunc) - 20/3 0.130 0.147 profilee.py:35(factorial) - 2 0.006 0.040 profilee.py:84(helper2_indirect) -profilee.py:48(mul) <- 20 0.020 0.020 profilee.py:35(factorial) -profilee.py:55(helper) <- 2 0.040 0.600 profilee.py:25(testfunc) -profilee.py:73(helper1) <- 4 0.116 0.120 profilee.py:55(helper) -profilee.py:84(helper2_indirect) <- 2 0.000 0.140 profilee.py:55(helper) -profilee.py:88(helper2) <- 6 0.234 0.300 profilee.py:55(helper) - 2 0.078 0.100 profilee.py:84(helper2_indirect) -profilee.py:98(subhelper) <- 8 0.064 0.080 profilee.py:88(helper2) -{built-in method builtins.hasattr} <- 4 0.000 0.004 profilee.py:73(helper1) - 8 0.000 0.008 profilee.py:88(helper2) -{built-in method sys.exc_info} <- 4 0.000 0.000 profilee.py:73(helper1) +profilee.py:110(__getattr__) <- 16 0.016 0.016 profilee.py:98(subhelper) +profilee.py:25(testfunc) <- 1 0.270 1.000 :1() +profilee.py:35(factorial) <- 1 0.014 0.130 profilee.py:25(testfunc) + 20/3 0.130 0.147 profilee.py:35(factorial) + 2 0.006 0.040 profilee.py:84(helper2_indirect) +profilee.py:48(mul) <- 20 0.020 0.020 profilee.py:35(factorial) +profilee.py:55(helper) <- 2 0.040 0.600 profilee.py:25(testfunc) +profilee.py:73(helper1) <- 4 0.116 0.120 profilee.py:55(helper) +profilee.py:84(helper2_indirect) <- 2 0.000 0.140 profilee.py:55(helper) +profilee.py:88(helper2) <- 6 0.234 0.300 profilee.py:55(helper) + 2 0.078 0.100 profilee.py:84(helper2_indirect) +profilee.py:98(subhelper) <- 8 0.064 0.080 profilee.py:88(helper2) +{built-in method builtins.hasattr} <- 4 0.000 0.004 profilee.py:73(helper1) + 8 0.000 0.008 profilee.py:88(helper2) +{built-in method sys.exc_info} <- 4 0.000 0.000 profilee.py:73(helper1) +{method 'append' of 'list' objects} <- 4 0.000 0.000 profilee.py:73(helper1) Stats.print_callees output for Profile doesn't fit expectation! --- +++ @@ -1,16 +1,16 @@ -:1() -> 1 0.270 1.000 profilee.py:25(testfunc) -profilee.py:110(__getattr__) -> -profilee.py:25(testfunc) -> 1 0.014 0.130 profilee.py:35(factorial) - 2 0.040 0.600 profilee.py:55(helper) -profilee.py:35(factorial) -> 20/3 0.130 0.147 profilee.py:35(factorial) - 20 0.020 0.020 profilee.py:48(mul) -profilee.py:48(mul) -> -profilee.py:55(helper) -> 4 0.116 0.120 profilee.py:73(helper1) - 2 0.000 0.140 profilee.py:84(helper2_indirect) - 6 0.234 0.300 profilee.py:88(helper2) -profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} -profilee.py:84(helper2_indirect) -> 2 0.006 0.040 profilee.py:35(factorial) - 2 0.078 0.100 profilee.py:88(helper2) -profilee.py:88(helper2) -> 8 0.064 0.080 profilee.py:98(subhelper) -profilee.py:98(subhelper) -> 16 0.016 0.016 profilee.py:110(__getattr__) -{built-in method builtins.hasattr} -> 12 0.012 0.012 profilee.py:110(__getattr__) +:1() -> 1 0.270 1.000 profilee.py:25(testfunc) +profilee.py:110(__getattr__) -> +profilee.py:25(testfunc) -> 1 0.014 0.130 profilee.py:35(factorial) + 2 0.040 0.600 profilee.py:55(helper) +profilee.py:35(factorial) -> 20/3 0.130 0.147 profilee.py:35(factorial) + 20 0.020 0.020 profilee.py:48(mul) +profilee.py:48(mul) -> +profilee.py:55(helper) -> 4 0.116 0.120 profilee.py:73(helper1) + 2 0.000 0.140 profilee.py:84(helper2_indirect) + 6 0.234 0.300 profilee.py:88(helper2) +profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} +profilee.py:84(helper2_indirect) -> 2 0.006 0.040 profilee.py:35(factorial) + 2 0.078 0.100 profilee.py:88(helper2) +profilee.py:88(helper2) -> 8 0.064 0.080 profilee.py:98(subhelper) +profilee.py:98(subhelper) -> 16 0.016 0.016 profilee.py:110(__getattr__) +{built-in method builtins.hasattr} -> 12 0.012 0.012 profilee.py:110(__getattr__) 1 test OK. Total duration: 73 ms Tests result: SUCCESS ---------- components: Tests messages: 288707 nosy: inada.naoki, xiang.zhang priority: normal severity: normal status: open title: verbose output of test_cprofile type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:03:23 2017 From: report at bugs.python.org (willvousden) Date: Tue, 28 Feb 2017 12:03:23 +0000 Subject: [issue27144] concurrent.futures.as_completed() memory inefficiency In-Reply-To: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za> Message-ID: <1488283403.09.0.0628856566209.issue27144@psf.upfronthosting.co.za> Changes by willvousden : ---------- nosy: +willvousden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:03:44 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 12:03:44 +0000 Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> Message-ID: <1488283424.09.0.642613941236.issue29110@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:15:52 2017 From: report at bugs.python.org (Will Vousden) Date: Tue, 28 Feb 2017 12:15:52 +0000 Subject: [issue27144] concurrent.futures.as_completed() memory inefficiency In-Reply-To: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za> Message-ID: <1488284152.36.0.240561418712.issue27144@psf.upfronthosting.co.za> Will Vousden added the comment: Is there a reason this hasn't been merged yet? Fixing this bug locally (albeit just by setting Future._result = None when I've extracted the result) reduced the memory footprint of my program from 50 GB to 7 GB, so it seems worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:21:31 2017 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 28 Feb 2017 12:21:31 +0000 Subject: [issue29672] `catch_warnings` context manager should reset warning registry to previous state upon exiting, to prevent warnings from being reprinted In-Reply-To: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> Message-ID: <1488284491.77.0.344515655295.issue29672@psf.upfronthosting.co.za> Changes by Gerrit Holl : ---------- title: `catch_warnings` context manager causes warnings to be reprinted -> `catch_warnings` context manager should reset warning registry to previous state upon exiting, to prevent warnings from being reprinted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:29:09 2017 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 28 Feb 2017 12:29:09 +0000 Subject: [issue29672] `catch_warnings` context manager should reset warning registry to previous state upon exiting, to prevent warnings from being reprinted In-Reply-To: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> Message-ID: <1488284949.61.0.180571139106.issue29672@psf.upfronthosting.co.za> Gerrit Holl added the comment: To resolve this, the `catch_warnings` context manager upon exiting should not only reset `filters`, but also `_filters_version`, and perhaps an associated dictionary? Not sure if I'm understanding the code in `warnings.c` correctly, and whether, for this change, it would suffice to change `warnings.py` or whether `warnings.c` would need to be updated as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:30:24 2017 From: report at bugs.python.org (ChrisRands) Date: Tue, 28 Feb 2017 12:30:24 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits Message-ID: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> New submission from ChrisRands: With a negative integer for ndigits the output from 'round()', for example 'round(3, -2)', is always zero ('0' for 'int.__round__' and '0.0' or '-0.0' for 'float.__round__'). I think either it should raise an exception or the docs should be updated to reflect the current behavior. The docs are currently silent on this: https://docs.python.org/3/library/functions.html#round I don't know C, but there appears to be a note in the source about this implying it is the desired behavior but without an explanation: "For ndigits < NDIGITS_MIN, x always rounds to +-0.0.": https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Objects/floatobject.c Anyway, I can't imagine an actual use case for negative ndigits. ---------- messages: 288710 nosy: ChrisRands priority: normal severity: normal status: open title: 'round()' accepts a negative integer for ndigits _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:34:51 2017 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 28 Feb 2017 12:34:51 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits In-Reply-To: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> Message-ID: <1488285291.46.0.670155909994.issue29677@psf.upfronthosting.co.za> Gerrit Holl added the comment: >>> round(21345, -2) 21300 Desired and useful to me. ---------- nosy: +Gerrit.Holl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:35:36 2017 From: report at bugs.python.org (Sebastien Bourdeauducq) Date: Tue, 28 Feb 2017 12:35:36 +0000 Subject: [issue27500] ProactorEventLoop cannot open connection to ::1 In-Reply-To: <1468346135.06.0.410333112523.issue27500@psf.upfronthosting.co.za> Message-ID: <1488285336.06.0.798151594281.issue27500@psf.upfronthosting.co.za> Sebastien Bourdeauducq added the comment: This is still a problem with Python 3.5.3 and 3.6.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:38:42 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Feb 2017 12:38:42 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits In-Reply-To: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> Message-ID: <1488285522.65.0.286425315513.issue29677@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yep, it's (genuinely) a feature, not a bug, and being able to round to the nearest ten, hundred, thousand, etc. is useful. The docs could perhaps be improved to make it clearer that this is supported. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:45:52 2017 From: report at bugs.python.org (ChrisRands) Date: Tue, 28 Feb 2017 12:45:52 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits In-Reply-To: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> Message-ID: <1488285952.16.0.636380130693.issue29677@psf.upfronthosting.co.za> ChrisRands added the comment: Ah yes, you're both completely right of course. Perhaps the docs could still be clarified though. I managed to completely overlook this, and perhaps other non-expert Python users would too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:50:19 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Feb 2017 12:50:19 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits In-Reply-To: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> Message-ID: <1488286219.45.0.570699534041.issue29677@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yes, I think the initial description could be clarified. It currently reads: > Return the floating point value number rounded to ndigits digits after the decimal point. ... which doesn't make it clear what happens for negative ndigits. There's a line in the second paragraph: > values are rounded to the closest multiple of 10 to the power minus ndigits which technically *does* cover the case of negative ndigits correctly, but I think it would be good to have a clarification in the first paragraph of the description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:53:06 2017 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 28 Feb 2017 12:53:06 +0000 Subject: [issue29677] 'round()' accepts a negative integer for ndigits In-Reply-To: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> Message-ID: <1488286386.17.0.326488778178.issue29677@psf.upfronthosting.co.za> Changes by Gerrit Holl : ---------- pull_requests: +304 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 08:48:31 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Feb 2017 13:48:31 +0000 Subject: [issue29676] verbose output of test_cprofile In-Reply-To: <1488281664.18.0.494134456081.issue29676@psf.upfronthosting.co.za> Message-ID: <1488289711.43.0.372627750942.issue29676@psf.upfronthosting.co.za> INADA Naoki added the comment: thanks. for summary, notable changes are: (print_callers) +{method 'append' of 'list' objects} <- 4 0.000 0.000 profilee.py:73(helper1) Stats.print_callees output for Profile doesn't fit expectation! and (print_callees) -profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} - 4 0.000 0.000 {built-in method sys.exc_info} +profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 09:30:44 2017 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 28 Feb 2017 14:30:44 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488292244.28.0.832026715507.issue28598@psf.upfronthosting.co.za> Martijn Pieters added the comment: > Is 2.7 free from this bug? No, 2.7 is affected too: >>> class SubclassedStr(str): ... def __rmod__(self, other): ... return 'Success, self.__rmod__({!r}) was called'.format(other) ... >>> 'lhs %% %r' % SubclassedStr('rhs') "lhs % 'rhs'" Expected output is "Success, self.__rmod__('lhs %% %r') was called" On the plus side, unicode is not affected: >>> class SubclassedUnicode(unicode): ... def __rmod__(self, other): ... return u'Success, self.__rmod__({!r}) was called'.format(other) ... >>> u'lhs %% %r' % SubclassedUnicode(u'rhs') u"Success, self.__rmod__(u'lhs %% %r') was called" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 09:42:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 14:42:25 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488292945.88.0.992073794123.issue28598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 2.7 -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 11:18:17 2017 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 28 Feb 2017 16:18:17 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1488298697.58.0.865997701712.issue29414@psf.upfronthosting.co.za> Wolfgang Maier added the comment: I studied the github PR and thought about it carefully, and that made me come to believe that the chapter deserves a larger rewrite not just of one section, but of several. I'm attaching my proposed change as a "classical" patch here for discussion. I hope that's still a valid way to do this as I did not want to mess with the original PR by Marco and, instead, wanted to see my proposal discussed first. Some of the changes I made: - I don't think range() really deserves its own section in a chapter about control flow, so I removed most of it and linked to the relevant stdtypes section instead - moved the definition of an iterable up into the for loop section - restructured the for loop section to discuss Python for loops first and only compare them to Pascal/C afterwards - moved the example for modifying a list while iterating over it to the datastructures chapter I find this new version much clearer, but lets see what people here think. ---------- nosy: +wolma Added file: http://bugs.python.org/file46681/controlflow_datastructures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 13:23:16 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 28 Feb 2017 18:23:16 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git In-Reply-To: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> Message-ID: <1488306196.31.0.677079307003.issue27593@psf.upfronthosting.co.za> Steve Dower added the comment: Just updated my PR to remove the GITTAG variable, so we'll just go with GITBRANCH and GITVERSION. (Any value in trying to extract the URL of the remote? That's probably going to be a bit flimsy, but might help more clearly identify forks.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 13:32:28 2017 From: report at bugs.python.org (Sergey) Date: Tue, 28 Feb 2017 18:32:28 +0000 Subject: [issue29678] email.Message.get_params decodes only first one header value Message-ID: <1488306748.36.0.996484861833.issue29678@psf.upfronthosting.co.za> New submission from Sergey: email.Message class has method get_params() that can decode(unquote) header values in compliance with RFC2231 and RFC2047. But if in email message exists multiple headers with the same key it can't be used to decode other headers than first. In my application I could use: headers = message.items() for key, value in headers: cleanValue = message.get_params(value=value) print(key, cleanValue) Also have posted question on stackoverflow: http://stackoverflow.com/questions/42502312/python-3-email-package-how-decode-given-header-value ---------- components: email messages: 288720 nosy: barry, pi314159, r.david.murray priority: normal severity: normal status: open title: email.Message.get_params decodes only first one header value type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 13:43:31 2017 From: report at bugs.python.org (Kartik) Date: Tue, 28 Feb 2017 18:43:31 +0000 Subject: [issue29666] Issue in enum documentation In-Reply-To: <1488203311.1.0.764284916797.issue29666@psf.upfronthosting.co.za> Message-ID: <1488307411.25.0.289337254672.issue29666@psf.upfronthosting.co.za> Kartik added the comment: Hi I've edited the documentation to correct this and submitted a PR. ---------- nosy: +exqu17 pull_requests: +305 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 14:52:18 2017 From: report at bugs.python.org (Douglas Greiman) Date: Tue, 28 Feb 2017 19:52:18 +0000 Subject: [issue28425] Python3 ignores __init__.py that are links to /dev/null In-Reply-To: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za> Message-ID: <1488311538.19.0.113999379621.issue28425@psf.upfronthosting.co.za> Douglas Greiman added the comment: Bazel has been updated to no longer create symlinks to /dev/null https://github.com/bazelbuild/bazel/issues/1458 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 14:57:30 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Tue, 28 Feb 2017 19:57:30 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1488311850.87.0.807461558797.issue27645@psf.upfronthosting.co.za> Aviv Palivoda added the comment: I actually looked at the patch and have a few comments: 1. You need to put Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS before the sqlite3 calls (especially the sleep). 2. I think that the `pysqlite_connection_backup` function will look a lot better if you will have a cleanup/error label. I am not a core developer but I think you should open the PR as it will be easier for the CR. ---------- nosy: +palaviv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 15:26:38 2017 From: report at bugs.python.org (Sergey) Date: Tue, 28 Feb 2017 20:26:38 +0000 Subject: [issue29678] email.Message.get_params decodes only first one header value In-Reply-To: <1488306748.36.0.996484861833.issue29678@psf.upfronthosting.co.za> Message-ID: <1488313598.56.0.25620977404.issue29678@psf.upfronthosting.co.za> Changes by Sergey : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 15:29:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Feb 2017 20:29:33 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1488313773.25.0.887673475194.issue24905@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Small discussion is started at pull request [1]. There are doubts about the usefulness of incremental I/O API. SQLite is rarely used for storing blobs of the size of hundreds of megabytes. For smaller blobs it may be enough to read or write all data at once. There are also questions about the support of len(), since other file-like objects don't support len(). This discussion remembered me about mmap objects. mmap objects implement two protocols: file protocol and sequence protocol (including the support of len()). The BLOB object looks similar to the mmap object. sqlite3_blob_write() may only modify the contents of the BLOB; it is not possible to increase the size of a BLOB using this API. Maybe implement the sequence protocol in the BLOB object? Or implement only the sequence protocol and drop away the file protocol? [1] https://github.com/python/cpython/pull/271 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 15:39:43 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Tue, 28 Feb 2017 20:39:43 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1488314383.78.0.297627782474.issue9303@psf.upfronthosting.co.za> Changes by Aviv Palivoda : ---------- pull_requests: +306 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 15:49:01 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Tue, 28 Feb 2017 20:49:01 +0000 Subject: [issue24905] Allow incremental I/O to blobs in sqlite3 In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za> Message-ID: <1488314941.08.0.136738193878.issue24905@psf.upfronthosting.co.za> Aviv Palivoda added the comment: Just to make sure when you say "sequence protocol" you thin about the doing blob[4:6] = "ab"? I actually think this is a nice feature. The Blob and the mmap object has a lot in common so I think that making the same API will be best. I think that adding the sequence protocol in addition to the file protocol is best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 15:51:17 2017 From: report at bugs.python.org (Aviv Palivoda) Date: Tue, 28 Feb 2017 20:51:17 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1488315077.26.0.403006322094.issue9303@psf.upfronthosting.co.za> Aviv Palivoda added the comment: I opened a PR. This actually is a bugfix in addition to an enhancement as it solves issue 26187 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 16:46:36 2017 From: report at bugs.python.org (Marco Buttu) Date: Tue, 28 Feb 2017 21:46:36 +0000 Subject: [issue29414] Change 'the for statement is such an iterator' in Tutorial In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> Message-ID: <1488318396.63.0.191998283353.issue29414@psf.upfronthosting.co.za> Marco Buttu added the comment: Wolfgang, thanks for your contribution. However, I prefere the chapter as it currently is, because IMHO it introduces the concepts more gradually than your proposal. In addition the modification of the title section from "for Statements" to "for Loops" IMHO makes the title not consistent with the other section titles. > - I don't think range() really deserves its own section > in a chapter about control flow, so I removed most of it > and linked to the relevant stdtypes section instead -1 for me: the range() function is used in several examples in the chapter, that is why IMHO it is worth having the range() section as it is now. > - moved the definition of an iterable up into the for > loop section -1 for me: IMHO the current definition/introdution of iterable is easier to understand for a beginner. > - restructured the for loop section to discuss Python for loops > first and only compare them to Pascal/C afterwards +0. I think for a reader who is coming from another language is better to have the current introduction. But maybe it is not the same for a reader who is learning Python as a first programming language. > - moved the example for modifying a list while iterating > over it to the datastructures chapter +0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 18:03:02 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 28 Feb 2017 23:03:02 +0000 Subject: [issue28791] update sqlite to 3.17.0 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1488322982.7.0.441048409868.issue28791@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Big Stone. Setting the version to 3.7. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 18:21:09 2017 From: report at bugs.python.org (Jelle Zijlstra) Date: Tue, 28 Feb 2017 23:21:09 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager Message-ID: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: An async equivalent of @contextmanager would be an obvious use case for async generators and the async with statement. In my own code, I have several async context objects that could have been written more concisely if @asynccontextmanager was available. I'll be working on a PR to implement this. ---------- components: Library (Lib) messages: 288729 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Add @contextlib.asynccontextmanager versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 19:19:07 2017 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 01 Mar 2017 00:19:07 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager In-Reply-To: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> Message-ID: <1488327547.34.0.513416764792.issue29679@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- pull_requests: +307 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 21:36:44 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 02:36:44 +0000 Subject: [issue29680] gdb/libpython.py does not work with gdb 7.2 Message-ID: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Printing the backtrace in gdb results in Python errors: (gdb) bt ... #6 0x00007ffff7ba9745 in _PyEval_EvalCodeWithName (_co=, globals=Traceback (most recent call last): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 1358, in to_string return pyop.get_truncated_repr(MAX_OUTPUT_LEN) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 243, in get_truncated_repr self.write_repr(out, set()) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 702, in write_repr for pyop_key, pyop_value in self.iteritems(): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 669, in iteritems entries, nentries = self._get_entries(keys) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 717, in _get_entries except gdb.error: AttributeError: 'module' object has no attribute 'error' ... ---------- assignee: belopolsky messages: 288730 nosy: belopolsky priority: normal severity: normal status: open title: gdb/libpython.py does not work with gdb 7.2 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 21:47:39 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 02:47:39 +0000 Subject: [issue29680] gdb/libpython.py does not work with gdb 7.2 In-Reply-To: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> Message-ID: <1488336459.15.0.358505418532.issue29680@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 21:48:36 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 02:48:36 +0000 Subject: [issue29680] gdb/libpython.py does not work with gdb 7.2 In-Reply-To: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> Message-ID: <1488336516.15.0.278433362149.issue29680@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- pull_requests: +308 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 21:48:36 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 02:48:36 +0000 Subject: [issue29680] gdb/libpython.py does not work with gdb 7.2 In-Reply-To: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> Message-ID: <1488336516.24.0.225765846776.issue29680@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- pull_requests: +308, 309 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 22:32:30 2017 From: report at bugs.python.org (Marshall Giguere) Date: Wed, 01 Mar 2017 03:32:30 +0000 Subject: [issue29681] getopt fails to handle option with missing value in middle of list Message-ID: <1488339150.93.0.468964367944.issue29681@psf.upfronthosting.co.za> New submission from Marshall Giguere: Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux >>> from getopt import getopt >>> argv = [ '-a', '-b', '-c', '-d', 'foo'] >>> opts, args = getopt( argv, 'abc:d:') >>> opts [('-a', ''), ('-b', ''), ('-c', '-d')] >>> args ['foo'] Expected behavior: opts = [('-a', ''), ('-b', ''), ('-c', ''), ('-d', 'foo')] Throws execption: getopt.GetoptError: option -c requires argument Note that -c requires a value, getopt swallows the next option '-d' as the argument to -c. However, if -c is the last option on the command line getopt properly throws an execption "getopt.GetoptError: option -c requires argument". The documentation states that getopt will throw an exception when an option requiring a value is missing and exception will be thrown. "exception getopt.GetoptError This is raised when an unrecognized option is found in the argument list or when an option requiring an argument is given none." The option -c requires an argument, none was given, no exception is thrown. Instead the next option, '-d', is taken as the argument. I have also tried this test on 2.7 with the same result. ---------- components: Extension Modules messages: 288731 nosy: Marshall Giguere priority: normal severity: normal status: open title: getopt fails to handle option with missing value in middle of list type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 22:49:36 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 03:49:36 +0000 Subject: [issue29680] gdb/libpython.py does not work with gdb 7.2 In-Reply-To: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> Message-ID: <1488340176.07.0.907687563415.issue29680@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- components: +Demos and Tools stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:16:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Mar 2017 04:16:37 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager In-Reply-To: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> Message-ID: <1488341797.03.0.542665560265.issue29679@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, ncoghlan, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:18:11 2017 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 01 Mar 2017 04:18:11 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1488341891.73.0.906587540117.issue28598@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- pull_requests: +310 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:19:01 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Mar 2017 04:19:01 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager In-Reply-To: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> Message-ID: <1488341941.47.0.466266573675.issue29679@psf.upfronthosting.co.za> Nick Coghlan added the comment: The general idea seems reasonable to me, and I've added some specific code level feedback on the PR. A related question to this one would be whether or not it may make sense to develop a more async-friendly variant of contextlib.ExitStack (I don't currently write enough async code to design that myself, but I'm open to the idea of adding something along those lines). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:30:32 2017 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 01 Mar 2017 04:30:32 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager In-Reply-To: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> Message-ID: <1488342632.63.0.0178485500018.issue29679@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks, I'll address your PR comments. issue 29302 is asking for AsyncExitStack, but that can be an independent change. I haven't personally felt the need for AsyncExitStack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:31:59 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 01 Mar 2017 04:31:59 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1488342719.22.0.276847178535.issue29302@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, ncoghlan, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 23:35:40 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 01 Mar 2017 04:35:40 +0000 Subject: [issue29679] Add @contextlib.asynccontextmanager In-Reply-To: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> Message-ID: <1488342940.34.0.761270765529.issue29679@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nick, do you think this belongs in contextlib to be side-by-side with @contextmanager or would it be better to group all async tools in their own module. It seems to me that people are going to ask for an async version of everything, effectively shadowing the core grammar and the library. Before we go very far down that road, I think we should decide where it all should go. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________