Ronald Oussoren <ronaldousso...@mac.com> added the comment:

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

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to