[issue25571] Improve the lltrace feature with the Py_Debug mode
Changes by A Kaptur : -- nosy: +akaptur ___ Python tracker <http://bugs.python.org/issue25571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24997] mock.call_args compares as equal and not equal
New submission from A Kaptur: mock.call_args can be both equal to and not equal to another object: >>> m = Mock() >>> m(1,2) >>> m.call_args call(1, 2) >>> m.call_args == call(1,2) True >>> m.call_args != call(1,2) True This appears to be a recent regression - it repros on trunk, but not on 3.3 or 2.7 with mock 1.3.0. -- components: Library (Lib) messages: 249715 nosy: akaptur priority: normal severity: normal stage: needs patch status: open title: mock.call_args compares as equal and not equal type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24857] mock: Crash on comparing call_args with long strings
A Kaptur added the comment: Here's a simple patch + test for the original bug. I'll file the __ne__ question separately. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40348/issue24857.patch ___ Python tracker <http://bugs.python.org/issue24857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24857] mock: Crash on comparing call_args with long strings
A Kaptur added the comment: It looks like there's a related bug in call_args around __ne__: >>> m = Mock() >>> m(1,2) >>> m.call_args call(1, 2) >>> m.call_args == call(1,2) True >>> m.call_args != call(1,2) True Any reason not to define __ne__ as not __eq__? Otherwise it looks like you fall back to tuple.__ne__, which does the wrong thing here. -- nosy: +akaptur ___ Python tracker <http://bugs.python.org/issue24857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22146] Error message for __build_class__ contains typo
New submission from A Kaptur: One of the error messages for __build_class__ has an extra underscore in the middle. -- files: build_class_typo.patch keywords: patch messages: 224874 nosy: akaptur priority: low severity: normal status: open title: Error message for __build_class__ contains typo versions: Python 3.4 Added file: http://bugs.python.org/file36272/build_class_typo.patch ___ Python tracker <http://bugs.python.org/issue22146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22008] Symtable's syntax warning should contain the word "because"
New submission from A Kaptur: The symbol table's syntax error about unqualified exec is missing the word "because". >>> def foo(): ... exec "a = 1" ... def bar(): ... print a ... File "", line 2 SyntaxError: unqualified exec is not allowed in function 'foo' it contains a nested function with free variables -- assignee: docs@python components: Documentation files: issue.patch keywords: patch messages: 223447 nosy: akaptur, docs@python priority: normal severity: normal stage: needs patch status: open title: Symtable's syntax warning should contain the word "because" type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35992/issue.patch ___ Python tracker <http://bugs.python.org/issue22008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator
A Kaptur added the comment: v3 of patch, including misc/news update, docstring for function, and removing class decorator tests, since it sounds like those are better handled in http://bugs.python.org/issue1764286. -- Added file: http://bugs.python.org/file34885/issue21217-v3.patch ___ Python tracker <http://bugs.python.org/issue21217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator
A Kaptur added the comment: v2 of the patch incorporating the comments at http://bugs.python.org/review/21217/ -- Added file: http://bugs.python.org/file34882/issue21217-v2.patch ___ Python tracker <http://bugs.python.org/issue21217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator
A Kaptur added the comment:
This patch adds tests demonstrating broken behavior inspect.getsource and
inspect.getsourcelines of decorators containing lambda functions, and modifies
inspect.getsourcelines to behave correctly.
We use co_lnotab to extract line numbers on all objects with a code object.
inspect.getsourcelines can also take a class, which cannot use co_lnotab as
there is no associated code object.
@ballingt and I paired on this patch.
Some open questions about inspect.getsource not created or addressed by this
patch:
- Is this a bug that should be patched in previous versions as well?
- the docs for say it can take a traceback. What is the correct behavior here?
There aren't any tests at the moment. We suggest the line of code that caused
the traceback, i.e. the line at tb.tb_lineno
- We added tests of decorated classes. The source of decorated classes does
not include the decorators, which is different than the usual behavior of
decorated functions. What is the correct behavior here?
- inspect.getblock and inspect.BlockFinder use the term "block" in a way that
is inconsistent with its typical use in the interpreter (that is, in ceval.c).
Should this be renamed? If so, to what? ("chunk"?)
--
keywords: +patch
nosy: +akaptur
stage: -> patch review
versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34857/issue21217.patch
___
Python tracker
<http://bugs.python.org/issue21217>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18036] "How do I create a .pyc file?" FAQ entry is out of date
A Kaptur added the comment:
Here is a suggestion for updated documentation in this section. I've added the
description of __pycache__, included a very short description of what a .pyc
file is, and moved the troubleshooting to the end of the section. I'm not sure
whether the description ("a byte code cache file") is desirable here, but my
sense is that people asking how to generate .pyc files are generally confused
beginners.
--
keywords: +patch
nosy: +akaptur
Added file: http://bugs.python.org/file30943/better_pyc_doc_akaptur.patch
___
Python tracker
<http://bugs.python.org/issue18036>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16482] pdb.set_trace() clobbering traceback on error
New submission from A Kaptur: pdb.set_trace() is overwriting the actual traceback when exiting with an error. See minimal recreation here: https://gist.github.com/4079971 -- messages: 175630 nosy: akaptur priority: normal severity: normal status: open title: pdb.set_trace() clobbering traceback on error type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16482> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
