Changes by Dave Malcolm :
--
nosy: +fche, scox
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Oops; closing. Thanks.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Dave Malcolm added the comment:
> I tried the patch under Mageia 1 and got the following failure:
Thanks. I'm attaching an updated patch which reworks test_systemtap so that
(a) it turns up the verbosity of stap invocations from "-v" to "-vv"
(b) it tests the &q
Dave Malcolm added the comment:
On Wed, 2012-05-16 at 16:41 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I tried the patch under Mageia 1 and got the following failure:
>
> test_systemtap skipped -- Test systemtap script did not run; stderr was:
>
Dave Malcolm added the comment:
(Sorry about msg160913; looks like my initial email response took about an hour
to get through, and I'd subsequently commented using the webui form)
--
___
Python tracker
<http://bugs.python.org/is
Changes by Dave Malcolm :
--
Removed message: http://bugs.python.org/msg160913
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list m
Changes by Dave Malcolm :
--
Removed message: http://bugs.python.org/msg160914
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list m
Changes by Dave Malcolm :
Removed file:
http://bugs.python.org/file25615/cpython-systemtap-2012-05-16-001.patch
___
Python tracker
<http://bugs.python.org/issue14
Dave Malcolm added the comment:
Thanks. I too am wondering where the documentation should go. We currently
have several locations for documentation:
(1) the man page
(2) the "Doc" subdirectory aka docs.python.org
(3) various text files in the source tree, su
Dave Malcolm added the comment:
I'm able to reproduce this on a RHEL 6 box, and I did some investigating. The
stray .pyc files are indeed reported by "file" as "python 2.6 byte-compiled" so
yes, it's using /usr/bin/python to byte-compile them
On RHEL 6, with
Dave Malcolm added the comment:
I'm attaching an updated version of the patch; I hope there's still time before
Saturday to get it into 3.3
I found a bug in the configure script in the old patch: /usr/bin/dtrace was
required, even without requesting systemtap. I've fixed it
Changes by Dave Malcolm :
--
keywords: -needs review
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Dave Malcolm added the comment:
The approach Nick suggests seems reasonable, but rpm.expandMacro isn't usable:
there's no guarantee that the machine has Python bindings for rpm installed
(especially not for the version of Python that we've just built).
However, we can get
Dave Malcolm added the comment:
(with the patch, it also continues to work on a test Fedora 15 box)
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue15110>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Fixes committed to 3.2 and default: RHEL 6.3 is now green for both branches.
Closing this bug out.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python track
New submission from Dave Chambers :
The current mimetypes.read_windows_registry() enums the values under
HKCR\MIME\Database\Content Type
However, this is the key for mimetype to extension lookups, NOT for extension
to mimetype lookups.
As a result, when >1 MIME types are mapped to a particu
Dave Chambers added the comment:
My first diff file... I hope I did it right :)
--
keywords: +patch
Added file: http://bugs.python.org/file26181/mimetypes.py.diff
___
Python tracker
<http://bugs.python.org/issue15
Dave Chambers added the comment:
I added a diff file to the bug.
Dunno if that's the same as a patch file, or how to create a patchfile if it's
not.
>Do you know if image/x-png and image/png are included in the registry on all
> windows versions?
I think your question is
Dave Malcolm added the comment:
I believe this was due to this line:
return self._gdbframe.name().startswith('pthread_cond_timedwait')
within is_waiting_for_gil(), and your gdb returned None for
self._gdbframe.name() for your build.
I've changed it to:
name = self._gdbfra
Changes by Dave Chambers :
Added file: http://bugs.python.org/file26185/mimetypes.py.diff.u
___
Python tracker
<http://bugs.python.org/issue15207>
___
___
Python-bug
Changes by Dave King :
--
nosy: +davbo
___
Python tracker
<http://bugs.python.org/issue15247>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Dave Abrahams added the comment:
I won't get to this, FYI.
--
___
Python tracker
<http://bugs.python.org/issue9458>
___
___
Python-bugs-list mailing list
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue15516>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Abrahams:
the docs for os.path don't mention the following facts which I think are
important (in fact I assumed the facts would be the reverse):
os.path.realpath(l) works when l is a broken symbolic link, returning the path
to the (missing) target
os.path.readl
Dave Malcolm added the comment:
Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint
directly from Python is:
os.kill(os.getpid(), signal.SIGTRAP)
--
___
Python tracker
<http://bugs.python.org/issue9
New submission from Dave Abrahams:
This session demonstrates. See especially the very last expression evaluated
>>> s='''this is the end
s='''this is the end
... your only friend
your only friend
... the end'''
the end'''
>
New submission from Dave Abrahams:
compare the output of
$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print
len(re.split('\n(?=x)', open('/tmp/tst').read()))"
100
with
$ python -c "open('/tmp/tst',&#
New submission from Dave Malcolm:
I've been trying to get numpy working with Python 3.3, and to so I had to make
some changes to CPython - hence I'm posting this to the Python bug tracker.
numpy pokes at the insides of PyUnicodeObject in a few places and is thus
affected by t
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file26669/hack-out-test-against-MAX_UNICODE-from-cpython-3.3.patch
___
Python tracker
<http://bugs.python.org/issue15
Changes by Dave Malcolm :
--
nosy: +haypo, loewis
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +teoliphant
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Abrahams added the comment:
Dang! Thanks, and sorry for wasting everyone's time on this.
--
___
Python tracker
<http://bugs.python.org/issue15537>
___
___
Dave Abrahams added the comment:
MacOS 10.7
--
___
Python tracker
<http://bugs.python.org/issue15531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Abrahams added the comment:
on Sat Aug 04 2012, Larry Hastings wrote:
> Larry Hastings added the comment:
>
> What does the following script print out?
>
> import os
>
> os.chdir('/tmp')
> os.symlink('--success--', 'foo')
> print(&q
Dave Malcolm added the comment:
On Tue, 2010-11-02 at 17:25 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to
> support this. Also, why do you allow any arguments to sys._breakpoin
New submission from Dave Malcolm:
I've been testing various 3rd-party python code against 3.3b1, and see
ValueError: level must be >= 0
exceptions where C code is using PyImport_ImportModuleEx.
PyImport_ImportModuleEx reads as
63 #define PyImport_ImportModuleEx(n, g, l, f)
Dave Malcolm added the comment:
(FWIW, this was observed when compiling pygobject-3.3.4 against Python-3.3.0b1)
--
___
Python tracker
<http://bugs.python.org/issue15
Dave Malcolm added the comment:
On Thu, 2012-08-09 at 21:04 +, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> Oh, I didn't realize that the documentation says that the default value is -1.
> http://docs.python.org/library/functions.html#__import__
>
New submission from Dave Malcolm:
In Python 3.2 and earlier:
>>> str(ImportError(b'foo'))
"b'foo'"
In Python 3.3:
>>> str(ImportError(b'foo'))
Traceback (most recent call last):
File "", line 1, in
TypeError: __str__ retu
Dave Malcolm added the comment:
Sorry, it's 6825fd9b00ed
--
___
Python tracker
<http://bugs.python.org/issue15778>
___
___
Python-bugs-list mailing list
Changes by Dave Malcolm :
--
keywords: +patch
Added file: http://bugs.python.org/file26988/fix-str-of-bogus-ImportError.patch
___
Python tracker
<http://bugs.python.org/issue15
Dave Malcolm added the comment:
(patch added)
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15778>
___
___
Python-bugs-list mai
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue16191>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Odell:
Here's a small program that crashes Python 3.
import winreg
winreg.SetValueEx(winreg.HKEY_CURRENT_USER, 'Value', 0, 3, None)
I get a 0xC374 exception (STATUS_HEAP_CORRUPTION) when trying to run this.
Here's a stack dump:
(snip)
ntdll.dl
Dave Odell added the comment:
Patch works on my end.
--
___
Python tracker
<http://bugs.python.org/issue21151>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Sawyer:
With Python 3.5, some refactoring of the documentation structure has been done.
Building the documentation targets directly works, but using the supplied
make.bat fails, not finding the sphinx python file.
--
assignee: docs@python
components
Changes by Dave Sawyer :
--
type: compile error -> behavior
___
Python tracker
<http://bugs.python.org/issue21289>
___
___
Python-bugs-list mailing list
Un
Changes by Dave Sawyer :
--
keywords: +patch
Added file: http://bugs.python.org/file34954/mywork.patch
___
Python tracker
<http://bugs.python.org/issue21
Dave Sawyer added the comment:
Removed the use of python in the make, calling the sphinx-build executable.
Also the Doc directory was called "Docs" in the readme.txt
--
___
Python tracker
<http://bugs.python.o
Dave Sawyer added the comment:
http://bugs.python.org/issue1669539 has been partially fixed. On Windows
os.path.join('foo', 'a:bar') gives 'a:bar' not 'foo\\a:bar'. However
os.path.isabs('a:bar') returns False yet it causes a reset in the joi
Changes by Dave Sawyer :
--
keywords: +patch
Added file: http://bugs.python.org/file34956/joindoc.patch
___
Python tracker
<http://bugs.python.org/issue15
Changes by Dave Sawyer :
--
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue15414>
___
___
Changes by Dave Sawyer :
Added file: http://bugs.python.org/file34957/mywork.patch
___
Python tracker
<http://bugs.python.org/issue21289>
___
___
Python-bugs-list mailin
Dave Sawyer added the comment:
Thanks Zach! The bug tracker was nice enough to prompt me to go look in my
email for the agreement too.
--
___
Python tracker
<http://bugs.python.org/issue21
Dave Sawyer added the comment:
Thanks Zach, I'm used to Git and this was my first foray with Hg and trying
to rebase (I knew I shoulda branched before starting on another patch). BTW,
the devs at PyCon Montreal said "Zach's a good guy. One of maybe 4 Window
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 11:10 +, Bohuslav "Slavek" Kabrda wrote:
> Bohuslav "Slavek" Kabrda added the comment:
>
> Hi,
> I'd like to take this over after Dave Malcolm. I don't see any issues that
> haven't be
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 14:15 +, Dave Malcolm wrote:
> Dave Malcolm added the comment:
>
> On Mon, 2014-05-19 at 11:10 +, Bohuslav "Slavek" Kabrda wrote:
> > Bohuslav "Slavek" Kabrda added the comment:
> >
> >
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue21590>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
In my Fedora Python packages I've been applying this patch:
http://pkgs.fedoraproject.org/cgit/python.git/plain/00156-gdb-autoload-safepath.patch
which uses this code fragment to detect if gdb has the autoload safe path code,
rather than trying to guess it
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15516>
___
___
Python-bugs-list mailing list
Unsubscri
Dave Malcolm added the comment:
Minor bikeshedding/spelling nit: should
"_Py_AllocedBlocks"
be changed to
"_Py_AllocatedBlocks"
(and s/_Py_GetAllocedBlocks/_Py_GetAllocatedBlocks/)?
--
___
Python tracker
<http://bug
Dave Chambers added the comment:
Disappointing that "faster but broken" is preferable to "slower but fixed"
--
___
Python tracker
<http://bug
Dave Chambers added the comment:
Seems to me that some hybrid would be a good solution: Hardcode the known types
(which solves the "windows is just wrong" case) then as a default look in the
registry for those that aren't hardcoded.
Therefore the hit of additional time would onl
Dave Chambers added the comment:
> removing read_windows_registry()
If you're suggesting hardcoding *ALL* the mimetypes for *ALL* OSes, I think
that's probably the best overall solution.
No variability, as fast as can be.
The downside is that there would occasionally be an unre
Dave Chambers added the comment:
(I'm a windows dev type)
I would say that there are 2 issues with relying on the registry:
1) Default values (ie. set by Windows upon OS install) are broken and MS never
fixes them.
2) The values can be changed at any time, by any app. Thus the value
New submission from Dave Jones:
import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6
I'm running this test from a LiveCD to make sure the environment is relatively
clean.
--
localhost Desktop # python --version
Pyt
Dave Jones added the comment:
That line (1) seems to pop up every time the subprocess call "hangs"
--
___
Python tracker
<http://bugs.python.o
Dave Jones added the comment:
Distros tested with include Funduntu 2012-4, Fuduntu 2013-1, Fedora 17,
Scientific Linux 6.3 & OpenSUSE 12.2 (all 32-bit) on the same hardware.
--
___
Python tracker
<http://bugs.python.org/iss
Dave Jones added the comment:
I think I found something but I do not know what it means.
Everytime the import hangs, it seems to leave behind a "time.pyc"
There are only 29 files in this directory.
[jonesda0@linux-2py2 pycode]$ ls -1tr
py5.py*
py4.py*
py3.py*
py2.py*
py1.py*
pri
Dave Jones added the comment:
Tried to edit subject to make it easier to search
--
title: import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, &
2.6.6 -> import subprocess hangs for ~25 seconds, time.py file in dir - py
2.7.3,
Dave Jones added the comment:
Hello Ian.
Thank you for the reply.
As I imagine you understand, I delete the "time.pyc" file every time it comes
back.
That being said, there *is* a "time.py" script in there from some testing I was
doing:
[jonesda0@toshiba pycode]$ ls -1
Dave Malcolm added the comment:
FWIW, I feel that it's worth just expecting failures with an *optimized* build:
with an optimizing compiler, there's likely to always be some program counter
location where the debugger is going to get confused for some variables. Given
umpteen
Dave Malcolm added the comment:
[FWIW, this looks similar to an issue I ran into on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=913732
which was due to a mismatch between the kernel headers on the system vs the
actually running kernel. I patched around it there with a downstream-only
Dave Malcolm added the comment:
On Tue, 2014-01-07 at 16:30 +, Yury V. Zaytsev wrote:
> Yury V. Zaytsev added the comment:
>
> After lots of fiddling, I can tell you what's wrong with the macro:
> apparently it's a compiler bug, visible at -O2 and disappearing at -O1
New submission from Dave Day :
When HTMLParser.HTMLParser encounters a malformed charref (for example
&#bad;) it no longer parsers the following HTML correctly.
For example:
&#bad;
Recognises the starttag "p" but considers the rest to be data.
To reprodu
Dave Malcolm added the comment:
> I cannot test this in my current environment because I'm stuck with Red
> Hat and it does not have a recent enough automake to re-create configure
> from configure.in.
FWIW, it may be an _autoconf_ version issue; I'm able to recreate
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue4111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue5753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1068268>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue4216>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
I'm working on an RPM package of Python 3.1.1 for Fedora [1]. Within my RPMs
are
precompiled .pyc and .pyo files that are not writable by users, and are
hardlinked
together if they have equal content. For example:
$ ls -al /usr/lib/python3.1/tk
Changes by Dave Malcolm :
--
title: importlib/_bootstrap.py write_bytecode fails if it can't open the .pyc
file for writing -> importlib/_bootstrap.py write_bytecode raises an IOError if
it can't open the .pyc file for writing
___
P
Dave Malcolm added the comment:
Aha! Thanks pitrou, looks like I managed to mess up my packaging (I was
wondering why no no-one else had run into this, looks like no-one else
made this mistake!).
--
___
Python tracker
<http://bugs.python.
Dave Malcolm added the comment:
For Fedora, I've fixed this (I hope) by special-casing those two files:
%{_libdir}/python%{pybasever}/config/Makefile
/usr/include/python2.6/pyconfig-{32|64}.h
making them part of the core python package.
See downstream bug here:
https://bugzilla.redha
Dave Malcolm added the comment:
> For Fedora, I've fixed this (I hope) by special-casing those two files:
Sorry; for "fixed", read "addressed"; this covers part 1 of the issue,
but not part 2.
--
___
Python trac
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue2422>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
I'm attempting to package Python 3 for a Linux distribution, together with a
stack of python extension
modules; I'm currently using Python-3.1.1. (see
https://fedoraproject.org/wiki/Features/Python3F13 )
Many of these extension modules ar
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1169193>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1448060>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
I see occasional failures where a broken module prevents "pydoc -k" ("apropos")
from working.
Examples of failures (from our downstream bug tracker) are:
https://bugzilla.redhat.com/show_bug.cgi?id=461419 : "pydoc -k&
New submission from Dave Malcolm :
Currently, Python's opcodes are defined as preprocessor #defines. This means
that they are
invisible to the debugger.
I'm attaching:
(i) a simple script (fixup-opcode-header.py) which converts Include/opcode.h
to use an
anonymous enum for
Changes by Dave Malcolm :
Added file: http://bugs.python.org/file15598/fixup-opcode-header.py
___
Python tracker
<http://bugs.python.org/issue7543>
___
___
Python-bug
Changes by Dave Malcolm :
Added file: http://bugs.python.org/file15599/opcode.h
___
Python tracker
<http://bugs.python.org/issue7543>
___
___
Python-bugs-list mailin
Changes by Dave Malcolm :
--
keywords: +patch
Added file: http://bugs.python.org/file15600/opcode.h.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Dave Malcolm :
Added file: http://bugs.python.org/file15601/use-opcode-enum.patch
___
Python tracker
<http://bugs.python.org/issue7543>
___
___
Python-bug
Dave Malcolm added the comment:
Ooops, sorry; in an earlier version of this work, I was generating an
enum of the form:
enum {
};
i.e. without an identifier (an anonymous enum)
which I later changed to:
enum Py_Opcode {
};
Mea culpa; I forgot to update the text for this bug when I
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file15602/diff-in-generated-assembler-for-ceval.diff
___
Python tracker
<http://bugs.python.org/issue7
401 - 500 of 633 matches
Mail list logo
