[issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
New submission from Sriram Thaiyar <sriram.thaiyar@gmail.com>: http://docs.python.org/dev/py3k/library/urllib.request.html#urllib.request._... [in the body] urllib._urlopener should be urllib.request._urlopener ---------- assignee: docs@python components: Documentation messages: 104998 nosy: Sriram.Thaiyar, docs@python priority: normal severity: normal status: open title: Doc bug for urllib.request._urlopener in Python 3.1+ versions: Python 3.1 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Fixed in r80773 and r80774. Thanks. ---------- assignee: docs@python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
sri <sriram.thaiyar@gmail.com> added the comment: You missed the code part: urllib._urlopener = AppURLopener() ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Fixed in r80775 and r80776 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
R. David Murray <rdmurray@bitdance.com> added the comment: Why do we have a public API that begins with an '_'? ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: That is actually a private attribute of urllib (not urllib2) module present from the very first version. It is intended strictly for overriding purposes not for anything else. During the merge in py3k, it has taken its place in urllib.request. I see no harm in it being there. If it needs to be un-advertised, perhaps we can remove its reference from the docs. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
R. David Murray <rdmurray@bitdance.com> added the comment: Mainly I'm saying that I don't think a public API should have a name starting with an '_'. Sets a bad precedent :) Looking at the functionality more closely, though, it does make me nervous that we are recommending changing the global state of the module. Sounds like a recipe for hard to find bugs. So maybe it should be removed from the docs, and a better way found to expose that functionality. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: The functionality provided by urllib.request._urlopener can be accomplished in a more natural way using build_opener. Historically, _urlopener was there for urllib and build_opener style came in urllib2. So, I think, this can be safely be removed from the docs considering David's suggestion that its better not to advertise _methods in the docs. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Actually, I see certain use-cases of _urlopener in py3k. Most visible one being urllib.request.urlretrieve and also URLOpener.open which is different from build_opener way of doing things. - But still, public exposure of overriding globals to can be removed. There is no harm in the functionality. In py3k, users should resort to build_opener style of doing than use FancyURLOpener or URLOpener which are present for backward compatibility reasons only. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Removed in r81283 and r81284. With respect to the technical details of exposing this functionality for _urlretrieve and URLOpener. - users can still do it. - There is a better way, if the other global _opener be served for the same purpose, so that build_opener can be used. There is TODO mentioned in the code, let me see if it can be accomplished without any problem. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Fixed in r80773 and r80774. Thanks. ---------- assignee: docs@python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
sri <sriram.thaiyar@gmail.com> added the comment: You missed the code part: urllib._urlopener = AppURLopener() ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Fixed in r80775 and r80776 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
R. David Murray <rdmurray@bitdance.com> added the comment: Why do we have a public API that begins with an '_'? ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: That is actually a private attribute of urllib (not urllib2) module present from the very first version. It is intended strictly for overriding purposes not for anything else. During the merge in py3k, it has taken its place in urllib.request. I see no harm in it being there. If it needs to be un-advertised, perhaps we can remove its reference from the docs. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
R. David Murray <rdmurray@bitdance.com> added the comment: Mainly I'm saying that I don't think a public API should have a name starting with an '_'. Sets a bad precedent :) Looking at the functionality more closely, though, it does make me nervous that we are recommending changing the global state of the module. Sounds like a recipe for hard to find bugs. So maybe it should be removed from the docs, and a better way found to expose that functionality. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: The functionality provided by urllib.request._urlopener can be accomplished in a more natural way using build_opener. Historically, _urlopener was there for urllib and build_opener style came in urllib2. So, I think, this can be safely be removed from the docs considering David's suggestion that its better not to advertise _methods in the docs. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Actually, I see certain use-cases of _urlopener in py3k. Most visible one being urllib.request.urlretrieve and also URLOpener.open which is different from build_opener way of doing things. - But still, public exposure of overriding globals to can be removed. There is no harm in the functionality. In py3k, users should resort to build_opener style of doing than use FancyURLOpener or URLOpener which are present for backward compatibility reasons only. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
Senthil Kumaran <orsenthil@gmail.com> added the comment: Removed in r81283 and r81284. With respect to the technical details of exposing this functionality for _urlretrieve and URLOpener. - users can still do it. - There is a better way, if the other global _opener be served for the same purpose, so that build_opener can be used. There is TODO mentioned in the code, let me see if it can be accomplished without any problem. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8619> _______________________________________
participants (4)
-
R. David Murray -
Senthil Kumaran
-
sri
-
Sriram Thaiyar