New submission from Tom Tromey:
I was debugging this bug reported against gdb:
http://sourceware.org/bugzilla/show_bug.cgi?id=14386
It turns out that what went wrong in this code was that
PyIter_Check evaluates to 0 when its argument is a
Python list.
This happens because the PyIter_Check
New submission from Tom Lynn:
The tarfile module silently truncates the list of entries when reading a tar
file if it sees an entry with a uid/gid field containing only spaces/NULs. I
got such a tarball from Java Maven/plexus-archiver. I don't know whether they
write such f
Tom Lynn added the comment:
I think the default has to be 0 for consistency with how other empty numeric
fields are handled.
In theory spaces and NULs are supposed to be equivalent terminators in numeric
fields, but I've just noticed that plexus-archiver is also using leading spaces
r
Tom Lynn added the comment:
See attached bad.tar.
$ less bad.tar | cat
drwxr-xr-x 0/0 0 2012-09-05 20:04 foo/
-rw-rw-r-- uname/gname 0 2012-09-05 20:04 foo/a
$ python -c 'import tarfile; print(tarfile.open("bad.tar").getnames())'
['foo']
$ py
Tom Lynn added the comment:
patch.py attached - what I'm using as a workaround at the moment.
--
Added file: http://bugs.python.org/file27130/patch.py
___
Python tracker
<http://bugs.python.org/is
Tom Wardill added the comment:
Patch attached using setting test to None after execution.
--
keywords: +patch
nosy: +tomwardill
Added file: http://bugs.python.org/file27352/11798.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Tom Wardill :
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue15505>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tom Wardill :
--
versions: +Python 3.4 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue11770>
___
___
Python-bugs-list mailing list
Unsub
Changes by Tom Wardill :
--
versions: +Python 3.4 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue13476>
___
___
Python-bugs-list mailing list
Unsub
New submission from Tom Kuiper:
This error comes from the logging module when a message is logged, but only
when I also import another module which does use logging at all:
Traceback (most recent call last):
File "/usr/lib/python2.6/logging/__init__.py", line 776, in em
Tom Kuiper added the comment:
Give me a few moments to dig further. I may have found the submodule
culprit. Checking.
Tom
On 10/30/2012 05:29 PM, R. David Murray wrote:
> R. David Murray added the comment:
>
> Do none of those submodules import logging?
>
> It is unlikely
Tom Kuiper added the comment:
On 10/30/2012 05:29 PM, R. David Murray wrote:
> R. David Murray added the comment:
>
> Do none of those submodules import logging?
>
> It is unlikely that this is a Python bug. Somewhere _fmt is getting set to
> an integer. The way to pro
New submission from Tom Pohl:
According to the documentation of the floor division
(http://docs.python.org/2/reference/expressions.html#binary-arithmetic-operations),
x//y should be equal to math.floor(x/y).
However, the result of 1//0.1 is 9.0 (tested on 2.6, 2.7, 3.2).
It might be related
Tom Pohl added the comment:
Thanks for your comments. From a technical/numerical point of view I agree with
you that the computed result is correct given the floating-point limitations.
>From a user's point of view (and the documentation seems to agree with me) the
>result is
Tom Pohl added the comment:
Thanks for all the explanations why Python's floor division (FD) works as
specified. And I agree, it does work as specified, but still, I think this is
not the behavior that most people would expect and is therefore dangerous to
provide/use.
What do I expect
Tom Pohl added the comment:
Martin:
Ok, just as you suggested, I did the calculations on a sheet of paper:
floor(1 mathematically-divided-by 0.1) = floor(10) = 10
qed ;-)
--
___
Python tracker
<http://bugs.python.org/issue16
Tom Pohl added the comment:
Since nobody seems to share my point of view, I give up. :-)
Thanks for your support and for working on Python (the best programming
language as we all know),
Tom
--
___
Python tracker
<http://bugs.python.org/issue16
Tom Pohl added the comment:
You still get me wrong. Thanks to your explanations and to my personal
knowledge about this topic (programming for 28 years now; PhD in
CS/numerics/HPC) I now fully understand the technical details about the current
implementation of FD. The problem I see is that
Tom Pohl added the comment:
This is "a fact-of-life for anyone using binary floating point":
x = 0.0
while x != 1.0: print(x); x += 0.1 # so long
This is not: 1 // 0.1 = 9.0 because math.floor(1/0.1) is able to come up with
the result that is expected from an operator called "
Tom Pohl added the comment:
Mark, thanks for explaining the connection of // and %. Finally, I can see why
somebody would want to stick to the current behavior of FD.
It renders FD useless for all of my use cases, but there are simple
alternatives.
Thanks for your time,
Tom
Tom Tromey added the comment:
It sure would.
Here's a new patch.
--
Added file: http://bugs.python.org/file28223/P
___
Python tracker
<http://bugs.python.org/is
Tom Tromey added the comment:
It does fail without the patch:
test_format
XXX undetected error
test test_format failed -- Traceback (most recent call last):
File "/home/tromey/Space/Python/cpython/Lib/test/test_format.py", line 251,
in test_format
def test_exc(formatstr, args,
Tom Pinckney added the comment:
Thanks for the feedback!
I'll incorporate it this weekend and make a new patch, though also feel free to
just go ahead and make the changes yourself if you'd rather not wait for me.
--
___
Python trac
Tom Pinckney added the comment:
Draft of new updates based on Eric's feedback. I haven't done a final
proof-reading over this patch as I wanted to upload it and see if I'm heading
in the right direction first.
--
Added file: http://bugs.python.org/file29
Tom Gross added the comment:
I guess you are on a 64bit os an the issue is a variant of issue1294959. Some
of the components (scripts) are installed in the $PREFIX/lib folder and some
are (libs) installed in the $PREFIX/lib64 folder. a workaround which worked for
me (on OpenSuse 12.3 which
Changes by Tom Tromey :
--
nosy: +tromey
___
Python tracker
<http://bugs.python.org/issue10112>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tom Hines added the comment:
The trace module ignores the --ignore-dir option for both the --listfuncs and
--trackcalls modes. I have attached a patch.
--
keywords: +patch
nosy: +tomhines
Added file: http://bugs.python.org/file32437/trace.diff
New submission from Tom Lynn:
PEP 8 currently has::
Yes::
...
c = (a+b) * (a-b)
No::
...
c = (a + b) * (a - b)
That looks wrong to me -- surely the parens are a sufficient
precedence hint, and don't need further squashing inside?
This will be worse with an
Tom Lynn added the comment:
FWIW, this pair of examples differs from the others in this section
as they were both explicitly okayed in the first version of PEP 8
<http://hg.python.org/peps/rev/4c31c25bdc03?revcount=120>::
- Use your better judgment for the insertion of spaces
Changes by Tom Tromey :
--
nosy: +tromey
___
Python tracker
<http://bugs.python.org/issue11410>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Tom Flanagan:
call_tzinfo_method in Modules/_datetimemodule.c:900 calls Py_DECREF(offset)
before trying to use offset to generate a TypeError message.
This causes a crash if that was the last reference to offset and Py_DECREF
clears it.
--
components: Library (Lib
Tom Flanagan added the comment:
Included python test case which causes a segmentation fault on
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit
(AMD64)] on win32
Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux
Python 3.5.0a0 (default
Tom Goddard added the comment:
I've seen this crash about 50 times in the UCSF Chimera molecular visualization
package, same traceback, and it is caused when a tooltip is raised, but not
from IDLE. The key observation is that it only happens on dual display systems
where the second di
Tom Goddard added the comment:
More testing shows that this Mac Tk crash with dual displays only happens when
the second display is partly or entirely above the primary display in the Mac
display system preferences. An attempt to show the tooltip on the second
display above the top of the
Tom Goddard added the comment:
Ok I reported this as a Mac Tk bug and gave a very simple way to reproduce it.
http://core.tcl.tk/tk/tktview?name=3Dc84f660833
--
___
Python tracker
<http://bugs.python.org/issue16
Tom Lynn added the comment:
The secondary issue, which the patch doesn't address, is that TarFile.next()
seems unpythonic; it treats any {Invalid,Empty,Truncated}HeaderError after
offset 0 as EOF rather than propagating the exception. It looks deliberate,
but I'm not sure why i
Tom Edwards added the comment:
Still an issue in 3.3.3. Igor's fix still works, thankfully.
--
nosy: +Artfunkel
versions: +Python 3.3 -Python 2.7
___
Python tracker
<http://bugs.python.org/is
Changes by Tom Edwards :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue17213>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Tom Brander:
Trying to build a Win 32 version using VS express on Win 7 (since it cannot do
x64) Rev 89320 tried to build python 3.4 from source using VS 2010 express no
dice. It complains about solutions folder that is not supported in VS 2010
express. While this is
New submission from Tom Clarke :
The enclosed script when run under 2.6.2 IDLE standard distribution on
x86 shows that shallow copy (.copy()) of a non-empty defaultdict object
returns an empty defaultdict!
Other ways to copy, e.g. defaultdict(none, d.items()), work fine.
Bug appears under
Changes by Tom Clarke :
Added file: http://bugs.python.org/file14641/bug.py
___
Python tracker
<http://bugs.python.org/issue6637>
___
___
Python-bugs-list mailin
Tom Clarke added the comment:
NB - (discussion of significance of this bug)
Defaultdict called with no argument is anomalous & this problem can be
avoided in such cases by using dict. However this is not possible if
default value can change and the documentation specifically def
New submission from Tom Morse :
Thank you for the most excellent documentation and notes on classes in
python:
http://docs.python.org/3.1/tutorial/classes.html
I found the following minor typos and provide feedback on the above web
page:
1. Where "unpacked again" occurs there is no
New submission from Tom Seddon :
Behaviour of "Locate" in latest Windows CHM file for Python 2.6.2 is
sub-optimal.
I first spotted this with the optparse module, so this bug refers to
the optparse module. It looks as if this is a global problem, though.
First, ensure one has late
New submission from Tom Kuiper :
Normal behavior:
>>> from os import path
>>> filename
=
"/home/kuiper/Projects/microdischarges/Observing/2009-09-01/STATS_NP2000_VSR1A.1W1.09-244-193632"
>>> print filename
/home/kuiper/Projects/microdischarges/Observing/200
Tom Kuiper added the comment:
That's a good point, Marco. I'd forgotten about the distinction.
Converting 'filename' to a Python string with 'str()' fixed the problem.
> However, when I tried to run your example, newWF.py, and tried to open a
Tom Kuiper added the comment:
Do I have to do that? I've never used the Python bug tracking system
before.
> BTW: I'm happy you solved this bug.
>
I guess we could consume a few beers over whether it's a bug or not.
Cheers
Tom
--
_
Changes by Tom Lynn :
--
nosy: +tlynn
___
Python tracker
<http://bugs.python.org/issue2746>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Tom Lynn added the comment:
This bug should be re-opened, since there is definitely a bug here.
I think the patch was incorrectly rejected.
If I can expand palfrey's example:
from textwrap import *
T = TextWrapper(replace_whitespace=False, width=75)
text = '''\
a aaa
Tom Switzer added the comment:
I am not sure I understand the reasoning behind removing the cmp
parameter (and agree with Lea Wiemann). Trying to wedge a proper
comparison into the key parameter is clumsy and unreadable (as can be
seen in the 2to3 example above). The intrinsic ordering on
Tom Switzer added the comment:
Mark: I think your example actually helps illustrate my point. My point was
that computing the angle directly is less efficient or not as nice
numerically. For instance, if you are sorting points by angle relative to an
extreme point you could do something like
Tom Switzer added the comment:
If the equal min y-coords are handled, I think it'd be quicker too. As Guido
noted, O(n) function calls is better then O(n log n) =] Though the general
case is still unhandled. And, though it doesn't help my case, the Graham
Scan can also be performed
New submission from Tom Goddard :
Bytecode compiling large Python files uses an unexpectedly large amount
of memory. For example, compiling a file containing a list of 5 million
integers uses about 2 Gbytes of memory while the Python file size is
about 40 Mbytes. The memory used is 50 times
Tom Goddard added the comment:
I agree that having such large Python code files is a rare circumstance
and optimizing the byte-code compiler for that should be a low priority.
Thanks for the cpickle suggestion. The Chimera session file Python code
is mostly large nested dictionaries and
Tom Seddon added the comment:
Yes, this new version looks to do the job!
(Regarding the CSS, I'm not so sure about the serifs yet, but I'll let it sink
in and see how I feel :)
--
___
Python tracker
<http://bugs.python.
Tom Zych added the comment:
The problem went away by itself after a while. I suspect a Windows update.
--
___
Python tracker
<http://bugs.python.org/issue7
New submission from Tom Dunham :
Some regression tests for logging handlers, brings coverage up from 37% to 52%.
Mainly tests to rotating file handlers.
--
components: Library (Lib)
files: rotating_file_handlers.patch
keywords: patch
messages: 112171
nosy: Tom
priority: normal
severity
Tom Dunham added the comment:
Good point, thank you. I've updated the patch.
--
Added file: http://bugs.python.org/file18313/rotating_file_handlers.patch
___
Python tracker
<http://bugs.python.org/i
Tom Krauss added the comment:
I'm trying to add support for this in cffi, which uses ctypes... apparently
this is now supported in libffi (https://github.com/libffi/libffi, v3.2 Nov
2014).
It would be nice if this issue could be re-opened, or another one created for
the same pu
New submission from Tom Myers:
_DummyThread objects have _is_stopped = False, but _tstate_lock = None. This
causes an AssertionError in is_alive and __repr__ .
File ".../cp34/lib/python3.4/threading.py", line 814, in __repr__
self.is_alive() # easy way to get ._is_stoppe
New submission from Tom Krauss:
Consider the following simple class that provides a "__complex__" method.
class C(object):
def __init__(self, x):
self.x = x
def __complex__(self):
return self.x
x=C(-0j)
PYTHON 2.7.13
>>> x.x
-0j
>>> complex(x)
0
New submission from Tom Middleton:
I was running:
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
I downloaded the msi for Python 2.
Tom Middleton added the comment:
@Steve,
I think my pip install was fine? I was using pip pretty regularly with 2.7.11.
I had to do a restore to get 2.7.11 working again, and after an install of
2.7.12 failed again with the same issue
Tom Middleton added the comment:
@Zachary,
I tried to uninstall (the C:\python27\ directory seemed to persist after) the
install of 2.7.12 failed again same message.
--
___
Python tracker
<http://bugs.python.org/issue27
Tom Middleton added the comment:
Ok, so really bizarre. I uninstalled 2.7.11, then I was getting the same error
with the 2.7.11 msi. So I was thinking that I should go back to the original
version I had installed (2.7.10) the installer showed a "repair" option so I
did that, then
Tom Tanner added the comment:
will the fix be backported to 2.7?
--
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list mailin
Tom Pinckney added the comment:
Updated based on Ezio's comments.
--
Added file: http://bugs.python.org/file29683/patch3.diff
___
Python tracker
<http://bugs.python.org/i
Tom Pinckney added the comment:
Another update based on comments. Removed links to cProfile.py and _lsof.c.
--
Added file: http://bugs.python.org/file29756/patch4.diff
___
Python tracker
<http://bugs.python.org/issue6
Tom Pinckney added the comment:
Great!
Just signed the contributor agreement.
On Apr 10, 2013, at 1:06 PM, Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Last patch LGTM (except a couple of minor whitespace issues).
> Tom, can you sign the contributor agr
Tom Vaughan added the comment:
PATHONPATH=/tmp: will also be interpreted as "/tmp" and ".". Do the patches
also address this case? PYTHONPATH=:/tmp and PYTHONPATH=/foo::/bar are also
problematic.
--
nosy: +tvaughan
___
P
Tom Vaughan added the comment:
Oh wow. That is not what I remembered/assumed about sh and PATH. Mind. Blown.
--
___
Python tracker
<http://bugs.python.org/issue16
Tom Pinckney added the comment:
Thanks everyone for helping me through my first python patch submission.
--
___
Python tracker
<http://bugs.python.org/issue6
Tom Tanner added the comment:
this patch fixes the bug.
It parses the with WITH statement.
--
keywords: +patch
nosy: +tanner
Added file: http://bugs.python.org/file36950/with.diff
___
Python tracker
<http://bugs.python.org/issue21
Changes by Tom Tanner :
Removed file: http://bugs.python.org/file36950/with.diff
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list mailin
Changes by Tom Tanner :
Added file: http://bugs.python.org/file36952/with2.diff
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list mailin
New submission from Tom Flanagan:
When slicing or cloning a memoryview object that has been previously cast to
change its format string, the new memoryview's format shares a pointer to the
parent's format string, which may be deleted at any time.
This manifests as a corrupt format
Tom Flanagan added the comment:
Fix memoryview object allocations to copy format string
--
keywords: +patch
Added file: http://bugs.python.org/file36966/22668patch.diff
___
Python tracker
<http://bugs.python.org/issue22
New submission from Tom Christie:
This is one of those behavioural issues that is a borderline bug.
The seperators argument to `json.dumps()` behaves differently across python 2
and 3.
* In python 2 it should be provided as a bytestring, and can cause a
UnicodeDecodeError otherwise.
* In
Tom Christie added the comment:
Not too fussed if this is addressed or not, but I think this is closed a little
prematurely.
I don't think there's a problem under Python 3, that's entirely reasonable.
However under Python 2, `json.dumps()` will normally handle *either* by
Tom Christie added the comment:
> But only if you use non-ascii in the binary input, in which case you get an
> encoding error, which is a correct error.
Kind of, except that this (python 2.7) works just fine:
>>> data = {'snowman': '☃'}
>
Tom Christie added the comment:
> So, as soon as (but only as soon as) you mix unicode with your non-ascii
> data, your program blows up.
Indeed. For context tho my example of running into this the unicode literals
used as seperators weren't even in the same package as the non-A
Tom Tanner added the comment:
ping
I'd appreciate a review of my patch.
--
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list m
Tom Tanner added the comment:
I confirm this fixes a bug.
To reproduce it just add, e.g.
X-Multline-Header: foo
bar
to your request.
It has been fixed in Python 3 with
https://github.com/python/cpython/commit/67dcb80f6e102622e4aa888930d3017fed9834de
--
nosy: +tanner
Tom Christie added the comment:
I believe the status of this should be reassessed and that python should
default to escaping '\u2028' and '\u2029'. *Strictly* speaking this isn't a bug
and is per the JSON spec.
*However* this *is* a bug in the JSON spec - which *shoul
Tom Christie added the comment:
> There is explicit note in the documentation about incompatibility with
> JavaScript.
That may be, but we're still unnecessarily making for a poorer user experience.
There's no good reason why we shouldn't just treat \u2028 and \u2029 a
Tom Tanner added the comment:
This is actually more complicated than I initially thought.
According to
https://www.python.org/dev/peps/pep-/#the-start-response-callable
"Each header_value must not include any control characters, including carriage
returns or linefeeds, either embedd
Tom Tanner added the comment:
attached is the updated patch, which unfolds multiline headers but not validate
them (tests included).
--
Added file: http://bugs.python.org/file37409/wsgi2.diff
___
Python tracker
<http://bugs.python.org/issue21
Tom Tanner added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue21114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Tom Edwards:
Consider this script:
f = open("bug>test.txt",'w')
f.write("hello")
f.close()
On Windows the first line will throw an OSError exception because the character
'>' is not valid in an NTFS filename. This is
Tom Edwards added the comment:
Ha! What a feature. Thanks for the link.
Maybe I'm rehashing old arguments, but I still think that Python's behaviour in
this case is wrong. This is very surprising behaviour to anyone who isn't
intimately familiar with NTFS and should not be so
Tom Hines added the comment:
Test attached. Paste into test/test_trace.py. I tested in 2.7 and 3.4. Feel
free to modify it.
--
Added file: http://bugs.python.org/file39503/test_ignoredir.py
___
Python tracker
<http://bugs.python.org/issue10
New submission from Tom Pohl:
>From the ctypes.create_string_buffer docs:
"""If a bytes object is specified as first argument, the buffer is made one
item larger than its length so that the last element in the array is a NUL
termination character. An integer can be passed
Tom Pohl added the comment:
I agree: not every buffer is null-terminated.
But the function name suggests that it creates a _string_ buffer which will
most likely be used as an input to a C function. There, it can easily trigger a
buffer overflow without a null termination which can be
Tom Pohl added the comment:
If one needs to set a general buffer (i.e. not a null-terminated string buffer)
one could always use:
>>> string = (ctypes.c_char*4)()
>>> string.raw = b'abcd'
--
___
Python tracker
<ht
New submission from Tom Meagher:
"if flag is False, system calls will be restarted when interrupted by signal
signalnum, otherwise system calls will be interrupted."
This sentence doesn't make any sense as written. I assume there should be a
"not" in there some
Tom F added the comment:
I've found this to be annoying as well especially in docstrings, hopefully this
will help in the meantime.
If you SHIFT + Tab it will at least resolve the problem of bringing up files
and remains as the usual tab function.
It makes me wonder if it is a bug a
Tom Lynn added the comment:
I think issue24514 (fixed in Py2.7.11) is a duplicate of this issue.
--
___
Python tracker
<http://bugs.python.org/issue15858>
___
___
New submission from Tom Anderl:
When the HTMLParser encounters a start tag element that includes:
1. an unquoted attribute as the final attribute
2. an optional '/' character marking the start tag as self-closing
3. no space between the final attribute and the '/&
Tom Parker added the comment:
FYI, I ran into this same issue, I believe this was caused by my selecting
Python tools when installing Visual Studio 2015 Community edition. But I
removed it and the issued didn't go away.
Then I deleted some empty python registry keys and voila the inst
Tom Parker added the comment:
Ah OK :) I had done a W10 reset to wipe my PC before reinstalling VS so I
could't imagine where else the python registry keys could have come from.
My install sequence was:
SQL Server 2012 Developer
Visual Studio 2015 Community Edition
Office 365
Inkscape -
301 - 400 of 422 matches
Mail list logo
