Module boot extremely slow (2-3 seconds)

On GNU/Debian 8,  AMD Phenom 9550 Quad-Core Processor, 8Gb DDR2, Python 2.7.9/3.4.2

requests version 2.12.4 from PyPi

This is due to the following code in the `__init__.py` file:

```
# Attempt to enable urllib3's SNI support, if possible
try:
    from .packages.urllib3.contrib import pyopenssl
    pyopenssl.inject_into_urllib3()
except ImportError:
    pass
```
After I commented out this code, the time was reduced to 0.05 seconds.

Whether this test is necessary for all users?
You may want to remove the code?



@djbaldey This code optionally injects the PyOpenSSL based TLS backend into Requests. It's extremely useful because in many cases it enables support of advanced features that the standard library TLS module does not support. For this reason, we always attempt to inject it, as this is the most reliably way to detect its presence.

In this case, it's almost certainly the result of you having an older cryptography module with a slow import time. Can you try updating cryptography and PyOpenSSL to the newest versions to see if that resolves your issue?

No, to upgrade PyOpenSSL impossible. Delete - possible. But, without this package - the same delay as with him.

Update:

I'm upgrade PyOpenSSL  from jessie-backports to 16.0.0-1~bpo8+1 version. Now the module is loaded a little faster - 1-1.5 seconds. But it's too slow!


What version of cryptography and PyOpenSSL is installed?

> I'm upgrade PyOpenSSL from jessie-backports to 16.0.0-1~bpo8+1 version.

What version of cryptography is installed? Have you tried not using system packages? I have no way of guaranteeing that they've built things appropriately and aren't contributing to the slowness you're seeing.

Package: python-cryptography
Version: 1.3.4-1~bpo8+2

Package: python-openssl
Source: pyopenssl
Version: 16.0.0-1~bpo8+1

> Have you tried not using system packages?

No. It is unsafe in production. The system packages is the only guarantee of stability and compatibility of all components.

If you're going to go that route and you've decided to only trust system packages, why are you installing "unsafe" packages from PyPi?

@drpoggi, why instead of trying to solve the problem with slow code - you are trying to shift the responsibility for organizational activities?


I'm not trying to shift anything. I'm not a core maintainer of Requests and certainly don't mean to represent the opinions of the core developers, sorry if it came across that way. I have no affiliation with Requests other than I submitted a PR once and Github I guess labels that.

The actual core developers of Requests have already suggested methods to fix your slow code and you've rejected them. I'm not sure what else they could do at this point. As has already been said, they're not responsible for maintaining the system packages which it seems like that is your issue.

@drpoggi, I understand all of this. Therefore, I suggest to remove the trying from urllib3 module initialization. I don't think that the most important component and it is more important than speed loading the module. I am sure that those who need urllib3 with TLS - they can write these strings in the app after loading the module. And it will be right.
Upd:
In addition, in the internal corporate network - ["advanced features TLS"](#issuecomment-269605327) may be banned or make mistakes.


Can you please open up a shell and check how long "import cryptography" takes for me? If this is the source of the slowdown then we can go from here. 

>  I don't think that the most important component and it is more important than speed loading the module.

On this I disagree with you strongly. On many platforms Python's standard TLS module does not support SNI, disabling TLS compression, or fine-grained control of TLS configuration. Those things are important, and if we can make them present for our users with zero configuration cost then we will try to do that.

I am entirely willing to look into and attempt to fix the slowdown problem, but removing the auto-insertion of PyOpenSSL from Requests is simply entirely off the table. 

Needless to say, I agree with @Lukasa. Being able to provide the best possible security out-of-the-box (without futher user configuration) is absolutely imperative. We will not sacrifice that.

If you are doing `apt-get install -y python-requests` and it's installing `PyOpenSSL` for you, that means the packagers understand this *and* they understand that the system Python you're using doesn't allow for the best possible security for you and every other user. Now, let's try to get to the bottom of thos.

@djbaldey can you determine how long it takes on your system to do `import cryptography`?

Excuse me.
The problem is my hardware. I tried on a laptop with Intel Core i3 - everything loads instantly.
Close the issue.