We used to be going indirectly through the socket module, but now we
just check for the ssl module.
Details
- Reviewers
indygreg - Group Reviewers
hg-reviewers - Commits
- rHG569d662816de: mail: modernize check for Python-with-TLS
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
+def _pyhastls():
+ """Returns true iff Python has TLS support, false otherwise."""
+ try:
+ import ssl
+ getattr(ssl, 'HAS_TLS', False)
+ return True
+ except ImportError:
+ return False
Maybe we can simply remove the check since we've dropped support for
Python 2.5.
Maybe we can simply remove the check since we've dropped support for
Python 2.5.
No, we're looking to see if the ssl module is importable - if it's not, that means Python was compiled without TLS support (which is an option, even on 3.x and 2.7). I'm just sniffing for this particular attribute to force the import. Maybe I should add a comment?
> Maybe we can simply remove the check since we've dropped support for > Python 2.5. No, we're looking to see if the ssl module is importable - if it's not, that means Python was compiled without TLS support (which is an option, even on 3.x and 2.7). I'm just sniffing for this particular attribute to force the import.
That's true, but I don't think we've ever had support for Python 2.6+ without
OpenSSL. Some commands would work thanks to our demandimport, but it also means
some stdlib modules (e.g. httlib) would be broken because import ssl doesn't
fail.
I think this utility function should live in sslutil.py.
mercurial/mail.py | ||
---|---|---|
85–92 | We may want to consider moving this to sslutil.py and refactoring sslutil.py to not crash and burn if the ssl module doesn't work (which I'm pretty sure it will do today). |
We may want to consider moving this to sslutil.py and refactoring sslutil.py to not crash and burn if the ssl module doesn't work (which I'm pretty sure it will do today).