[issue1191964] asynchronous Subprocess
Josiah Carlson added the comment: All of the standard tests plus another few that I added all pass on Windows and Linux. I've got some cleanup and a couple more tests to add tomorrow, then I'll post a patch. I ended up not using any overlapped IO cancellation in the Windows variant of communicate(), as there is no benefit to doing so, and the function is as re-entrant as the original. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
Charles-François Natali added the comment: Indeed, I think it would make sense to consider this for 3.4, and even 2.7 if we opt for a simple fix. As for the best way to fix it in the meantime, I'm fine with a buffered zero-filling (the mere fact that noone ever complained until now probably means that the performance isn't a show-stopper for users). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Roundup Robot added the comment: New changeset 91d7fadac271 by Mark Dickinson in branch 'default': Issue #21136: Avoid unnecessary normalization in Fractions resulting from power and other operations. http://hg.python.org/cpython/rev/91d7fadac271 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Changes by Mark Dickinson dicki...@gmail.com: -- stage: needs patch - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Mark Dickinson added the comment: Applied. I added an extra test for the `Fraction(0, 1) ** 2` case. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Roundup Robot added the comment: New changeset 9acc8196a82c by Victor Stinner in branch 'default': Issue #21118: Remove unused variable http://hg.python.org/cpython/rev/9acc8196a82c New changeset bd594dd71d46 by Victor Stinner in branch 'default': Issue #21118: Add more unit tests on str.translate() http://hg.python.org/cpython/rev/bd594dd71d46 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Roundup Robot added the comment: New changeset cca6b056236a by Victor Stinner in branch 'default': Issue #21118: Optimize str.translate() for ASCII = ASCII translation http://hg.python.org/cpython/rev/cca6b056236a New changeset 6a347c0ffbfc by Victor Stinner in branch 'default': Issue #21118: Add unit test for invalid character replacement (code point higher than U+10) http://hg.python.org/cpython/rev/6a347c0ffbfc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14576] IDLE: IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection.
Divyanshu Sharma added the comment: I found the root cause for the error regarding python in my pc that shows the error message IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection. It was caused due to a software known as proxifier which provides fast and somewhat unrestricted network access on proxy networks. It redirected my connection request from pythonw.exe to the port and IP on which the proxy network is established. The problem hence can be easily sorted by creating new proxification rules in such softwares, if the cause of the problem can be traced to some similar mechanisms used that may intercept and modify the network requests for other programs. -- title: IDLE: resolving home directory for configuration uses HOMEDRIVE, HOMEPATH, and USERPROFILE inconsistently on Windows. - IDLE: IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14576 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21159] configparser.InterpolationMissingOptionError is not very intuitive
New submission from Claudiu.Popa: The error message from the title is not very intuitive from a user point of view. For instance, in the following traceback, only the first one gives a meaning to this error, through the leaked KeyError, thus the user knows that home_dir1 is invalid and missing. But the second message with Bad value substitution doesn't emphasize the actual problem and you have to stare at it for a couple of moments to figure out what's happening and why. Maybe changing the Bad value substitution with a Missing value would suffice. This came up in issue19546. Traceback (most recent call last): File C:\Python34\lib\configparser.py, line 410, in _interpolate_some v = map[var] File C:\Python34\lib\collections\__init__.py, line 789, in __getitem__ return self.__missing__(key)# support subclasses that define __missing__ File C:\Python34\lib\collections\__init__.py, line 781, in __missing__ raise KeyError(key) KeyError: 'home_dir1' During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 1, in module File C:\Python34\lib\configparser.py, line 1204, in __getitem__ return self._parser.get(self._name, key) File C:\Python34\lib\configparser.py, line 773, in get d) File C:\Python34\lib\configparser.py, line 374, in before_get self._interpolate_some(parser, option, L, value, section, defaults, 1) File C:\Python34\lib\configparser.py, line 413, in _interpolate_some option, section, rest, var) configparser.InterpolationMissingOptionError: Bad value substitution: section: [Paths] option : my_dir key: home_dir1 rawval : /lumberjack -- components: Library (Lib) messages: 215589 nosy: Claudiu.Popa priority: normal severity: normal status: open title: configparser.InterpolationMissingOptionError is not very intuitive type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19546] configparser leaks implementation detail
Claudiu.Popa added the comment: I've created a new issue for the InterpolationMissingOptionError message, issue21159. This issue can be closed. -- resolution: - 3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19546] configparser leaks implementation detail
Claudiu.Popa added the comment: Ups, sorry for the change of resolution. -- resolution: 3rd party - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21160] incorrect comments in nturl2path.py
New submission from Jurko Gospodnetić: nturl2path.py module contains comments implying that it converts local paths to URLs with ':' characters replaced with '|'. This has not been true since Python 2.6. Commit at: http://bitbucket.org/jurko/cpython/commits/8fe56380b09e238f104ba4a4d7a67df73182bc21 updates those comments - prepared against the CPython development repo. -- components: Library (Lib), Windows hgrepos: 230 messages: 215592 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: incorrect comments in nturl2path.py versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15582] Enhance inspect.getdoc to follow inheritance chains
Claudiu.Popa added the comment: Yury, Nick, how is my latest patch? -- Added file: http://bugs.python.org/file34733/issue15582_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Serhiy Storchaka added the comment: fast_translate.patch works only with ASCII input string and ASCII 1:1 mapping. Is this actually typical case? Here is a patch which uses different approach. It caches values for ASCII keys. It works with all types of input strings and mappings and can speed up more use cases, including non-ASCII data, deletion and enlarging. translate_timing.py results: unpatched patched Testing 1-1 translation str.translate 4.551259276999190.7898181750006188 str.translate from bytes trans 1.8910855210015143 0.779950579000797 Testing deletion str.translate 4.481863372000589 0.771826150138 Testing enlarging translations str.translate 4.42152127085 0.9290620680003485 translate_script_ascii.py results: ---+---+--- Tests | translate_script_ascii.34 | translate_script_ascii.cached3 ---+---+--- replace none, length=10 | 6.12 us (+176%) | 2.22 us (*) replace none, length=10**3 | 448 us (+1293%) | 32.2 us (*) replace none, length=10**6 | 474 ms (+1435%) | 30.9 ms (*) replace 10%, length=10 | 5.73 us (+133%) | 2.46 us (*) replace 10%, length=10**3 | 412 us (+1060%) | 35.5 us (*) replace 10%, length=10**6 | 442 ms (+1204%) | 33.9 ms (*) replace 50%, length=10 | 4.75 us (+85%) | 2.57 us (*) replace 50%, length=10**3 | 311 us (+552%) | 47.7 us (*) replace 50%, length=10**6 | 331 ms (+617%) | 46.2 ms (*) replace 90%, length=10 | 3.36 us (+29%) | 2.59 us (*) replace 90%, length=10**3 | 178 us (+250%) | 50.8 us (*) replace 90%, length=10**6 | 192 ms (+291%) | 49.2 ms (*) replace all, length=10 | 2.64 us (+28%) | 2.06 us (*) replace all, length=10**3 | 146 us (+189%) | 50.3 us (*) replace all, length=10**6 | 152 ms (+194%) | 51.7 ms (*) ---+---+--- Total | 1.59 sec (+651%) | 212 ms (*) ---+---+--- -- Added file: http://bugs.python.org/file34734/translate_cached.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
New submission from Kay: Using generators in pdb are very handy but since Python3 they don't work properly. For example: import pdb def foo(): items = [1, 2, 3] limit = 5 pdb.set_trace() foo() in pdb prompt the following fails: (pdf) all(x limit for x in items) *** NameError: global name 'items' is not defined I can express that in a lambda expression (i.e. pass items as an argument) but this seems unnecessary and very inelegant. -- components: Interpreter Core messages: 215595 nosy: kay priority: normal severity: normal status: open title: list comprehensions don't see local variables in pdb in python3 versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21153] bdist_rpm fails if project contains files with spaces in the names
Jason R. Coombs added the comment: My last version of the repo script would have worked had I coded it correctly. The line-by-line substitution was broken, not taking into account the newline character. This new script demonstrates that quoting each file works - simply run the script with --install-script install.txt. -- Added file: http://bugs.python.org/file34735/issue21153.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Changes by Kay straitsai...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue809163] Can't add files with spaces under bdist_rpm
Jason R. Coombs added the comment: In issue21153, I explored this problem as well, before being aware of this issue. I had searched for bdist_rpm. I've since confirmed that the sed approach is viable. For example, the following works around the issue by overriding the install_script with the sed technique: $ cat install.txt python setup.py install -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES sed -i -e 's/.*/\0/' INSTALLED_FILES $ python setup.py bdist_rpm --install-script install.txt I agree that sed can probably be assumed to be present, though it would be nicer not to depend on it. It may also be possible not to have to list the files explicitly. In reading the rpm docs (http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html), I discovered that rpm will traverse a directory, adding it and its contents. Perhaps the whole routine of recording installed files and then listing them explicitly can be replaced by simply referencing the build root. -- nosy: +jason.coombs title: Can't add files with spaces - Can't add files with spaces under bdist_rpm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue809163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Roundup Robot added the comment: New changeset 47b0c076e17d by Victor Stinner in branch 'default': Issue #21118: Optimize also str.translate() for ASCII = ASCII deletion http://hg.python.org/cpython/rev/47b0c076e17d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment:
Serhiy wrote:
fast_translate.patch works only with ASCII input string and ASCII 1:1
mapping. Is this actually typical case?
I just checked the Python stdlib: as expected, all usages of
str.translate() except of email.quoprimime use ASCII 1:1. My
optimization is only used if the input string is ASCII, but I expect
that most strings are just ASCI.
** distutils: ASCII = ASCII (1:1)
longopt_xlate = str.maketrans('-', '_')
and
WS_TRANS = {ord(_wschar) : ' ' for _wschar in string.whitespace};
.. text = text.translate(WS_TRANS)
** email.quoprimes:
encoded = header_bytes.decode('latin1').translate(_QUOPRI_HEADER_MAP)
and
body = body.translate(_QUOPRI_BODY_ENCODE_MAP)
= my optimization is used if the input string contains safe header
characters (a-z, A-Z, 0-9, space and -!*+/). It should be the
common case for emails.
** rot13 encoding: ASCII 1:1
** idlelib.PyParse: ASCII 1:1
str = str.translate(_tran)
** textwrap: ASCII 1:1
text = text.translate(self.unicode_whitespace_trans)
** zipfile: ASCII 1:1
arcname = arcname.translate(table)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21118
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Serhiy Storchaka added the comment: Previous patch and results were against source code before committing fast_translate.patch. Here is a patch synchronized with current code. translate_timing.py results: unpatched patched Testing 1-1 translation str.translate 0.526542655469 0.6120695240006171 str.translate from bytes trans 0.260863407289 0.32327288200031035 Testing deletion str.translate 4.331346814999051 0.7960810519998631 Testing enlarging translations str.translate 4.392650978999882 0.9280614529998275 translate_script_ascii.py results: ---+--+--- Tests | translate_script_ascii.fastA | translate_script_ascii.cached2 ---+--+--- replace none, length=10 | 1.54 us (*) | 2.07 us (+34%) replace none, length=10**3 | 10.5 us (*) | 10.6 us replace none, length=10**6 | 12.6 ms | 12.3 ms (*) replace 10%, length=10 | 1.69 us (*) | 2.31 us (+37%) replace 10%, length=10**3 | 10.6 us (*) | 10.7 us replace 10%, length=10**6 | 12.6 ms | 12.1 ms (*) replace 50%, length=10 | 1.69 us (*) | 2.31 us (+36%) replace 50%, length=10**3 | 10.6 us (*) | 10.9 us replace 50%, length=10**6 | 12.6 ms | 12.3 ms (*) replace 90%, length=10 | 1.69 us (*) | 2.26 us (+34%) replace 90%, length=10**3 | 10.6 us (*) | 10.7 us replace 90%, length=10**6 | 12.6 ms | 12.2 ms (*) replace all, length=10 | 1.07 us (*) | 1.68 us (+56%) replace all, length=10**3 | 9.28 us (*) | 9.46 us replace all, length=10**6 | 12.6 ms | 12 ms (*) ---+--+--- Total | 63 ms | 60.9 ms (*) ---+--+--- translate_cached_2.patch little slows down translation of short ASCII strings (due to cache initialization and freeing), but speeds up deletion and enlarging and works with non-ASCII data. -- Added file: http://bugs.python.org/file34736/translate_cached_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue809163] Can't add files with spaces under bdist_rpm
Jason R. Coombs added the comment: I decided to test my proposition. It seems that simply specifying / for %files leads to the RPM including parent directories. Here's the output I get when running my test with the sed workaround: $ rpm -q -filesbypkg -p dist/issue21153-package-0.0.0-1.noarch.rpm issue21153-package /usr/local/lib/python2.7/dist-packages/issue21153_package-0.0.0.egg-info issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/__init__.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyo issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.py issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyc issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyo If instead I apply the no-record patch (attached), I can run bdist_rpm (not using sed workaround) without errors, but the resulting RPM has more directories specified: $ rpm -q -filesbypkg -p dist/issue21153-package-0.0.0-1.noarch.rpm issue21153-package/ issue21153-package/usr issue21153-package/usr/local issue21153-package/usr/local/lib issue21153-package/usr/local/lib/python2.7 issue21153-package/usr/local/lib/python2.7/dist-packages issue21153-package /usr/local/lib/python2.7/dist-packages/issue21153_package-0.0.0.egg-info issue21153-package/usr/local/lib/python2.7/dist-packages/pkg issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/__init__.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyo issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.py issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyc issue21153-package/usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyo Perhaps that's acceptable. If it is, it makes the code simpler and cleaner. Can someone comment on the impact of the presence of those parent directories in the RPM? -- Added file: http://bugs.python.org/file34737/issue809163-no-record.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue809163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment: bench_translate.py: benchmark ASCII 1:1 but also ASCII 1:1 with deletion. Results of the benchmark comparing tip (47b0c076e17d which includes my latest optimization on deletion) and 6a347c0ffbfc + translate_cached_2.patch. Common platform: Python unicode implementation: PEP 393 CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform: Linux-3.12.8-300.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Bits: int=32, long=64, long long=64, size_t=64, void*=64 CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Timer: time.perf_counter Timer precision: 45 ns Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Platform of campaign remove: SCM: hg revision=47b0c076e17d tag=tip branch=default date=2014-04-05 14:27 +0200 Python version: 3.5.0a0 (default:47b0c076e17d, Apr 5 2014, 14:50:53) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-04-05 14:51:55 Platform of campaign cache: SCM: hg revision=6a347c0ffbfc+ branch=default date=2014-04-05 11:56 +0200 Python version: 3.5.0a0 (default:6a347c0ffbfc+, Apr 5 2014, 14:53:02) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-04-05 14:53:12 ---+-+ Tests | remove | cache ---+-+ replace none, length=10| 184 ns (*) | 275 ns (+50%) replace none, length=10**3 | 1.06 us (*) | 1.1 us replace none, length=10**6 | 827 us (*) | 792 us replace 10%, length=10 | 207 ns (*) | 298 ns (+44%) replace 10%, length=10**3 | 1.08 us (*) | 1.12 us replace 10%, length=10**6 | 828 us (*) | 793 us replace 50%, length=10 | 205 ns (*) | 298 ns (+46%) replace 50%, length=10**3 | 1.08 us (*) | 1.17 us (+7%) replace 50%, length=10**6 | 827 us (*) | 793 us replace 90%, length=10 | 208 ns (*) | 298 ns (+44%) replace 90%, length=10**3 | 1.09 us (*) | 1.13 us replace 90%, length=10**6 | 850 us (*) |793 us (-7%) replace all, length=10 | 145 ns (*) | 226 ns (+56%) replace all, length=10**3 | 1.03 us (*) | 1.04 us replace all, length=10**6 | 827 us (*) | 792 us remove none, length=10 | 184 ns (*) | 274 ns (+49%) remove none, length=10**3 | 1.07 us (*) | 1.09 us remove none, length=10**6 | 836 us (*) |793 us (-5%) remove 10%, length=10 | 223 ns (*) | 408 ns (+83%) remove 10%, length=10**3 | 1.45 us (*) | 9.13 us (+531%) remove 10%, length=10**6 | 1.08 ms (*) | 8.73 ms (+706%) remove 50%, length=10 | 221 ns (*) | 407 ns (+84%) remove 50%, length=10**3 | 1.23 us (*) | 8.28 us (+575%) remove 50%, length=10**6 | 948 us (*) | 7.9 ms (+734%) remove 90%, length=10 | 230 ns (*) | 375 ns (+63%) remove 90%, length=10**3 | 1.57 us (*) | 3.86 us (+145%) remove 90%, length=10**6 | 1.28 ms (*) | 3.49 ms (+173%) remove all, length=10 | 139 ns (*) | 266 ns (+92%) remove all, length=10**3 | 1.24 us (*) | 2.46 us (+99%) remove all, length=10**6 | 1.07 ms (*) | 2.13 ms (+100%) ---+-+ Total | 9.38 ms (*) | 27 ms (+188%) ---+-+ You patch is always slower for the common case (ASCII = ASCII translation). I implemented the most obvious optimization for the most common case (ASCII 1:1 and ASCII 1:1 with deletion). I consider that the current code is enough to close this issue. @Josh Rosenberg: Thanks for the report. The current implementation should be almost as fast as bytes.translate() (the 60x factor you mentionned in the title) for ASCII 1:1 mapping. -- Serhiy: If you are interested to optimize str.translate() for the general case (larger charset), please open a new issue. It will probably require more complex cache. You may take a look at charmap codec which has such more complex cache (cache with 3 levels), see my message msg215301. IMO it's not interesting to invest time on optimizing str.translate(), it's not a common function. It took some years before an user run a benchmark on it :-) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21159] configparser.InterpolationMissingOptionError is not very intuitive
R. David Murray added the comment: Another problem with that error message is that it seems confusing as to where the bad value *reference* came from, given that rawval doesn't seem to include any interpolation point. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19546] configparser leaks implementation detail
R. David Murray added the comment: I've been thinking about this more, and I think I will revise my opinion. I haven't been able to think of a place where knowing that the key is missing in self._sections would in fact be helpful to a programmer using the module. So I'm OK with this being an example of a place where the new error fully encapsulates the information from the context and therefore the context can be suppressed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21111] PyLong_AsUnsignedLongAndOverflow does not exist
Hristo Venev added the comment: Please apply in 3.4.1. I need this ASAP. -- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file34738/a ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Roundup Robot added the comment: New changeset e56c71c6b45e by Victor Stinner in branch 'default': Issue #21118: str.translate() now raises a ValueError, not a TypeError, if the http://hg.python.org/cpython/rev/e56c71c6b45e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21111] PyLong_AsUnsignedLongAndOverflow does not exist
STINNER Victor added the comment: Please apply in 3.4.1. I need this ASAP. New functions are new features, and new features are no more added after a release (ex: 3.4.0). If something is changed, it will done in Python 3.5. You can add PyLong_AsUnsigned*AndOverflow() functions to your project so you will support older versions too, like Python 3.3. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18478] Class bodies: when does a name become local?
Nitika Agarwal added the comment: Hi, I have attached the patch for the issue.Please someone review my patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4744] asynchat documentation needs to be more precise
Nitika Agarwal added the comment: Hi, I hvae attached the patch for review.I am waiting for reviewal.Please review the attached patch as soon as possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4744 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Nitika Agarwal added the comment: @Ezio Melotti Please see if this is what you wanted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Serhiy Storchaka added the comment: субота, 05-кві-2014 12:49:22 ви написали: STINNER Victor added the comment: Serhiy wrote: fast_translate.patch works only with ASCII input string and ASCII 1:1 mapping. Is this actually typical case? I just checked the Python stdlib: as expected, all usages of str.translate() except of email.quoprimime use ASCII 1:1. Because str.translate() is much slower than a series of str.replace() (which already is optimized), some usages of str.translate() was rewritten to use str.replace(). See for example html.escape(). This is about what this issue. My optimization is only used if the input string is ASCII, but I expect that most strings are just ASCI. In most (if not all) these cases input string can be non-ASCII. bench_translate.py: benchmark ASCII 1:1 but also ASCII 1:1 with deletion. Could you please provide bench_translate.py? It will probably require more complex cache. You may take a look at charmap codec which has such more complex cache (cache with 3 levels), see my message msg215301. I were going to do this on next step. Full cache can grow up to 1114112 characters, so I planned to cache only BMP characters (cache with 2 levels). You commit too fast, I am late for you. ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Serhiy Storchaka added the comment: Do you plan to backport bug fixes to 3.3 and 2.7? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Nick, it shouldn't be hard to drop to 3.3, but I'm curious why would the 3.4 requirement break Fedora, or anything for that matter? Does Fedora regenerate the C implementation of the AST for some reason on every build? AFAIU, building Python from source with make should not do that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21111] PyLong_AsUnsignedLongAndOverflow does not exist
Hristo Venev added the comment: Will you release 3.5 in the next few weeks? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Nick Coghlan added the comment: It won't break the build, but requiring 3.4 to be installed (rather than 3.3) makes it more annoying for me (and other Fedora users) to work on the compiler before F21 is released :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Larry Hastings added the comment: I was told to keep Argument Clinic compatible with 3.3. I think it's a good idea for the tools to not require absolutely current Python. Would it be a big deal to support 3.3? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Nitika Agarwal added the comment: Hi, I have attached the patch.Please review the patch attached. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError
Nitika Agarwal added the comment: Hi, Please review the patch attached. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21111] PyLong_AsUnsignedLongAndOverflow does not exist
Benjamin Peterson added the comment: No -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit
New submission from Ivan K: Here is a code. https://gist.github.com/anonymous/9994217 When I run it in freeze and never end. If I run it without pool with loop or joblib - it works fine. Also there is a question on stackoverflow: http://stackoverflow.com/q/22881850/1888017 Python 2.7.6/2.7.3, cpu core i7 if it's important -- components: Library (Lib) messages: 215620 nosy: Ivan.K priority: normal severity: normal status: open title: code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19546] configparser leaks implementation detail
Łukasz Langa added the comment: FWIW I agree with Claudiu that the internal exceptions are an implementation detail. If we ever made, say, a SQLite-based or memcache-based configparser, those would be different, but the external API would stay the same. Will fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21159] configparser.InterpolationMissingOptionError is not very intuitive
Łukasz Langa added the comment: Those exception messages are really old. I agree we should fix them, we have to think about possible compatibility breakage though. I'll look into it. -- assignee: - lukasz.langa nosy: +lukasz.langa stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit
Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10769] ast: provide more useful range information
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Changes by Kay straitsai...@gmail.com: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Terry J. Reedy added the comment: I think 'Builtin-in Types' should probably be 'Built-in Classes' as there is no longer any difference between types and classes. Note that after the unification, we added 'issubclass', not 'issubtype'. type should at least be listed under types/classes. The one-parameter introspection use returns an existing instance of type rather than a new instance. In this, it is similar to bool, which returns an existing rather than new bool instance, and which is also used for introspection. I think both should be listed as classes, which they are, and then the intro to Introspection should mention that bool(ob) and type(ob) both return information about ob by returning existing instances of bool and type respectively. I thought about whether we should merely add a categorized index or also re-arrange the entire page. It it the possibly of adding section paragraphs, including cross-references like the above, that pushes me in the latter direction. The math section intro could mention that functions of collections of numbers are in the Iterables section section. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18478] Class bodies: when does a name become local?
Terry J. Reedy added the comment: After seeing my suggestion applied, I decided I don't like it. Sorry. A 'function code block' is a 'function suite'. A deeper problem is that the revision now omits the rules for classes. The base problem is that I don't know what the rules are when classes and functions are nested within each other (does anybody, without reading the code?). A puzzling example was posted on python-list yesterday, which I will try to find. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Georg Brandl added the comment: Your failure appears to be not pasted from an interpreter session; the actual failure is: (Pdb) all(x limit for x in items) *** NameError: global name 'limit' is not defined (i.e. limit is not found, not items). This actually does not work in Python 2 either. What did work in Python 2 and doesn't work in 3, is using a list comprehension like all([x limit for x in items]) This is because list comprehensions are now implemented with their own function object like generator expressions have always been. To make the code in pdb compile as if it was put in the debugged function will be as good as impossible, so I'm closing this as won't fix. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Well, that seems complicated: you can't overwrite a io.FileIO().name attribute, and doing so would be nonsensical for tarfile, which would try to perform IO operations on a random file descriptor... Also, I can't think of any case where a .name attribute could actually be bytes (I was just mirroring the code in msg214670). Here's a patch that tries all combinations of encoding for writing, but I can't see a way to enforce manually the name attribute being an int, even for this test purposes. -- Added file: http://bugs.python.org/file34739/test_tarfile_all_modes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj
Antoine Pietri added the comment: Actually, thinking about it, it seems safer to use os.open() + os.fdopen() than TemporaryFile(), like in the equivalent test for 'gzip'. This new patch replaces last one. -- nosy: +seirl Added file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj
Changes by Ezio Melotti ezio.melo...@gmail.com: -- Removed message: http://bugs.python.org/msg215627 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader
Eric Snow added the comment: source_to_code() seems like a good fit on InspectLoader to me. Is there something in particular that motivated the idea of moving it up to Loader? -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Eric Snow added the comment: Sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj
Changes by Ezio Melotti ezio.melo...@gmail.com: Removed file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Changes by Ezio Melotti ezio.melo...@gmail.com: Added file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Raymond Hettinger added the comment: FWIW, I don't think we should separate built-in types from built-in functions. Tools like str(x) and int(x) are frequently used as if there were functions. Tools like iter(x) and open(x) could be viewed as constructors. Tools like type(x) are both a function (the one-variable form) and a class constructor (the three variable form). For the most part, I don't think the distinction is meaningful or helpful. As a reference point, authors of Python books have avoided making a distinction and have favored the alphabetical ordering we have now (which has the virtue of making functions easy to find). If you feel a need to provide groups of related functions, please do so in an addenda to the core function reference. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- versions: -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader
Brett Cannon added the comment:
The inspiration was that I realized there was no technical reason to have it on
InspectLoader. Past that there was my thinking of trying to come up with a
source_to_module() method on importlib.abc.Loader which would do the right
thing with create_module() and init_module_attrs() such that replicating
imp.load_module() would be something like::
loader = importlib.machinery.SourceLoader # or something
with open('file.py') as file:
module = loader.source_to_module(file.read(), location='file.py')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21156
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
eryksun added the comment:
you can't overwrite a io.FileIO().name attribute
A FileIO instance uses a dict for 'name' (msg214670):
vars(sys.stdin.buffer.raw)
{'name': 'stdin'}
f = tempfile.TemporaryFile()
vars(f.raw)
{'name': 3}
The name is optional meta-information. If it gets deleted, the repr falls back
on using the file descriptor:
f.raw
_io.FileIO name=3 mode='rb+'
del f.raw.name
f.raw
_io.FileIO fd=3 mode='rb+'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21044
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio Task Possibly Incorrectly Garbage Collected
New submission from Richard Kiss: Some tasks created via asyncio are vanishing because there is no reference to their resultant futures. This behaviour does not occur in Python 3.3.3 with asyncio-0.4.1. Also, doing a gc.collect() immediately after creating the tasks seems to fix the problem. Attachment also available at https://gist.github.com/richardkiss/9988156 -- components: Library (Lib) files: asyncio-gc-issue.py hgrepos: 231 messages: 215633 nosy: richard.kiss priority: normal severity: normal status: open title: asyncio Task Possibly Incorrectly Garbage Collected type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34741/asyncio-gc-issue.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio Task Possibly Incorrectly Garbage Collected
Changes by Richard Kiss h...@richardkiss.com: -- hgrepos: -231 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Changes by Richard Kiss h...@richardkiss.com: -- title: asyncio Task Possibly Incorrectly Garbage Collected - asyncio task possibly incorrectly garbage collected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Ezio Melotti added the comment: Tools like str(x) and int(x) are frequently used as if there were functions. The description of each object already mentions the function/type duality, and links to https://docs.python.org/3/library/stdtypes.html. If they are grouped together, a paragraph like the objects in this section can be used both as constructors or as functions can be added at the beginning of the section Similarly a paragraph pointing to itertools can be used in the section that describes map/zip/filter/all/any/etc. For the most part, I don't think the distinction is meaningful or helpful. There are two distinctions I want to make: 1) grouping the built-in types; 2) grouping related functions; 1 should be especially useful to people that are new to the language. Here they can know quickly what are the Python equivalents of the objects they use in other languages (e.g. a structure similar to a C char*, or a JS object, or a PHP array...) and discover objects that might not exist in their language (e.g. sets, bytes, memoryviews). 2 is useful to find related functions. For example, if I'm looking at map(), I might be interested at zip() and filter() too, or if I'm looking at getattr(), having hasattr(), setattr() and delattr() nearby will make it easy to discover them and consult their docs. As a reference point, authors of Python books have avoided making a distinction and have favored the alphabetical ordering we have now (which has the virtue of making functions easy to find). The table at the beginning and ctrl+f makes the alphabetic order almost useless, so more meaningful orderings can be used instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Updated patch attached: 1. Python 3.3+ supported (I suspect 3.2 will work too) 2. Incorporated Serhiy's suggestions (thanks for the review!) -- Added file: http://bugs.python.org/file34742/new-asdl-parser.issue19655.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Raymond Hettinger added the comment: This include two main groups that should be separated in two different sections: built-in types and functions. I forgot to mention that the docs have already been organized to cover the two groups. Section 3.2 has the built-in functions and Section 3.4 has the built-in types. Where they overlap (str and list, for example), section section addresses their use as a function (i.e. list(iterable) acts like a function that loops over an iterable to create a list, and str(x) like a function to lookup the string representation of an object). The current organization has been somewhat successful and I don't want to damage it by regrouping. This will make it easier to find similar functions, This isn't the primary role of a library reference. That said, I would not object to either 1) an extra section that shows a high level grouping of functions or 2) adding to each function a list of see also links (the Microsoft Excel documentation takes that approach). and will allow us to factor out some documentation that is repeated[0]. This should not be done either. For example, we really to want min() and max() to be completely documented in isolation from one another (this is a reference document, repeating definitions as dictionaries do is proper). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Changes by Brett Cannon br...@python.org: -- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader
Eric Snow added the comment: Now that I've thought about it a little more, I'm more open to the idea. Source is definitely a universal concept in Python, as is code. So source_to_code() makes some sense on a most-base type like Loader. On the other hand, source isn't necessarily associated with all loaders. I guess my initial gut reaction was that it seemed out of place API-wise. On InspectLoader it's presence is tied to get_code(), so it makes more sense. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Guido van Rossum added the comment: Ouch. That example is very obfuscated -- I fail to understand what it is trying to accomplish. Running it I see that it always prints 100 for the count with 3.3 or DO_CG on; for me it prints 87 with 3.4 an DO_GC off. But I wouldn't be surprised if the reason calling do.collect() fixes whatever issue you have is that it causes there not to be any further collections until the next cycle through that main loop, and everything simply runs before being collected. But that's just a theory based on minimal understanding of the example. I'm not sure that tasks are *supposed* to stay alive when there are no references to them. It seems that once they make it past a certain point they keep themselves alive. One more thing: using a try/except I see that the lost consumers all get a GeneratorExit on their first iteration. You might want to look into this. (Sorry, gotta run, wanted to dump this.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: ezio.melotti - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Richard Kiss added the comment: I agree it's confusing and I apologize for that. Background: This multiplexing pattern is used in pycoinnet, a bitcoin client I'm developing at https://github.com/richardkiss/pycoinnet. The BitcoinPeerProtocol class multiplexes protocol messages into multiple asyncio.Queue objects so each interested listener can react. An example listener is in pycoinnet.helpers.standards.install_pong_manager, which looks for ping messages and sends pong responses. When the peer disconnects, the pong manager sees a None (to indicate EOF), and it exits. The return value is uninteresting, so no reference to the Task is kept. My client is in late alpha, and mostly works, but when I tried it on Python 3.4.0, it stopped working and I narrowed it down to this. I'm not certain this behaviour is incorrect, but it's definitely different from 3.3.3, and it seems odd that a GC cycle BEFORE additional references can be made would allow it to work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Guido van Rossum added the comment: Most likely your program is simply relying on undefined behavior and the right way to fix it is to keep strong references to all tasks until they self-destruct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Raymond Hettinger added the comment: Nikita, your additional dispatch table looks like a reasonable addition. I'll wait on additional commentary before pushing it forward 1 should be especially useful to people that are new to the language Ezio, please take care not to conflate the role of reference material (where people lookup what a function does) and tutorials (which introduce, synthesize, and organize). Also take consider that the proposed groupings have some downsides as well (for example str and repr don't appear in the same grouping, likewise, int and round aren't in the same grouping). And, I *really* don't want to separate-out types (that is what section 3.4 is for). You're fighting a long-standing decision to use 3.2 to talk about the tools as functions and again in 3.4 as types. For example, it is not helpful at all to classify range() as a type. Its usage is better grouped with looping idioms like range, zip, enumerate, sorted, and reversed. A possible solution is to list words in more than one category so that int() would be listed as a type conversion (so it wouldn't get separated from str(), and listed math related (so it won't be separated from round() which is another way to convert a float to an integer). This documentation page has proven useful in its current form to a great many users. We should take care not to muck-up one of the better pages in the docs. In particular, we REALLY don't want to factor-out redundant text -- as reference material, each function's description needs to stand-alone. This is not a page that people typically read start to finish in a book like form -- it is much closer to a dictionary or encyclopedia where topics are looked up directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Richard Kiss added the comment: I'll investigate further. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Terry J. Reedy added the comment: I would be happy enough to just add a second index section, with short annotations or commentaries about the categories -- nitika's patch with sentences added. I would put it after the current table, and not box the links. Short example: The following functions convert an integer to a binary, octal, or hexadecimal string: :func:`bin`, :func:`oct`, :func:`hex`. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Raymond Hettinger added the comment: Terry, I concur. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
Ned Deily added the comment:
test_default_ecdh_curve is failing on current OS X systems (10.9 Mavericks and
10.8 Mountain Lion, at least) using the system-supplied OpenSSL libraries:
==
ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests)
--
Traceback (most recent call last):
File /py/3x/unix/source/Lib/test/test_ssl.py, line 2596, in
test_default_ecdh_curve
context.set_ciphers(ECDH)
ssl.SSLError: ('No cipher can be selected.',)
--
The OpenSSL command advertise itself as 0.9.8y but it doesn't include any ECDH
ciphers. It appears from the OpenSSL source that it's possible to specify at
build configure time which ciphers are included so I guess the version test in
_ssl.c for ECDH isn't sufficient.
$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.9.2
BuildVersion: 13C64
$ /usr/bin/openssl version
OpenSSL 0.9.8y 5 Feb 2013
$ /usr/bin/openssl ciphers -v 'ALL:eNULL'
ADH-SEED-SHASSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1
DHE-RSA-SEED-SHASSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
SEED-SHASSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
ADH-DES-CBC3-SHASSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1
ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1
EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export
EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
DES-CBC3-MD5SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5
DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
--
nosy: +ned.deily
resolution: fixed -
stage: committed/rejected - needs patch
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21015
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Richard Kiss added the comment: You were right: adding a strong reference to each Task seems to have solved the original problem in pycoinnet. I see that the reference to the global lists of asyncio.tasks is a weakset, so it's necessary to keep a strong reference myself. This does seem a little surprising. It can make it trickier to create a task that is only important in its side effect. Compare to threaded programming: unreferenced threads are never collected. For example: f = asyncio.Task(some_coroutine()) f.add_callback(some_completion_callback) f = None In theory, the some_coroutine task can be collected, preventing some_completion_callback from ever being called. While technically correct, it does seem surprising. (I couldn't get this to work in a simple example, although I did get it to work in a complicated example.) Some change between 3.3 and 3.4 means garbage collection is much more aggressive at collecting up unreferenced tasks, which means broken code, like mine, that worked in 3.3 fails in 3.4. This may trip up other early adopters of tulip. Maybe adding a do_not_collect=True flag to asyncio.async or asyncio.Task, which would keep a strong reference by throwing it into a singleton set (removing it as a future callback) would bring attention to this subtle issue. Or displaying a warning in debug mode when a Task is garbage-collected before finishing. Thanks for your help. -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21163] asyncio task possibly incorrectly garbage collected
Guido van Rossum added the comment: Thanks for understanding. It's definitely subtle: there is also some code in asyncio that logs an error when a Future holding an exception becomes unreachable before anyone has asked for it; this has been a valuable debugging tool, and it depends on *not* holding references to Futures. Regarding the difference between Python 3.3 and 3.4, I don't know the exact reason, but GC definitely gets more precise with each new revision, and there are also some differences in how exactly the debug feature I just mentioned is implemented (look for _tb_logger in asyncio/futures.py). OTOH it does seem a little odd to just GC a coroutine that hasn't exited yet, and I'm not 100% convinced there *isn't* a bug here. The more I think about it, the more I think that it's suspicious that it's always the *first* iteration that gets GC'ed. So I'd like to keep this open as a reminder. Finally, I'm not sure the analogy with threads holds -- a thread manages OS resources that really do have to be destroyed explicitly, but that's not so for tasks, and any cleanup you do need can be handled using try/finally. (In general drawing analogies between threads and asyncio tasks/coroutines is probably one of the less fruitful lines of thinking about the latter; there are more differences than similarities.) -- resolution: invalid - remind ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Raymond Hettinger added the comment: Would allow for the name attribute to be optional ... with the idea that sometime in the future we can deprecate pulling attributes from a module directly Is there any chance that this would ever happen? The __name__ attribute has been around almost forever is widely relied on. Deprecating it would be a very disruptive event for nearly zero benefit. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Eric Snow added the comment: I made roughly the same point in the current import-sig thread that relates here: https://mail.python.org/pipermail/import-sig/2014-April/000805.html Basically, I agree we should be careful with both __name__ and __file__. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
