[issue24129] Incorrect (misleading) statement in the execution model documentation
levkivskyi added the comment: Eric, the rule that classes don't play the nested scopes game is explained at beginning of the same section, but the explanation is one sided it only explains that names defined in classes are not visible inside functions. Nick, thank you for the thorough explanation. I will try to improve the wording. It looks like a bit more substantial changes are needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: OK, let's go with cr_* prefix for coroutine type's slots. Nick, there is one more thing I'd be glad to receive your input on. Currently, inspect.iscoroutine(o) uses isinstance(o, abc.Coroutine) to do the check. Ben and Stefan reasonably ask to refactor isgenerator() to use abc.Generator. However, after giving this some thought, I think that inspect.iscoroutine() should actually use isinstance(types.CoroutineType). Lots of existing code assumes, that if isgenerator() returns True, then the object has gi_code etc, so the function returns True when the passed object is a pure Python generator. Same logic should work for iscoroutine(), right? isawaitable(), however, should continue using abc.Awaitable, since it only checks for __await__ presence on the type (or should we just drop it?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14911] generator.throw() documentation inaccurate
Martin Panter added the comment: See Issue 13213 for some analysis of the behaviour of different combinations of arguments. The docstring should be changed if necessary, but in this case I don’t see what needs changing. The argument names perhaps, just for consistency’s sake? -- nosy: +vadmium versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot
New submission from STINNER Victor: It looks like buildbot slave crashs since: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/23 or http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/22 Changes: changeset a1b76c1c3be8409565af71b02b84685233276120 == FAIL: test_env_var_debug (test.test_asyncio.test_base_events.BaseEventLoopTests) -- Traceback (most recent call last): File B:\buildarea\3.x.ware-win81-release\build\lib\test\test_asyncio\test_base_events.py, line 680, in test_env_var_debug PYTHONASYNCIODEBUG='') File B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py, line 135, in assert_python_ok return _assert_python(True, *args, **env_vars) File B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py, line 121, in _assert_python err)) AssertionError: Process return code is 3221225477 command line: ['B:\\buildarea\\3.x.ware-win81-release\\build\\PCbuild\\amd64\\python.exe', '-X', 'faulthandler', '-c', 'import asyncio\nloop = asyncio.get_event_loop()\nprint(loop.get_debug())'] stdout: --- --- stderr: --- Fatal Python error: Segmentation fault Current thread 0x0390 (most recent call first): File B:\buildarea\3.x.ware-win81-release\build\lib\functools.py, line 423 in decorating_function File B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py, line 1963 in IPv6Address File B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py, line 1869 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File B:\buildarea\3.x.ware-win81-release\build\lib\ssl.py, line 90 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\sslproto.py, line 5 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap, line 1016 in _handle_fromlist File B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\proactor_events.py, line 16 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap, line 1016 in _handle_fromlist File B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\windows_events.py, line 13 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\__init__.py, line 46 in module File frozen importlib._bootstrap, line 222 in _call_with_frames_removed File frozen importlib._bootstrap_external, line 661 in exec_module File frozen importlib._bootstrap, line 673 in _load_unlocked File frozen importlib._bootstrap, line 958 in _find_and_load_unlocked File frozen importlib._bootstrap, line 969 in _find_and_load File string, line 1 in module --- -- components: Windows, asyncio messages: 245551 nosy: gvanrossum, haypo, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24478 ___ ___
[issue24474] Accidental exception chaining in inspect.Signature.bind()
Nick Coghlan added the comment: The sentinel form of next() is nice when there's a natural sentinel value, but needing to *create* a sentinel is generally a sign that the out-of-band exception is a better fit. The function could likely do with some refactoring (e.g. breaking out some helper functions to make the logic easier to follow), but shifting from idiomatic code to non-idiomatic code isn't a good way of tackling that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24474 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21279] str.translate documentation incomplete
Martin Panter added the comment: Patch v6 looks okay, so I think it is ready to commit. -- stage: patch review - commit review versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24129] Incorrect (misleading) statement in the execution model documentation
Nick Coghlan added the comment: The normal rules for name resolution reference here is referring to the name lookup rules as they existed prior to the introduction of lexical scoping for functions. It's a dated way of describing it, as the current behaviour of functions has now been around long enough that a lot of folks will consider *that* normal, and the module, class and exec scoping rules to be the unusual case (as levkivskyi has here). However, I've spent far too many hours staring at CPython compiler internals to be able to suggest a helpful rewording that will make sense to folks that *haven't* done that, so I'll instead provide the relevant background info to see if others can come up with a concise rewording of the reference docs :) Prior to Python 2.1, Python didn't have closure support, and hence nested functions and classes couldn't see variables in outer scopes at all - they could see their local scope, the module globals, and the builtins. That changed with the introduction of nested scopes as a __future__ import in Python 2.1 and the default behaviour in 2.2: https://www.python.org/dev/peps/pep-0227/ As a result of that change, the compiler now keeps track of function locals at compile time, and *emits different code for references to them*. Where early versions of CPython only had LOAD_NAME and LOAD_GLOBAL in the bytecode, these days we now also have LOAD_FAST (function local), LOAD_CLOSURE (function local referenced as a nonlocal), LOAD_DEREF (function nonlocal) and LOAD_CLASSDEREF (class nonlocal). The latter four opcodes will *only* be emitted in a function body - they'll never be emitted for module level code (include the bodies of module level class definitions). If you attempt to reference a function local before a value has been assigned, you'll get UnboundLocalError rather than NameError. The name lookup rules used for execution of class bodies are thus the same ones used for the exec() builtin with two namespace arguments: there is a local namespace where name assignments happen, and name lookups check the local, global and builtin namespaces in that order. The code is executed line by line, so if a name is referenced before it has been assigned locally, then it may find a global or builtin of that name. Classes that are defined inside a function may refer to lexically scoped local variables from the class body, but class variables are not themselves visible to function definitions nested inside a class scope (i.e. method definitions). These rules are also used for module level execution and exec() with a single namespace argument, except that the local namespace and the global namespace refer to the same namespace. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20387] tokenize/untokenize roundtrip fails with tabs
Dingyuan Wang added the comment:
Sorry for the inconvenience. I failed to find this old bug.
I think there is another problem. The docs of `untokenize` said The iterable
must return sequences with **at least** two elements, the token type and the
token string. Any additional sequence elements are ignored., so if I feed in,
say, a 3-tuple, the untokenize should accept it as tok[:2].
The attached patch should have addressed the problems above.
When trying to make a patch, a tokenize bug was found. Consider the new
attached tab.py, the tabs between comments and code, and the tabs between
expressions are lost, so when untokenizing, position information is used to
produce equivalent spaces, instead of tabs.
Despite the tokenization problem, the patch can produce syntactically correct
code as accurately as it can.
The PEP 8 recommends spaces for indentation, but the usage of tabs should not
be ignored.
new tab.py (in Python string):
'#!/usr/bin/env python\n# -*- coding: utf-8 -*-\n\ndef foo():\n\t\n\tTests
tabs in tokenization\n\t\tfoo\n\t\n\tpass\n\tpass\n\tif 1:\n\t\t# not indent
correctly\n\t\tpass\n\t\t# correct\ttab\n\t\tpass\n\tpass\n\tbaaz =
{\'a\ttab\':\t1,\n\t\t\t\'b\': 2}\t\t# also fails\n\npass\n#if
2:\n\t#pass\n#pass\n'
--
keywords: +patch
nosy: +gumblex
Added file: http://bugs.python.org/file39748/tokenize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20387
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: My view is that the gi_* prefixed attributes are the ducktyped representation of whether an object is a generator-iterator or a coroutine. With the change, it means hasattr(obj, 'cr_running') is to hasattr(obj, 'gi_running') as isinstance(obj, collections.abc.Coroutine) is to isinstance(obj, collections.abc.Generator). The main lesson I personally learned from our experience with PEP 342 is that generator-as-iterator and generator-as-coroutine are fundamentally different concepts, and that having them *look* similar on the surface turned out to be inherently confusing. I see PEP 492 as the natural consequence of that perspective: from an eval loop perspective, native coroutines and generators-as-coroutines remain essentially interchangeable, but on the surface, they'll now look *completely* different. That allows folks to learn them as two distinct concepts (generator-iterator and coroutine), and defer (perhaps indefinitely) the realisation that they share a common underlying foundation. Originally we were happy to let that distinction be purely syntactic, and still let the underlying implementation details leak through in the object model. This issue helped highlight that that approach was likely to prove to be a recipe for hard to debug problems as we tried to figure out where we were dealing with generator-iterator objects, native coroutine objects and generator-as-coroutine objects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24129] Incorrect (misleading) statement in the execution model documentation
Armin Rigo added the comment: Related to http://bugs.python.org/issue19979 and others mentioned there. -- nosy: +arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13213] generator.throw() behavior
Changes by Martin Panter vadmium...@gmail.com: -- resolution: - duplicate stage: - resolved status: open - closed superseder: - generator.throw() documentation inaccurate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24474] Accidental exception chaining in inspect.Signature.bind()
Yury Selivanov added the comment: This isn't a bug, as raise exc from None only hides *display* of the context, it doesn't lose the record of the context entirely. Agree. My patch, though, is still valid. I think removing try..except blocks actually simplifies the code, and removes the need of using 'raise .. from None' completely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24474 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: Based on that last comment, I realised there's something else @types.coroutine should now do: delegate both the existing gi_* attributes *and* the new cr_* attributes to the underlying generator. That should allow all of the poking around in code object flags to be encapsulated entirely in the types module, as the 3 kinds of object would subsequently be distinguishable by their attributes: gi_running: generator-iterator or generator-as-coroutine cr_running: native coroutine or generator-as-coroutine both: generator-as-coroutine -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24479] Support LMMS project files in mimetypes.guess_type
New submission from Andreas Nilsson: There is no support for recognizing LMMS project files (.mmpz / .mmp). Could this be added for strict=False? -- components: Library (Lib) messages: 245556 nosy: Andreas Nilsson priority: normal severity: normal status: open title: Support LMMS project files in mimetypes.guess_type type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24479 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: I believe the key issue of concern for Cython is being able to emulate the native CPython types in a way that things like asyncio just work, rather than specifically needing to have inspect report them as native generators and coroutines. As such, having inspect.isgenerator() and inspect.iscoroutine() be consistent in checking specifically for the *native* types makes sense to me, but it should be made clear that they're stricter checks than isinstance(obj, collections.abc.Generator) and isinstance(obj, collections.abc.Coroutine). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19979] Missing nested scope vars in class scope (bis)
Nick Coghlan added the comment: With the fact that the existence of Python without closures predates Python 2.2, this now reads like a straight up compiler bug to me. Compare the behaviour with no local assignment in the class body: def f(): ... n = 1 ... class C: ... print(n) ... f() 1 To the behaviour once the local is assigned: def f(): ... n = 1 ... class C: ... n = n ... print(n) ... f() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in f File stdin, line 4, in C NameError: name 'n' is not defined The issue is that the latter will still emit a LOAD_NAME/STORE_NAME pair, while the former emits LOAD_CLASSDEREF (and has emitted LOAD_DEREF for as long as I can recall hacking on the compiler). Off the top of my head, I'm not sure our current symbol table analysis pass can actually cope with this idea though - it would require separating just a class body local, which may or may not first be retrieved as a global or builtin from a class body local which is first retrieved from a closure reference. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10482] subprocess and deadlock avoidance
Martin Panter added the comment: Related: Issue 1260171, essentially proposing streaming readers and writers for communicate() instead of fixed buffers, but without using OS threads. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10482 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20344] subprocess.check_output() docs misrepresent what shell=True does
Martin Panter added the comment: I think it might be better to leave the platform-specific details in the full Popen description, not under Frequently Used Arguments. I suggest to use 20344_4.patch: * Move existing pointer to Popen constructor details up to top of section * Explain the escaping and quoting of a sequence only applies to Windows * Remove claim that a string simply names a program without arguments; appears to be only half true under Windows * Clarify shell=True command is normally a string, not a sequence * Drop new description of Unix shell argument sequence in favour of existing description under Popen * Move warning about Windows shell argument sequence under Popen -- stage: needs patch - patch review versions: +Python 3.5, Python 3.6 -Python 3.3 Added file: http://bugs.python.org/file39747/20344_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20344 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24370] OrderedDict behavior is unclear with misbehaving keys.
Raymond Hettinger added the comment: I would expect the behavior to be undefined (though non-crashing). That is all you should expect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24370 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24474] Accidental exception chaining in inspect.Signature.bind()
Nick Coghlan added the comment: This isn't a bug, as raise exc from None only hides *display* of the context, it doesn't lose the record of the context entirely. This means Walter's display code is incorrect, as it isn't checking for __suppress_context__: import inspect try: ... inspect.signature(lambda x:None).bind() ... except Exception as e: ... exc = e ... exc.__suppress_context__ True Interestingly, neither PEP 409 *nor* PEP 415 capture the rationale for that design: retaining the full context data even when it's hidden by the default exception display routines means that you can still debug code that uses raise X from None inappropriately. (I thought there was an open RFE to make it easy to force the traceback module to ignore __suppress_context__ but if there is one, I can't find it) -- resolution: - not a bug stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24474 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20387] tokenize/untokenize roundtrip fails with tabs
Jason R. Coombs added the comment: @gumblex: This is a good start. It certainly provides a candidate implementation. First, can I suggest that you remove the changes pertinent to the at least two elements and address that in a separate ticket/discussion? Second, any patch will necessarily need to include a test that fails before the patch and passes after the test. Third, and least important, the proposed implementation adds a lot of branching and cognitive complexity to an already complicated function. I'd like to work on the implementation to see if we can make it easier to comprehend. That said, practicality beats purity, so if it passes the test, then it's surely acceptable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20387 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot
Steve Dower added the comment: Presumably it's from the C implementation of lru cache -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24306] Backport py.exe to 3.4
Steve Dower added the comment: Attached a patch to set the component IDs in the 3.4 installer to match the ones we're using for 3.5 and later. This should prevent downgrading of the launcher in future releases, though it's not strictly the right way to do this. (Nosied Martin in case he wants to weigh in on this.) (The right way is to have a separate MSI with a matching upgrade code, which is not feasible for 3.4.) Unfortunately, it won't help when 3.5 is installed per-user (the default), but there's nothing we can do there short of backporting the launcher changes, probably selectively to avoid the fixes for the VC10-14 change. (Nosied Larry to see if he wants to approve this.) -- keywords: +patch nosy: +larry, loewis Added file: http://bugs.python.org/file39750/24306_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24480] Python 2.7.10
New submission from Yunlong Liu: Hi, I detected an inconsistency in the Modules stack of Python 2.7.10. In Module/_ssl.c, I see all _ssl._SSLContext are changed to ssl.SSLContext but it is inconsistent with the lib file in Lib/ssl.py. In ssl.py, it is still importing _SSLContext, which doesn't exist in the C file. -- components: Library (Lib) messages: 245566 nosy: yliu120 priority: normal severity: normal status: open title: Python 2.7.10 type: crash versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24480 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24129] Incorrect (misleading) statement in the execution model documentation
Ivan Levkivskyi added the comment: Eric, I have submitted a new version of the patch. Could you please make a review? Nick, it will be interesting to hear your opinion too. I tried to follow such rules: 1. Explanation should be succinct yet clear 2. It should tell as less as possible about implementation details 3. Minimize necessary changes It turns out that these goals could be achieved by a) simply reshuffling and structuring the existing text to separate the exceptions (classes, etc.) from the general case; and b) adding some minor clarifications. Armin, thank you for the link. It looks like this is a really old discussion. PS: Unfortunately, the diff after reshuffling of the text looks big and cumbersome, in fact the changes are minimal. -- Added file: http://bugs.python.org/file39749/classdoc-v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot
Zachary Ware added the comment: Note that it's not necessarily that changeset; I think build 22 is around when the buildbot started actually doing non-debug builds (the buildmaster and buildslave scripts in Tools/buildbot had no support for a non-debug build before then). I'll try to run the tests a little further back soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4322] function with modified __name__ uses original name when there's an arg error
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4322 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24480] Python 2.7.10
Yunlong Liu added the comment: I have seen this has been corrected in the svn python chunk. But I doubt it is still there in the public download tar ball. Please make a change to the tar ball. Thanks -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24480 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24306] Backport py.exe to 3.4
Larry Hastings added the comment: Last installed wins isn't perfect, but at least it's predictable. Is it possible to make the 3.4 installer detect that 3.5+ is installed and not install the launcher? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24481] hotspot pack_string Heap Buffer Overflow
New submission from JohnLeitch:
The hotspot module suffer from a heap buffer overflow due to a memcpy in the
pack_string function at line 633:
static int
pack_string(ProfilerObject *self, const char *s, Py_ssize_t len)
{
if (len + PISIZE + self-index = BUFFERSIZE) {
if (flush_data(self) 0)
return -1;
}
assert(len INT_MAX);
if (pack_packed_int(self, (int)len) 0)
return -1;
memcpy(self-buffer + self-index, s, len);
self-index += len;
return 0;
}
The problem arises because const char *s is variable length, while
ProfilerObject.buffer is fixed-length:
typedef struct {
PyObject_HEAD
PyObject *filemap;
PyObject *logfilename;
Py_ssize_t index;
unsigned char buffer[BUFFERSIZE];
FILE *logfp;
int lineevents;
int linetimings;
int frametimings;
/* size_t filled; */
int active;
int next_fileno;
hs_time prev_timeofday;
} ProfilerObject;
An overflow can be triggered by passing a large string to the Profile.addinfo
method via the value parameter:
from hotshot.stats import *
x = hotshot.Profile(A, A)
x.addinfo(A, A * 0xfceb)
Which produces the following exception:
0:000 r
eax=0041 ebx=fceb ecx=3532 edx=0002 esi=075dcb35 edi=075d9000
eip=6c29af1c esp=0027fc78 ebp=0027fc80 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
MSVCR90!LeadUpVec+0x70:
6c29af1c f3a5rep movs dword ptr es:[edi],dword ptr [esi]
0:000 db edi-0x10
075d8ff0 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075d9000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
075d9060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??
0:000 db esi
075dcb35 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb45 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb55 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb65 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb75 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb85 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcb95 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
075dcba5 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41
0:000 !heap -p -a edi
address 075d9000 found in
_DPH_HEAP_ROOT @ 6ca1000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize -
VirtAddr VirtSize)
722809c: 75d67c8 2838 -
75d6000 4000
6c3194ec verifier!AVrfDebugPageHeapAllocate+0x023c
77a257b7 ntdll!RtlDebugAllocateHeap+0x003c
779c77ce ntdll!RtlpAllocateHeap+0x0004665a
77981134 ntdll!RtlAllocateHeap+0x014d
6c2c3db8 MSVCR90!malloc+0x0079
[f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163]
1e0ae6d1 python27!PyObject_Malloc+0x0161
[c:\build27\cpython\objects\obmalloc.c @ 968]
0:000 !heap -p -a esi
address 075dcb35 found in
_DPH_HEAP_ROOT @ 6ca1000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize -
VirtAddr VirtSize)
7228068: 75da300 fd00 -
75da00011000
6c3194ec verifier!AVrfDebugPageHeapAllocate+0x023c
77a257b7 ntdll!RtlDebugAllocateHeap+0x003c
779c77ce ntdll!RtlpAllocateHeap+0x0004665a
77981134 ntdll!RtlAllocateHeap+0x014d
6c2c3db8 MSVCR90!malloc+0x0079
[f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163]
1e0ae6d1 python27!PyObject_Malloc+0x0161
[c:\build27\cpython\objects\obmalloc.c @ 968]
0:000 k4
ChildEBP RetAddr
0027fc80 1e008380 MSVCR90!LeadUpVec+0x70
[f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289]
0027fc90 1e008407 python27!pack_string+0x40
[c:\build27\cpython\modules\_hotshot.c @ 634]
0027fca8 1e0089bb python27!pack_add_info+0x77
[c:\build27\cpython\modules\_hotshot.c @ 652]
0027fcc0 1e0aafd7 python27!profiler_addinfo+0x5b
[c:\build27\cpython\modules\_hotshot.c @ 1020]
0:000 .frame 1
01 0027fc90 1e008407 python27!pack_string+0x40
[c:\build27\cpython\modules\_hotshot.c @ 634]
0:000 dV
self = 0x075dcb35
s = 0x075da314 AAA[...]AA...
len = 0n123572224
0:000 dt self
Local var @ esi Type ProfilerObject*
+0x000 ob_refcnt: 0n1094795585
+0x004 ob_type : 0x41414141 _typeobject
+0x008 filemap
[issue24462] bytearray.find Buffer Over-read
JohnLeitch added the comment: Given my understanding of the issue, the memcmp approach seems like a viable fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24462 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: Nick, Martin, here's an updated patch with all your comments addressed. -- Added file: http://bugs.python.org/file39751/corotype.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ 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
Changes by Yury Selivanov yseliva...@gmail.com: -- dependencies: +Awaitable ABC incompatible with functools.singledispatch ___ 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
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: Latest version looks good to me - I'd suggest we merge this, and file any remaining problems as separate issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24468] Expose C level compiler flag constants to Python code
Nick Coghlan added the comment: Making _opcode a builtin module rather than an extension module makes more sense to me than adding more random stuff to the sys module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24468 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24325] Speedup types.coroutine()
Nick Coghlan added the comment: +1 from me for merging this for 3.5.0 and deferring issue 24468 (which now proposes making _opcode a builtin module to allow compiler constants to be easily shared between C code and Python code) to 3.6 instead. The design changes to address issue 24400 cleaned up various aspect of both the internal architecture and the public data model of PEP 492, and the latest draft of this patch benefits accordingly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24325 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15753] No-argument super in method with variable arguments raises SystemError
Martin Panter added the comment: The obvious workaround is to include an explicit “self” parameter (name shouldn’t matter): def f(arbitrary, *positional, **most_keywords): all_positional = (arbitrary,) + positional ... If you need to reserve all keyword parameter names, you could try the manual version of super(): class A: def f(*all_positional, **all_keywords): print(super(A, all_positional[0]).__repr__()) -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15753 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24325] Speedup types.coroutine()
Yury Selivanov added the comment: Larry, Nick, Looking at how issue24400 progresses, I think it would be really great if we can merge this one in 3.5.0. It also makes it unnecessary to merge issue24468 in 3.5. -- dependencies: +Awaitable ABC incompatible with functools.singledispatch Added file: http://bugs.python.org/file39754/types_coroutine_speedup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24325 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24481] hotshot pack_string Heap Buffer Overflow
Changes by Ned Deily n...@acm.org: -- nosy: +benjamin.peterson stage: - needs patch title: hotspot pack_string Heap Buffer Overflow - hotshot pack_string Heap Buffer Overflow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20387] tokenize/untokenize roundtrip fails with tabs
Jason R. Coombs added the comment:
I've committed the patch without the change for at least two elements as
https://bitbucket.org/jaraco/cpython-issue20387/commits/b7fe3c865b8dbdb33d26f4bc5cbb6096f5445fb2.
The patch corrects the new test, demonstrating its effectiveness, but yields
two new test failures (apparent regressions):
$ ./python.exe Lib/test/test_tokenize.py
**
File /public/cpython-issue20387/Lib/test/test_tokenize.py, line ?, in
test.test_tokenize.__test__.doctests
Failed example:
roundtrip(try: import somemodule\n
except ImportError: # comment\n
print('Can not import' # comment2\n)
else: print('Loaded')\n)
Exception raised:
Traceback (most recent call last):
File /public/cpython-issue20387/Lib/doctest.py, line 1318, in __run
compileflags, 1), test.globs)
File doctest test.test_tokenize.__test__.doctests[14], line 1, in
module
roundtrip(try: import somemodule\n
File /public/cpython-issue20387/Lib/test/test_tokenize.py, line 698, in
roundtrip
bytes_from5 = untokenize(tokens5)
File /public/cpython-issue20387/Lib/tokenize.py, line 339, in untokenize
out = ut.untokenize(iterable)
File /public/cpython-issue20387/Lib/tokenize.py, line 273, in untokenize
self.add_whitespace(start)
File /public/cpython-issue20387/Lib/tokenize.py, line 236, in
add_whitespace
.format(row, col, self.prev_row, self.prev_col))
ValueError: start (4,1) precedes previous end (4,4)
**
File /public/cpython-issue20387/Lib/test/test_tokenize.py, line ?, in
test.test_tokenize.__test__.doctests
Failed example:
for testfile in testfiles:
if not roundtrip(open(testfile, 'rb')):
print(Roundtrip failed for file %s % testfile)
break
else: True
Exception raised:
Traceback (most recent call last):
File /public/cpython-issue20387/Lib/doctest.py, line 1318, in __run
compileflags, 1), test.globs)
File doctest test.test_tokenize.__test__.doctests[70], line 2, in
module
if not roundtrip(open(testfile, 'rb')):
File /public/cpython-issue20387/Lib/test/test_tokenize.py, line 698, in
roundtrip
bytes_from5 = untokenize(tokens5)
File /public/cpython-issue20387/Lib/tokenize.py, line 339, in untokenize
out = ut.untokenize(iterable)
File /public/cpython-issue20387/Lib/tokenize.py, line 273, in untokenize
self.add_whitespace(start)
File /public/cpython-issue20387/Lib/tokenize.py, line 236, in
add_whitespace
.format(row, col, self.prev_row, self.prev_col))
ValueError: start (73,8) precedes previous end (73,12)
**
1 items had failures:
2 of 74 in test.test_tokenize.__test__.doctests
***Test Failed*** 2 failures.
Traceback (most recent call last):
File Lib/test/test_tokenize.py, line 1261, in module
test_main()
File Lib/test/test_tokenize.py, line 1252, in test_main
support.run_doctest(test_tokenize, True)
File /public/cpython-issue20387/Lib/test/support/__init__.py, line 1854, in
run_doctest
raise TestFailed(%d of %d doctests failed % (f, t))
test.support.TestFailed: 2 of 79 doctests failed
@gumblex, Can you review the failures and address them?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20387
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24479] Support LMMS project files in mimetypes.guess_type
Changes by Ned Deily n...@acm.org: -- keywords: +easy stage: - needs patch versions: +Python 3.6 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24479 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
