Fix return type of Env.read_env()

[hukkin]

• Fix typehint of Env.read_env() return_value
• Fix returning None if dotenv file not found recursively. Always return True, just like dotenv.load_dotenv does, regardless of whether the file was found or not.

I set the return value to True for consistency and backwards compatibility. I recommend though that we set the return value to either always None, or return a boolean that expresses whether the dotenv file was found or not.

[sloria]

Shouldn't it be changed to Optional[_BoolType]?

[sloria]

Won't we still return a DotEnv here?

[hukkin]

No. The return type of dotenv.load_dotenv() is bool, never aDotEnv. More specifically it is a literal True value always.

If we want to keep behavior exactly as it was, then yes, we can return None and set the return type to Optional[_BoolType] in this MR, in which case the behavior doesn't change at all compared to what it currently is. This is a very confusing and inconsistent return value though: it means we return None if a recursive search was done, and no .env was found, and a literal True in all other cases (including the case when no .env was done and no recursive search was done). We never return a False. The return value is essentially quite meaningless.

Like said, if the return value is meaningless, it should IMO always be None. I can and would like to make that change, but it's a breaking change, so it's up to you.

This MR in its current state would change the return value to a literal True value, which is consistent with dotenv.load_dotenv.

[sloria]

Ah I see. I was misreading the code for load_dotenv. Sure enough, it returns True.

I'm fine returning None here instead; as you said, the return value should not be used, so I think the code should reflect that.

Can you make that change?

[hukkin]

Nice, made us return None always now.

[sloria]

Thanks again!