Tom Lynn added the comment:
I think issue24514 (fixed in Py2.7.11) is a duplicate of this issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 it would
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 any non
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 around
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']
$ python -c 'import tarfile, patch
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 rep...@bugs.python.org
http://bugs.python.org/issue15858
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
rather
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 fields
Tom Lynn tl...@users.sourceforge.net added the comment:
I've also been attempting to look into this and came up with an almost
identical patch, which is promising:
https://bitbucket.org/tlynn/issue1859/diff/textwrap.py?diff2=041c9deb90a2diff1=f2c093077fbf
I missed the wordsep_simple_re though
Tom Lynn tl...@users.sourceforge.net added the comment:
I'm still unsure. I think this confusion does cause bugs in real-world code.
Perhaps more prominence for \A and \Z in the docs? There's already a section
comparing regexps starting '^' with match under Matching vs Searching
Tom Lynn tl...@users.sourceforge.net added the comment:
Actually, looking at the second part of the docs for $ (on foo.$) makes me
think the main motivating case here may be a bug in re.match::
re.match('foo$', 'foo\n\n')
re.match('foo$', 'foo\n')
_sre.SRE_Match object
Tom Lynn tl...@users.sourceforge.net added the comment:
Oh dear, I'm wrong on two fronts (I wish Roundup had post editing).
a) foo$ doesn't match the 'foo' part of 'foo\nbar' as I stated above, but does
match the 'foo' part of 'foo\n'.
b) Obviously shortening an input string can cause
Tom Lynn tl...@users.sourceforge.net added the comment:
(Sorry to comment on a closed issue, it was closed as I was writing this.)
It's not that I'm not convinced of the need, just not of the solution. I still
think that there are problems here:
a) forgetting any \Z or $ terminator
Tom Lynn tl...@users.sourceforge.net added the comment:
I don't know whether it should stand, I'm somewhere around 0 on it myself. So I
guess that means it shouldn't, since it's easier to add features than remove
them. The problem is that once you're aware of the need for it you need it less
Tom Lynn tl...@users.sourceforge.net 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
Changes by Tom Lynn tl...@users.sourceforge.net:
--
nosy: +tlynn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2746
___
___
Python-bugs-list
Tom Lynn tl...@users.sourceforge.net added the comment:
The only difference between the two regexps is that the email/header.py
version looks for::
(?=[ \t]|$) # whitespace or the end of the string
at the end (with re.MULTILINE, so $ also matches '\n').
To expand
Tom Lynn tl...@users.sourceforge.net added the comment:
Duplicates issue1047.
--
nosy: +tlynn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4958
Tom Lynn tl...@users.sourceforge.net added the comment:
Oops, duplicates issue 1079 even.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4958
___
___
Python
Tom Lynn tl...@users.sourceforge.net added the comment:
Duplicates issue1079.
--
nosy: +tlynn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4491
New submission from Tom Lynn tl...@users.sourceforge.net:
The docs for time.ctime() (quoted below) seem to have been copied from
time.asctime(). They refer to a time tuple and localtime(), where they
should refer to seconds and time().
Current docs::
ctime(seconds) - string
Changes by Tom Lynn tl...@users.sourceforge.net:
--
components: +Library (Lib)
type: - feature request
versions: +Python 2.5, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5079
New submission from Tom Lynn tl...@users.sourceforge.net:
This file fails when run with doctest.testfile::
print __name__
__builtin__
print globals()['__name__'] # fails with KeyError: __name__
__builtin__
__builtin__ is probably not a good value, but more importantly, this
means
Tom Lynn [EMAIL PROTECTED] added the comment:
Yes, that's right. The binary aspect of it was something of a red
herring, I'm afraid, although I still think that (or parsing in general)
is an important use case. The prime motivation it that it's easy to
either forget the '\Z' or to use
New submission from Tom Lynn [EMAIL PROTECTED]:
urllib2.py:424 (Py 2.4) or urllib2.py:443 (Py 2.5) in build_opener()::
skip = []
for klass in default_classes:
for check in handlers:
if inspect.isclass(check):
if issubclass(check
Tom Lynn added the comment:
Nice changes to the wording. (For the record: it's r60316 in fact.)
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1631394
_
___
Python-bugs
Tom Lynn added the comment:
Thanks for fixing this. I now also note that (?=...), (?!...) and (?
(id/name)yes-pattern|no-pattern) aren't documented, and nor is finditer
in the main docstring.
The attached patch fixes these, as well as what looks like mistaken
formatting on one line. Some
27 matches
Mail list logo
