On Sun, Feb 24, 2013 at 12:28 PM, llanitedave <llanited...@veawb.coop> wrote: > On Sunday, February 24, 2013 1:35:31 AM UTC-8, Chris Rebert wrote: >> On Feb 24, 2013 1:21 AM, "llanitedave" <llani...@veawb.coop> wrote: >> > I created an html help page for my Python 2.7.3 application and put it in >> > a documentation folder. I used webbrowser.open() to fetch the page. >> > On linux -- KDE specifically, the command opens the local file on my >> > default browser with no issues. However, on Windows 7, it opens Internet >> > Explorer, which doesn't even search the local folder, but goes straight to >> > the web and does a Google search, returning nothing but useless noise. >> > My default browser on Windows is Chrome, so my intention is getting >> > undermined right from the start. >> > How do I get a local html file to open properly from Python in Windows? >> >> Sounds like this might be your problem: >> http://bugs.python.org/issue8936 >> >> The fix would seem to be ensuring that the URL you pass includes the scheme >> (in your case, "file:"). > > Holy Toledo! That's a two-year-old bug spanning two versions of the language! > > BTW, Chris, the snippet I showed in the title essentially WAS the exact code.
Sorry, my bad. This is why I dislike messages that put critical info *only* in the subject line; I tend not to reread the subject line once I've opened the message. > It's a method with that single line called from a wxPython Help menu. I > can't really put an absolute pathname into the argument, because the > application is going to be distributed to a variety of computers at my > workplace, and there's no assurance that it will go into (or remain in)a > particular folder. As Demian demonstrated, you can simply compute the absolute path from the relative path at runtime; although I would probably toss an abspath() call in for good measure (http://docs.python.org/2/library/os.path.html#os.path.abspath ). > This to me illustrates the downside of the Python philosophy of "There should > be only one obvious way to do things". If that one obvious way has a fatal > bug, you're pretty much SOL. On the other hand, you don't have to investigate which of N APIs is the "fixed"/"correct" one (Which PHP MySQL function is safe from SQL injection again?), and you only have wait for 1 fix instead of N. But yes, some of Python's included batteries are due for some recharging. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
