All committers have signed the CLA.

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

self._timeout = (
    float(os.getenv("GLOBAL_DEFAULT_TIMEOUT"))
    if os.getenv("GLOBAL_DEFAULT_TIMEOUT") is not None
    else socket.getdefaulttimeout()
)

PR Code Suggestions ✨

Explore these optional code suggestions:

+global_timeout = os.getenv("GLOBAL_DEFAULT_TIMEOUT")
 self.timeout = (
-    float(os.getenv("GLOBAL_DEFAULT_TIMEOUT"))
-    if os.getenv("GLOBAL_DEFAULT_TIMEOUT") is not None
+    float(global_timeout)
+    if global_timeout is not None
     else (timeout if timeout is not None else socket.getdefaulttimeout())
 )

@XueSongTap Thanks for the PR!... this looks really good.

Please see my review comments, and also don't forget to sign the CLA as mentioned here:

#15628 (comment)

Also, take a look at the code suggestions that the AI bot left in earlier comments.

Hi @barancev, thank you for your helpful review!

You're absolutely right that reading the environment variable at module/class construction time makes it static and insensitive to any later changes to GLOBAL_DEFAULT_TIMEOUT.

To address this, I'm planning to refactor the timeout logic in the following way:

• Instead of evaluating the timeout once in __init__, I will expose it via a @property method, something like:

@property
def timeout(self):
    env_value = os.getenv("GLOBAL_DEFAULT_TIMEOUT")
    if env_value is not None:
        return float(env_value)
    if self._explicit_timeout is not None:
        return self._explicit_timeout
    return socket.getdefaulttimeout()

• The constructor will keep _explicit_timeout to capture any user-specified value.
• Calling reset_timeout() will simply clear _explicit_timeout, allowing fallback to either the env variable or socket default.

This way, changes to GLOBAL_DEFAULT_TIMEOUT at runtime will be respected dynamically, which should make the behavior more predictable and flexible.

Would this approach align with your expectations? Let me know what you think before I proceed with the changes.

Thanks again!

@XueSongTap I didn't see any recent activity on this, so I submitted #15673 to address the decision in #15604.

Thank you very much for your effort anyway.