[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Change by Matt Bogosian : -- pull_requests: +29919 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/31821 ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Change by Matt Bogosian : -- keywords: +patch nosy: +mbogosian nosy_count: 4.0 -> 5.0 pull_requests: +29243 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31061 ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Matt Bogosian added the comment: Please consider highlighting that dicts are not included in the documentation. While *technically* true, this ... > compact impacts the way that long sequences (lists, tuples, sets, etc) are > formatted. If compact is false (the default) then each item of a sequence > will be formatted on a separate line. If compact is true, as many items as > will fit within the width will be formatted on each output line. ... has several problems. First, sequence is a term of art that also has a common meaning. This creates a potential ambiguity in the understanding of the reader. Resolving that ambiguity in this context requires that readers have already internalized that dicts are not Python sequences. Those new to Python may not understand the (to them, subtle) differences between Python's iterables and sequences. Second, the "etc" only expands that ambiguity and invites confusion. Third, the term "items" is strongly associated with dicts and is used several times throughout the paragraph. This ... > According to https://docs.python.org/3/library/pprint.html compact impacts > the way that sequences are displayed, and a dict is not a sequence. ... is unhelpfully pedantic, and ignorant of the needs of the newcomer (a key demographic of documentation). Documentation is a core product surface with a diverse audience. Rather than focus on technical correctness, documentation authors should focus on accessibility. Redundancy is a feature, not a bug. You can't predict how your reader got to that slice of the documentation. Imagine this as an opportunity to educate or reinforce concepts for readers, not as an opportunity to argue from a position of technical superiority. The fact that there are now four developers who have taken their time to file patches, bugs, and comments is pretty strong signal that confusion exists among the audience and that the documentation is insufficient. -- nosy: +posita ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40346] Add random.BaseRandom to ease implementation of subclasses
Matt Bogosian added the comment: Thanks! Where's that documented? (Apologies if I missed it.) -- ___ Python tracker <https://bugs.python.org/issue40346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40346] Add random.BaseRandom to ease implementation of subclasses
Matt Bogosian added the comment: I landed here after investigating this surprising result: # test_case.py from random import Random from typing import Sequence, Union _RandSeed = Union[None, int, Sequence[int]] class MyRandom(Random): def __init__( self, seed: _RandSeed = None, ): if seed is not None and not isinstance(seed, int): seed = sum(seed) super().__init__(seed) MyRandom([1, 2]) Output: python ./test_case.py Traceback (most recent call last): File "/…/./test_case.py", line 16, in MyRandom([1, 2]) TypeError: unhashable type: 'list' In my observation, the Random class aspires to be an interface (and default implementation), but doesn't really live up to those aspirations. (See also https://github.com/python/typeshed/issues/6063.) I suspect nudging Random closer to its claims was the point of this proposal. I'm kind of sad it (or something like it) was rejected in favor of a process that will probably take years. Is there a reason not to do both, meaning heal what lives in the standard library now to live up to its own marketing *and* work toward a better interface in the future? -- nosy: +posita ___ Python tracker <https://bugs.python.org/issue40346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
Matt Bogosian added the comment:
After some consideration, I think this is probably more correct:
```
--- /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py
2016-12-17 12:41:21.0 -0800
+++ tarfile.py 2017-03-10 14:57:15.0 -0800
@@ -2347,9 +2347,10 @@
# Advance the file pointer.
if self.offset != self.fileobj.tell():
-self.fileobj.seek(self.offset - 1)
+self.fileobj.seek(max(self.offset - 1, 0))
if not self.fileobj.read(1):
raise ReadError("unexpected end of data")
+self.fileobj.seek(self.offset)
# Read the next block.
tarinfo = None
```
But again, I'm no expert here.
--
Added file: http://bugs.python.org/file46719/tarfile.patch
___
Python tracker
<http://bugs.python.org/issue29760>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
Changes by Matt Bogosian : Removed file: http://bugs.python.org/file46717/tarfile.patch ___ Python tracker <http://bugs.python.org/issue29760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
Matt Bogosian added the comment:
This patch (also attached) seems to address this particular use case:
```
--- a/Lib/tarfile.py2016-12-17 12:41:21.0 -0800
+++ b/Lib/tarfile.py2017-03-10 12:23:34.0 -0800
@@ -2347,7 +2347,7 @@
# Advance the file pointer.
if self.offset != self.fileobj.tell():
-self.fileobj.seek(self.offset - 1)
+self.fileobj.seek(max(self.offset - 1, 0))
if not self.fileobj.read(1):
raise ReadError("unexpected end of data")
```
However, I am unfamiliar with the code, especially in light of #24259, and
haven't tested it thoroughly. Oversight is needed.
--
keywords: +patch
Added file: http://bugs.python.org/file46717/tarfile.patch
___
Python tracker
<http://bugs.python.org/issue29760>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
Matt Bogosian added the comment:
I'm not sure if it helps at this point, but I've tried several "flavors" of
apparently legit tar files with zero entries. All fail.
``tarfile`` module:
```
$ ( set -x ; cd /tmp || exit 1 ; python -V ; rm -fv test.tar ; python -c
'import os, tarfile ; fd = os.open("test.tar", os.O_WRONLY | os.O_CREAT |
os.O_EXCL) ; f = os.fdopen(fd, "w") ; f = tarfile.open("test.tar", "w", f) ;
f.close() ; f = tarfile.open("test.tar") ; print("okay so far; calling
f.next()...") ; f.next()' ; openssl dgst -sha256 test.tar ; rm -fv test.tar )
+/bin/zsh:496> cd /tmp
+/bin/zsh:496> python -V
Python 2.7.13
+/bin/zsh:496> rm -v -fv test.tar
+/bin/zsh:496> python -c 'import os, tarfile ; fd = os.open("test.tar",
os.O_WRONLY | os.O_CREAT | os.O_EXCL) ; f = os.fdopen(fd, "w") ; f =
tarfile.open("test.tar", "w", f) ; f.close() ; f = tarfile.open("test.tar") ;
print("okay so far; calling f.next()...") ; f.next()'
okay so far; calling f.next()...
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py",
line 2350, in next
self.fileobj.seek(self.offset - 1)
IOError: [Errno 22] Invalid argument
+/bin/zsh:496> openssl dgst -sha256 test.tar
SHA256(test.tar)=
84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652
+/bin/zsh:496> rm -v -fv test.tar
test.tar
```
BSD tar (OS X):
```
$ ( set -x ; cd /tmp || exit 1 ; tar --version ; rm -fv test.tar ; tar -cf
test.tar -T /dev/null ; python -c 'import tarfile ; f =
tarfile.open("test.tar") ; print("okay so far; calling f.next()...") ;
f.next()' ; openssl dgst -sha256 test.tar ; rm -fv test.tar )
+/bin/zsh:499> cd /tmp
+/bin/zsh:499> tar --version
bsdtar 2.8.3 - libarchive 2.8.3
+/bin/zsh:499> rm -v -fv test.tar
+/bin/zsh:499> tar -cf test.tar -T /dev/null
+/bin/zsh:499> python -c 'import tarfile ; f = tarfile.open("test.tar") ;
print("okay so far; calling f.next()...") ; f.next()'
okay so far; calling f.next()...
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py",
line 2350, in next
self.fileobj.seek(self.offset - 1)
IOError: [Errno 22] Invalid argument
+/bin/zsh:499> openssl dgst -sha256 test.tar
SHA256(test.tar)=
5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
+/bin/zsh:499> rm -v -fv test.tar
test.tar
```
GNU tar (OS X via MacPorts):
```
( set -x ; cd /tmp || exit 1 ; gnutar --version ; rm -fv test.tar ; gnutar -cf
test.tar -T /dev/null ; python -c 'import tarfile ; f =
tarfile.open("test.tar") ; print("okay so far; calling f.next()...") ;
f.next()' ; openssl dgst -sha256 test.tar ; rm -fv test.tar )
+-zsh:23> cd /tmp
+-zsh:23> gnutar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.
+-zsh:23> rm -v -fv test.tar
+-zsh:23> gnutar -cf test.tar -T /dev/null
+-zsh:23> python -c 'import tarfile ; f = tarfile.open("test.tar") ;
print("okay so far; calling f.next()...") ; f.next()'
okay so far; calling f.next()...
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py",
line 2350, in next
self.fileobj.seek(self.offset - 1)
IOError: [Errno 22] Invalid argument
+-zsh:23> openssl dgst -sha256 test.tar
SHA256(test.tar)=
84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652
+-zsh:23> rm -v -fv test.tar
test.tar
```
The discussion from #24259 does not appear to contemplate this case, and seems
to imply an assumption that there will be at least one entry (which is not
always the case).
--
___
Python tracker
<http://bugs.python.org/issue29760>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
Matt Bogosian added the comment: FWIW, the (offending) fix for #24259 was introduced (e.g., in 2.7) via 2.7.10. I've verified that 2.7.9 works as expected: ``` $ python -V Python 2.7.9 $ python tarfail.py opening /…/tarfail/test.tar.bz2 opening /…/tarfail/test.tar . -- Ran 1 test in 0.010s OK ``` So this should probably be considered a regression. -- ___ Python tracker <http://bugs.python.org/issue29760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)
New submission from Matt Bogosian: It looks like there's a problem examining ``.tar`` files with no entries: ``` $ # == $ # Extract test cases (attached to this bug report) $ tar xpvf tarfail.tar.bz2 x tarfail/ x tarfail/tarfail.py x tarfail/test.tar x tarfail/test.tar.bz2 $ cd tarfail $ # == $ # Note that test.tar.bz2 is just test.tar, but bzip2'ed: $ bzip2 -c test.tar | openssl dgst -sha256 ; openssl dgst -sha256 test.tar.bz2 f4fad25a0e7a451ed906b76846efd6d2699a65b40795b29553addc35bf9a75c8 SHA256(test.tar.bz2)= f4fad25a0e7a451ed906b76846efd6d2699a65b40795b29553addc35bf9a75c8 $ wc -c test.tar* # these are not empty files 10240 test.tar 46 test.tar.bz2 10286 total $ tar tpvf test.tar # no entries $ tar tpvf test.tar.bz2 # no entries $ # == $ # test.tar.bz2 works, but test.tar causes problems (tested in 2.7, $ # 3.5, and 3.6): $ python2.7 tarfail.py opening /…/tarfail/test.tar.bz2 opening /…/tarfail/test.tar E == ERROR: test_next (__main__.TestTarFileNext) -- Traceback (most recent call last): File "tarfail.py", line 29, in test_next next_info = tar_file.next() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2350, in next self.fileobj.seek(self.offset - 1) IOError: [Errno 22] Invalid argument -- Ran 1 test in 0.005s FAILED (errors=1) $ python3.5 tarfail.py opening /…/tarfail/test.tar.bz2 opening /…/tarfail/test.tar E == ERROR: test_next (__main__.TestTarFileNext) -- Traceback (most recent call last): File "tarfail.py", line 29, in test_next next_info = tar_file.next() File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tarfile.py", line 2273, in next self.fileobj.seek(self.offset - 1) OSError: [Errno 22] Invalid argument -- Ran 1 test in 0.066s FAILED (errors=1) $ python3.6 tarfail.py opening /…/tarfail/test.tar.bz2 opening /…/tarfail/test.tar E == ERROR: test_next (__main__.TestTarFileNext) -- Traceback (most recent call last): File "tarfail.py", line 29, in test_next next_info = tar_file.next() File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tarfile.py", line 2279, in next self.fileobj.seek(self.offset - 1) OSError: [Errno 22] Invalid argument -- Ran 1 test in 0.090s FAILED (errors=1) ``` Here's the issue (as far as I can tell): ``` $ ipdb tarfail.py > /…/tarfail/tarfail.py(3)() 2 > 3 from __future__ import ( 4 absolute_import, division, print_function, unicode_literals, ipdb> b /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py:2350 Breakpoint 1 at /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py:2350 ipdb> c opening /…/tarfail/test.tar.bz2 > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py(2350)next() 2349 if self.offset != self.fileobj.tell(): 1> 2350 self.fileobj.seek(self.offset - 1) 2351 if not self.fileobj.read(1): ipdb> self.fileobj ipdb> self.offset, self.fileobj.tell(), self.offset - 1 (0, 512, -1) ipdb> c opening /…/tarfail/test.tar > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py(2350)next() 2349 if self.offset != self.fileobj.tell(): 1> 2350 self.fileobj.seek(self.offset - 1) 2351 if not self.fileobj.read(1): ipdb> self.fileobj ipdb> self.offset, self.fileobj.tell(), self.offset - 1 (0, 512, -1) ipdb> c E == ERROR: test_next (__main__.TestTarFileNext) -- Traceback (most recent call last): File "tarfail.py", line 29, in test_next next_info = tar_file.next() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2350, in next self.fileobj.seek(self.offset - 1) IOError: [Errno 22] Invalid argument -- Ran 1 test in 38.300s FAILED (errors=1) The program exited via
[issue28981] distutils/check.py overzealous catch block hides errors
New submission from Matt Bogosian:
>From (e.g)
>https://github.com/python/cpython/blob/2.7/Lib/distutils/command/check.py#L145:
{{{
try:
parser.parse(data, document)
except AttributeError as e: # <- this could happen anywhere inside
parser.parse
reporter.messages.append(
(-1, 'Could not finish the parsing: %s.' % e, '', {}))
}}}
Without a stack trace, diagnosing problems like #23063 becomes unnecessarily
difficult. See also:
* https://sourceforge.net/p/docutils/bugs/270/
* https://sourceforge.net/p/docutils/bugs/302/
I'd offer a patch, but I'm not sure what is meant to be signaled by the
`AttributeError`. (Could `parser.parse` not exist? Is it something else?)
--
components: Distutils
messages: 283338
nosy: dstufft, eric.araujo, posita
priority: normal
severity: normal
status: open
title: distutils/check.py overzealous catch block hides errors
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue28981>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives.
Changes by Matt Bogosian : -- nosy: +posita ___ Python tracker <http://bugs.python.org/issue23063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py
Matt Bogosian added the comment: > I consider this as a bug and think that we should weak some of checks > isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too > wide type, C implementation doesn't support it. Oddly enough, the C implementation is what is working with `future` in this case (although I take your point regarding `numbers.Integral` being too wide; `future.types.newint` effectively behaves like a `long`, and `isinstance(future.types.newint(1), long)` returns `True`). -- ___ Python tracker <http://bugs.python.org/issue25714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py
New submission from Matt Bogosian: datetime.py is peppered with ``assert`` statements that are two restrictive. Specifically, ``isinstance(..., int)`` does not afford compatibility with alternate ``int``-like implementations (e.g., ``future.types.newint``). Some background: * https://github.com/PythonCharmers/python-future/issues/187 * https://bitbucket.org/pypy/pypy/issues/2193/datetimetimedelta-chokes-on-seconds In all cases that I can find, ``assert isinstance(..., int)`` is unnecessarily restrictive, since it is always followed by another ``assert`` which validates that the boundaries are far smaller than a Python 2 native `int` type. (See, e.g., `datetype.py at line 395 <https://hg.python.org/cpython/file/ebec1a98ab81/Lib/datetime.py#l395>`__). I propose replacing instances of ``assert isinstance(..., int)`` and ``assert isinstance(..., (int, long))`` with ``assert isinstance(..., numbers.Integral)`` akin to `this patch <https://bitbucket.org/pypy/pypy/pull-requests/361/fix-2193/diff>`__. -- components: Library (Lib) messages: 255211 nosy: posita priority: normal severity: normal status: open title: Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
