[issue24068] statistics module - incorrect results with boolean input
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20014] Makes array.array constructor accepts ascii-unicode typecode
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13566] Array objects pickled in 3.x with protocol =2 are unpickled incorrectly in 2.x
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24134] assertRaises can behave differently
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file39340/assert_raises_args_deprecation.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Larry Hastings added the comment: I'd rather have the general-purpose freelist for ints too. How about we close this issue now, and assuming the freelist for ints goes in we can abandon this approach entirely. -- resolution: - rejected stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: According to my and Larry's measurements [1] the distribution of created int's by size during running Python tests is: On 32-bit Linux: int 42828741 13.40% 0 425353 0.99% 0.99% 1 21399290 49.96% 50.96% 2 10496856 24.51% 75.47% 34873346 11.38% 86.85% 41021563 2.39% 89.23% 51246444 2.91% 92.14% 6 733676 1.71% 93.85% 7 123074 0.29% 94.14% 8 139203 0.33% 94.47% ... On 64-bit Linux: int 47600237 13.53% 0 294964 0.62% 0.62% 1 36135772 75.92% 76.53% 24504046 9.46% 86.00% 32109837 4.43% 90.43% 41277995 2.68% 93.11% 5 542775 1.14% 94.25% 6 485451 1.02% 95.27% ... 86% of ints have size = 3 on 32-bit and = 2 on 64-bit. This is enough to represent 32-bit integers (as in Python 2 int). I think we should support free list not only for 1-digit ints, but at least up to 3 digit on 32-bit build and up to 2 digits on 64-bit build. Other natural limit is 3 digit on 64-bit build (enough to represent 64-bit C long on Linux or pointer on all platforms). Larger integers perhaps are encountered mainly in tests. Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Antoine Pitrou added the comment: I'd rather stick to the simple freelist approach. People interested in (allegedly) more ambitious designs can open new issues, together with patches to evaluate their efficiency. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24164] Support pickling objects with __new__ with keyword arguments with protocol 2+
New submission from Serhiy Storchaka: Pickling of objects of classes whose __new__ mandates the use of keyword-only arguments is supported with protocol 4 (using a new opcode NEWOBJ_EX). But it is possible to implement this feature with protocol 2+ (less efficiently than with NEWOBJ_EX). __new_ex__ is pickled as partial(cls.__new__, cls, *args, **kwargs). Pickled data is compatible with older Python releases up to 2.7 (issue5228). Proposed patch adds support of __new__ with keyword arguments with protocols 2 and 3. -- components: Extension Modules, Interpreter Core, Library (Lib) files: pickle_new_ex_protocol_2.patch keywords: patch messages: 242890 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Support pickling objects with __new__ with keyword arguments with protocol 2+ type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39341/pickle_new_ex_protocol_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24164 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Nick Coghlan added the comment: It sounds like fixing this properly requires fixing issue 17620 first (so the interactive interpreter actually uses sys.stdin), so I've flagged that as a dependency. -- dependencies: +Python interactive console doesn't use sys.stdin for input ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Marc-Andre Lemburg added the comment: I like the idea of adding a free list of longs in Python 3, but I think we should extend this somewhat to cover more ground, e.g. by pre-allocating a block of 1 digit long objects, like we did for Python 2 ints, and perhaps allocate up to 4k (= 1 memory page) towards such a free list. The added cache locality of having the data in a pre-allocated block should provide some more performance. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: [1] http://comments.gmane.org/gmane.comp.python.devel/153078 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Paul Moore p.f.mo...@gmail.com: -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Marc-Andre Lemburg added the comment: On 11.05.2015 11:42, Serhiy Storchaka wrote: Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. True, but if it's only 1-4k RAM, I don't think anyone would mind :-) Python 2 is doing exactly that with 1k RAM for the integer free list. I think it was one of the first free lists ever added to Python, so done in a time when RAM was expensive ;-). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24138] Speed up range() by caching and modifying long objects
Serhiy Storchaka added the comment: Well, 1-4k RAM can be consumed just after the start up (it's only 100-300 integers) and never freed. What next? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
New submission from Serhiy Storchaka: Proposed patch adds free list for single-digit PyLong objects. In Python tests 7% of created objects are ints. 50% of them are 15-bit (single-digit on 32-bit build), 75% of them are 30-bit (single-digit on 64-bit build). See the start of the discussion in issue24138. -- components: Interpreter Core files: int_free_list_2.patch keywords: patch messages: 242894 nosy: BreamoreBoy, ethan.furman, larry, lemburg, mark.dickinson, pitrou, rhettinger, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Free list for single-digits ints type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39342/int_free_list_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: I looked at this six years ago. I still haven't found a situation where I pined for a NamedTupleReader. That said, I have no objection to committing it if others, more well-versed in current Python code and NamedTuples than I gives it a pass. Note that I added a couple comments to the csv.py diff, but nobody either updated the code or explained why I was out in the weeds in my comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
New submission from Paul Baker: On the www.python.org/downloads/windows page, the Windows x86 MSI installer links for versions 2.4.4, 2.4.3, 2.4.2 and 2.4.0 point to the IA64 versions of the installers rather than the x86 versions. For example, the 2.4.4 link points to python-2.4.4.ia64.msi rather than python-2.4.4.msi. -- components: Installation, Windows messages: 242897 nosy: paul.baker, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 2.4.X links on www.python.org/downloads/windows point to the wrong files ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Brett Cannon added the comment: Any chance of running hg.python.org/benchmarks to see what kind of performance this would get us? -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24166] ArgumentParser behavior does not match generated help
New submission from Benjamin Schubert:
When creating a ArgumentParser on which we attach a subparser with different
options and then add a nargs=+ argument to the initial parser, the command
format string generated does not match the behavior.
for example it would generate :
argparse_error.py [-h] {ls,du} ... vm [vm ...]
but only accept one vm.
I would suspect a bug when parsing the arguments (as the help meets the desired
behavior).
Attached is a little script to reproduce the error.
Thank you !
--
components: Library (Lib)
files: argparse_error.py
messages: 242895
nosy: tellendil
priority: normal
severity: normal
status: open
title: ArgumentParser behavior does not match generated help
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file39343/argparse_error.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
STINNER Victor added the comment: You should report bugs of the website to https://github.com/python/pythondotorg/issues -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
Paul Baker added the comment: Done: https://github.com/python/pythondotorg/issues/751 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Serhiy Storchaka added the comment: Report on Linux xarax 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:15 UTC 2015 i686 athlon Total CPU cores: 2 ### 2to3 ### 15.796000 - 15.652000: 1.01x faster ### etree_generate ### Min: 0.687270 - 0.715218: 1.04x slower Avg: 0.698458 - 0.722657: 1.03x slower Significant (t=-9.02) Stddev: 0.01846 - 0.00431: 4.2808x smaller ### etree_iterparse ### Min: 1.145829 - 1.117311: 1.03x faster Avg: 1.159865 - 1.129438: 1.03x faster Significant (t=21.95) Stddev: 0.00835 - 0.00513: 1.6297x smaller ### etree_parse ### Min: 0.816515 - 0.867189: 1.06x slower Avg: 0.825879 - 0.877618: 1.06x slower Significant (t=-48.87) Stddev: 0.00405 - 0.00630: 1.5556x larger ### etree_process ### Min: 0.542221 - 0.565161: 1.04x slower Avg: 0.548276 - 0.569324: 1.04x slower Significant (t=-28.38) Stddev: 0.00380 - 0.00361: 1.0540x smaller ### json_load ### Min: 1.020657 - 0.995001: 1.03x faster Avg: 1.025593 - 0.998038: 1.03x faster Significant (t=28.37) Stddev: 0.00503 - 0.00468: 1.0738x smaller ### nbody ### Min: 0.577393 - 0.588626: 1.02x slower Avg: 0.578246 - 0.590917: 1.02x slower Significant (t=-43.51) Stddev: 0.00037 - 0.00203: 5.4513x larger ### regex_v8 ### Min: 0.123794 - 0.119950: 1.03x faster Avg: 0.124631 - 0.121131: 1.03x faster Significant (t=4.92) Stddev: 0.00340 - 0.00371: 1.0917x larger The following not significant results are hidden, use -v to show them: django_v2, fastpickle, fastunpickle, json_dump_v2, tornado_http. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 11.05.2015 21:03, Steve Dower wrote: Steve Dower added the comment: Simply because I didn't update the doc string :) I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. But my main question is why would you still need the old versions around, given that compatibility is already broken? In Python 2, distutils could be easily be used on earlier Python versions, simplifying the amount of work you'd need to do in your setup.py to address differences between the various Python versions you wanted to support. I don't know what the deal is for Python 3. Apart from that, it may be necessary to compile some parts of C extensions with older compilers. Probably a rare case, but then again: what do we gain by removing the old code ? Note that VC9 was handled in the same way: it was added to the set rather than replacing it. That was done in the Python 2 series, though, where the above guarantee was used as basis, so things may be different for Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1100942] Add datetime.time.strptime and datetime.date.strptime
Maciej Szulik added the comment: Berker per your comment updated patch changing those two new methods (namely date.strptime and time.strptime) to be classmethod and not staticmethods. -- Added file: http://bugs.python.org/file39345/issue1100942.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1100942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24157] test_urandom_fd_reopened failure on Mac OS X
Ned Deily added the comment: Skip, looking at the test, it seems likely that there is unexpected writing to stdout in the subprocess. Can you add a print(out) in the test (around test_os.py:1273) to see what is actually being written on your machine? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24157 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24159] Misleading TypeError when pickling bytes to a file opened as text
Changes by Ned Deily n...@acm.org: -- nosy: +alexandre.vassalotti, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Changes by Ned Deily n...@acm.org: -- nosy: +ghaering stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc
Changes by Ned Deily n...@acm.org: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Paul Moore added the comment: I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work (I guess we'll then just continue to override the .initialize() call). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: I guess we need a third opinion. For me, the subclasses of CCompiler are undocumented and not a guaranteed interface (people using them directly are consenting adults). They're also an eyesore, so if I can clean them up without breaking the CCompiler interface (or minor version upgrades) then I should. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24163] shutil.copystat fails when attribute security.selinux is present
Ned Deily added the comment: Possibly related: Issue15238 (msg165591 re root) -- nosy: +hynek, ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 11.05.2015 23:50, Paul Moore wrote: I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work (I guess we'll then just continue to override the .initialize() call). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. This is not about our code. We can work around all this. The point is that in general, we don't break things in Python just because we can, even if we don't need to. In this case, I don't see a need to break things to add support for a new compiler version, which is why I don't follow Steve's arguments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Simply because I didn't update the doc string :) I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. But my main question is why would you still need the old versions around, given that compatibility is already broken? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Antoine Pitrou added the comment: You probably need a workload that uses integers quite heavily to see a difference. And even then, it would also depend on the allocation pattern. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Yury Selivanov added the comment: Nick, Guido, Updated patch attached. -- Added file: http://bugs.python.org/file39344/await_06.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Stefan Behnel added the comment: Well, as I've shown in issue 24076 (I'm copying the numbers here), even simple arithmetic expressions can benefit from a free-list. Basically anything that uses temporary integer results. Original: $ ./python -m timeit 'sum(range(1, 10))' 1000 loops, best of 3: 1.86 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 1))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 1.05 msec per loop With freelist: $ ./python -m timeit 'sum(range(1, 10))' 1000 loops, best of 3: 1.52 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 1))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 931 usec per loop -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24076] sum() several times slower on Python 3
Stefan Behnel added the comment: Issue 24165 was created to pursue the path of a free-list for PyLong objects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Antoine Pitrou added the comment: Yes, but I meant a realistic workload, not a micro-benchmark. There are tons of ways to make Python look faster on micro-benchmarks but that have no relevant impact on actual applications. (note that I'm still sympathetic to the freelist approach) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Stefan Behnel added the comment: I got similar results on 64bits for my original patch (very similar to what Serhiy used now). The numbers are not really conclusive. Report on Linux leppy 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 Total CPU cores: 4 ### 2to3 ### 6.885334 - 6.829016: 1.01x faster ### etree_process ### Min: 0.249504 - 0.253876: 1.02x slower Med: 0.252730 - 0.258274: 1.02x slower Avg: 0.254332 - 0.261100: 1.03x slower Significant (t=-5.99) Stddev: 0.00478 - 0.00640: 1.3391x larger ### fastpickle ### Min: 0.402085 - 0.416765: 1.04x slower Med: 0.405595 - 0.424729: 1.05x slower Avg: 0.405882 - 0.429707: 1.06x slower Significant (t=-12.45) Stddev: 0.00228 - 0.01334: 5.8585x larger ### json_dump_v2 ### Min: 2.611031 - 2.522507: 1.04x faster Med: 2.678369 - 2.544085: 1.05x faster Avg: 2.706089 - 2.552111: 1.06x faster Significant (t=10.40) Stddev: 0.09551 - 0.04290: 2.2265x smaller ### nbody ### Min: 0.217901 - 0.214968: 1.01x faster Med: 0.224340 - 0.216781: 1.03x faster Avg: 0.226012 - 0.216981: 1.04x faster Significant (t=6.03) Stddev: 0.01049 - 0.00142: 7.4102x smaller ### regex_v8 ### Min: 0.040856 - 0.039377: 1.04x faster Med: 0.041847 - 0.040082: 1.04x faster Avg: 0.042468 - 0.040726: 1.04x faster Significant (t=3.20) Stddev: 0.00291 - 0.00252: 1.1549x smaller The following not significant results are hidden, use -v to show them: etree_generate, etree_iterparse, etree_parse, fastunpickle, json_load. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Nick Coghlan added the comment: Guido convinced me that having StopAsyncIteration inherit from Exception was the right approach, as it means errors are more likely to be of the we caught it when we shouldn't have variety, rather than the harder to debug an exception escaped when it shouldn't have variety. This isn't like SystemExit, KeyboardInterrupt or GeneratorExit where they're specifically designed to reliably terminate a thread of execution. That means I can offer an unreserved +1 on the current patch (#6) for beta 1 :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24165] Free list for single-digits ints
Serhiy Storchaka added the comment: Oh, sorry, Stefan, I didn't noticed your patch. I wouldn't write my patch if noticed your patch. int_free_list_2.patch adds free list only for single-digits ints. Following patch adds free list for multi-digit ints (3 on 32-bit build, 2 on 64-bit build) enough to represent 32-bit integers. Unfortunately it makes allocating/deallocating of single-digit ints slower. Microbenchmarks: $ ./python -m timeit -s r = range(10**4) -- for i in r: pass Unpatched: 1000 loops, best of 3: 603 usec per loop 1-digit free list: 1000 loops, best of 3: 390 usec per loop Multi-digit free list: 1000 loops, best of 3: 428 usec per loop $ ./python -m timeit -s r = range(10**5) -- for i in r: pass Unpatched: 100 loops, best of 3: 6.12 msec per loop 1-digit free list: 100 loops, best of 3: 5.69 msec per loop Multi-digit free list: 100 loops, best of 3: 4.36 msec per loop $ ./python -m timeit -s a = list(range(10**4)) -- for i, x in enumerate(a): pass Unpatched: 1000 loops, best of 3: 1.25 msec per loop 1-digit free list: 1000 loops, best of 3: 929 usec per loop Multi-digit free list: 1000 loops, best of 3: 968 usec per loop $ ./python -m timeit -s a = list(range(10**5)) -- for i, x in enumerate(a): pass Unpatched: 100 loops, best of 3: 11.7 msec per loop 1-digit free list: 100 loops, best of 3: 10.9 msec per loop Multi-digit free list: 100 loops, best of 3: 9.99 msec per loop As for more realistic cases, base85 encoding is 5% faster with multi-digit free list. $ ./python -m timeit -s from base64 import b85encode; a = bytes(range(256))*100 -- b85encode(a) Unpatched: 100 loops, best of 3: 10 msec per loop 1-digit free list: 100 loops, best of 3: 9.85 msec per loop Multi-digit free list: 100 loops, best of 3: 9.48 msec per loop -- Added file: http://bugs.python.org/file39346/int_free_list_multidigit.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 11.05.2015 23:20, Steve Dower wrote: I guess we need a third opinion. For me, the subclasses of CCompiler are undocumented and not a guaranteed interface (people using them directly are consenting adults). They're also an eyesore, so if I can clean them up without breaking the CCompiler interface (or minor version upgrades) then I should. The distutils interface isn't documented in all details, so the rule of thumb by which everybody operates is that any non-private symbol is part of the public API. FWIW: I don't see a problem with keeping implementations around for older MS VC versions. It's well possible that someone might want to use them for creating a Python version compiled with an older version of MS VC, e.g. in an embedding scenario. And you can still have your new cleaned up version override the default msvccompiler class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Roundup Robot added the comment: New changeset 3a3cc2b9a1b2 by Yury Selivanov in branch 'default': Issue 24017: Update NEWS file. https://hg.python.org/cpython/rev/3a3cc2b9a1b2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6057] sqlite3 error classes should be documented
Radek Holý added the comment: One reason why I would like to have it mentioned in the documentation is that the fact that it is not documented there causes sqlite3.Error to be missing in the objects.inv file generated by Sphinx so that enabling the nitpicky mode with intersphinx extension when generating my documentation using Sphinx results in many WARNING: py:exc reference target not found: sqlite3.Error false positives. (I'd also like to have it backported to Python 2.6 but I know that it's impossible) -- nosy: +PyDeq ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6057 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Things are already 'broken' for the new compiler version, so Python won't build properly with older versions of VC anymore (there are a few more changes, like removing _PyVerify_fd, that will make this even less likely - the new CRT is for too incompatible with the old one, though it's much more compatible with other OSs). If it's a big deal, I'll add the new compiler class as _msvccompiler.py and leave the old ones there as legacy code. That will save us from this discussion next time and avoid breaking people immediately (though there's almost certainly going to be subtle issues for them...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Nick Coghlan added the comment: Latest version looks good to me (aside from a quibble about whether StopAsyncIteration should inherit from BaseException instead of Exception - see my review for details). Based on Guido's explanation in the review, I also suggested adding the following example method to the PEP as part of the rationale for StopAsyncIteration: def __anext__(self): try: data = await self._get_data() except EOFError: raise StopAsyncIteration return data The trick is that when __anext__ is itself a coroutine, we really do have 3 exit paths: * suspension to wait for events (await) * returning the next value (return) * terminating iteration (raise StopAsyncIteration) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name
New submission from Toshishige Hagihara:
There is a problem with unittest discovering with namespace packages.
Given the following directory structure, the following command fails with the
errors.
# Directory Structure
```
/home/hagihara/test.cybozu/infra/forest/lib/python3/
cybozu/ # - namespace package
cmdb/
__init__.py
test.py
```
# Commands
```
# setup module path
echo /home/hagihara/test.cybozu/infra/forest/lib/python3 sudo dd
of=/usr/lib/python3/dist-packages/cybozu.pth
cd /home/hagihara/test.cybozu/infra
python3 -m unittest discover -s cybozu
```
# Errors
```
$ python3 -m unittest discover -s cybozu
Traceback (most recent call last):
File /usr/lib/python3.4/unittest/loader.py, line 221, in discover
os.path.dirname((the_module.__file__)))
AttributeError: 'module' object has no attribute '__file__'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /usr/lib/python3.4/runpy.py, line 170, in _run_module_as_main
__main__, mod_spec)
File /usr/lib/python3.4/runpy.py, line 85, in _run_code
exec(code, run_globals)
File /usr/lib/python3.4/unittest/__main__.py, line 18, in module
main(module=None)
File /usr/lib/python3.4/unittest/main.py, line 92, in __init__
self.parseArgs(argv)
File /usr/lib/python3.4/unittest/main.py, line 116, in parseArgs
self._do_discovery(argv[2:])
File /usr/lib/python3.4/unittest/main.py, line 225, in _do_discovery
self.test = loader.discover(self.start, self.pattern, self.top)
File /usr/lib/python3.4/unittest/loader.py, line 242, in discover
namespace=True))
File /usr/lib/python3.4/unittest/loader.py, line 349, in _find_tests
namespace=namespace)
File /usr/lib/python3.4/unittest/loader.py, line 310, in _find_tests
name = self._get_name_from_path(full_path)
File /usr/lib/python3.4/unittest/loader.py, line 284, in _get_name_from_path
assert not _relpath.startswith('..'), Path must be within the project
AssertionError: Path must be within the project
```
# Cause of the error
This error happens because TestLoader.discover does not set
`self._top_level_dir` properly.
`/usr/lib/python3.4/unittest/loader.py`
```
class TestLoader(object):
...
def discover(self, start_dir, pattern='test*.py', top_level_dir=None):
...
if os.path.isdir(os.path.abspath(start_dir)):
...
else:
# support for discovery from dotted module names
try:
__import__(start_dir)
except ImportError:
is_not_importable = True
else:
try:
start_dir = os.path.abspath(
os.path.dirname((the_module.__file__)))
except AttributeError:
# look for namespace packages
...
if spec and spec.loader is None:
if spec.submodule_search_locations is not None:
is_namespace = True
for path in the_module.__path__:
if (not set_implicit_top and
not path.startswith(top_level_dir)):
continue
self._top_level_dir = \---
cause of the error.
(path.split(the_module.__name__
.replace(., os.path.sep))[0])
```
If path of the module contains the string same as the module name,
the path is split at incorrect position and invalid value is set to
`self._top_level_dir`.
```
path.split(the_module.__name__.replace(., os.path.sep))[0]
```
the_module - cybozu
cybozu.__path__ -
['/home/hagihara/test.cybozu/infra/forest/lib/python3/cybozu']
path.split('cybozu')[0] - '/home/hagihara/test.'
--
components: Tests
messages: 242929
nosy: toshishige hagihara
priority: normal
severity: normal
status: open
title: Unittest discover fails with namespace package if the path contains the
string same as the module name
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24168
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] test.test_ssl.ThreadedTests unit test failed
Ned Deily added the comment: There are places in the test suite that assume 127.0.0.1 is the standard loopback address and will fail if the system under test doesn't follow that convention; see, for example, the discussion in Issue22753. I suspect that, in your case, the system's host configuration (/etc/hosts, DNS configuration, or similar) is such that the loopback address (127.0.0.1) is round-tripped as the actual address (192.168.1.103) of the interface. What platform are you running this on? Can you check what the addresses association with localhost and the names associated with the two IP addresses? For example, on many POSIX-y platforms, the following might work: dig localhost dig -x 127.0.0.1 dig -x 192.168.1.103 ifconfig -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22385] Define a binary output formatting mini-language for *.hex()
Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 after folks have had a chance to get some experience with the basic bytes.hex() method. -- versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15216] Support setting the encoding on a text stream after creation
Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 after folks have had a chance to get some experience with the interpreter defaulting to using surrogateescape on the standard streams when an underlying *nix operating system (other than Mac OS X) claims that the system encoding is ASCII. -- priority: high - normal versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22555] Tracking issue for adjustments to binary/text boundary handling
Nick Coghlan added the comment: I just went through the still-open issues referenced from here, and recommended deferring further consideration of all of the remaining items to 3.6: * utilities for clearing out surrogates from strings: issue 18814 * treating wsgistr as a serialisation format: issue 22264 * defining a formatting mini-language for hex output: issue 22385 * providing a way to change the encoding of an existing stream: issue 15216 I also added two new dependencies to this tracking issue: * Improved Unicode handling in the Windows console: issue 17620 * Using sys.stdin consistently at the default interactive prompt: issue 1602 -- dependencies: +Python interactive console doesn't use sys.stdin for input, windows console doesn't print or input Unicode ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22555 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add utilities to clean surrogate code points from strings
Nick Coghlan added the comment: I suggest we defer this one to 3.6 - I still think it's worth doing, but I don't think it's a major barrier to migration, and it would be good to get some real world experience with the new sys.stdin behaviour of defaulting to using surrogateescape in the POSIX locale in 3.5 before committing to a particular design for the surrogate cleaning API. I do like the idea of a string.internals submodule as a possible home for exposing the Python level API. -- title: Add codecs.convert_surrogateescape to clean surrogate escaped strings - Add utilities to clean surrogate code points from strings versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.dump_wsgistr load_wsgistr
Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 and/or the creation of a WSGI 2.0 specification. -- versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name
Eric Snow added the comment: Just in case, please take a look at issues #17457 and #23882 to see if they already cover the bug. -- nosy: +eric.snow, rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24168 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Roundup Robot added the comment: New changeset 957478e95b26 by Yury Selivanov in branch '3.4': asyncio: Support PEP 492. Issue #24017. https://hg.python.org/cpython/rev/957478e95b26 New changeset 44c1db190525 by Yury Selivanov in branch 'default': asyncio: Merge 3.4 -- Support PEP 492. Issue #24017. https://hg.python.org/cpython/rev/44c1db190525 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Yury Selivanov added the comment: Guido, Nick, Victor, Thanks for your reviews and guidance! The patch has been committed to the default branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name
Toshishige Hagihara added the comment: Thanks for suggestion. I checked both issues and found that this bug is created in #17457 and #23882 does not fix it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24168 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9517] Make test.script_helper more comprehensive, and use it in the test suite
Christie added the comment: Hey @berker.peksag, @r.david.murray, @serhiy.storchaka, If you get a chance I've got some changes up for review at: * http://bugs.python.org/issue24033 * http://bugs.python.org/issue23981 Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24033] Update _test_multiprocessing.py to use script helpers
Christie added the comment: Updated both tests in _test_mulitprocessing.py which were using sys.exectuable and Popen to use script_helpers instead, refactored script_helpers a bit to make this work. -- keywords: +patch Added file: http://bugs.python.org/file39347/issue24033_script_helper_multi_both.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24033 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Roundup Robot added the comment: New changeset eeeb666a5365 by Yury Selivanov in branch 'default': PEP 0492 -- Coroutines with async and await syntax. Issue #24017. https://hg.python.org/cpython/rev/eeeb666a5365 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Guido van Rossum added the comment: Thank you Yury! You are a coding machine. On Mon, May 11, 2015 at 8:06 PM, Yury Selivanov rep...@bugs.python.org wrote: Yury Selivanov added the comment: Guido, Nick, Victor, Thanks for your reviews and guidance! The patch has been committed to the default branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
Roundup Robot added the comment: New changeset 0f7795edca65 by Raymond Hettinger in branch '2.7': Issue #24161: Document that PyIter_Check() returns false positives for old-style instances. https://hg.python.org/cpython/rev/0f7795edca65 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21795] smtpd.SMTPServer should announce 8BITMIME when supported and accept SMTPUTF8 without it
Roundup Robot added the comment: New changeset e34ed02738bf by R David Murray in branch 'default': #21795: advertise 8BITMIME if decode_data is False. https://hg.python.org/cpython/rev/e34ed02738bf -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21795 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files
Changes by Berker Peksag berker.pek...@gmail.com: -- resolution: - third party stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21795] smtpd.SMTPServer should announce 8BITMIME when supported and accept SMTPUTF8 without it
R. David Murray added the comment: Thanks, Milan. I tweaked some things and tried to sort out the docs for all the changes we have made to smtpd. If you see anything I screwed up let me know. -- resolution: - fixed stage: commit review - resolved status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21795 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24166] ArgumentParser behavior does not match generated help
paul j3 added the comment:
I wouldn't describe this as bug, just a nuance on how parsers and subparsers
play together.
To the main parser, the subparser argument looks like another positional. It
allocates strings to it and any following positionals based on their respective
'nargs'.
The nargs for a subparser is 'A...' (argparse.PARSER), which is similar to '+'
(it takes one or more strings)
parser2=ArgumentParser()
parser2.add_argument('arg1',nargs='A...')
parser2.add_argument('arg2',nargs='+')
parser2.parse_args(['create','test','test2'])
produces
Namespace(arg1=['create', 'test'], arg2=['test2'])
Notice how 2 of the strings are allocated to arg1, and only 1 to arg2. arg2 is
happy with just 1, so arg1 gets the rest.
In your example it's the subparser that is issuing the 'unrecognized arguments'
message, because it doesn't have a positional argument that would take it.
Having more than one positional that takes are variable number of arguments is
tricky. I find it helpful to think in terms of how `re` would handle a pattern
like `(A+)(A*)(A)`.
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24155] Optimize heapify for better cache utililzation
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24155 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24155] Optimize heapify for better cache utililzation
Roundup Robot added the comment: New changeset db87591fce01 by Raymond Hettinger in branch 'default': Issue #24155: Optimize heapify for better cache utililzation. https://hg.python.org/cpython/rev/db87591fce01 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24155 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24166] ArgumentParser behavior does not match generated help
paul j3 added the comment:
And the behavior does match the help
{ls,du} ... vm [vm ...]
It's just that one of the strings is allocated to the first `...`, whereas you
expected it to be put in the second.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: Why are you removing the mcvs9compiler.py file when at the same time your are referencing it in the msvccompiler.py doc string ? --- a/Lib/distutils/msvccompiler.py +++ b/Lib/distutils/msvccompiler.py @@ -1,201 +1,120 @@ distutils.msvccompiler Contains MSVCCompiler, an implementation of the abstract CCompiler class -for the Microsoft Visual Studio. +for Microsoft Visual Studio 2015. + +The module is compatible with VS 2015 and later. You can find legacy support +for older versions in distutils.msvc9compiler and distutils.msvccompiler. IMO, it would be better and more in line with the b/w aspects of distutils, to move the VS15 support into a new msvc14compiler.py which is then imported by msvccompiler.py at the end (much like this was done for msvc9compiler.py. That way we can maintain compatibility with existing code which uses stuff from those legacy modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
