http_proxy and https_proxy are common environment variables used cross platform. Currently, urllib.request has support for it, but http.client does not. It probably should. If support is added to http.client, the handling of proxy environment variables in urllib.request should be factored out and made to be reliant on the changes in http.client (which shouldn't require any new code, only removal). Given the common usage of the environment variables (as observed by other utilities such as wget and curl), it seems odd to require a user to know about and use the higher level urllib.request API rather than have support for it baked into the lower level http.client API.
I think this would have a serious chance of breaking stuff unless it was only enabled with a new flag or similar. Also, I guess it would probably be limited to Basic authentication. The wget and curl programs both support different URL protocols, HTTP redirects (if curl --location is enabled), etc. In my mind they operate at a higher level, like urlopen(), and http.client is a more lower-level client. Are there many use cases where you would want proxy support for a HTTP request, but wouldn’t want to use urlopen() or some other high-level library like Requests?
Yeah, agreed that it should be opt-in, at least until a major release. I've run into a couple cases where higher level libraries use http.client (or httplib) directly, but don't expose the client directly (not that they should anyways). Because of that, there are higher level libraries that simply /can't/ support http_proxy environment variable because they didn't use a higher level abstraction. Given http.client /does/ implement everything required to support this, I can't see it impacting the architecture in any negative way.
