[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: I believe standard interpreter only adds '' to path after its startup. But it might be vulnerable to shadowing of delayed imports. -- ___ Python tracker

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: I was CC-ed on a response to a user who reported module shadowing as a security issue. If it is disabled by default, we could add an option to enable for intentional experiments. See idle.py. -- ___ Python

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Change by Terry J. Reedy : -- versions: +Python 3.10 -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Changes by Terry J. Reedy : -- keywords: +patch ___ Python tracker ___ ___ Python-bugs-list

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: #25488 and #26143 address related issues of sys.path as seen by IDLE and user code. #26143 focuses on what IDLE sees, and user modules shadowing IDLE modules, #25488 focuses on what user code sees, and the presence of idlelib in sys.path making buggy code

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Changes by Terry J. Reedy : -- components: +IDLE ___ Python tracker ___ ___

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Matthew Cowles added the comment: > a) for IDLE to run without stumbling over user files > b) for user code to see the same sys.path when executing under IDLE as when > executed directly with the same cpython binary in the same mode. If you can achieve that, no one will be more impressed than

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: What I want from this issue , from a user perspective, is a) for IDLE to run without stumbling over user files, and b) for user code to see the same sys.path when executing under IDLE as when executed directly with the same cpython binary in the same mode.

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Matthew Cowles added the comment: I'm very willing to believe that I'm missing something critical here, but wouldn't it be satisfactory to just move "" from the beginning to the end of sys.path in IDLE? I can imagine that it might cause a few problems for users, but it is simple and the

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: Thank you for making a start on code for this issue. After thinking about this a few hours, here is what I currently think. I don't want a tiny module for one function. I would like a module with objects common to the idle and user processes, in particular

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Louie Lu added the comment: Because sys module is correctly imported, we can modify sys.path to change the import behave. Add new PR 1364 for this. This add a new private function `_fix_import_path` that will remove the local import path `''`, when running IDLE from command line, it will

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Changes by Louie Lu : -- pull_requests: +1474 ___ Python tracker ___ ___ Python-bugs-list

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: I and others constantly tell people to start IDLE from the command line when they have a problem. Today, someone actually followed the advice and the traceback revealed that the problem was a personal tkinter.py masking the stdlib file! Renaming it to

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Matthew Cowles added the comment: > Do you have access to IDLE on any system other than Windows? I don't have a Windows machine at all. For what it's worth, here's the behavior I'm talking about, albeit with an old version of Python: $ mkdir testidle $ cd testidle $ /usr/local/bin/python

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: >From the viewpoint of IDLE and masking, the stdlib has three parts: idlelib, >other modules that IDLE imports, and other modules that IDLE does not import. >As I already noted, this division is different for IDLE and user processes. IDLE may delay importing

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: I will make this one of my priority issues once I get up to speed with the new workflow. However, it is not a trivial issue, and I am not sure that all my beliefs of a year ago were correct. What I really do not want to do is break IDLE running when users

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Matthew Cowles added the comment: This bug should be fixed urgently. Over at python-help we just got another Python beginner who was using IDLE and then started to get the "IDLE's subprocess didn't make connection" error. The problem was that the user had named one of their programs

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

Terry J. Reedy added the comment: Looking at https://stackoverflow.com/questions/15888186/cant-run-python-via-idle-from-explorer-2013-idles-subprocess-didnt-make-c and https://stackoverflow.com/questions/874757/python-idle-subprocess-error it seems that people have put things like tkinter.py,

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib

New submission from Terry J. Reedy: In the past few months, there has been an increase "IDLE fails to start" reports that are apparently due to shadowing of stdlib modules by user modules in the same directly as as user code. For instance, a beginner creates turtle.py and then writes "import