Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset ab6496b98ac4 by Lars Gustäbel in branch 'default':
Issue #13815: Resurrect the ExFileObject class.
http://hg.python.org/cpython/rev/ab6496b98ac4
--
___
Python tracker
Lars Gustäbel l...@gustaebel.de added the comment:
Okay, I close this issue now, as I think the problems are now resolved.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13815
Lars Gustäbel l...@gustaebel.de added the comment:
Okay, I attached a patch that I hope we can all agree upon. It restores the
ExFileObject class as a small subclass of BufferedReader as Amaury suggested.
Does the documentation have to be changed, too? It states that an
io.BufferedReader
R. David Murray rdmur...@bitdance.com added the comment:
I don't think a doc change is needed. An isinstance check based on the docs
will succeed, and the rest is an implementation detail, I think.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Well, if it's not documented, it's technically a private API.
Also, there doesn't seem to be any explicit use of ExFileObject outside of
tarfile.py:
http://code.google.com/codesearch#searchq=lang:python+exfileobject
--
nosy: +pitrou
Lars Gustäbel l...@gustaebel.de added the comment:
In an earlier draft of my patch, I had kept ExFileObject as a subclass of
BufferedReader, but I later decided against it. To use BufferedReader directly
is in my opinion the cleaner solution.
I admit that the change is not fully backward
R. David Murray rdmur...@bitdance.com added the comment:
Yeah, I know it is technically private. We still tend to keep names around
unless there's a good reason to delete them (like using them leads to broken
code anyway). The code search is some evidence this deletion would be OK, but
why
Antoine Pitrou pit...@free.fr added the comment:
Yeah, I know it is technically private. We still tend to keep names
around unless there's a good reason to delete them (like using them
leads to broken code anyway). The code search is some evidence this
deletion would be OK, but why *not*
R. David Murray rdmur...@bitdance.com added the comment:
Code search is not proof, I'm afraid. It is evidence, though, and I thought I
indicated I thought it was a good argument in favor of dropping the class.
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Code search is not proof, I'm afraid. It is evidence, though, and I
thought I indicated I thought it was a good argument in favor of
dropping the class.
Yes, sorry for the vocabulary mismatch :-)
--
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I came here when I saw this comment in the diff: # Keep the traditional
pre-3.3 API intact. Why keep an internal API intact if we do it partially?
The ExFileObject class above will also simplify the code: simply return
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I think it would have been better to keep the ExFileObject class, and base it
on io.BufferedReader:
class ExFileObject(io.BufferedReader):
def __init__(self, tarfile, tarinfo):
raw = _FileInFile(tarfile.fileobj,
R. David Murray rdmur...@bitdance.com added the comment:
Indeed, even though it is not a documented API, our backward compatibility
policy pretty much requires that something named ExFileObject still exist, just
in case. And in this case it probably should still be the thing returned.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 254cb4f5d0ff by Lars Gustäbel in branch 'default':
Issue #13815: TarFile.extractfile() now returns io.BufferedReader objects.
http://hg.python.org/cpython/rev/254cb4f5d0ff
--
nosy: +python-dev
Lars Gustäbel l...@gustaebel.de added the comment:
I did some tarfile spring cleaning: I removed the ExFileObject class completely
as it was more or less a leftover from the old days. io.BufferedReader now does
the job. So, as a side-effect, I close this issue as fixed.
(BTW, this makes
Éric Araujo mer...@netwok.org added the comment:
Please always use explicit roles in reST, i.e. :meth:`flush` instead of `flush`
(use ``flush`` when you don’t want a ton of identical links).
In the test, using assertEqual instead of assertTrue will certainly give more
useful output in case of
Terry J. Reedy tjre...@udel.edu added the comment:
Based on other examples in the doc, I think the note
... and also supports iteration over its lines.
should be extended with
It also has a dummy `flush` method, so that it can be wrapped using
:class:`io.TextIOWrapper`.
Then just add
..
New submission from Colin Watson cjwat...@users.sourceforge.net:
The file-like object returned by TarFile.extractfile can't be wrapped in an
io.TextIOWrapper (which would be rather convenient in some cases to get
something that reads str rather than bytes).
The attached patch demonstrates the
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13815
___
___
Python-bugs-list mailing
Changes by Lars Gustäbel l...@gustaebel.de:
--
assignee: - lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13815
___
20 matches
Mail list logo