logging.handlers.SysLogHandler in __init__ contains the following code, where socket is created and then connected right away. This seem to provide no way to specify a connection timeout for the socket being created.

sock = socket.socket(af, socktype, proto)
if socktype == socket.SOCK_STREAM:
    sock.connect(sa)

I believe to add an argument to specify the optional timeout would be appreciated, i.e., optionally calling sock.settimeout(..), something like:

sock = socket.socket(af, socktype, proto)
if timeout:
    sock.settimeout(timeout)
if socktype == socket.SOCK_STREAM:
    sock.connect(sa)

Hi, 

If I don't see bad, if a timeout occur this is catch by the OSError exception.

Yes, when timeout occurs it's then caught by the OSError -- you are completely right about that.

Instead my suggestion was meant to provide an option to specify a timeout when creating an instance of SysLogHandler. Currently the socket is created with default timeout (which is AFAIK set via socket.setdefaulttimeout though this applies to the whole module and effectively affects other sockets created).

In my particular use case I have the SysLog settings user-configurable, and thus sometimes it gets misconfigured. Then it is annoying to wait for a default timeout.. and there seem no way to specify the particular timeout when creating the handler. 
(Not speaking of the fact that SysLogHandler connects right away in __init__ call which I don't consider very reasonable but that would be a different story.)

Therefore I suggest to either add new argument for timeout (as the example in my comment above), or to wrap the socket creation into a method/function which an extending class could extend/implement, e.g. by changing:

sock = socket.socket(af, socktype, proto)
if socktype == socket.SOCK_STREAM:
    sock.connect(sa)

to

def _create_socket(af, socktype, proto): # or adding *args, **kwargs?
    socket.socket(af, socktype, proto)

sock = create_socket(af, socktype, proto) 
if socktype == socket.SOCK_STREAM:
    sock.connect(sa)


By the way, thanks for marking the issue as enhancement. Kind of missed that when creating the issue at first.