[Paul's PEP]
> > > help( "string" ) -- built-in topic or global
[me]
> > Why does a global require string quotes?
[Paul]
> It doesn't, but if you happen to say
>
> help( "dir" ) instead of help( dir ), I think it should do the right
> thing.
Fair enough.
> > I'm missing
> >
> > help() -- table of contents
> >
> > I'm not sure if the table of contents should be printed by the repr
> > output.
>
> I don't see any benefit in having different behaviors for help and
> help().
Having the repr() overloading invoke the pager is dangerous. The beta
version of the license command did this, and it caused some strange
side effects, e.g. vars(__builtins__) would start reading from input
and confuse the users. The new version's repr() returns the desired
string if it's less than a page, and 'Type license() to see the full
license text' if the pager would need to be invoked.
> > > If you ask for a global, it can be a fully-qualfied name such as
> > > help("xml.dom").
> >
> > Why are the string quotes needed? When are they useful?
>
> When you haven't imported the thing you are asking about. Or when the
> string comes from another UI like an editor window, command line or web
> form.
The implied import is a major liability. If you can do this without
importing (e.g. by source code inspection), fine. Otherwise, you
might issue some kind of message like "you must first import XXX.YYY".
> > > You can also use the facility from a command-line
> > >
> > > python --help if
> >
> > Is this really useful? Sounds like Perlism to me.
>
> I'm just trying to make it easy to quickly get answers to Python
> questions. I could totally see someone writing code in VIM switching to
> a bash window to type:
>
> python --help os.path.dirname
>
> That's alot easier than:
>
> $ python
> Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import os
> >>> help(os.path.dirname)
>
> And what does it hurt?
The hurt is code bloat in the interpreter and creeping featurism. If
you need command line access to the docs (which may be a reasonable
thing to ask for, although to me it sounds backwards :-), it's better
to provide a separate command, e.g. pythondoc. (Analog to perldoc.)
> > > In either situation, the output does paging similar to the "more"
> > > command.
> >
> > Agreed. But how to implement paging in a platform-dependent manner?
> > On Unix, os.system("more") or "$PAGER" is likely to work. On Windows,
> > I suppose we could use its MORE, although that's pretty braindead. On
> > the Mac? Also, inside IDLE or Pythonwin, invoking the system pager
> > isn't a good idea.
>
> The current implementation does paging internally. You could override it
> to use the system pager (or no pager).
Yes. Please add that option to the PEP.
> > What does "demand-loaded" mean in a Python context?
>
> When you "touch" the help object, it loads the onlinehelp module which
> has the real implementation. The thing in __builtins__ is just a
> lightweight proxy.
Please suggest an implementation.
> > > It Should Also Be Possible To Override The Help Display Function By
> > > Assigning To Onlinehelp.Displayhelp(Object_Or_String).
> >
> > Good Idea. Pythonwin And Idle Could Use This. But I'D Like It To
> > Work At Least "Okay" If They Don'T.
>
> Agreed.
Glad You'Re So Agreeable. :)
> > > The Module Should Be Able To Extract Module Information From Either
> > > The Html Or Latex Versions Of The Python Documentation. Links Should
> > > Be Accommodated In A "Lynx-Like" Manner.
> >
> > I Think This Is Beyond The Scope.
>
> Well, We Have To Do One Of:
>
> * Re-Write A Subset Of The Docs In A Form That Can Be Accessed From The
> Command Line
> * Access The Existing Docs In A Form That'S Installed
> * Auto-Convert The Docs Into A Form That'S Compatible
I Really Don'T Think That This Tool Should Attempt To Do Everything.
If Someone *Really* Wants To Browse The Existing (Large) Doc Set In A
Terminal Emulation Window, Let Them Use Lynx And Point It To The
Documentation Set. (I Agree That The Html Docs Should Be Installed,
By The Way.)
> I'Ve Already Implemented Html Parsing And Latex Parsing Is Actually Not
> That Far Off. I Just Need Impetus To Finish A Latex-Parsing Project I
> Started On My Last Vacation.
A Latex Parser Would Be Most Welcome -- If It Could Replace
Latex2html! That Old Perl Program Is Really Ready For Retirement.
(Ask Fred.)
> The Reason That Latex Is Interesting Is Because It Would Be Nice To Be
> Able To Move Documentation From Existing Latex Files Into Docstrings.
That'S What Some People Think. I Disagree That It Would Be Either
Feasible Or A Good Idea To Put All Documentation For A Typical Module
In Its Doc Strings.
> > The Latex Isn'T Installed Anywhere
> > (And Processing Would Be Too Much Work).
> > The Html Is Installed Only
> > On Windows, Where There Already Is A Way To Get It To Pop Up In Your
> > Browser (Actually Two: It'S In The Start Menu, And Also In Idle'S Help
> > Menu).
>
> If The Documentation Becomes An Integral Part Of The Python Code, Then
> It Will Be Installed. It'S Ridiculous That It Isn'T Already.
Why Is That Ridiculous? It'S Just As Easy To Access Them Through The
Web For Most People. If It'S Not, They Are Available In Easily
Downloadable Tarballs Supporting A Variety Of Formats. That'S Just
Too Much To Be Included In The Standard Rpms. (Also, Latex2html
Requires So Much Hand-Holding, And Is So Slow, That It'S Really Not A
Good Idea To Let "Make Install" Install The Html By Default.)
> Activepython Does Install The Docs On All Platforms.
Great. More Power To You.
> > A Standard Syntax For Docstrings Is Under Development, Pep 216. I
> > Don'T Agree With The Proposal There, But In Any Case The Help Pep
> > Should Not Attempt To Legalize A Different Format Than Pep 216.
>
> I Won'T Hold My Breath For A Standard Python Docstring Format. I'Ve Gone
> Out Of My Way To Make The Code Format Independent..
To Tell You The Truth, I'M Not Holding My Breath Either. :-) So your
code should just dump the doc string on stdout without interpreting it
in any way (except for paging).
> > Neat. I noticed that in a 24-line screen, the pagesize must be set to
> > 21 to avoid stuff scrolling off the screen. Maybe there's an off-by-3
> > error somewhere?
>
> Yes.
It's buggier than just that. The output of the pager prints an extra
"| " at the start of each page except for the first, and the first
page is a line longer than subsequent pages.
BTW, another bug: try help(cgi). It's nice that it gives the default
value for arguments, but the defaults for FieldStorage.__init__ happen
to include os.environ. Its entire value is dumped -- which causes the
pager to be off (it wraps over about 20 lines for me). I think you
may have to truncate long values a bit, e.g. by using the repr module.
> > I also noticed that it always prints '1' when invoked as a function.
> > The new license pager in site.py avoids this problem.
>
> Okay.
Where's the check-in? :-)
> > help("operators") and several others raise an
> > AttributeError('handledocrl').
>
> Fixed.
>
> > The "lynx-line links" don't work.
>
> I don't think that's implemented yet.
I'm not sure what you intended to implement there. I prefer to see
the raw URLs, then I can do whatever I normally do to paste them into
my preferred webbrowser (which *not* lynx :-).
> > I think it's naive to expect this help facility to replace browsing
> > the website or the full documentation package. There should be one
> > entry that says to point your browser there (giving the local
> > filesystem URL if available), and that's it. The rest of the online
> > help facility should be concerned with exposing doc strings.
>
> I don't want to replace the documentation. But there is no reason we
> should set out to make it incomplete. If its integrated with the HTML
> then people can choose whatever access mechanism is easiest for them
> right now
>
> I'm trying hard not to be "naive". Realistically, nobody is going to
> write a million docstrings between now and Python 2.1. It is much more
> feasible to leverage the existing documentation that Fred and others
> have spent months on.
I said above, and I'll say it again: I think the majority of people
would prefer to use their standard web browser to read the standard
docs. It's not worth the effort to try to make those accessible
through help(). In fact, I'd encourage the development of a
command-line-invoked help facility that shows doc strings in the
user's preferred web browser -- the webbrowser module makes this
trivial.
> > > Security Issues
> > >
> > > This module will attempt to import modules with the same names as
> > > requested topics. Don't use the modules if you are not confident
> > > that everything in your pythonpath is from a trusted source.
> > Yikes! Another reason to avoid the "string" -> global variable
> > option.
>
> I don't think we should lose that option. People will want to look up
> information from non-executable environments like command lines, GUIs
> and web pages. Perhaps you can point me to techniques for extracting
> information from Python modules and packages without executing them.
I don't know specific tools, but any serious docstring processing tool
ends up parsing the source code for this very reason, so there's
probably plenty of prior art.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4