You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before pymonetdb 1.8.0, the value of connection_timeout could be one of:
-1 (the default), to use the Python-wide default timeout,
None, to block indefinitely,
0, to enable non-blocking mode on the socket,
>0, to set a timeout.
All negative values except -1 yielded an error message.
Note however that pymonetdb was not designed for use with non-blocking sockets. This means setting it to zero, either directly or using socket.setdefaulttimeout(), has never worked.
In 1.8.0, the behaviour was changed in a not well thought out manner. The default changed to 0 and the values 0 and None both meant "use the system default". Other values, including -1 were passed as-is to socket.settimeout(). However, that function does not accept negative values.
It turns out some users explicitly pass connection_timeout=-1. This now fails, which is undesirable. However, the old behaviour is also suboptimal because value 0 is unusable. It makes more sense to interpret connection_timeout=0 as an explicit request for blocking without timeout.
The following table lists the original, the modified and the desired behaviour:
1.7.1
1.8.1
DESIRED
unspecified
sysdefault
sysdefault
sysdefault but not non-blocking
-1
sysdefault
error
sysdefault but not non-blocking
other negative
error
error
error
0
non-blocking (broken)
sysdefault
blocking
>0
timeout
timeout
timeout
The text was updated successfully, but these errors were encountered:
Before pymonetdb 1.8.0, the value of
connection_timeout
could be one of:-1
(the default), to use the Python-wide default timeout,None
, to block indefinitely,0
, to enable non-blocking mode on the socket,>0
, to set a timeout.All negative values except
-1
yielded an error message.Note however that pymonetdb was not designed for use with non-blocking sockets. This means setting it to zero, either directly or using
socket.setdefaulttimeout()
, has never worked.In 1.8.0, the behaviour was changed in a not well thought out manner. The default changed to
0
and the values0
andNone
both meant "use the system default". Other values, including-1
were passed as-is tosocket.settimeout()
. However, that function does not accept negative values.It turns out some users explicitly pass
connection_timeout=-1
. This now fails, which is undesirable. However, the old behaviour is also suboptimal because value0
is unusable. It makes more sense to interpretconnection_timeout=0
as an explicit request for blocking without timeout.The following table lists the original, the modified and the desired behaviour:
The text was updated successfully, but these errors were encountered: