This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients neologix, pitrou
Date 2012-12-28.17:55:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1356717332.75.0.961741176545.issue16763@psf.upfronthosting.co.za>
In-reply-to
Content
> support.transient doesn't help here since no exception is raised

An exception can still be raised in do_handshake(), which is called when the connection succeeds. But, yes, it's otherwise useless.

> Note that I'm not sure that connect_ex returning None is normal in the 
> first place

It is not. The 2.7 implementation currently calls socket.connect() and catches socket errors, while the 3.2 implementation directly calls socket.connect_ex(). This means the 2.7 implementation will unwillingly catch name resolution errors, and other issues:

>>> socket.socket().connect_ex(("svnn.python.org", 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/27/Lib/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -5] No address associated with hostname
>>> ssl.wrap_socket(socket.socket()).connect_ex(("svnn.python.org", 443))
-5

I will backport the 3.2 implementation of connect_ex() in order to fix this inconsistency. Unfortunately there is no easy way to test for it.
History
Date User Action Args
2012-12-28 17:55:32pitrousetrecipients: + pitrou, neologix
2012-12-28 17:55:32pitrousetmessageid: <1356717332.75.0.961741176545.issue16763@psf.upfronthosting.co.za>
2012-12-28 17:55:32pitroulinkissue16763 messages
2012-12-28 17:55:32pitroucreate