[Python-Dev] urllib.browse() issues

[Fred L. Drake, Jr.]

Eric S. Raymond writes:
 > Frankly, what's there strikes me as overly complex and tied to the
 > heavyweight IDLE environment.  Here's the latest version of my code

  Actually, the code didn't originate in IDLE, but it did originate in
a GUI program (never tested on Windows, but it used GTK+, so it might
have worked there).

 > One significant difference is that my code gets the user preference
 > for a browser from an environment variable, rather than a profile.
 > This is appropriate for a preference that will be shared across multiple
 > applications, and follows the pattern of well-known Unix envirinment
 > variables like EDITOR.

  Which is great for Unix users, but otherwise stinks.  I wasn't real
happy with the .ini file thing, but wanted a way to configure it
independent of the hosting application.

 > Another difference is that my code tries harder to have smart default
 > behavior.  Notice the order of attempts -- X browsers are tried first
 > in background, then character browsers in the foreground.  This means
 > you are more likely to get some reasonable behavior independent of
 > whether the calling Python program is launched from within X, from an
 > Xterm, or on an X-less console.

  I agree that this is good; I'll try and incorporate this.  It would
require that open/open_new could block (consoles, etc.), but that
would be apporopriate in those contexts.

 > The register() calls seem kind of overelaborate.  Why not just
 > update a global dictionary directly?

  Perhaps that's the right way to do it, but I'm not completely
convinced either.  If a GUI library uses this to provide help, and an
application like Grail uses that library, Grail should be able to
register itself as a help viewer.  The exact mechanics are certainly
open to debate; I'm not terribly enamored of the machinery there now.

 > Things I like about the IDLE code, on the other hand...the
 > distinction between open() and open_new() methods is good.  It's also
 > clearly smarter about the actual mechanics of browser invocation.

  And I'd like to be able to support several more browsers, especially
on Windows.  I have no idea how any of this should be done for MacOS
machines, either, which should be supportable.

 > I think what I'd like to see is a merged version that starts with your
 > class organization, discards the .ini profile cruft in favor of an
 > environment-variable check, uses my logic for hunting up a browser,
 > and uses your incantations for actually invoking the browser.

  I'll see if I can throw something together later today, and send it
to python-dev for comments before checking it in.
  I guess the documentation falls in the category of "Internet
Protocols *and Support*"... I don't think it fits anywhere else!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member