Dave Malcolm added the comment:
>From IRC discussion, how about something like:
The current implementation consolidates integers in the range -5 to 256
(inclusive) into singleton PyIntObject instances, whereas other integer values
have unique PyIntObject instances created for them.
T
Dave Malcolm added the comment:
Perhaps should also note that this is done for the purposes of optimization
(both speed and memory).
--
___
Python tracker
<http://bugs.python.org/issue11
Dave Malcolm added the comment:
Interpreter idea: " is " could trigger a compatibility warning,
perhaps, to help people avoid relying on CPython quirks
--
___
Python tracker
<http://bugs.python.o
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue11849>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Fix committed to py3k as r86499
--
___
Python tracker
<http://bugs.python.org/issue9518>
___
___
Python-bugs-list mailin
Dave Malcolm added the comment:
Perhaps "make patchcheck" (a.k.a Tools/scripts/patchcheck.py ) should verify
the markup of Misc/NEWS? Not sure what the easiest way to do that is, though,
without bringing in lots of deps.
--
nosy:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1353344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
> Third, for that Graphviz output, was anything special required? If so,
> I would toss the code into Tools for others to benefit from.
It's merely the "to_dot" function from Lib/__optimizer__.py (which turns an AST
into .dot sour
Dave Malcolm added the comment:
Sorry again for another epic-length comment...
I'm attaching the latest work-in-progress on this.
The code is still fairly messy (embarrasingly so in places), but it's better to
have it out in public in this tracker than stuck on my hard drive.
Sym
Dave Malcolm added the comment:
Thanks for reading through this.
> There are a couple places you mention not doing the optimization when
> specific functions are used (e.g. dir, globals, locals), how exactly do you
> verify that, given those functions could be bound to any name?
I d
New submission from Dave Malcolm :
Misc/NEWS needs to be valid reST.
Issue 10450 identified an issue where it wasn't.
"make patchcheck" potentially could check the markup of that file, and,
potentially all the other places in the source tree that are supposed to be
valid r
Dave Malcolm added the comment:
Opened as issue 10507
--
___
Python tracker
<http://bugs.python.org/issue10450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Attaching a simplified version of the patch; I got rid of the callbacks.
Still doesn't have test cases.
I suspect that the use of __STRING and __PRETTY_FUNCTION__ may be compatibility
issues. I believe that __FILE__ and __LINE__ and standard C t
Dave Malcolm added the comment:
> If this a work in progress, you could create an SVN branch in the
> sandbox (you can then use svnmerge to avoid diverging too much from
> mainline) or an hg repo.
Good idea; I've created branch "dmalcolm-ast-optimization-branch" (of
py3
Dave Malcolm added the comment:
py3k-ast-pyoptimize-2010-11-19-006.patch fixed up and committed to the branch
as r86715; I'll work on that branch for the time being.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue10517>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
I'm able to reliably reproduce this on a RHEL 5 box (i386 in this case).
All of the "ProcessPool*" unittest subclasses within
Lib/test/test_concurrent_futures.py exhibit this hang, each printing out just
the name of the first test (so presumabl
Dave Malcolm added the comment:
Minimal reproducer:
$ ./python -c "from concurrent.futures import * ; e = ProcessPoolExecutor() ;
e.submit(pow, 2, 5)"
Fatal Python error: Invalid thread state for this thread
--
___
Python trac
Dave Malcolm added the comment:
Seems to be an issue within (or triggered by) multiprocessing (test_threads and
test_threading pass OK, fwiw):
$ ./python -m test.test_multiprocessing
Fatal Python error: Invalid thread state for this thread
Traceback (most recent call last):
File "
Dave Malcolm added the comment:
By strategically adding print() and input() calls, I was able to isolate the
error to this line in test_multiprocessing.py's test_main:
ManagerMixin.pool = ManagerMixin.manager.Pool(4)
specifically, to the construction:
ManagerMixin.manager.P
Dave Malcolm added the comment:
FWIW, I was able to do an almost full run of regrtest on this box with:
-x test_multiprocessing test_concurrent_futures
Other than those two, all tests pass.
So _something_ is going wrong w.r.t. threads, though I'm not sure what at this
New submission from Dave Malcolm :
2.6.6 has an erronenous use of a unittest method that was added in 2.7, but
it's only seen when running as root. More specificially, with this guard:
if posix.getuid() == 0 and hasattr(posix, 'getgroups') and sys.platform !=
'darwi
New submission from Dave Malcolm :
(was misspelled when issue 5650 was fixed, FWIW)
--
assignee: orsenthil
components: Library (Lib)
files: py3k-fix-jwz-surname.patch
keywords: patch
messages: 123079
nosy: dmalcolm, orsenthil
priority: low
severity: normal
status: open
title
Dave Malcolm added the comment:
Fixed in py3k in r86932
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Dave Malcolm added the comment:
This is very interesting work - thank you!
Sorry for not commenting earlier (very busy), so here are my thoughts so far.
The baseline for the diff appears to be against the py3k branch, in that it
adds back in classes from 2.*: PyIntObject.
There's curr
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1705520>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
A (probably crazy) idea that just occurred to me:
typedef char utf8_bytes;
typedef char iso8859_1_bytes;
typedef char fsenc_bytes;
then specify the encoding in the type signature of the API e.g.:
- int PyRun_SimpleFile(FILE *fp, const char *filename)
+ int
Dave Malcolm added the comment:
What version of the compiler was this with?
(For reference, I see that you also filed this downstream in Fedora's bug
tracker as:
https://bugzilla.redhat.com/show_bug.cgi?id=661510 )
--
nosy: +dmalcolm
___
P
Dave Malcolm added the comment:
Forgot to close this one out
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Dave Malcolm :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue9518>
___
___
Python-bugs-list mai
Changes by Dave Malcolm :
--
assignee: -> dmalcolm
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailing list
Unsubscri
Dave Malcolm added the comment:
One of RH's gcc gurus told me in IRC that:
__ppc__ is not a standard powerpc*-linux macro
__PPC__ or __powerpc__ is
--
___
Python tracker
<http://bugs.python.org/is
Dave Malcolm added the comment:
For reference, this seems to affect SWIG, specifically, I'm seeing build
failures using:
/usr/share/swig/2.0.1/python/pycontainer.swg
from swig-2.0.1
See downstream build failure report for znc, which uses swig to generate python
3 bindings:
Dave Malcolm added the comment:
Note that for that test case to be run, it must be on an installed python:
@unittest.skipIf(sysconfig.is_python_build(),
"need an installed Python. See #7774")
Am testing the 2.7 branch now on an x86_64 Fed
Dave Malcolm added the comment:
That test works for me on this x86_64 Fedora 13 box (using latest 2.7 code from
SVN, built and installed to a test prefix):
[da...@surprise bin]$ ./python -m test.regrtest -v test_subprocess
== CPython 2.7.1+ (release27-maint:87724, Jan 3 2011, 19:39:26) [GCC
Dave Malcolm added the comment:
I should note that Fedora Core 4 reached its "End of Life" at August 2006:
http://fedoraproject.org/wiki/End_of_life
Do you see this with a more up-to-date version of Fedora?
--
___
Python trac
Dave Malcolm added the comment:
FWIW, I just added this patch downstream to Fedora's python 3 builds:
http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2b2-fix-ppc-debug-build.patch;hb=5659c63442be2e91eb42e60284d7a9a9ab0
Dave Malcolm added the comment:
Adrian verified in the downstream bug tracker that this fixed the build for him
(and the logs show it successfully ran the test suite), so I committed my patch
to py3k as r87796.
--
___
Python tracker
<h
Dave Malcolm added the comment:
Merged back to 3.1 as r87800 and to 2.7-maint as r87801
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Dave Malcolm added the comment:
Attaching updated version of the patch.
I've added a selftest which (in a sacrificial subprocess) abuses ctypes to
break an ob_refcnt, and then triggers a garbage collection.
I also changed the printing to stderr to directly use fprintf and fflush to
e
Dave Malcolm added the comment:
As above, but I added an extra call to fflush in case the call to
_PyObject_Dump leads to a segfault.
--
Added file:
http://bugs.python.org/file20344/py3k-objdump-on-gcmodule-assertions-2011-01-10-002.patch
New submission from Dave Malcolm :
If we start a short-lived process which finishes before we begin communicating
with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving
process no longer existing. This becomes an EPIPE, which becomes an:
OSError: [Errno 32] Broken pipe
Dave Malcolm added the comment:
On Wed, 2011-02-09 at 16:41 +, Barry A. Warsaw wrote:
> IIRC we thought about something like this during the PEP discussions and
> Guido nixed it.
FWIW, the closest I could find was this mail:
http://www.mail-archive.com/python-dev@python.org/ms
Changes by Dave Malcolm :
--
title: test_concurrent_futures crashes with "Fatal Python error: Invalid thread
state for this thread" -> test_concurrent_futures crashes with "--with-pydebug"
on RHEL5 with "Fatal Python error: Invalid
Dave Malcolm added the comment:
I spent some time bisecting the SVN history in the py3k branch, and believe
that r84914 is the commit that introduced this issue.
Details:
Trying on 4-core i386 RHEL 5 box
$ svn up -r REV
$ make clean ; make
(configured --with-pydebug)
Reproducer
Changes by Dave Malcolm :
--
nosy: +krisvale
___
Python tracker
<http://bugs.python.org/issue10517>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
r84914 was the implementation of issue 9786 (Native TLS support for pthreads)
--
___
Python tracker
<http://bugs.python.org/issue10
Dave Malcolm added the comment:
This appears to be happening in a child process when the parent process is
running:
Lib/multiprocessing/util.py, line 255, in _exit_function ()
Liberally adding printf() and getpid() calls in various places, seems to always
happen when parent process is
Dave Malcolm added the comment:
CVE-2011-0705
--
___
Python tracker
<http://bugs.python.org/issue11197>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
FWIW, this regressed in 2.6.6 relative to 2.6.5, due to r79646 adding the
T_STRING_INPLACE test code to the 2.6 branch.
Note to self: https://bugzilla.redhat.com/show_bug.cgi?id=677392
--
___
Python tracker
<h
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue775964>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
In many places throughout the existing test suite, there are assertions of the
form:
self.assertTrue(chips in menu)
and of the form:
self.assertTrue(cheese not in shop)
If these fail, the error message will merely tell you that the condition
failed
New submission from Dave Malcolm :
Currently sys.std[in|out|err] are set to the locale encoding but only if they
are directly connected to a tty (and PYTHONIOENCODING is not set in the
environment to override things).
The conditionality on "isatty" leads to lots of unexpected ch
Changes by Dave Malcolm :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7745>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1475523>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue5504>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue7861>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
http://www.python.org/dev/faq/ doesn't seem to explain how to regenerate
"configure"
Here's an attempt at answering that question; I hope the following is
appropriate and factually correct:
How to regenerate the "configure&q
Dave Malcolm added the comment:
Eric Smith:
> Isn't it true that after regenerating configure that you need to check
> it back in? Or is that so obvious to everyone except me that it's not
> worth mentioning?
FWIW the above point wasn't obvious to me; if that's t
Dave Malcolm added the comment:
At Red Hat we've done some work on this feature. I'm sorry for not updating
this issue, I was swamped with tasks both pre-PyCon and during the event; I did
show the following to various folks at PyCon; I attempted to find Skip at PyCon
but was un
Dave Malcolm added the comment:
Attached is the patch I'm currently applying in Fedora 13 to Python 3.
The patch is actually against the 3.1.1 tarball, rather than SVN; sorry
(swamped with post-pycon tasks here), as that's what I've been testing this
work against.
The pa
New submission from Dave Malcolm :
gdb 7 can be extended with Python code, allowing the writing of domain-specific
pretty-printers and commands.
I've been working on gdb 7 hooks to make it easier to debug python itself, as
mentioned here:
https://fedoraproject.org/wiki/Fea
Changes by Dave Malcolm :
--
keywords: +patch
Added file:
http://bugs.python.org/file16403/add-gdb7-python-hooks-to-trunk.patch
___
Python tracker
<http://bugs.python.org/issue8
Dave Malcolm added the comment:
(I faxed in my contributor agreement to the PSF on 2010-03-03)
--
___
Python tracker
<http://bugs.python.org/issue8032>
___
___
Dave Malcolm added the comment:
Martin: thanks for reviewing this.
Re msg100537: sorry about the inauspicious start. I've added some
bulletproofing for the case you discovered, and added two new unit tests.
Re msg100538: OK. I've removed my name and the copyright notice in
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file16497/diff-of-gdb7-hooks-v2-relative-to-v1.diff
___
Python tracker
<http://bugs.python.org/issue8
Dave Malcolm added the comment:
Perhaps this is an issue in a 3rd-party extension module? (Given that you're
running Django, do you have a 3rd-party database connection module?; the last
message in the log is "Validating models", does that require Django to go to
the db to
New submission from Dave Malcolm :
A minor nit: configure.in has this comment twice:
"Check for Python-specific malloc support"
c.f.:
# Check for Python-specific malloc support
AC_MSG_CHECKING(for --with-tsc)
(snip)
# Check for Python-specific malloc support
AC_MSG_CHECKING(
Dave Malcolm added the comment:
Thanks for reviewing the patch.
I've changed the pretty-printing of NULL pointers to "0x0" as suggested, and
I've updated frame printing. Frames are now printed like this
(gdb) p f
$1 = Frame 0x827e544, for file /home/david/coding/python-
Dave Malcolm added the comment:
Attaching diff from v2 to v3
--
Added file:
http://bugs.python.org/file16526/diff-of-gdb7-hooks-v3-relative-to-v2.diff
___
Python tracker
<http://bugs.python.org/issue8
Dave Malcolm added the comment:
> Nitpick: Various occurrences of 2.6.1 in the above should probably be 2.61.
Good catch - I think my brain or fingers are too used to Python's versioning
scheme, rather than autoconf's.
Here's a revised set of commands, hopefully fixing
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue8140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
I'm attaching a new version of the patch (v4), against svn trunk (r79422)
Changes since v3:
* added support for PySetObject (set/frozenset)
* added support for PyBaseExceptionObject (BaseException)
* fixed a signed vs unsigned char issue that l
Dave Malcolm added the comment:
(adding diff from v3 to v4, for ease of review)
--
Added file:
http://bugs.python.org/file16657/diff-of-gdb7-hooks-v4-relative-to-v3.diff
___
Python tracker
<http://bugs.python.org/issue8
Dave Malcolm added the comment:
I'm attaching a new version of the patch (v5), against svn trunk (r79517)
I've been testing these hooks by using "gdb attach" to attach to real-world
python programs.
When doing this with earlier versions of the hooks, gdb would pause fo
Dave Malcolm added the comment:
Adding diff from v4 to v5, for ease of review.
For my reference, md5sum of v5's hooks:
d3e039bb1279e71e847cc7ade10d3272 python-gdb.py
--
Added file:
http://bugs.python.org/file16716/diff-of-gdb7-hooks-v5-relative-to-v4
Dave Malcolm added the comment:
Thanks for reviewing the gdb work.
I was mistakenly testing using:
make ; ./python Lib/test/test_gdb.py
which led to path assumptions in the code.
I'm now testing with:
make ; ./python Lib/test/regrtest.py -v test_gdb
I'm attaching a patch
Changes by Dave Malcolm :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue8279>
___
___
Python-bugs-list mailing list
Unsubscri
Dave Malcolm added the comment:
Sorry about that.
"test_gdb_sample.py" is merely a sample script for use by "test_gdb.py" (see
issue 8032); it's not intended to do anything useful by itself (though it does
need a "print" invocation, since test_gdb.py uses a
Dave Malcolm added the comment:
"gdb_sample.py" as a name works for me. I don't have commit rights to SVN so I
can't perform the rename myself.
(Note that due to issue 8279 the file isn't actually used at the moment by
test_gdb.py so it should be safe to rename. I
Dave Malcolm added the comment:
I'm attaching a revised version of the patch; this is as before, but takes
account of the rename of the sample file from "test_gdb_sample.py" to
"gdb_sample.py" in r79557.
--
Added file:
http://bugs.python.org/file16727/fix
Dave Malcolm added the comment:
Sorry about this.
I believe this is the expansion of these fragments from the Makefile.pre.in
(indenting for clarity):
gdbhooks: $(BUILDPYTHON)-gdb.py
$(BUILDPYTHON)-gdb.py: Tools/gdb/libpython.py
$(INSTALL_SCRIPT) $< $(BUILDPYT
Dave Malcolm added the comment:
> A nitpick: on OS X, the gdb script ends up being called:
>
> python.exe-gdb.py
>
> Is this intentional? If it is, then I'll add this filename to the
> svn:ignore property. (And also to make distclean, I guess. Is python-
> gdb
Dave Malcolm added the comment:
It looks like all of the failures were due to gdb.Frame not having a "function"
method.
I did some digging, and it appears that this attribute may not yet be in the
upstream version of gdb.
The gdb/python integration was largely implemented by col
Dave Malcolm added the comment:
I believe $(INSTALL_SCRIPT) was changed to $(INSTALL_DATA) in r79716 (see
http://bugs.python.org/issue8032#msg102288 )
Attaching refreshed version of the patch.
--
Added file:
http://bugs.python.org/file16760/introduce-var-for-gdb-hooks-002.patch
New submission from Dave Malcolm :
test_gdb's get_gdb_repr carves up a gdb backtrace to try to extract how gdb
representated the data.
When connected to a tty, gdb will insert additional newlines and spaces based
on the width of the tty (internally it has a wrap_here() function to do
New submission from Dave Malcolm :
http://www.python.org/dev/buildbot/trunk/builders/alpha%20Debian%20trunk/builds/52/steps/test/logs/stdio
shows some failures in test_gdb:
==
FAIL: test_corrupt_ob_type
Dave Malcolm added the comment:
There's also a deprecation warning in that log:
/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py:229:
DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
if e.message != 'unichr() arg not in ran
Dave Malcolm added the comment:
( #8330 has a patch for a DeprecationWarning )
--
___
Python tracker
<http://bugs.python.org/issue8337>
___
___
Python-bugs-list m
Dave Malcolm added the comment:
Both of the failing tests use "set" inside gdb to try to corrupt the memory of
the inferior process.
I believe the issue here is that reading through 0xDEADBEEF within gdb on this
machine isn't generating a RuntimeError; perhaps that _is_ a v
Dave Malcolm added the comment:
( #8330 has a patch which may fix this )
--
___
Python tracker
<http://bugs.python.org/issue8337>
___
___
Python-bugs-list mailin
Changes by Dave Malcolm :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue8330>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
I'm attaching a patch for the py3k branch to port the gdb hooks to Python 3.
The libpython.py code installed to python-gdb.py "knows" about the internal
details of the Python within the tree. This patch makes the necessary changes
to th
Dave Malcolm added the comment:
> Should we call it libpython3.py, in order to distinguish it from the 2.x
> version?
We could; it gets copied to python-gdb.py by the Makefile though.
The code is intended to track the low-level implementation details of the tree
that its in, so I&#x
Dave Malcolm added the comment:
New version of patch attached
All tests continue to pass for me.
I believe this will fix the "py-list", "py-locals", "py-print" commands and
their respective tests on Ubuntu; I expect py-up/py-down to still fail due to
m
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue7332>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
If I'm reading this bug correctly, there are two issues here:
(A) that we shouldn't use gdb.Frame.function.name(), and should instead use
gdb.Frame.name(). I believe this is a duplicate of issue 8279, and that this
was fixed in trunk in r80156.
Dave Malcolm added the comment:
Assigning to loewis for review
--
assignee: dmalcolm -> loewis
stage: -> patch review
___
Python tracker
<http://bugs.python.org/
Dave Malcolm added the comment:
> Attached patch is based on add-conditions-for-gdb.Frame.select-to-
> trunk.patch and fix described problems. Using test_gdb-2.patch, test_gdb
> pass without any error on my Debian Sid (gdb 7.1).
The patch conditionalizes each test within StackNaviga
101 - 200 of 417 matches
Mail list logo
