| msg59102 - (view) |
Author: Barry A. Warsaw (barry) *  |
Date: 2008-01-02 18:33 |
| urllib.splithost() and .splittype() are included in urllib's __all__ but are not documented in urllib's module documentation. They are used quite extensively in the module so they should be documented |
|
|
| msg59483 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-01-07 19:22 |
| There are quite a lot more functions in __all__, more than 10 split* functions... should they all be documented? Also, isn't urlparse meant to do such tasks? |
|
|
| msg59577 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2008-01-09 00:32 |
| > Georg Brandl added the comment: > > There are quite a lot more functions in __all__, more than 10 split* > functions... should they all be documented? > > Also, isn't urlparse meant to do such tasks? I agree. I too feel that not everything in the __all__ list should be documented. And in this specific case of splithost, it is more appropriate for the user to use urlparse. |
|
|
| msg113210 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-08-07 21:27 |
| When internal functions lack '_', perhaps the doc should say "xys,uie, and ooe are intentionally undocumented internal functions." Otherwise, how is one supposed to know? |
|
|
| msg188014 - (view) |
Author: Nathan Housel (plasticgap) |
Date: 2013-04-28 19:06 |
| This has been fixed in trunk, the split* methods have documentation and appear in the module docs. See: >>> help('urllib') |
|
|
| msg188263 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-05-02 12:50 |
| New changeset c3656dca65e7 by Senthil Kumaran in branch '2.7': # 1722 - Add a note on urllib helper functions like splittype, splithost etc. http://hg.python.org/cpython/rev/c3656dca65e7 |
|
|
| msg188264 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2013-05-02 12:53 |
| I had added a note in the documentation c3656dca65e7 conveying that splittype, splithost should not be relied upon, and urlparse should be used for parsing. Also, Python3 does not include these in __all__ - It is in Python2 for backwards compatibility purposes. It is not possible provide deprecation warning to things we leave off from __all__ from subsequent versions of python. I consider this request as resolved. Thanks! |
|
|