pydoc contains some useful methods like "pager()" that could be reused in many python application, and it would be handy to have a documentation for them in Python manual http://docs.python.org/library/pydoc

Very likely, these functions are not meant to be anything but utilities.  As API functions, they also don't belong into pydoc.

I won't mind against the pager module in the main library.

Pydoc has a number of useful things that might be moved elsewhere and imported. An example is the no-yes filter _split_list. Documenting them in place would create something of a jumble. So I think this issue should be either closed (and possibly another opened) or renamed "Extract pydoc.page into a separate stdlib module." and reclassified.

I think a good place for the pager is in the cmd module.  I have a separated version of it I could upload if there is consensus on this.

I've extracted the text server, but it's in a minimum 'works for pydoc' stage. (See issue 2001)

Both of these need some more eye to look at the api's before they get documented.

pager is a general utility whereas cmd is for building REPLs, so I don’t think cmd is a good place. Can’t find a better one, though; shutil maybe. I have another feature in mind for a new module dedicated to the console: color codes, as seen duplicated in apps like Pygments, Sphinx, Mercurial, etc.

I have looked at the pydoc module.  Everything except help() is intended to be private. The author says within the file that __all__, when present, defines public interface and uses that definition within help() to decide what to display. So I do not think anything else should be documented unless it is made 'public' by being added to pydoc.__all__ or moved to another module. In either case, the result would be a new code feature. Doc addition would naturally follow. Also, if a function is made public, the interface and code could be reconsidered for possible modification for general usage.

I’ve looked hard at pydoc and opened distinct bug reports so that each piece of maybe-useful functionality can be discussed independently:

#12918 New module for terminal utilities
#12917 Make visiblename and allmethods functions public
#12916 Add inspect.splitdoc
#12915 Add inspect.locate and inspect.resolve
#12914 Add cram function to textwrap

Resist the urge to fatten APIs until you're sure that:
* they are needed
* they are well developed (many internal utils fail this test)
* they are worth the extra time it takes to learn what is in a module (adding rarely needed tools has the side-effect of obscuring things people actually need)

Georg's advice is spot on.  There are a lot of little internal routines in the standard library that aren't sufficiently fit to be exposed (perhaps a little too ad-hoc or special purpose, perhaps the API isn't sufficiently general, perhaps the routines rely on non-guaranteed aspects of the implementation).  For example, visiblename() is more heuristic than algorithmic -- right now, we can change that as needed (for instance, the recent updates to accommodate named tuples), but as soon as the method or function becomes public, its API freezes and it is hard for us to make changes.

The pager functions are interesting and non-trivial.  Before making them public in the standard library though, it would be best if it had some life as third-party module to let it mature (i.e. making sure it works as well in other contexts as it does in pydoc).

Also consider whether other documentation tools have already encountered and addressed these use cases, perhaps in a different and better way.