This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Doc bug for urllib.request._urlopener in Python 3.1+
Type: Stage: resolved
Components: Documentation Versions: Python 3.1
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: orsenthil Nosy List: docs@python, orsenthil, r.david.murray, sri
Priority: normal Keywords:

Created on 2010-05-05 03:43 by sri, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (10)
msg104998 - (view) Author: sri (sri) Date: 2010-05-05 03:43

[in the body]
urllib._urlopener should be urllib.request._urlopener
msg104999 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-05 05:34
Fixed in r80773 and r80774.

msg105000 - (view) Author: sri (sri) Date: 2010-05-05 06:19
You missed the code part:

urllib._urlopener = AppURLopener()
msg105001 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-05 07:25
Fixed in r80775 and r80776
msg105016 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-05-05 12:21
Why do we have a public API that begins with an '_'?
msg105021 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-05 12:45
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.
msg105064 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-05-05 18:04
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.
msg105949 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-18 03:38
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.
msg105950 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-18 03:56
Actually, I see certain use-cases of _urlopener in py3k. Most visible one being urllib.request.urlretrieve and also 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.
msg105951 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-05-18 04:07
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.
Date User Action Args
2022-04-11 14:57:00adminsetgithub: 52865
2010-05-18 04:07:10orsenthilsetmessages: + msg105951
2010-05-18 03:56:04orsenthilsetmessages: + msg105950
2010-05-18 03:38:46orsenthilsetmessages: + msg105949
2010-05-05 18:04:30r.david.murraysetmessages: + msg105064
2010-05-05 12:45:30orsenthilsetmessages: + msg105021
2010-05-05 12:21:44r.david.murraysetnosy: + r.david.murray
messages: + msg105016
2010-05-05 07:25:09orsenthilsetmessages: + msg105001
2010-05-05 06:19:11srisetmessages: + msg105000
2010-05-05 05:34:59orsenthilsetstatus: open -> closed

assignee: docs@python -> orsenthil

nosy: + orsenthil
messages: + msg104999
resolution: fixed
stage: resolved
2010-05-05 03:43:01sricreate