Proposal: Python Info Collective

Mitchell Morris mgm at unpkhswm04.bscc.bls.com
Fri Nov 19 15:07:49 CET 1999


In article <slrn8393kv.f1h.thantos at chancel.org>, Alexander Williams wrote:
>On 18 Nov 1999 20:31:58 GMT, Mitchell Morris
><mgm at unpkhswm04.bscc.bls.com> wrote:
>
>>Reading is not so bad ... searching blows. As an example, I'm looking at the
>>page for the "re" module and want to see the argument list for "unpack" but
>>can't seem to remember if it's in "string" or "struct" or
>>Guido-only-knows-where. Lynx provides squat for this operation, so I wind up
>
>Magic word: index.
>
>See the last page of the doc list in HTML, an index of functions and
>terms hyperlinked to the discussion thereof.  Voila.
>
>Has the dimmunation of print media really caused us to forget such
>simple methods?



"For the sake of argument I'll ignore all your fighting words" -- Larry Wall



Your editing of my paragraph removed the portion where I stated that I had to
traverse the document hierarchy. That is, while viewing the "re" page, I must
go "back" to the previous node, in either a browser of the GNU info viewer,
and then forward to another page which contains the information I desire. Is
this not the procedure you're suggesting? Please note that traversing the
hierarchy does not imply that there are no indices nor does it imply that the
indices are unused.

I just find it tedious to have to visit the index page and manually search
(or initiate an automated search) to find the other page of interest. I was
observing that the other "P*" language supplies a tool that removes the need
to visit the index page in between, and I thought that was a good thing.



Or are you saying that your copies of the index pages have all the references
flattened therein so that you can use Lynx's "search in document" feature to
jump directly from the "re.compile" secion to the "struct.unpack" section?



index-pages-are-for-automated-tools-ly y'rs,
+Mitchell

-- 
Mitchell Morris

Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden implementation of half of Common Lisp.
	-- Phil Greenspun




More information about the Python-list mailing list