ThomasH 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/trun
ThomasH 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
ThomasH 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 recu
New submission from ThomasH :
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__
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. W
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
&
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
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
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: Documen
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.Messag
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
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 f
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
--
as
13 matches
Mail list logo
