Pressing <Tab> while the cursor is in a string will bring up the file completion dialog rather than inserting a tab (or 4 spaces). This behavior is rather annoying in a text editor especially when editing multi-line doc strings.

This behavior is new to the 3.3 series as a consequence of #59142. Arguably, it is a regression.

The logic for bringing up the file completion window when pressing Tab in a string needs to be revised. If the string already contains a partial match, then bring up the window when pressing Tab, otherwise insert a Tab character or spaces.

Alternatively, the Ctrl+Space key sequence will already bring up the file completion dialog, so having an automatic Tab completion behavior is not absolutely necessary.

This issue can also be triggered in the shell. Start a string and then press tab twice.

(PATCH - adds 11 lines to autocomplete.py, needs test and conversion to PR. tjr)

Attached is a preliminary patch. It checks to see if the cursor is on a line within a multiline string in order to avoid displaying the ACW. As a last resort, it checks to make sure that a valid match exists before opening the ACW when mode == COMPLETE_FILES.

On windows, one tab brings up the box and in 3.2.3 and 2.7.3 also. Perhaps they should be revised also.

The difference is that in those latter two, <space> dismisses the box whereas in 3.3.0, it does not, making it even more obnoxious. Two more tabs inserts something. Tab within a comment just enters a tab converted to spaces.

I think that maybe tabs within strings should always do the same as within comments. Perhaps one way is enough. (I am guessing that other editors use <tab> for this, so I can see the desire to use it.) There needs to be a way to get tabbing within multiline strings. I did not see 'file completion' in Options/Configure/Keys. Is it there under a different name?

I was puzzled by the example path #59142 until I retried in 3.2.3. In 3.3.0, a / disables filename completion. I reopened this issue.

If one types 'd:\' and there is no d:, <tab> inserts spaces and ^space is ignored. I do not like this kind of inconsistency (or magical behavior shift). If you ask for file names, better to bring up a blank box, or a one-line box [<no matches>].

I think that maybe tabs within strings should always do the same as within comments. Perhaps one way is enough. (I am guessing that other editors use <tab> for this, so I can see the desire to use it.) There needs to be a way to get tabbing within multiline strings. I did not see 'file completion' in Options/Configure/Keys. Is it there under a different name?
Tab completion for file names is a convenience feature in IDLE, since
file I/O requires specifying file names in strings. The given patch
restores tabbing within a multiline string.

There is no configuration option for file completion.

I was puzzled by the example path d:/Biblioteca/Técnica/informática/Python from bpo-14937 until I retried in 3.2.3. In 3.3.0, a / disables filename completion. I reopened this issue.
I can use either "/" or "\" for file completion under Windows 7 with
3.3.0. Try "C:/" instead.

If one types 'd:\' and there is no d:, <tab> inserts spaces and ^space is ignored. I do not like this kind of inconsistency (or magical behavior shift). If you ask for file names, better to bring up a blank box, or a one-line box [<no matches>].
I agree that it is inconsistent, but then again, file-completion in a
string with Tab is a convenience feature. There is no good way to
specify "ask for file names" unless you create a separate key binding
just for that. Sometimes, a Tab is just a Tab.

The behavior introduced by the provided patch will only provide the file
completion box (or automatic fill-in) if the given string already
partially matches a file in the file system.

I have had problems entering docstrings because of this. Box should not come us when tab on successive lines. (There really should be autoindent, maybe this interferes.)

I've found this to be annoying as well especially in docstrings, hopefully this will help in the meantime.

If you SHIFT + Tab it will at least resolve the problem of bringing up files and remains as the usual tab function.

It makes me wonder if it is a bug at all though?

It is intentional that <modifier> <tab> be treated as a normal tab. The autocomplete_event tab handler begins with
if hasattr(event, "mc_state") and event.mc_state:
# A modifier was pressed along with the tab, continue as usual.
return

To fix the problem with tabs at the beginning of a line within multiline strings, I am adding to the condition a clause to catch tabs at the beginning of lines, whether within a multiline string or not.

or not self.text.get("insert linestart", "insert").strip()

Tests still pass with this addition. I need to add a test that fails without it.

I think a tab should bring up completion box even immediately after an opening quote, as in
open('<tab>
Typing a letter fails to open a box if there is only one completion, so that is not a foolproof way to get a box with all choices.

I pushed a patch on another issue that fixed tabbing on lines after the first line within multiline strings. With 3.6 and 3.11 I verified that tabbing anywhere on the same line of an opening quote, except immediately after the quote, brings up the box.

My local branch strcomp currently has a slight revision of the 'match' part of Roger's patch, and it seems to work as promised.
The 'multiline-string' part is not needed. I will skip the 'empty' part until a find trigger case for a test. It seems to be a separate issue. I might consider dumping tab for path completion, but wanting literal tab chars in strings is rare (and they are not converted to spaces). '\t' is better for getting a tab in the string object. Maybe literal tabs should become r'\t'.