I am not sure you should pass the exceptions silently.

I'm not sure what to report, otherwise. Passing on the FileNotFoundError feels right to me.

I could drop catching CalledProcessError?

You could use shutil.which to determine if xdg-settings exists before trying to call it (LBYL). But here ignoring the exception (EAFP) seems right to me.

With a _preferred_browsers set, this would become:

try:
    cmd = "xdg-settings get default-web-browser".split()
    _xdg_default_browser = subprocess.check_output(cmd).decode().strip()
except (FileNotFoundError, subprocess.CalledProcessError):
     pass
else:
    _preferred_browsers.add(_xdg_default_browser)

I believe that would be more self-explanatory as to the purpose of ignoring the exceptions here (if we fail to find the xdg default browser, we simply don't add it to the preferred browser set)

I wonder if it’s good to change the signature here. Is it impossible to give high priority to the browser found with xdg-settings, if any, with the update_tryorder param?

I took the opportunity to make what I thought was an improvement. The tri-state definition of the old parameter seemed a bit clumsy and unnecessary (note that it was left out of the documentation).

I can back out the change to update_tryorder if it is deemed appropriate.

I'd suggest making the parameter preferred rather than priority and making it keyword-only.

Rather than only allowing a single preferred browser, perhaps it would make sense to make this a _preferred_browsers set? That would have a ripple effect on the other updates below.

My original implementation did this, but I didn't find the enhancement useful. There weren't any ripples.

That said, I'll make the change if this is considered a blocker.

With a set, this condition would become if priority or name in _preferred_browsers:

'preferred' is a better name. I'll make the change.

I had managed to make it to this point without encountering the keyword-only concept in the library (or elsewhere, for that matter). Would this cause unnecessary confusion?

Note that 'name in _preferred_browsers' is not enough. xdg-settings returns e.g. 'firefox.desktop'.

keyword-only is our preferred approach to handling boolean arguments in Python 3, as otherwise you end up with code that's ambiguous at the point of calling (as here, where the True conveys no info to a reader that doesn't already know the signature, while preferred=True is a lot more descriptive)

Regarding _preferred_browser potentially needing to match things like firefox against firefox.desktop, that belongs in an explanatory comment in the code itself. I'm fine with dropping the idea of switching to a set, though.

A slight name tweak may help convey the difference between this field and the new parameter to register though: what do you think about renaming it to _os_preferred_browser?

With a _preferred_browsers set, this would become:

try:
    cmd = "xdg-settings get default-web-browser".split()
    _xdg_default_browser = subprocess.check_output(cmd).decode().strip()
except (FileNotFoundError, subprocess.CalledProcessError):
     pass
else:
    _preferred_browsers.add(_xdg_default_browser)

I believe that would be more self-explanatory as to the purpose of ignoring the exceptions here (if we fail to find the xdg default browser, we simply don't add it to the preferred browser set)

I'd suggest making the parameter preferred rather than priority and making it keyword-only.

With the above suggested change to the signature of register, this and the other options below would become:

register("safari", None, MacOSXOSAScript('safari'), preferred=True)

I'll add the 'else' construct.