Calling get_proxies() in a subprocess would also work, although I'd then prefer to use a small daemon proces to avoid the startup cost of a new process for every call to _scproxy functions.

There is a conflict between two goals w.r.t. the macOS port:

1) Integrate nicely with the platform

2) Be like other unixy platforms

The former requires the use of Apple specific APIs, like those used in _scproxy, but those cause problems when using fork without calling exec.

The latter is technically an issue for all processing using threads on POSIX systems (see <http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html>), AFAIK users get bitten by this more on macOS because Apple appears to use threading in their implementation (making processes multi-threaded without explicitly using threading in user code), and because Apple explicitly checks for the "fork without exec" case and crashes the child proces.

This can of course also be seen as a qualify of implementation issue on macOS, as in "Apple can't be bothered to do the work to support this use case" ;-/

Anyways: As Ned writes this is unlikely to change on Apple's side and we have to life with that.

There's three options going forward:

1) Remove _scproxy

I'm -1 on that because I'm in favour of having good platform integration, Python's URL fetching APIs should transparently use the system proxy config configuration.

2) Document this problem and move on

3) Find a workaround (such as calling the APIs used by _scproxy in a clean supprocess).

The 3th option is probably the most useful in the long run, but requires someone willing to do the work.  I'm in principle willing to do the work, but haven't had enough free time to work on CPython for quite a while now (which saddens me, but that's off topic).