Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Uploaded pdb_default_2.patch.
This new patch fixes the previous patch that fails to stop at
breakpoints set in nested functions, and extends the previous patch in
allowing breakpoints outside function and method definitions.
> When a breakpoint is set at
New submission from Xavier de Gaye:
The attached script, named find_duplicate_test_names.py, prints
duplicate regression test method names in a given directory tree.
Running this script on the standard library test suite shows few
duplicates, see below. It means that some of those tests are not
Xavier de Gaye added the comment:
Running find_duplicate_test_names.py (after changing the print
statements) on the 2.7 branch, gives the following output:
$ ./python find_duplicate_test_names.py Lib/test/
Duplicate test method names:
Lib/test/test_unicode.py: .UnicodeTest.test_capitalize
Lib
Xavier de Gaye added the comment:
The attached patch uses the infrastructure of patchcheck.py and
merges the script into patchcheck.py instead of adding a new script.
--
keywords: +patch
Added file: http://bugs.python.org/file27320/duplicate_test_names.patch
Xavier de Gaye added the comment:
patchcheck output with the patch applied:
$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 1 file
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0
New submission from Xavier de Gaye:
See also issue 16056 for the current list of duplicate test names in
the std lib.
The attached patch improves patchcheck.py to list duplicate test
names when running 'make patchcheck'. This patch to the default
branch can also be applied asis
Xavier de Gaye added the comment:
> To simplify and keep the discussions more focused, etc, I would
> create a new issue for the patch to patchcheck
New issue 16079 has been created.
The proposed patch in the new issue 16079 is slightly improved to
produce a cleaner output by printi
Xavier de Gaye added the comment:
Note that using the module code object to find duplicates does not
allow for selecting among the different code types: function, nested
function, method or class.
Duplicates are extensively used within the std lib:
Running find_duplicate_test_names.py, the
Xavier de Gaye added the comment:
Using the python class browser (pyclbr.py) in conjunction with the
search for duplicates in the module code object would allow to
restrict the listing of duplicates to functions and methods or even
just to methods (depending on the feature requirements), without
Xavier de Gaye added the comment:
> I'm not sure if there is ever a use case for duplicate method
> names. Is there?
property getter, setter, and deleter methods do have the same name.
--
___
Python tracker
<http://bugs.python.
Xavier de Gaye added the comment:
> Here are a couple examples of test method names that don't begin
> with "test_":
>
> def testLoadTk(self):
> def testLoadTkFailure(self):
Also Lib/test/test_smtplib.py test method names start with 'test'
ins
Xavier de Gaye added the comment:
The attached script, named duplicate_code_names.py, takes a file
name list as argument and prints duplicate code names found in these
files ordered by function, class, method and nested class or
function.
The script output on the whole std lib (see the result
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file27376/std_lib_duplicates.txt
___
Python tracker
<http://bugs.python.org/issue16079>
___
___
Python-bug
Xavier de Gaye added the comment:
Another example where pdb does not stop at breakpoints set at
global, else and finally statements:
$ nl -ba foo.py
1 x = 1
2 def main():
3 global x
4 try:
5 if not x:
6 x = 2
7 else
New submission from Xavier de Gaye:
$ tmp=`mktemp /tmp/foo.XX`; echo 'def foo: pass' > $tmp; python3 -m pdb
$tmp; rm $tmp
Traceback (most recent call last):
File "/usr/local/lib/python3.2/pdb.py", line 1556, in main
pdb._runscript(mainpyfile)
File &q
Xavier de Gaye added the comment:
Attached patch pdb_lnotab.patch uses lnotabs (see
Objects/lnotab_notes.txt) to find the actual breakpoint line number and
parses the module source with tokenize to find the set of function and
fully qualified method names in a module.
The patch fixes issues
Xavier de Gaye added the comment:
This is fixed in the proposed patch named pdb_lnotab.patch attached to
issue 14913.
--
___
Python tracker
<http://bugs.python.org/issue6
Xavier de Gaye added the comment:
test_statistics also defines a load_tests() function that builds unittest tests
from doctests with doctest.DocTestSuite() and also fails in refleak mode. The
above regrtest.diff patch also fixes the test_statistics in refleak mode
Xavier de Gaye added the comment:
> There is at least one other place (do_break) where this same problem could
> crop up.
Also in do_retval. And the exception is silently ignored in do_p and do_pp when
repr() fails, which is not correct.
A solution could be to have a message_safe met
New submission from Xavier de Gaye:
The following output of settrace.py shows that the Tracer trace function is
still called in foo() after the New_tracer trace function has been installed
with sys.settrace() from within the trace function itself, and even though
f_trace has been set on all
Xavier de Gaye added the comment:
FWIW this generator expression can be evaluated with the 'interact' command:
--Return--
> /test/comprehension.py(5)foo()->None
-> pdb.set_trace()
(Pdb) interact
*interactive*
>>> all(x < limit for x in items)
True
>&g
Xavier de Gaye added the comment:
The runcode() method of InteractiveInterpreter in code.py uses the
'self.locals' dictionary as the 'globals' parameter of the invoked exec()
function. And the do_interact() method of Pdb instantiates
InteractiveInterpreter with '
Xavier de Gaye added the comment:
The NameError exception occuring on a generator expression referencing a local
variable when the generator is called within exec() is the object of multiple
entries in the bug tracker, see issue 13557.
msg 149096 in this issue suggests using exec(code, locals
Xavier de Gaye added the comment:
Interestingly, the interact command was added at changeset:
$ hg log -v --pager cat -r $(hg blame Lib/pdb.py | grep do_interact | awk -F :
'{print $1}')
changeset: 66691:c2578a68879d
user:Georg Brandl
date:Sat Dec 04 11:20:26
Xavier de Gaye added the comment:
The patch fails to invoke exec() with the locals argument set to the current
frame locals.
The attached patch fixes this, and test_pdb runs now fine with it.
--
Added file: http://bugs.python.org/file35305/default.patch
Xavier de Gaye added the comment:
Commands that silently fail when an object is not printable: p, pp
Commands that crash when an object is not printable:
args, retval
Python 3: display
Python 2: on a 'return' trace event when the return value is not printable
The attac
Xavier de Gaye added the comment:
The patch with a test case.
--
Added file: http://bugs.python.org/file35339/sigint_2.patch
___
Python tracker
<http://bugs.python.org/issue20
Xavier de Gaye added the comment:
An improved patch with a test case.
--
Added file: http://bugs.python.org/file35349/refleak_2.patch
___
Python tracker
<http://bugs.python.org/issue20
Xavier de Gaye added the comment:
Yes the patch does change the semantics of the quit command:
* no change when pdb is run as a script or with 'python -m pdb
script_name'. As stated in the doc, the 'quit command': "Quit from the
debugger. The program being execute
New submission from Xavier de Gaye:
Also, the two oldest frames of the stack are identical (sic),
according to the printed traceback.
$ python3 foo.py
> /tmp/foo.py(3)()
-> x = 1
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55)
[GCC 4.3.2]
(Pdb) list
1
Xavier de Gaye added the comment:
I cannot reproduce the problem on python 2.7. The example runs
without problem after fixing the example with the
following changes:
remove the call to pdb.set_trace(), the debugger is already
started with a call to pdb.run()
add the missing
New submission from Xavier de Gaye:
Create the following tree:
foo.py
mypackage
__init__.py
and get a loader for the non existent module 'mypackage.foo'.
$ mkdir tmp
$ cd tmp
$ >foo.py
$ mkdir mypackage
$ >mypackage/__init__.py
$ ./python
Python 3.4.0a0 (defa
Xavier de Gaye added the comment:
And yes, find_loader returns None, when correctly invoked with the
path argument:
>>> importlib.find_loader('mypackage.foo', ['./mypackage/'])
>>>
--
___
Python track
Xavier de Gaye added the comment:
Maybe find_loader could check its parameters, notice that the name is a
dotted name, that path is None and in this case, not return a loader ?
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
> Not necessarily. The fact that there is nothing to load doesn't
> mean it isn't the right loader if there *was* something to load.
But it is not even the right loader if there *was* something to load,
as get_filename() returns './foo.py
Xavier de Gaye added the comment:
If one would want to fix this, one way to do it could be to change the
following two methods of the PathFinder class such that:
find_module() does not set path to sys.path when its path argument
is None, so as to keep this information for _get_loader
Xavier de Gaye added the comment:
I was bitten by this behavior while, new to the importlib library, I
was trying to understand if one has to call recursively find_loader
for a dotted module name (in the way it must be done when using
imp.find_module), since the documentation on find_loader is
Xavier de Gaye added the comment:
Thanks, this is great!
--
___
Python tracker
<http://bugs.python.org/issue16489>
___
___
Python-bugs-list mailing list
Unsub
Xavier de Gaye added the comment:
The top level frame line number is not updated because it has a local
trace function while the global trace function is None. This is
related to issue 7238.
The following patch fixes the issue. The patch removes the local trace
at the top level frame and makes
Xavier de Gaye added the comment:
See also the related issue 16482.
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue7238>
___
___
Python-bug
Xavier de Gaye added the comment:
It is not only the up and down commands; the where, longlist and
source commands may also overwrite changes made to f_locals.
In Markus sample script above, and with the patch applied, when the
change made to stack_2 is followed by a step command, stack_2 value
Xavier de Gaye added the comment:
See also how it is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=123d1b6db6649f4b54712db321865fda55395488&name=default
--
___
Python tracker
<http://bugs.python.org/iss
Xavier de Gaye added the comment:
See also how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=6ad576592286a005694690906644cb3004090eeb
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
The run, runeval and runcall methods run the debugging session in a
try/finally clause and set the global trace function to None in the
finally clause. But set_trace does not run in a try/finally, hence the
problem. A possible fix is to ensure that the bottom
Xavier de Gaye added the comment:
See how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=0d4d905c6e0aa9c47611dbae514d3f7f53776dcb
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
See how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=8bbac1ffee749fcfd96ea3a2aaca1f240cafc2cc
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
See also how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=625d61e3494d3b7e2a3e8578ddd2f204e21f1800
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
See also how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=4a6d8f2515eed16347d2e2c304e1942585427d50
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
See also how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=6b342324ebdc4558b83b9391e34478c1fa0752db
--
___
Python tracker
<http://bugs.python.org/issue6
Xavier de Gaye added the comment:
See also how this is fixed at
http://code.google.com/p/pdb-clone/source/detail?r=6b342324ebdc4558b83b9391e34478c1fa0752db
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue13328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue16596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
> On finalizing pdb can stop working at some time, but debugging on
> finalization stage can be still useful in certain cases.
Agreed that debugging on finalization stage is useful. Debugging on
finalization stage does not seem to work
Xavier de Gaye added the comment:
In the test named 'test_pdb_return_command_for_generator' in the patch, the
return command does not cause pdb to stop at the StopIteration debug event as
expected. Instead the following step command steps into the generator.
With the patch appli
Xavier de Gaye added the comment:
This new patch fixes the two problems described in my previous message.
The patch is different from Andrew's patch in that it does not use a new state
variable, and the test cases in the patch are a copy of Andrew's patch
Xavier de Gaye added the comment:
When the generator is used in a for loop, the interpreter handles the
StopIteration in its eval loop, and the exception is not raised. So it may be
considered as confusing to have pdb behave differently with a generator
depending on its context. A way to fix
New submission from Xavier de Gaye:
The following debugging session, run with python on the default branch, shows
that pdb does not stop in __del__ when it is invoked.
The reason is:
- The destructor is not called when processing the 'c = 1' statement because
foo frame.f_loc
Xavier de Gaye added the comment:
Tracing/profiling is disabled when tstate->tracing is true or
tstate->use_tracing is false. The proposed patch fixes the problem by reducing
the scope where this condition is true.
As a consequence call_trace, profile_trampoline, trace_trampoli
Xavier de Gaye added the comment:
The 'until' command is also broken (by xdegaye's patch) when issued at a return
debug event and not debugging a generator.
This new patch fixes both problems.
The patch also adds another test case to check that pdb stops after a 'next&
New submission from Xavier de Gaye:
When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation of
the trace function (see trace_trampoline).
maybe_call_line_trace() does quite some work though _PyCode_CheckLineNumber to
find out if the instruction should be traced, and all
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file28298/foo.py
___
Python tracker
<http://bugs.python.org/issue16672>
___
___
Python-bugs-list mailin
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file28299/bar.py
___
Python tracker
<http://bugs.python.org/issue16672>
___
___
Python-bugs-list mailin
Xavier de Gaye added the comment:
> When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation
> of the trace function (see trace_trampoline).
This may be confusing. I meant that when f_trace is NULL, PyTrace_LINE,
PyTrace_RETURN and PyTrace_EXCEPTION are not
Xavier de Gaye added the comment:
This patch breaks extension modules (for example Ned Batchelder's
coverage.py) that use PyEval_SetTrace to set the trace function.
--
___
Python tracker
<http://bugs.python.org/is
Xavier de Gaye added the comment:
Same problem in 3.4.
$ ./python
Python 3.4.0a0 (default:e1bee8b09828, Jan 5 2013, 20:29:00)
[GCC 4.3.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncore
>>
Xavier de Gaye added the comment:
Still randomly getting ignored exceptions on 3.3 and the default
branch, got for example:
Exception TypeError: TypeError("argument of type 'NoneType' is not
iterable",) in ignored
This happens in a threaded application. The root cause
Changes by Xavier de Gaye :
--
keywords: +patch
Added file: http://bugs.python.org/file28743/teardown_module.diff
___
Python tracker
<http://bugs.python.org/issue9
Xavier de Gaye added the comment:
The reason why this happens in python 3.3.0 and not in 3.2:
1) lastResort holds a reference to an instance of _StderrHandler at
module tear down, thus potentially triggering a TypeError in
_removeHandlerRef.
2) The logging code has the following two
Xavier de Gaye added the comment:
The initial teardown_module.py can be simply replaced with
(not a contrived example anymore) the following statements
to print the spurious ignored Exceptions:
# Run the script in a loop:
# while [ 1 ]; do python3 teardown_module.py; sleep .1; done
import
Xavier de Gaye added the comment:
Yes, my last two messages refer to python 3.3.0 only.
The changes logged in http://bugs.python.org/issue9501#msg180039
do fix the behavior of both versions of teardown_module.py.
--
___
Python tracker
<h
Xavier de Gaye added the comment:
Attached is a patch for the current head of 2.7.
It would nice to have this patch on 2.7 too.
With this patch, an implementation of pdb running on 2.7 with an
extension module, runs at 1.2 times the speed of the interpreter when
the trace function is active
Xavier de Gaye added the comment:
One may argue that this is not only a performances patch and that it
fixes the wasting of cpu resources when tracing is on. Wasting cpu
resources is a bug. Anyway, this is fine with me to close this minor
issue on 2.7.
The test_hotshot test is ok on my linux
Xavier de Gaye added the comment:
The patch applied to the default branch should be reverted.
The 2.7 _hotshot extension module follows the specifications of PyEval_SetTrace:
"""Set the tracing function to func. This is similar to PyEval_SetProfile(),
except the tracin
Xavier de Gaye added the comment:
It is not possible to improve the performances of the trace function set with
sys.settrace without breaking backward compatibility for PyEval_SetTrace or
without introducing a new PyEval_xxx of some sort.
Yes, I suggest to revert this patch
Xavier de Gaye added the comment:
status should be close, I guess.
--
___
Python tracker
<http://bugs.python.org/issue16672>
___
___
Python-bugs-list mailin
New submission from Xavier de Gaye:
The following test illustrates the problem.
script.py contains the line "1 / 0".
The 'bt' command is also wrong.
$ python3 -m pdb script.py
> /tmp/script.py(1)()
-> 1 / 0
(Pdb) continue
Traceback (most recent call last):
File
New submission from Xavier de Gaye:
An 'ignore' pdb command issued without any parameter raises IndexError.
--
components: Library (Lib)
messages: 181633
nosy: xdegaye
priority: normal
severity: normal
status: open
title: the 'ignore' pdb command raises Index
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue16956>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
> How does this interact with pdb?
Also, the findlinestarts() function from the dis module computes line
numbers from lnotab. This function is used by pdb when displaying the
lines of a traceback.
--
___
Pyt
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue18968>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
The duplicate_code_names.py script in issue 16079 did find that there
are duplicate test_attribute_deletion tests in testmock.py (see
http://bugs.python.org/file27376/std_lib_duplicates.txt).
--
nosy: +xdegaye
Xavier de Gaye added the comment:
duplicate_code_names_2.py uses tokenize to print duplicate code names
within the same scope, excluding property setter/getter/deleter
duplicates, excluding duplicates of nested classes or functions, and
ignoring duplicates listed in a file (run with --help for
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file31892/ignored_duplicates
___
Python tracker
<http://bugs.python.org/issue16079>
___
___
Python-bug
New submission from Xavier de Gaye:
class _TestProcess in Lib/test/_test_multiprocessing.py is
overshadowed by a function of the same name. And test_current is its
first method:
$ ./python -m test -v test_multiprocessing_fork | grep test_current
$
With the attached patch:
$ ./python -m test
New submission from Xavier de Gaye:
After renaming the first test_errors method to test_errors_1 and the
second one to test_errors_2:
$ /bin/sh -c "cd Lib/ctypes/test; ../../../python runtests.py test_functions.py&q
New submission from Xavier de Gaye:
$ ./python -m unittest -v Lib/distutils/tests/test_cmd.py 2>&1 | grep
test_ensure_string_list
test_ensure_string_list (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
$
And after renaming the first test_ensure_string_list to
test_ensure_string
New submission from Xavier de Gaye:
There are 5 duplicate test names in this file.
$ ./python -m unittest Lib/lib2to3/tests/test_fixers.py
..
--
Ran 451 tests
New submission from Xavier de Gaye:
$ ./python -m test -v test_complex | grep test_truediv
test_truediv (test.test_complex.ComplexTest) ... ok
After renaming the first test_truediv to test_truediv_1 and the second
one to test_truediv_2:
$ ./python -m test -v test_complex | grep test_truediv
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_dis.py:250 DisTests.test_big_linenos
./Lib/test/test_dis.py:294 DisTests.test_dis_object
The attached patch fixes this.
--
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_ftplib.py:537 TestFTPClass.test_mkd
The attached patch fixes this.
--
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198543
nosy: giampaolo.rodola, xdegaye
priority: normal
New submission from Xavier de Gaye:
There are two test_get_only methods. The patch provides a partial
fix, but removes the following two lines from the first method as the
execution of these lines fails:
for f in (self.module.nlargest, self.module.nsmallest):
self.assertRaises(TypeError
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_import.py:255 ImportTests.test_import_name_binding
Attached patch fixes it.
--
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198576
nosy: brett.cannon, xdegaye
priority
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_regrtest.py:210 ParseArgsTestCase.test_findleaks
Attached patch fixes it.
--
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198577
nosy: ezio.melotti, michael.foord, pitrou
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_smtplib.py:249 DebuggingServerTests.testNotImplemented
Attached patch fixes this: the first method has been renamed to
testEHLO since the channel_class of the DebuggingServer is
SMTPChannel, and SMTPChannel does support
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/test/test_webbrowser.py:161 OperaCommandTest.test_open_new
Attached patch fixes it.
--
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198583
nosy: georg.brandl, xdegaye
priority
701 - 800 of 1614 matches
Mail list logo
