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
François-Xavier Bourlet added the comment:
No worries, I am glad to see asyncore going away. It was indeed badly
designed in the first place.
--
François-Xavier Bourlet
On Fri, Jun 27, 2014 at 2:28 PM, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> "A
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
Xavier de Gaye added the comment:
Sorry, I posted to the wrong issue, please ignore my previous message.
--
___
Python tracker
<http://bugs.python.org/issue20
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file36163/refleak_3.patch
___
Python tracker
<http://bugs.python.org/issue20766>
___
___
Python-bugs-list m
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
Xavier de Gaye added the comment:
After refleak_3.patch, test_pdb_next_command_in_generator_for_loop is the only
remaining test that sets a breakpoint without reinitializing the breakpoints
numbering first.
As a result, this test may also fail in the future when tests are reordered by
the
New submission from Xavier de Gaye:
Pdb sets a handler for the SIGINT signal (which is sent when the user presses
Ctrl-C on the console) when you give a continue command.
'continue' is not the only pdb command that may be interrupted, all the
commands that resume the execution of t
Changes by Xavier de Gaye :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xavier de Gaye:
When tracing, the frame of a suspended generator should not have an f_trace
function as there is no way to delete the frame f_trace attribute in that case
even though
tracing may have been disabled.
The patch relies on the fact that whenever the generator
New submission from Xavier de Gaye:
'test_faulthandler.patch' uses dedent to have triple-quoted strings in indented
form. This allows viewing the source code with the folding tools available with
some editors.
'test_faulthandler.diff' is the result of 'hg diff --igno
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file36322/test_faulthandler.diff
___
Python tracker
<http://bugs.python.org/issue22175>
___
___
Python-bug
Xavier de Gaye added the comment:
This issue can be closed.
After changeset 7bc53cf8b2df by Zachary Ware in issue 22104:
./python -m test -R3:3 test_statistics
is ok now.
--
nosy: +zach.ware
___
Python tracker
<http://bugs.python.org/issue20
New submission from Xavier de Gaye:
With the following script:
import time
def foo():
import pdb; pdb.set_trace()
while 1:
time.sleep(.5)
foo()
Hitting ^C after continue gives:
$ ./python foo.py
> foo.py(5)foo()
-> while 1:
(Pdb) continue
^C
Program interrupted. (Use
Xavier de Gaye added the comment:
This issue has been entered while checking for duplicate test names in issue
16079.
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Xavier de Gaye:
With the following pdb_jump.py script:
def foo(x):
import pdb; pdb.set_trace()
lineno = 3
lineno = 4
foo(1)
The change made to 'x' is lost after a jump to line 4:
$ ./python ~/tmp/test/pdb_jump.py
> ~/tmp/test/pdb_jump.py(3)foo()
Xavier de Gaye added the comment:
This seems to break BaseTestSuite.countTestCases when invoked after the
TestSuite has been run:
...
File "Lib/unittest/suite.py", line 42, in countTestCases
cases += test.countTestCases()
AttributeError: 'NoneType' obj
New submission from Xavier de Gaye:
The sys.settrace documentation states:
The trace function is invoked (with event set to 'call') whenever a new local
scope is entered;
it should return a reference to a local trace function to be used that scope,
or None if the scope shouldn’t
Changes by Xavier de Gaye :
--
keywords: +patch
Added file: http://bugs.python.org/file33246/f_trace.patch
___
Python tracker
<http://bugs.python.org/issue20
New submission from Xavier de Gaye:
Section 3.2 of 'The Python Language Reference' states:
f_trace, if not None, is a function called at the start of each source code
line
Run the attached tracer.py and see that although f_trace is None in both cases
when 'cmd' is eit
Xavier de Gaye added the comment:
A patch proposed in issue 20041 provides a backward compatible solution to this
performance enhancement.
--
___
Python tracker
<http://bugs.python.org/issue16
Xavier de Gaye added the comment:
A patch is proposed in issue 20041.
--
___
Python tracker
<http://bugs.python.org/issue20040>
___
___
Python-bugs-list mailin
Xavier de Gaye added the comment:
See also issue 20040.
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue11992>
___
___
Python-bugs-list mailin
Xavier de Gaye added the comment:
Adding the corresponding tests.
--
components: +2to3 (2.x to 3.x conversion tool) -Interpreter Core
Added file: http://bugs.python.org/file33260/tests.patch
___
Python tracker
<http://bugs.python.org/issue20
Changes by Xavier de Gaye :
--
components: +Interpreter Core -2to3 (2.x to 3.x conversion tool)
___
Python tracker
<http://bugs.python.org/issue20041>
___
___
Changes by Xavier de Gaye :
--
nosy: +xdegaye
___
Python tracker
<http://bugs.python.org/issue20061>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xavier de Gaye:
With this script:
# START
def foo():
while 1:
pass
import pdb; pdb.set_trace()
foo()
# END
The following sequence of pdb commands aborts the script with a
KeyboardInterrupt exception:
next
Ctrl-C
continue
While the equivalent following
New submission from Xavier de Gaye:
The following code crashes python with:
python: Objects/object.c:512: PyObject_Str: Assertion `!PyErr_Occurred()'
failed.
on the tip of the default branch, but not on python 3.3.3.
import sys
error = None
try:
raise ValueError('some tex
New submission from Xavier de Gaye:
After an alarm handler raises an exception while a tracing function is being
invoked and when this exception is not caught by the tracing function, the
call_trampoline() function in sysmodule.c returns NULL and its caller,
trace_trampoline(), removes the
Xavier de Gaye added the comment:
The following code shows that the trace function is removed when an alarm
raises an exception and prints: 'trace function: None'
import sys, signal, time
def trace(frame, event, arg):
if frame.f_code.co_name == 'foo&#x
New submission from Xavier de Gaye:
The following line should be removed from test_ssl.py:
from unittest import mock
--
components: Library (Lib)
messages: 211148
nosy: xdegaye
priority: normal
severity: normal
status: open
title: test_ssl does not use mock
type: behavior
versions
Xavier de Gaye added the comment:
> A signal should not remove the trace function.
And a signal should be traced.
The attached patch postpones all signals except SIGINT while the trace function
is being invoked, and thus the signal is traced after returning from this
function.
My previ
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file34070/signal_test.py
___
Python tracker
<http://bugs.python.org/issue20601>
___
___
Python-bugs-list m
Xavier de Gaye added the comment:
With the previous patch, after the signal arrives and the first call to
PyErr_CheckSignals, PyErr_CheckSignals is called for each bytecode processed in
the eval loop
of the tracing function (and the eval loop of functions called by the tracing
function, and
Xavier de Gaye added the comment:
Hum hum, and now with this last patch PyErr_CheckSignals is called for each
traced line even when no signal is pending, which is worse than the previous
one as far as performance is concerned.
--
___
Python tracker
New submission from Xavier de Gaye:
Occurs on the tip of the Python default branch on ArchLinux when running 'make
html PYTHON=python2' from Doc/.
Traceback attached.
--
assignee: docs@python
components: Documentation
files: sphinx-err-DH3qAl.log
messages: 211311
nosy: d
Xavier de Gaye added the comment:
$ hg log -r tip
changeset: 89198:72f9b6222476
tag: tip
parent: 89195:dcbbff7e6b56
parent: 89197:f45d4823f63c
user:Ezio Melotti
date:Sat Feb 15 16:59:39 2014 +0200
summary: #19890: merge with 3.3.
The README.txt says:
A
New submission from Xavier de Gaye:
Issuing the 'continue' pdb command with a lazy_import.py script as:
# START of lazy_import.py
import sys, pdb
for m in sys.modules:
if m == 'sys':
pdb.set_trace()
# END of lazy_import.py
gives the following output:
$ p
New submission from Xavier de Gaye:
After the pdb 'continue' command, the signal module owns a reference to
Pdb.sigint_handler. On the next instantiation of pdb, the signal module owns a
reference to a new sigint_handler method that owns a reference to the previous
sigint_han
Xavier de Gaye added the comment:
> the first pdb instance is never freed
The first pdb instance is (and all the other pdb instances) never freed until
the call to PyOS_FiniInterrupts() in Py_Finalize().
--
___
Python tracker
&l
Xavier de Gaye added the comment:
The doctests are executed with 'test.globs' as globals which is set in the
'find' method of doctest.DocTestFinder, and cleared after each run (unless
'clear_globs' is false). One possible fix is to have test.regrtest 'find&
Xavier de Gaye added the comment:
After applying patch 'regrtest.diff' from issue 20746, the command:
$ ./python -m test -W -R3:3 test_pdb
succeeds now and shows there are no reference leaks.
However, with the following change in Lib/test/test_pdb.py and patch
'regrtes
Xavier de Gaye added the comment:
See also issue 20766.
--
___
Python tracker
<http://bugs.python.org/issue20746>
___
___
Python-bugs-list mailing list
Unsub
Xavier de Gaye added the comment:
Documentation update attached.
--
Added file: http://bugs.python.org/file34326/pdb_doc.diff
___
Python tracker
<http://bugs.python.org/issue16
New submission from Xavier de Gaye :
Python 2.7 - svn revision 82852
Bug description
===
Test script foo.py
--
#!/usr/bin/env python
import distutils.core
import test.regrtest
Exception when running foo.py
-
Traceback
Xavier de Gaye added the comment:
http://pyclewn.sourceforge.net uses the regrtest module to run its
testsuite.
The test package is documented in the Standard Library documentation,
quote:
"The test package contains all regression tests for Python as well
as the modules test.test_suppor
Xavier de Gaye added the comment:
Thanks for your comments, that was fast!
I will skip using the test package then.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/iss
Changes by Xavier de Gaye :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue9250>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Xavier de Gaye:
With this patch, cross compiling a third-party extension module is done with
the command:
XBUILD_PYTHON_DIR=/path/to/python/dir python setup.py build
where XBUILD_PYTHON_DIR is the location of the directory of the cross-compiled
python executable.
It may
Xavier de Gaye added the comment:
> This approach will not work with a "multiarch" enabled environment, and break
> cross builds on Debian and Ubuntu.
No, the patch does not break cross builds on Debian and Ubuntu, unless you can
demonstrate it does.
> Afaics, the propos
Changes by Xavier de Gaye :
--
nosy: +Chi Hsuan Yen
___
Python tracker
<http://bugs.python.org/issue28833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
> I don't think that identifying the target by some path is the right way to
> go, and you should be able to identify the target by giving the target
> triplet as used by the configure parameters and then deduce the location from
> the t
Xavier de Gaye added the comment:
So I suggest we start with this patch as it works for:
* The standard library extension modules (for debian as well).
* The third-party extension modules on platforms that have multiarch defined
and on platforms that do not have multiarch defined (on debian
New submission from Xavier de Gaye:
Android is not a multiarch system and the unix build system can cross compile
non-multiarch systems as well as multiarch systems. This is a follow up of the
decisions implemented in issue 28046 and the patch fixes also an oversight made
in this issue in
Xavier de Gaye added the comment:
$ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android
PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr
python3.7 setup.py build_ext
>
Variables prefixed by an underscore such as '_PYTHON_SYSCONFIGDATA_N
Xavier de Gaye added the comment:
> How about renaming sys.implementation._multiarch to
> sys.implementation.target_architecture and make it public?
> sys.androidapilevel() sounds too specific to me.
Please do not hijack this issue. The removal of sys.implementation._multiarch
for A
Xavier de Gaye added the comment:
@Chi Hsuan Yen
And please, let us not waste any more time on lost battles, this suggestion of
using sys.implementation has already been rejected at issue 27442 (see
msg269748) as you must know since you were involved in the discussion there
Xavier de Gaye added the comment:
> getandroidapilevel-3.patch: Updated version of getandroidapilevel.patch:
> replace "runtime" with "build time" in the doc :-) Remove also "version > 0"
> check in support/__init__.py.
LGTM
> About the version &g
Xavier de Gaye added the comment:
Here is the output of getandroidapilevel(), a verbose run of test_sys and a run
of the test suite on the Android x86 emulator API 21. All the results are as
expected, the failed tests are the usual ones, BTW all of the failed tests have
either a patch ready
Xavier de Gaye added the comment:
FWIW the definition of free variables can be found in the Language Reference at
section 4.2.1. "Binding of names" [1].
The list of the free variables of a user defined function can be accessed
through the __closure__ function attribute, a tuple. Th
Xavier de Gaye added the comment:
The change made by the patch in Makefile.pre.in handles the removing of the
dangling underscore in the patch of issue 28833, it is not needed.
android_multiarch_2.patch is simpler: the change in Makefile.pre.in has been
removed and test_triplet_in_ext_suffix
Xavier de Gaye added the comment:
The MULTIARCH triplet:
* is used by the build system in the suffix of the name of the _sysconfigdata
private module, it may have any value (including being empty) when the platform
is non-multiarch - for example cross-compiling for an Android emulator with
Changes by Xavier de Gaye :
--
assignee: -> xdegaye
stage: needs patch -> patch review
type: behavior -> performance
versions: -Python 3.6
___
Python tracker
<http://bugs.python.or
Xavier de Gaye added the comment:
This is a performance issue. I will look at it shortly.
--
___
Python tracker
<http://bugs.python.org/issue28596>
___
___
Pytho
Xavier de Gaye added the comment:
issue #20211: setup.py: do not add system header locations when cross compiling
issue #28190: Detect curses headers correctly for cross-compiling
--
dependencies: +Detect curses headers correctly for cross-compiling, setup.py:
do not add system header
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Xavier de Gaye:
This happens when the cross compilation is done with '--with-pydebug' while the
native interpeter used to run setup.py has been built without it. The error
message is:
Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and
Py
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Xavier de Gaye added the comment:
Patch attached.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45812/xxlimited_abiflags.patch
___
Python tracker
<http://bugs.python.org/issu
Xavier de Gaye added the comment:
The only change that is needed here is to not include /usr/include/ncursesw in
setup.py when cross compiling to ensure that the headers of the build platform
are not included. When cross compiling Python, it is the responsability of the
packager to set the
Xavier de Gaye added the comment:
When cross compiling, setup.py must not look for headers in the directory for
installing C header files and must not look for libraries in the directory for
installing object code libraries of the _native_ interpreter which is being
used to run setup.py
Xavier de Gaye added the comment:
This patch does not add /usr/include/ncursesw to the include directories search
paths when cross compiling.
Restoring the original title.
@Chi Hsuan Yen
Please open a new issue for the detection of the curses paths. The current
issue is about the failure to
Xavier de Gaye added the comment:
> Both gcc and clang offer a method to search for header files and libraries in
> a target specific location.
AFAIK there is no target specific location when cross compiling. What are those
cross compilation target specific locations according
Xavier de Gaye added the comment:
> this assumption is wrong for the multiarch case.
Please explain why it is wrong.
--
___
Python tracker
<http://bugs.python.org/issu
Xavier de Gaye added the comment:
> no, this is a very wrong simplification. Both gcc and clang offer a method
> to search for header files and libraries in a target specific location.
> Please use these options.
Please open a new issue for the detection of the curses paths. Th
Xavier de Gaye added the comment:
> Now users have to specify the path manually even for native builds.
This does not make sense, the patch does not change anything for the native
builds.
--
___
Python tracker
<http://bugs.python.org/issu
Xavier de Gaye added the comment:
Hum, I did miss that line in configure.ac, thanks for pointing that out.
New patch.
--
Added file: http://bugs.python.org/file45850/no-path-to-ncursesw_2.patch
___
Python tracker
<http://bugs.python.org/issue28
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Xavier de Gaye :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
801 - 900 of 1614 matches
Mail list logo
