Starts using socks proxy after socks.wrapmodule(smtplib)

On one hand, I am using `requests` to access a web service in the local network. On the other hand, I access a SMTP server outside the network through a proxy. Once I do `socks.wrapmodule(smtplib)`, `requests` starts using the proxy as well. Here is an example:
```
> python
Python 2.7.13 (default, Jan 13 2017, 10:15:16) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.get('http://127.0.0.1:8000')
<Response [400]>
>>> import socks
>>> socks.setdefaultproxy(socks.PROXY_TYPE_HTTP, '...', 8088)
>>> requests.get('http://127.0.0.1:8000')
<Response [400]>
>>> import smtplib
>>> socks.wrapmodule(smtplib)
>>> requests.get('http://127.0.0.1:8000')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/api.py", line 70, in get
    return request('get', url, params=params, **kwargs)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/sessions.py", line 475, in request
    resp = self.send(prep, **send_kwargs)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/sessions.py", line 596, in send
    r = adapter.send(request, **kwargs)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 595, in urlopen
    chunked=chunked)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 363, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib64/python2.7/httplib.py", line 1042, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.7/httplib.py", line 1082, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python2.7/httplib.py", line 1038, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 882, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.7/httplib.py", line 844, in send
    self.connect()
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/packages/urllib3/connection.py", line 167, in connect
    conn = self._new_conn()
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/packages/urllib3/connection.py", line 142, in _new_conn
    (self.host, self.port), self.timeout, **extra_kw)
  File "/home/vernica/.local/lib/python2.7/site-packages/requests/packages/urllib3/util/connection.py", line 88, in create_connection
    sock.connect(sa)
  File "/home/vernica/.local/lib/python2.7/site-packages/socks.py", line 780, in connect
    negotiate(self, dest_addr, dest_port)
  File "/home/vernica/.local/lib/python2.7/site-packages/socks.py", line 700, in _negotiate_HTTP
    raise HTTPError(error)
socks.HTTPError: 503: Service Unavailable

>>> requests.__version__
'2.11.1'
>>> socks.__version__
'1.6.4'
```

If you use socks.wrapmodule then a whole bunch of monkey patching will take place. It is clearly not safe to monkeypatch smtplib, because those monkeypatches end up affecting the socket module, and thus requests. 

You should look for an smtp module that can use SOCKS directly, or move the SMTP code out of the process, but there is really nothing we can do to meaningfully prevent this. If you mess with the socket object, it will affect us too: nothing can be done about that.

This does not make any sense.

`wrapmodule` implies that it will only be applied for the module (and possibly its children).

At the very least the naming is wrong.

Could it not be possible to clone the module and ensure it is only applied for `smtplib` and children?

> This does not make any sense.

Possibly you meant to say, "I do not understand this"?
Possibly you are mistaken. Possibly you are confused.  Possibly "this"
makes total sense.

Humbleness.  Try it.  Others may find your words more acceptable that way.


On Sun, Nov 18, 2018 at 9:58 PM Pascal van Kooten <notifications@github.com>
wrote:

> This does not make any sense.
>
> wrapmodule implies that it will only be for the module (and possibly its
> children).
>
> At the very least the naming is wrong.
>
> Could it not be possible to clone the module and ensure it is only applied
> for smtplib and children?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/requests/requests/issues/3890#issuecomment-439780174>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AADlQLzJ5RWyrqfVmtaqjyRU4EUzfB94ks5uwkiMgaJpZM4MLoxP>
> .
>


I meant what I said. Deal with it, it's the internet. I chose the tone because of the severity of the issue, actually. 

Also, content-wise, I feel like it deserves a strong reaction because this is a very big problem. 
It's one of the biggest sins when this behavior can cause an interaction based on which other modules are loaded. 

Monkey patching at the level of affecting only smtplib is acceptable, but leaking beyond a single module (and its children) should not be acceptable.

(I'm happy with any feedback on my projects; user frustration is useful in whatever shape it comes) 

Oh, I fully expected that you meant what you said, which is why I felt a need to address your attitude.  I meant what I said as well.  

I'm simply an observer on this project. I have very seldom observed rudeness here, especially from anyone expecting cooperation and collaboration in return.

I'm happy to reiterate:  Humbleness.  Try it.   Better still:  Embrace the humility of uncertainty.  https://www.ted.com/talks/julia_dhar_how_to_disagree_productively_and_find_common_ground
  

I'm sure he won't watch that ted talk that you just posted