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
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