I'm running Python 3.8 and Mac Os Catalina 10.15.1 When I click a .py file, it will open the shell + editor, However if I try to open a new .py file from my finder window it won't open. The only way I can open another file is through the shell by clicking file - open. I downloaded a folder with containing .py files from the web and I have no issue opening those files from my finder window. It appear to be only files created in my computer.

Thanks for the report.  If I understand correctly, the issue you are seeing is that, when IDLE is already launched and you double-click on a .py file in the Finder, that .py file does not open in IDLE, even though it will open in IDLE if IDLE is not already launched.  This does seem to be a change in behavior between macOS 10.14 Mojave and 10.15 Catalina. Further investigation is needed.

Of course, launching files in the right application is always somewhat dicey in macOS when there is more than one application claiming an association with a particular file type, like for .py files, so it is always safest to open files from with the app itself, for example, with IDLE's File -> Open menu option.

With Mohave, double click on a file name in Finder Documents opens the file in an editor and then opens the shell.  Double click on another file opens the file in another editor (but not a duplicate shell).  These are .py files I saved from IDLE.

Ramon originally posted this on Stackoverflow, where it is slightly off topic.  I suggested posting it here to at least have it documented and see what Ned says and for the off chance that there is something we can do.

I wonder how a downloaded file could be different from a saved file.  Are file permissions as revealed by 'ls -l' in the directory in Terminal the same?

We have a 10.15.3 Mac with python 3.8.2, IDLE version 3.8.2, and we see similar behavior.

Summary:
The *second* 'bad' .py file you double-click won't open in IDLE. This seems unrelated to permissions, but a 'bad' file (saved by IDLE) can be converted to a 'good' file by emailing the file to myself.

Details:
Open IDLE, save a 5-byte file 'fails.py' (contents: pass) to an empty folder. Permissions are rw-r--r--.

Close IDLE. Double-click 'fails.py', which opens in the IDLE editor; a shell also opens. Double-click 'fails.py' again, or drag it onto the IDLE icon in the Dock, and it does not open in a second instance of the IDLE editor. Typing `idle3 fails.py` in the terminal does open in a second instance of the IDLE editor (same version as first instance).

Email 'fails.py' to myself, via Gmail. Download 'fails.py' from Gmail, and rename it to 'works.py'. Permissions are still rw-r--r--.

Close IDLE. Double-click 'works.py', which opens in the IDLE editor; a shell also opens. Double-click 'works.py' again, or drag it onto the IDLE icon in the Dock, and it *does* open in a second instance of the IDLE editor. Any number of instances can be simultaneously opened this way.

Close IDLE. Double-click 'works.py' several times to open it in several different instances of the IDLE editor. Double-click 'fails.py' once, which successfully opens in one more instance of the IDLE editor. Finally, double-click 'fails.py' a second time; it does *not* open a second instance of 'fails.py' in the IDLE editor.

IDLE's File->Open menu option does not open two instances of `fails.py` OR `works.py`; attempts to open the second instance simply raise focus of the first instance. However, if you open 'fails.py' via the menu, you can then open a second instance of 'fails.py' via double-clicking, but not a third.

By design, IDLE should only allow one editor instance per file for a given python-IDLE process.  "$ python3 fails.py" opens a new python-IDLE process, independent of existing processes. It is possible that double-clicking good.py multiple times opens a new IDLE process each time, without a new Shell.  You could check the process list in Terminal. (I have forgotten the unix command and barely know bash.)

If possible, I would like to raise the priority of this issue.  I teach Python and I use IDLE every day.  This bug makes using IDLE for teaching extremely difficult.

Hopefully new information:

I have just bought a new Mac, which is running Catalina (MacOS 10.15).  I am using Python/IDLE 3.7.3, and I am seeing the same issue.  And it does seem to behave differently depending on if I created the file(s) on my computer (fails) vs downloading files from the internet (opens just fine). 

(For background info, I have used IDLE for years on my older Mac with MacOS 10.12 without seeing this problem.)

I have my Mac Finder set to open all ".py" files using IDLE.app in the Python 3.7 folder.

In the Finder, if I select one or more files and double click, each file opens in an editor window in IDLE.  But after that, with IDLE still open, double clicking on any other .py file is ignored.  I can edit and save any open file, but I can no longer open additional files by double clicking in the Finder, or by dragging a file to the IDLE icon in my Dock.

Further info:  If I am in IDLE and have an editing window open, then I choose to open a different file using File -> Open File, and navigate to another Python file, then the open file closes, and the new file opens - even if I have not saved any changed in the first file.

I never use the command line.  I just double click on Python files, and want to see them open in IDLE.  That's how I teach my students, and I typically have multiple small sample files open at the same time.  This bug makes it impossible to teach and work this way.

If it would help, I would be happy to create a small movie demonstrating this problem.

This is not really an IDLE issue; I only tagged it as such to make it easy for IDLE users to find.  It might or not be a python-install Catalina-upgrade issue.  It definitely is an Apple issue in that they care little for Python, nothing for tcl/tk, and released something that broke even 64-bit apps.

On my copy of Mohave, if x.py is open in IDLE, double clicking x.py in Finder does not open x.py in a new window.  Rather, it raises the existing x.py window to the top and makes it the active window.  This is what it should do.

IDLE File=>Open has a shortcut -- Command-O.  Either opens a  IDLE-specific Finder-like window.  The main difference from the Finder-app window is that selections are guaranteed to open in IDLE regardless of Finder/system settings. And once you have a file open, File-open/Command-C opens the IDLE-Finder dialog in the directory containing that file, with that file highlighted and others listed. So I consider this superior to the OS File Manager.  I also make great use of File=>Recent Files to open files.

Irv, file closing when you open another is a different issue from files not opening (but I don't know that a separate tracker issue would be useful).  It seems crazy, and was not reported by anyone else yet, but I will believe it without a movie.  Does this happen with IDLE's open dialog, or only with Finder itself?  If the latter, use the former.

Irv, I'm sorry you are having problems and I think it is very reasonable to bump the priority of the issue as you are not alone, even though, as Terry notes, a complete resolution may require changes elsewhere. I am looking more into this now. macOS 10.15 Catalina has introduced a number of changes in the interest of improving your security and some of these have had an impact on both Python and on Tcl/Tk which IDLE uses to power its GUI. While most of the 10.15-specific issues are addressed in the latest release of Python (3.8.3), the issue of double-clicking a file while IDLE is already open is not yet. However, I notice you mention that you are using IDLE from Python 3.7.3. If so, be aware that that is not the latest release of either Python 3 or Python 3.7 (3.7.3 predates Catalina.) 3.7.7 is the most recent for 3.7 but Python 3.8 is now current and its most recent release, 3.8.3, has the most up-to-date support for 10.15. If possible, you should update to 3.8.3 or at least to 3.7.7, which has some. That won't fix everyting but it may make some issues go away.

You also mention the apparent closing of an IDLE edit window when you open another edit window. I have not seen nor am aware of reports of behavior exactly like that; however, I think you might be running into a similar situation to what Andrew reports in an earlier comment (msg366978) in this issue. What you may be going on is a case where trying to open another file to edit in IDLE unexpectedly causes a second instance of IDLE to open, with the original file still open in the original instance (but perhaps with its windows now obscured by other windows) and with the second file open in an edit window in the additional IDLE instance.  That can be very confusing as having more than one instance of the same app running is normally not supposed to happen. One way to tell that this is happening is to check the macOS Dock and see if there is more than one IDLE icon present with the active indicator. If you switch to the other IDLE instance, your original edit window should still be present. (You could also use Mission Control features to see all open windows.)  Let us know if you can determine that the closing window is the second IDLE case with 3.7.3; this problem may not occur with IDLE from 3.8.3 but let us know.

By the way, I am assuming here that you are using Python 3.7.3 downloaded from the python.org website. Let us know if that is not the case.

If it's helpful, I'd be happy to do a screenshare session (Google Meet, Zoom, etc), to demonstrate and explore the behavior.

We have a 10.15.4 Mac with python 3.8.3 freshly installed from python.org, Tk version 8.6.8, IDLE version 3.8.3. IDLE file opening functions very differently on this machine then on any Linux or Windows machine I've used in the past decade.

Thanks, Andrew, for the offer. I think we have enough to go on right now but we may want to touch base a bit later.

From your comment about how IDLE on macOS is different than it is on Windows or Linux, I assume that means you may be new to IDLE on macOS. Yes, there are a number of sometimes subtle differences. Most of these are differences in how Tk behaves (rather than IDLE itself) and usually with a very good reason: Tk tries very hard to be a "good" citizen in each of the three major windowing environments it is supported: Windows-native, macOS-native, and X11 (Linux and others). As such, Tk tries to look and behave as native applications in each are expected to behave, which leads to subtle but important programming issues, like the fact that macOS applications are expected to have one menu bar that appears at the top of the active display whereas on other platforms, each window may have its own menu bar.  Or Tk uses the macOS-supplied file opening and closing sheets which differ from other platforms, etc etc. That can make using Tk-based apps, like IDLE, more familiar-looking to and easier to learn for macOS users but it can be disconcerting if you are using such an app on multiple platforms. Or perhaps you meant something else.

Thanks for all the message about this issue.

I have made a three-minute video that demonstrates what I am seeing.  Here is a link (the video is marked as "unlisted" so only people with this link can see it):

https://youtu.be/OIu-HCVVDn8

To answer your questions:

- Using 3.7 because I'm a heavy user of Pygame, and my understanding is that 3.8 is not compatible with Pygame now
- Yes, this is an absolutely standard installation from Python.org
- In all my testing, I have never seen multiple instances of IDLE.  There is only one.

I understand from the comments that this may not fully be an IDLE issue, and may require changes from Apple.  

I appreciate anything you can do to help resolve this issue. I am willing to supply any more information and/or do any testing to help.

Thank you for going to the trouble to produce the movie, Irv! It was very helpful. It turns out the disappearing window issue is because you are using the macOS 10.6+ Python 3.7.3 installer variant rather than the macOS 10.9+ installer variant. For some reason, the Tk built for 10.6 has this problem but when built for 10.9 it does not. So this problem is, indeed, not the two instances of IDLE behavior I speculated. The fix is simple: don't use the 10.6 variant. In fact, as of the beginning of 2020, we no longer provide the 10.6 variant for any version. I don't have experience with pygame but I did a quick test on 10.15 following the directions on the Pygame Getting Started page and verified that the aliens example worked with the latest 3.7.7 10.9 installer. I also tried with 3.8.3 and saw that the problem there is that the project has not provided a pre-built wheel for Pygame 1.9.6 so the installation fails while trying to build everything from source. I did try their suggestion further down the page to use a pre-release of pygame 2.  The latest prelease, 2.0.0.dev8, does have a prebuilt wheel for 3.8.x on macOS; it installed without issue and the aliens still worked. (Now back to the original issue!)

When I say that I am 99% sure that this is not an IDLE issue at all, I mean that I am 99% sure that a non-IDLE tkinter program registered as a working double-click handler in Mohave will not be properly invoked in Catalina.  A counter-example might suggest a possible fix for IDLE.

Likewise, doubt that this is a tkinter issue means that I suspect that a working .tcl Mohave double click handler would fail in Catalina.  A counterexample would suggest looking at tkinter/__init__.py and  _tkiter.py.  For example, #40452 was opened as a Windows-specific IDLE failure, with a PR.  However, Tal Einat discovered that a) the same problem existed on macOS, b) a 4-line tkinter program also failed, c) a 4-line .tcl program worked, and d) on exit, tcl calls code that is no longer called in _tkinter, during python exit (after python was partly torn down).  We expect to fix the issue by calling a narrower acting tcl function before python exit.

IDLE opens existing files with idlelib.filelist.FileList.open.  It gets filenames from the os command line, the tk open file dialog, IDLE's Open Module dialog and Path Browser, and its Recent Files list.  I don't know how an OS file manager passes a filename to this function in a particular process, but I imaging that the GUI framework, the IDLE icon, and the double-click registration information may all be involved.  (On both Windows and macOS, double clicks to not open the file in an existing IDLE opened from a command line.) Anyway, here is an easy experiment with IDLE itself that someone should do on Catalina.

Open x.y Shell an IDLE icon (not the command line).
File => OpenModule idlelib.filelist
At the top of the open() body, after 'def open(self, filename,...)' add
        tkMessageBox.showerror('', filename, master=self.root)
Save and close the editor and shell (*required*).
Open x.y Shell from the same IDLE icon.  It will import the revised filelist module.
Open a file from within IDLE.  A message box appears with the full path and an [OK] button.  Click the button and the new editor window appears.
Double-click a file in Finder.  For me, on Mohave, the same thing happens as above.  I expect that on Catalina, there is no message box, indicating that IDLE's file open function is not called.  If I am wrong, check the displayed path and move the debug line down to find where execution stops.

Thanks Ned and Terry for your responses.

Ned: I am currently teaching a course where my students and I are all using Python 3.7 and the current Pygame 1.9.6, so unfortunately, I cannot update to the newer development release of 2.0.  I am also writing a book on OOP using Pygame, and that is currently dependent on the same Pygame release.

Terry:  I tried following your steps.  I opened the appropriate file (idlelib.filelist), and added the line at the appropriate place.  But when I go to save, I get a message:

[Errno 13] Permission denied: 'Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/idlelib/filelist.py'

So I cannot save the file.

I tried opening the same file a simple text editor, BBEdit, and made the same change.  When I went to save I got a message:

Are you sure you want to unlock filelist.py?  You aren't a member of the group 'wheel'.
      Cancel   Unlock

I chose Unlock, saved and quit.  The Finder shows a new date for the file.  But when I double clicked on my Python 3.7 icon, or if I double click on any Python file, IDLE no longer opens.  

I went back into BBEdit, removed the new line, saved again.  Now I can open IDLE as before.  

I don't have a good feel for what files I am supposed to be "allowed" to edit, so I don't know what to try next.  If you have any suggestions about how I can add your debugging line successfully, I'm happy to help.

Irv, thanks for the feedback and the attempt. I think we had a little bit of a misunderstanding on our end so I don't think we need you to try anything more for this problem.

Terry, I apologize if I left the impression that there was some doubt about whether the double-clicking failure was due to a problem in IDLE. This is almost certainly a Tk issue but ultimately we need to be able to address the problem for python.org macOS installers. That's what I am working on right at the moment. I should have something for you and Tal to look at soon and we can proceed from there. Thanks!

Ramon, I am not sure why you closed this issue. Perhaps it may no longer be a problem for you, but it has not yet been resolved for users of the python.org macOS installers.

Right.  I'm struggling with this bug every day.

Irv

> On Jul 23, 2020, at 9:09 AM, Ned Deily <report@bugs.python.org> wrote:
> 
> 
> Ned Deily <nad@python.org> added the comment:
> 
> Ramon, I am not sure why you closed this issue. Perhaps it may no longer be a problem for you, but it has not yet been resolved for users of the python.org macOS installers.
> 
> ----------
> stage: resolved -> 
> status: closed -> open
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue38946>
> _______________________________________
>

Yep, me too. It's very annoying indeed.

As another datapoint: This works for me on macOS 11.1 with the universal2 installer for Python 3.9.1 (which includes Tk 8.6.10).

Thanks, Ronald and others. I have done some testing now with macOS 11 Big Sur and retested on 10.15 Catalina and with various versions of Tk and what I am seeing is as follows.

- On macOS 11.1 Big Sur with IDLE.app from the python.org 3.9.1 universal2 installer set as the user default for .py files, double-clicking on a .py file causes IDLE 3.10 to launch and the .py file to open in an edit window as expected. Double-clicking on additional .py files in the Finder while IDLE is already launched does cause the files to be opened in the active IDLE.app also as expected. Performing the same sequence with the same 3.9.1 installer on macOS 10.15.7 Catalina, double-clicking on additional files do not cause them to be opened in the active IDLE.app as reported in this issue.

- I also verified that the same behavior is seen with IDLE.app from a couple of other python.org installers, for example, 3.8.7: double-clicking on additional .py files does not cause them to be opened in an active IDLE.ap on 10.15.7 but does on 11.1.

So, it looks like this really is an operating system (Launch Services?) issue in macOS 10.15 that has been changed/fixed in macOS 11. While there *might* be a way to programmatically workaround this within IDLE, Python, or Tk on 10.15, so far we haven't found one. And there is a fairly simple workaround on 10.15: just use the IDLE File -> Open menu item or keyboard shortcut (cmd-O).  It's not as elegant if you are used to double-clicking but it works and realistically we are not going to see a change in 10.15 behavior from Apple.

I would appreciate any other confirmations of this behavior or any ideas for a workaround. Barring the latter, I think we should probably just close this issue, unfortunately, as an OS bug.



Now just to make things a bit more complicated - sigh: I also tested with the recent python.org installer for the 3.10.0a4 pre-release. The principal difference between the 3.9.1 and 3.10.0a4 versions I tested with is that the 3.9.1 is linked with Tk 8.6.10 while 3.10.0a4 is linked with the just-released Tk 8.6.11. On macOS 11 Big Sur, there is one noticeable difference in behavior between the two. With the macOS 11 Big Sur / 3.10.0a4 / 8.6.11 combo, when double-clicking on a .py file without IDLE.app being active, a message window appears saying that the application cannot open Python Script files but does launch IDLE.app. With IDLE.app now active, double-clicking again on the same file then does cause the file to be opened in an edit window of the active IDLE as expected and double-clicking on other .py files then open edit windows for them as expected. Without more detailed investigation, this appears to be a minor problem (possibly a change in Tk) unrelated to those in this issue other than that it involves double-clicking on .py files but I thought I should mention it here in case someone runs into it before it is resolved.

I have little experience posting in forums, so if this post is in the wrong place, please let me know. 

I am running Python3.9, with Apple OS 10.15.7
I was using IDLE successfully for a class in Python for the past three weeks, although I was rarely able to open a file by double clicking it. It actually worked a few times, but most of the time, nothing happened, and I would open IDLE first, and then open a file from its file menu. 

But today, IDLE will not open. When I click on the icon in the dock like I usually did, it seems to open for about .5 seconds, and then quits. Also, now when I double click on a .py file, IDLE will open for about .5 seconds and then quits. I reinstalled the package, but no change.

However, in terminal I can launch python with this command: python3.9. Then I can launch IDLE with this command: import idlelib.idle. The IDLE window opens, and I can open files from the file menu and they run as before. However, the title of the file menu is now "Python" where before, it was "IDLE"

Sorry, I meant to say the title of the PROGRAM in the menu items is now Python.

Yes, the program title depends on what 'app' you start.  I presume that this is normal for Mac.