[issue11203] gzip doc is behind

Éric Araujo added the comment: Just one thing: > I think the close call needs equal treatment to the open call. The open call is a module-level functions; the close method of GzipFile cannot be equally treated, as it is in the doc of the class, where no methods are given special treatment :)

[issue11203] gzip doc is behind

K Richard Pixley added the comment: I'm now convinced this isn't worth fixing in 2.x. -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ _

[issue11203] gzip doc is behind

K Richard Pixley added the comment: I didn't miss it. I think the close call needs equal treatment to the open call. The mention is certainly present, but seems implicit to me. I would prefer to see it listed explicitly. But I also don't think it's important enough in the 2.7 docs to discu

[issue11203] gzip doc is behind

Éric Araujo added the comment: > I see no such reference in the 2.7 gzipfile doc Did you miss the first part of my previous message? The 2.7 docs for GzipFile do not link to the ABC, but they mention the close method in plain text. -- ___ Python t

[issue11203] gzip doc is behind

K Richard Pixley added the comment: An interesting point, although I think that's only relevant if the documentation lists the ABC and a reference to it. (python-3 doc essentially does this.) I see no such reference in the 2.7 gzipfile doc, which leads me to believe, (from the doc alone), t

[issue11203] gzip doc is behind

Éric Araujo added the comment: In 2.7, while there is no index-generating entry for the close method, it is mentioned: “Calling a GzipFile object’s close() method [...]”. > Yes, I concur that there is an implication, but I would prefer to see > it stated explicitly along with the explicit stat

[issue11203] gzip doc is behind

K Richard Pixley added the comment: My point was for python-2.7. I haven't stumbled into the buffer protocol yet. So no, it doesn't really. I still think the documentation, especially the 2.7 doc, could be more explicit. My concern here is with the use of close() becoming obscure, a second

[issue11203] gzip doc is behind

Éric Araujo added the comment: > This implies that it also supports close(). One has to follow the link to BufferedIOBase and then to IOBase, but I think it’s okay. Richard: Does that address your issue? -- ___ Python tracker

[issue11203] gzip doc is behind

Antoine Pitrou added the comment: The 3.x doc states that "GzipFile supports the io.BufferedIOBase interface, including iteration and the with statement. Only the truncate() method isn’t implemented". This implies that it also supports close(). -- nosy: +pitrou versions: -Python 3.1,

[issue11203] gzip doc is behind

Changes by Adam Woodbeck : -- nosy: +adam.woodbeck ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue11203] gzip doc is behind

Éric Araujo added the comment: Thanks for the report. Would you like to propose a patch? -- nosy: +eric.araujo versions: +Python 3.1, Python 3.2 ___ Python tracker ___

[issue11203] gzip doc is behind

New submission from K Richard Pixley : The documentation for gzip should include the "close" method. It's use in the 2.7 documentation implies it's existence but it should also be stated explicitly that it exists. In the 3.x documentation, the use of "close" not in the examples since the exam