[issue3430] httplib.HTTPResponse documentations inconsistent
ThomasH thomas.bugzi...@gmx.net added the comment: Still applies. Neither the 2.7 documentation has changed (judging from the current online dev docs), nor the implementation (judging from current svn). So my first two lists are still valid. I cannot comment on the third, as I don't have a 2.7 installation at hand, or will have any time soon. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3428] httplib.HTTPMessage undocumented
ThomasH thomas.bugzi...@gmx.net added the comment: Actually urllib.urlopen.info method return a mimetools.Message instance But the urllib.rst documentation is still flawed: The :meth:`info` method returns an instance of the class :class:`httplib.HTTPMessage` (http://svn.python.org/view/python/trunk/Doc/library/urllib.rst?revision=81775view=markup) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6395] Infinite Recursion during Unpickling a codecs Object
ThomasH thomas.bugzi...@gmx.net added the comment: Sounds good to me. The main intention of this bug is not to make codecs objects pickleable by all means (I don't know if this would be sensible and/or possible), but at least to have them degrade gracefully during pickling, particularly without infinite recursion. I've changed the bug title to reflect this. -- title: Add Pickle Support to the codecs Module - Infinite Recursion during Unpickling a codecs Object ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6395 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6395] Add Pickle Support to the codecs Module
New submission from ThomasH thomas.bugzi...@gmx.net: I recently ran into an infinite recursion trying to unpickle a codecs.StreamWriter object (I presume the issue would be the same for a StreamReader). Here is the end of the stack trace: File /sw/lib/python2.5/codecs.py, line 330, in __getattr__ return getattr(self.stream, name) File /sw/lib/python2.5/codecs.py, line 330, in __getattr__ return getattr(self.stream, name) File /sw/lib/python2.5/codecs.py, line 330, in __getattr__ return getattr(self.stream, name) RuntimeError: maximum recursion depth exceeded The issue is the same under Python2.6 but the error output has changed (see http://bugs.python.org/issue5508). The problem is that the codecs module tries to delegate member lookup to the underlying stream. But after unpickling, self.stream is not defined, so the reference to self.stream in __getattr__ itself leads to an invocation of __getattr__ - hence the recursion loop. Using tools from the Pickle protocol, like __getstate__/__setstate__, could help degrade codecs objects gracefully during pickle/unpickle cycles. E.g. it might be enough to provide a dummy self.stream through __setstate__. -- components: Library (Lib) messages: 89985 nosy: ThomasH severity: normal status: open title: Add Pickle Support to the codecs Module type: crash versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6395 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3429] urllib.urlopen() return type
ThomasH [EMAIL PROTECTED] added the comment: On Fri, Aug 8, 2008 at 2:04 AM, Senthil [EMAIL PROTECTED] wrote: Senthil [EMAIL PROTECTED] added the comment: I agree with Benjamin on this issue, describing what is a File like Object is so much un-needed in Python and especially at urlopen function. Users have been able to understand and use it properly from a long time. If only it were more file-like. But, oh, it adds info() and geturl() methods which you have to string-search for to find the proper description in the prose. And, ah, the size argument of the read() method doesn't quite behave like on other file-like objects, but there you go. And, uh, by the way, you really can't use it in places where a true built-in file object is required (and I'm sure everybody knows what that means). - So much for file-like. I have no doubt that people can get along with the description as it is, because that's what they always try. My main point was that it is less approachable and breaks the usual format of a class documentation. But I see there is much agreement in keeping the status quo. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3429 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3429] urllib.urlopen() return type
ThomasH [EMAIL PROTECTED] added the comment: Georg, you seem like a dedicated person. I'm sure you guys have thought about documenting return types of methods and functions in a standardized way, documenting classes so that you could fade in and out inherited features, and such. Where do you guys discuss general documentation issues? Is there a mailing list dedicated to Python documentation?! On Fri, Aug 8, 2008 at 8:43 AM, Georg Brandl [EMAIL PROTECTED] wrote: Georg Brandl [EMAIL PROTECTED] added the comment: Agreed. -- resolution: - works for me status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3429 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3429 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3427] urllib documentation: urlopen().info() return type
New submission from ThomasH [EMAIL PROTECTED]: http://docs.python.org/lib/module-urllib.html The page says that the return type of urlopen().info() is a mimetools.Message object, which is not quite true; it is a httplib.HTTPMessage object, which is a class derived from mimetools.Message, but with additional features. The httplib.HTTPMessage class is not documented at all, for which I will file a separate bug. -- assignee: georg.brandl components: Documentation messages: 70154 nosy: ThomasH, georg.brandl severity: normal status: open title: urllib documentation: urlopen().info() return type type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3428] httplib.HTTPMessage undocumented
New submission from ThomasH [EMAIL PROTECTED]: The httplib.HTTPMessage class needs documentation; it is missing from the package documentation entirely. Instances of this class are e.g. returned by the urllib.urlopen().info() method. -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70155 nosy: ThomasH, georg.brandl severity: normal status: open title: httplib.HTTPMessage undocumented versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3429] urllib.urlopen() return type
New submission from ThomasH [EMAIL PROTECTED]: The file-like object returned by urllib.urlopen() should be documented like a proper class. The textual description under the urlopen() method is less approachable and breaks the usual format of a class documentation. Maybe the return type should be changed to be a httplib.HTTPResponse object (but that's a separate issue). -- assignee: georg.brandl components: Documentation messages: 70156 nosy: ThomasH, georg.brandl severity: normal status: open title: urllib.urlopen() return type type: feature request versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3429 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3430] httplib.HTTPResponse documentations inconsistent
New submission from ThomasH [EMAIL PROTECTED]: The library reference documentation of httplib.HTTPResponse does not match up with the online help documentation, or with the dir() information of a particular instance. E.g. the list of public features in the library reference (http://docs.python.org/lib/httpresponse-objects.html) is: - read - getheader - getheaders - msg - version - status - reason From the online documentation (with 'help(httplib.HTTPResponse)'): - begin - close - getheader - getheaders - isclosed - read And from a class instance (via 'dir(httpResponseInstance)'): - 'begin', - 'chunk_left', - 'chunked', - 'close', - 'debuglevel', - 'fp', - 'getheader', - 'getheaders', - 'isclosed', - 'length', - 'msg', - 'read', - 'reason', - 'status', - 'strict', - 'version', - 'will_close' -- assignee: georg.brandl components: Documentation messages: 70158 nosy: ThomasH, georg.brandl severity: normal status: open title: httplib.HTTPResponse documentations inconsistent versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3324] Broken link in online doc
ThomasH [EMAIL PROTECTED] added the comment: Thank you for both of your feedback. I was sure that there is a release and deployment process in place for the docs. But if the process doesn't allow links to be fixed on a web page, there is probably something wrong with it. It's hard to believe you would leave such a trivial thing unfixed, accepting hundreds or thousands of people running into a dead end. Don't you run a link checker on the online version? Does anybody check the web server logs for misses? It's also hard to understand why you would treat a (flexible) online presentation like (inflexible) released software. At the very least, could you fix the existing link (http://www.python.org/doc/devel/lib/module-site.html), which is seemingly a development URL, to redirect to the correct page?! Or does this also interfer with policies and procedures?! Essence over ceremony (after Neil Ford) On Wed, Jul 16, 2008 at 3:44 AM, Georg Brandl [EMAIL PROTECTED] wrote: Georg Brandl [EMAIL PROTECTED] added the comment: In addition to what Benjamin said, the Python docs are released together with the source, so even if the issue was corrected in the 2.5 docs now, the correction would not show up until 2.5.3 is released, which is not even planned before 2.6. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3324 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3324] Broken link in online doc
ThomasH [EMAIL PROTECTED] added the comment: What? You have fixed it in some development version, and left the current online version broken? How much can it take to fix a broken link on a web page? If that's the net effect, I shouldn't have gone through all the efforts of filing this issue! Rather than closing the bug somebody should have asked the question how broken links can creep into the Python web site at all, and how to prevent this situation from re-occurring. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3324] Broken link in online doc
New submission from ThomasH [EMAIL PROTECTED]: The page http://docs.python.org/inst/search-path.html contains a broken link to site module documentation. Is: http://www.python.org/doc/devel/lib/module-site.html Should be: http://docs.python.org/lib/module-site.html -- assignee: georg.brandl components: Documentation messages: 69462 nosy: ThomasH, georg.brandl severity: normal status: open title: Broken link in online doc type: behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
