Now, exactly WHY is it looking for a file called
<stdin>? :-)

This bug has been present since at least 2.3.3 - I
can't be bothered to
check back further. Not surprisingly, it causes
misbehaviour if there
is a file called <stdin> in any of the places searched,
but it doesn't
strike me as the world's most catastrophic bug.

strace -e open python
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import dismal
open("dismal.so", O_RDONLY)             = -1 ENOENT (No
such file or directory)open("dismalmodule.so",
O_RDONLY)       = -1 ENOENT (No such file or directory)
open("dismal.py", O_RDONLY)             = -1 ENOENT (No
such file or directory)
open("dismal.pyc", O_RDONLY)            = -1 ENOENT (No
such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/dismal.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/site-packages/<stdin>",
O_RDONLY) = -1 ENOENT (No such file or directory)
  File "<stdin>", line 1, in <module>
ImportError: No module named dismal
>>>

Logged In: YES
user_id=580910

It's probably looking for a file named <stdin> because the co_filename
attribute for code that's executed from the interactive prompt has that value:

>>> import sys
>>> f = sys._getframe(0)
>>> f.f_code.co_filename
'<stdin>'

I agree that looking for that file is rather pointless and a bug.

Confirmed in py3k and trunk. It's also possible to create a file named
"<stdin>", I seem to recall discussion on this.

The bug is certainly not catastrophic, but creates
a slight security risk:

ln -s /etc/shadow '<stdin>'
some-suid-program -with-error

or whatever.

I don't think the security risk exists due to this bug. As Python is searching for various places anyway, an attacker could just symlink one of those places anyway instead of '<stdin>'.

The problem is not in the import, but when displaying the traceback of the exception. In other words, if you catch the exception, no attempt to open "<stdin>" happens:

$ strace -e open ./python
[...]
Python 3.5.0a0 (default:3417a95df7e2, Apr 16 2014, 17:57:12) 
[GCC 4.8.1] on linux
[...]
>>> 
>>> try: import dismal
... except ImportError: pass
... 
>>>

Also, by construction it will only happen if the import happens under the interpreter prompt (hence the "<stdin>" filename).

I honestly don't think this deserves introducing some complication, only to avoid a couple filesystem accesses.

I was able to reproduce it on 3.8, but I'm confused about where the open is happening because linecache.updatecache tries to avoid this:

if not filename or (filename.startswith('<') and filename.endswith('>')):
        return []

Ok, I'm unconfused now - this is the C version of the traceback, in _Py_DisplaySourceLine, not the traceback.py one that uses linecache.

It wouldn't be hard to add the check for "<>" in the filename there. Is there a reason not to do it?

New changeset f71300c by Irit Katriel in branch 'main':
bpo-1514420: Do not attempt to open files with names in <>s when formatting an exception (GH-28143)
f71300c

Fixed for Python 3.11. Thanks! ✨ 🍰 ✨