[Python-Dev] urllib.browse() issues
Fred L. Drake, Jr.
Thu, 6 Jul 2000 16:51:15 -0400 (EDT)
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 L. Drake, Jr. <fdrake at beopen.com>
BeOpen PythonLabs Team Member