The second line of the Find in Files dialog is
In files: [____________________________________]
When this is opened in the startup directory, Shell or an untitled editor, the entry starts as '*.py'. When this is opened in an titled editor file, the initial entry is the full path. A full path is much more useful and should always be given.

To be more exact, if 'Find in Files' is called in an unsaved editor window, including Output windows, the the entry starts as '*.py'. I presume that this is relative to the current working directory, which is initially the startup directory. But this can change in an undocumented way. There is currently no way in a grep output to determine which directory was searched. This is especially annoying when there are no hits and one knows that there should be some.

My initial thought was to prefix '*.py' with the directory of sys.executable. os.getcwd() might be more useful. This would be in GrepDialog.open. This will still be untested after PR12203 for bpo-23205.
Most of this method is self-free path manipulation that can be pulled into a module method and separately tested.

PR12203 adds os.curdir ('.') to no-directory patterns. After this issue, that will not be necessary unless a user deletes the explicit directory. I am pausing a PR for this issue until I finish reviewing that one and it is merged.

In the long run, I might like to separate the 'In files' glob path into 'Directory' and file glob pattern. (On Windows at least, glob patterns are not allowed in the directory part of the pattern.)

A related improvement would be listing the base search directory once at the top of output windows and not repeat it on every hit line. This would require revising the GoTo File/Line function.

See also bpo-21960. I'm going to close that one in favor of this issue.

Thanks. I somehow never marked it for IDLE. Using groupby components, I discovered another +-10 and marked them and included in my list.