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
New submission from Xavier de Gaye:
Duplicate method names:
./Lib/xml/dom/minidom.py:379 Attr._get_name
--
components: Library (Lib)
messages: 198584
nosy: xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/xml/dom/minidom.py
type: behavior
versions
New submission from Xavier de Gaye:
Duplicate method names:
./Mac/Tools/Doc/setup.py:123 DocBuild.makeHelpIndex
--
components: Library (Lib)
messages: 198585
nosy: hynek, ned.deily, ronaldoussoren, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Mac
Xavier de Gaye added the comment:
The following issues have been entered for all the above duplicate
names found by duplicate_code_names_2.py:
issue 19112, issue 19113, issue 19114, issue 19115, issue 19116,
issue 19117, issue 19118, issue 19119, issue 19122, issue 19123,
issue 19125, issue
Xavier de Gaye added the comment:
After the last changeset 39f9adc8ad5b there are still 3 methods named
test_findleaks. The proposed patch was also missing one of them.
--
___
Python tracker
<http://bugs.python.org/issue19
Xavier de Gaye added the comment:
There is a backward compatibility issue with changeset d5ef330bac50
that enables tab-completion in the interactive interpreter by default.
When a user is not aware of this new feature and has been implementing
up to now her/his PYTHONSTARTUP file with the first
Xavier de Gaye added the comment:
The patch fixes the problem on my setup. A very minor glitch: after
manually emptying or removing the PYTHONSTARTUP history file, the
history is loaded with the content of ~/.python_history on the next
session
Xavier de Gaye added the comment:
It was proposed, in issue 16056, to enhance `make patchcheck` with the
detection of duplicate code names. This triggered the creation of issue 16079.
The script named duplicate_code_names_2.py, in issue 16079, listed about 20
duplicate names among all the non
Xavier de Gaye added the comment:
A less invasive alternative could be to instrument Bdb with a subclass
that processes send-expect sequences. This is what does
http://code.google.com/p/pdb-clone/source/browse/Lib/test/test_bdb.py
This code could be adapted to run with python bdb
Xavier de Gaye added the comment:
A description of what goes wrong when stepping out of the generator
would be helpful.
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
This is a consequence of the problem mentioned in msg 177059 above.
New patch 'issue16596_nostate_3.diff' fixes both problems by having the
interpreter
issue an exception debug event when processing a StopIteration in target
FOR_ITER:
* The same de
Xavier de Gaye added the comment:
Forgot to say that the only difference between this patch and the previous one
is in Python/ceval.c.
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
Hopefully issue16596_nostate_4.diff should fix this.
The patch issues a StopIteration debug event in ceval.c (similar to the change
made in the previous
patch for the for loop), when the subgenerator is exhausted. This debug event
is printed as
'Int
Xavier de Gaye added the comment:
> Sorry Xavier for your patches, but it's time to focus our efforts on a single
> module and asyncio has a much better design to handle such use cases.
No problem. Thanks for taking your time to review patches made on this
Xavier de Gaye added the comment:
Python 3.5 is still crashing with this test:
$ python jump.py
> jump.py(7)()
-> for i in gen():
(Pdb) break 3
Breakpoint 1 at jump.py:3
(Pdb) continue
> jump.py(3)gen()
-> yield i
(Pdb) step
--Return--
> jump.py(3)gen()->0
-> yield i
(Pd
New submission from Xavier de Gaye:
The Py_XDECREF statement in gen_iternext() at Objects/genobject.c is not needed
since val is NULL (may be optimized out by the compiler).
Actually, the whole function could be written as:
return gen_send_ex(gen, NULL, 0);
--
components
Xavier de Gaye added the comment:
The previous patch changed a field in the PyThreadState structure. This new
patch is simpler and does not prevent to change f_lineno when it is not the
attribute of the frame being traced. The new patch fixes also issue 7238, issue
16482 and issue 17697
Xavier de Gaye added the comment:
Two issues here:
a) in IDLE, on a 'return' debug event in the main module, the step command does
not end the debugging session.
b) in IDLE, BdbQuit is raised by the quit command when the debugger is started
with pdb.set_trace().
I do not know I
Xavier de Gaye added the comment:
> # This returns to a '>>>' prompt,
At the above line in Terry test, the debugger is not terminated and on linux
when I type at this point I get:
>>>
--Call--
> /home/xavier/etc/.pystartup(21)save_history()
-> def save_h
New submission from Xavier de Gaye:
$ ./python
Python 2.7.8+ (2.7:5563f895b215, Jul 20 2014, 18:10:28)
[GCC 4.9.0 20140521 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>
Xavier de Gaye added the comment:
> The same kind of fix should also be applied to '_once_registry' and
> '_filters'.
Oops, no they are correctly refcounted.
--
___
Python tracker
<http
Xavier de Gaye added the comment:
This is because breakpoints number are class attributes. With the following
change, the "./python -m test test_pdb test_pdb" is ok:
$ hg diff
diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py
--- a/Lib/test/test_pdb.py
+++ b/Lib/test/t
601 - 700 of 1492 matches
Mail list logo
