load_dotenv fails to find .env file by default under python 3.13

[mpounsett]

When using python 3.13, load_dotenv() requires an explicit path to a dotenv file in the current directory.

% cat .env
FOO="bar"

Python 3.12.9 (main, Mar 24 2025, 18:36:22) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dotenv, dotenv.version
>>> dotenv.version.__version__
'1.0.1'
>>> dotenv.load_dotenv()
True

Python 3.12.9 (main, Mar 24 2025, 18:36:22) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dotenv, dotenv.version
>>> dotenv.version.__version__
'1.1.0'
>>> dotenv.load_dotenv()
True

Python 3.13.3 (main, May 17 2025, 17:59:15) [Clang 17.0.0 (clang-1700.0.13.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dotenv, dotenv.version
>>> dotenv.version.__version__
'1.0.1'
>>> dotenv.load_dotenv()
False
>>> dotenv.load_dotenv('.env')
True

Python 3.13.3 (main, May 17 2025, 17:59:15) [Clang 17.0.0 (clang-1700.0.13.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dotenv, dotenv.version
>>> dotenv.version.__version__
'1.1.0'
>>> dotenv.load_dotenv()
False
>>> dotenv.load_dotenv('.env')
True

[burnout-projects]

For me on Windows 11, I can reproduce this issue on the CLI, but works fine from a script.

(.venv) C:\Personal\Projects\python-dotenv>python
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr  8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import dotenv
>>> dotenv.load_dotenv()
False
>>> 

[burnout-projects]

After a bit of digging, the _is_interactive() function that decides if it's running from REPL returns False in python 3.13 (and True in python 3.12). This then decides the path where to look for .env and in most cases not in the current path.

This appears to be the result of the developments that went into the 3.13 version. I think it's time we revisit the _is_interactive() function.

A suggestion is to look for sys.ps1 to determine if interactive or not (as also described in python docs)
https://docs.python.org/3/library/sys.html#sys.ps1

Python 3.13

(.venv) C:\Personal\Projects\python-dotenv>python
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr  8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def _is_interactive():
...     """ Decide whether this is running in a REPL or IPython notebook """
...     try:
...         main = __import__('__main__', None, None, fromlist=['__file__'])
...     except ModuleNotFoundError:
...         return False
...     return not hasattr(main, '__file__')
...
...
>>> _is_interactive()
False
>>>

Python 3.12

C:\>python
Python 3.12.4 (tags/v3.12.4:8e8a4ba, Jun  6 2024, 19:30:16) [MSC v.1940 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def _is_interactive():
...   """ Decide whether this is running in a REPL or IPython notebook """
...   try:
...     main = __import__('__main__', None, None, fromlist=['__file__'])
...   except ModuleNotFoundError:
...     return False
...   return not hasattr(main, '__file__')
...
>>> _is_interactive()
True
>>>

[burnout-projects]

Updating the function to use sys.ps1 works perfectly on both py3.13 and py3.12.

def _is_interactive():
    """ Decide whether this is running in a REPL or IPython notebook """
    return hasattr(sys, 'ps1')

The sys.ps1 attribute has existed since Python 3.0, making it a reliable indicator of an interactive environment. It's curious why a different approach was initially chosen. Perhaps @theskumar or @freddyaboulton knows the reasoning behind it.

[mpounsett]

What led me to do the python console test was the same problem in a script... I was just trying to show the simplest possible example of the issue. Testing with a very simple script is getting me results though, so I'll have to go back to my original application and see if I can figure out what's different.

It was the same problem in the application though... load_dotenv() with no arguments didn't find anything, but load_dotenv('.env') did.

[burnout-projects]

IMO, what you found was a valid issue and after the change I mentioned above, it works perfectly fine on script and REPL as well (with Python 3.13):

(.venv) C:\Personal\Projects\python-dotenv>python
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr  8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from dotenv import load_dotenv
>>> load_dotenv()
True
>>>

Maybe the path of .env is not in the root folder of the project. IIRC, the dotenv lib tries to find the .env file starting with the current directory of the script calling it and one by one all the way up to the top.