Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On the notion that IDLE is fatally flawed and is driving away potential users of Python (to put the statements in their most extreme form): It seems that there are (at least) two very different communities people have in mind. I can appreciate that highly expert programmers may find IDLE insufficient for their needs, and it might even be the case that these people should be advised not to even try IDLE. But I want to stress as strongly as possible that for a very large community of nonexpert users of Python, IDLE has been extremely important and works very well for their purposes. Editing is pretty much like what they're already used to in word processors, which is certainly not the case with professional tools such as vim or Emacs. That said, yes, there are some significant deficiencies with the current IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear from Martin that Guilherme is free to commit his important bug fixes and improvements. I'm afraid that neither Guilherme nor I understood the procedures and thought that we had to wait for others to act. Bruce Sherwood
On Sun, Jul 11 2010, Bruce Sherwood wrote:
On the notion that IDLE is fatally flawed and is driving away potential users of Python (to put the statements in their most extreme form):
It seems that there are (at least) two very different communities people have in mind. I can appreciate that highly expert programmers may find IDLE insufficient for their needs, and it might even be the case that these people should be advised not to even try IDLE. But I want to stress as strongly as possible that for a very large community of nonexpert users of Python, IDLE has been extremely important and works very well for their purposes. Editing is pretty much like what they're already used to in word processors, which is certainly not the case with professional tools such as vim or Emacs.
Particularly on Windows, there is an expectation that a contemporary programming language comes with a GUI. Using the Windows Python shell isn't very satisfactory, largely because of the poor file handling capability in that environment. IDLE provides a simple solution, suitable for beginners as well as experts. It provides one-keystroke save/run in a fresh environment not associated with the GUI. I have run IDLE inside IDLE (though I'm not positive that will work right now). How many IDEs can do that? I've tried to channel Guido, and my general approach has been to provide as much functionality as needed, but to hide the more advanced features to avoid clutter. When the 'experts' need them, they will find them. I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? And IDLE is cross-platform. There are perhaps deficiencies on the Mac, but Ron has made good progress. I haven't been able to come up with a Mac yet, so I can't really comment. IDLE works on 2.7 and 3.x. Running IDLE on the trunk is a decent test of Python and tkinter during development. It seems that people who do Scheme write Scheme implementations, while people who do Python write IDEs :-) Usually, they keep adding features and buttons until it looks like Eclipse. That's fine. But why turn IDLE into another example of that style and diminish diversity in doing so? On a netbook, screen space is at a premium, and a simple interface has advantages. There are many IDEs listed on the wiki if people are looking for the more complex style, but I'd suggest that they aren't appropriate for beginners. And by beginners, I include elementary school students. IDLE works with "extensions". Plug-ins, if you will. The Option dialog needs enhancement to support extension selection, and I believe there is a patch to do that. More extensions would be a good thing. The .idlerc directory determines IDLE's configuration, including the help source urls available on the Help menu. By downloading .idlerc or via indirection, a student environment can be set up including the day's lesson and which extensions are activated. Call tips and method name completion can be "hidden" by increasing the time delay before they pop up.
That said, yes, there are some significant deficiencies with the current IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear from Martin that Guilherme is free to commit his important bug fixes and improvements. I'm afraid that neither Guilherme nor I understood the procedures and thought that we had to wait for others to act.
Tal has made a couple of comments about not being able to run multiple IDLEs at the same time, and he mentions http://bugs.python.org/issue1529142 This bug has been closed for over a year, and you can run as many IDLEs as you like. You can run 2.7 and 3.x at the same time. I would have expected Tal to know that. Also, the current right click edit action on Windows is to only open an edit window; no shell. And it uses the subprocess! So, some of the comments on this thread are not up to date. The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool. Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it. As I recollect, much of what Scherer did in VIDLE related to running multiple IDLE copies. For that reason, the VIDLE changes have to be evaluated carefully to determine what has already been incorporated. I believe I added a couple of his smaller changes, also. Bruce, speaking of Dave Scherer, we've been trying to get a Python Contributor Agreement from him. Is that something you can help us with? -- KBK
On Mon, 12 Jul 2010 05:20:49 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly?
Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it; the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code. Regards Antoine.
After a few keystrokes in the interactive interpreter, I got the following traceback: Traceback (most recent call last): File "Lib/idlelib/idle.py", line 11, in <module> idlelib.PyShell.main() File "/home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py", line 1420, in main root.mainloop() File "/home/antoine/py3k/__svn__/Lib/tkinter/__init__.py", line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0: invalid start byte The keystrokes were ['d', 'i', Ctrl+Space], which briefly displayed the completion popup before crashing. Regards Antoine.
On Mon, Jul 12 2010, Antoine Pitrou wrote:
On Mon, 12 Jul 2010 05:20:49 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly?
Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets.
That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4. On Windows, our installer is using 8.5. Here's a screenshot from my eeePC, 1024 x 600: http://images.rant.ml1.net/idle.gif Quoting Tal: ============================================
Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter.
Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native look&feel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. =============================================
Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago. Linux is behind, we don't control that, but our Windows installer and tkinter is cutting edge! Thanks, Martin! I don't know what version is running on the Mac: http://blog.markroseman.com/2007/12/tcltk-85-first.html I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk 8.4. I think you guys are exaggerating. It's not /all/ that ugly, not by a long shot. It's just not native look and feel (yet).
Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it;
On Linux and Windows, <alt> f will drop the file menu.
the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts).
Looks much better in 8.5 and the shortcuts work. http://images.rant.ml1.net/idle2.gif
The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code.
Pull down the format menu. The dedent hotkey is Ctrl+[ This possibly could be changed to Shift+Tab by the user, but there may be conflicts with completion. -- KBK
On Mon, 12 Jul 2010 08:12:10 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets.
That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4.
No, that's wrong. Tk here is 8.6: $ ldd build/lib.linux-x86_64-3.2/_tkinter.so [...] libtk8.6.so.0 => /usr/lib64/libtk8.6.so.0 (0x00007f4eb9259000) libtcl8.6.so.0 => /usr/lib64/libtcl8.6.so.0 (0x00007f4eb8f07000) [...] $ ./python -c "import tkinter; print(tkinter.TkVersion)" 8.6
the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts).
Looks much better in 8.5 and the shortcuts work.
Well, this is a Windows screenshot. I'm under Linux.
On Mon, Jul 12 2010, Antoine Pitrou wrote:
On Mon, 12 Jul 2010 08:12:10 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets.
That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4.
No, that's wrong. Tk here is 8.6:
$ ldd build/lib.linux-x86_64-3.2/_tkinter.so [...] libtk8.6.so.0 => /usr/lib64/libtk8.6.so.0 (0x00007f4eb9259000) libtcl8.6.so.0 => /usr/lib64/libtcl8.6.so.0 (0x00007f4eb8f07000) [...]
$ ./python -c "import tkinter; print(tkinter.TkVersion)" 8.6
What distro are you using? Tk8.6 is still in beta. Still looks crummy? Bummer.
the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts).
Looks much better in 8.5 and the shortcuts work.
Well, this is a Windows screenshot. I'm under Linux.
Fine, I showed it as an example of the improvement in 8.5. Most people, I think, are using Windows or Macs. Looks decent, don't you think? I don't have Tk8.5 running under Linux yet, much less 8.6. But the Tk release docs claim improvement under X11. It's possible we may have to use Tk theming to get full benefit of the Tile improvements in X11. -- KBK
On Mon, 12 Jul 2010 11:23:04 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
What distro are you using? Tk8.6 is still in beta.
It's Mandriva 2010.1
Still looks crummy? Bummer.
Yes.
Fine, I showed it as an example of the improvement in 8.5. Most people, I think, are using Windows or Macs. Looks decent, don't you think?
Yes, it does. If indeed the main target population for IDLE is Windows and Mac users (since Linux users have a lot of alternatives almost by default), then I suppose the situation is not that bad. Regards Antoine.
On Tue, Jul 13, 2010 at 1:44 AM, Bill Janssen <janssen@parc.com> wrote:
Steve, you encouraged me to try it again. From an xterm on OS X 10.5.8, it launches fine (long as you know where it is -- /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle). Seems to work OK for what it is, too. Same for Terminal. When I start it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window pops up under the Emacs window, which is why I didn't see it over the weekend.
FWIW, "./python -m idlelib,idle" launched the shell window for me on two development installs. "python -m idlelib.idle" didn't work intially on the system Python (since Kubuntu leaves idle out by default), but it worked fine once I installed the idle package. (Oh, and I can confirm it still looks like a Tcl/Tk app on Kubuntu rather than a KDE app even with Tk 8.5) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Jul 12, 2010 at 8:12 AM, Kurt B. Kaiser <kbk@shore.net> wrote:
On Mon, Jul 12 2010, Antoine Pitrou wrote:
On Mon, 12 Jul 2010 05:20:49 -0400 "Kurt B. Kaiser" <kbk@shore.net> wrote:
I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly?
Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets.
That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4.
FYI, I'm at 8.5 here, running Ubuntu 9.10, haven't knowingly updated tk.
On Windows, our installer is using 8.5. Here's a screenshot from my eeePC, 1024 x 600:
You may have meant to put a different image up, this one is windows.
Quoting Tal: ============================================
Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter.
Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native look&feel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. =============================================
Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago. Linux is behind, we don't control that, but our Windows installer and tkinter is cutting edge! Thanks, Martin! I don't know what version is running on the Mac:
http://blog.markroseman.com/2007/12/tcltk-85-first.html
I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk 8.4. I think you guys are exaggerating. It's not /all/ that ugly, not by a long shot. It's just not native look and feel (yet).
No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point.
Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it;
On Linux and Windows, <alt> f will drop the file menu.
the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts).
Looks much better in 8.5 and the shortcuts work.
http://images.rant.ml1.net/idle2.gif
The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code.
Pull down the format menu. The dedent hotkey is Ctrl+[
This possibly could be changed to Shift+Tab by the user, but there may be conflicts with completion.
-- KBK _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/debatem1%40gmail.com
On Mon, Jul 12 2010, geremy condra wrote:
No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point.
Right, I stay away from working on Tk. It's not even a tkinter issue. I hope it will continue to get better, but I imagine it's a moving target for the Tk developers. In your case, just bring up Wing. That'll impress them. As long as it's not on netbook :-) -- KBK
On Mon, Jul 12, 2010 at 11:32 AM, Kurt B. Kaiser <kbk@shore.net> wrote:
On Mon, Jul 12 2010, geremy condra wrote:
No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point.
Right, I stay away from working on Tk. It's not even a tkinter issue. I hope it will continue to get better, but I imagine it's a moving target for the Tk developers.
In your case, just bring up Wing. That'll impress them. As long as it's not on netbook :-)
The point isn't to impress them. The point is to not embarrass us. I just do it in gedit and ipython now, and I use an eee 901 for all my presentations and a good bit of my work and it seems to be fine, which is not paying much of a complement to IDLE. Geremy Condra
Hi Kurt, I'm glad you've joined this discussion. My point is that whatever the reason, for the past five years (at least) nearly every issue related to IDLE has taken years to be resolved, and many have still not been resolved. As a result the current state of IDLE is quite poor. To be perfectly clear, I'm am not blaming anyone for this. I just think this is something the development community should be more aware of and decide how to deal with. On Mon, Jul 12, 2010 at 12:20 PM, Kurt B. Kaiser wrote:
Particularly on Windows, there is an expectation that a contemporary programming language comes with a GUI. Using the Windows Python shell isn't very satisfactory, largely because of the poor file handling capability in that environment. IDLE provides a simple solution, suitable for beginners as well as experts. It provides one-keystroke save/run in a fresh environment not associated with the GUI. I have run IDLE inside IDLE (though I'm not positive that will work right now). How many IDEs can do that?
[snip]
On a netbook, screen space is at a premium, and a simple interface has advantages. There are many IDEs listed on the wiki if people are looking for the more complex style, but I'd suggest that they aren't appropriate for beginners. And by beginners, I include elementary school students.
I agree that IDLE is great specifically thanks to its simplicity, and should be kept simple. I think something like IDLE can be great for teaching and learning Python (and other uses as well) and has a place in the stdlib. I'm simply not sure if IDLE in its current state is fit for this purpose.
I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly?
IDLE may be somewhat close to looking like a native application, but it is not quite there. Some examples: * Users expect to be able to copy/paste using the mouse via the right-click context menu, which is impossible in IDLE (in both shell and editor windows). * The selection jumping to the end of the line unexpectedly doesn't happen in any other GUI text editor. * The config dialog looks archaic. As for the native look&feel, this has still not been integrated into IDLE, though it seems now it will happen soon. This has already been discussed here.
IDLE works with "extensions". Plug-ins, if you will. The Option dialog needs enhancement to support extension selection, and I believe there is a patch to do that. More extensions would be a good thing.
IDLE extensions are a pain to work with and badly supported. Installing an extension requires manually placing it in the idlelib directory and manually adding its config options to a certain text file in that directory. In practice nobody ever takes the effort to try installing an IDLE extension, such as my SearchBar extension. There has been discussion on improving this situation, but again this never actually happened. I tried to move this along with a patch which adds an extension config dialog, which has been sitting in the issue tracker ignored for two years.
Tal has made a couple of comments about not being able to run multiple IDLEs at the same time, and he mentions
http://bugs.python.org/issue1529142
This bug has been closed for over a year, and you can run as many IDLEs as you like. You can run 2.7 and 3.x at the same time. I would have expected Tal to know that.
I clearly mentioned that as an example of a fix for a major usability issue which took three years to resolve after a workaround was first posted. It is worth noting that most people still don't use the versions of Python (and IDLE) where this fix has been integrated.
The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool.
Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it.
True, but it took three whole years for this to happen. And this is for a glaring, annoying and limiting issue that nearly every user of IDLE has encountered.
Kurt B. Kaiser:
I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly?
While Tk has improved at emulating native appearance, there are still many differences. On the main editing screen of IDLE, the most noticeable issue is that there is no horizontal scroll bar even though the text will move left when you move the caret beyond the rightmost visible character. The scrollbar and status bar have an appearance that looks to be from Windows 2000, not Windows XP and there is no resizing gripper on the right side of the status bar. The tear off menus are ugly as well as being non-standard on all three major platforms. Use the "Configure IDLE..." and an "idle" dialog appears that also looks to be from Windows 2000. I know Tk can do better than this as Git Gui (the Tk (8.5.8) program I use most often) at least shows XP themed buttons, scrollbars and other controls. However, the "idle" dialog (as well as Git Gui) shows the largest remaining problem for Tk user interfaces: keyboard navigation. When the "idle" dialog opens, try doing anything with the keyboard. Chances are nothing will happen. If you press Tab 16 times (yes, 16!) a focus rectangle will finally show on the "Bold" check box. Another Tab takes you to the "Indentation Width" slider. After that you don't see the focus until it wraps around to "Bold" again. The Enter key doesn't trigger OK and the Escape key doesn't let you escape. The Find and Replace dialogs are better as focus works as do Enter and Escape but none of the buttons have mnemonics. This may all sound like picking nits but details and consistency are important in user interfaces and this is just looking at the most easily discovered problems. Neil
On Mon, Jul 12 2010, Neil Hodgson wrote:
On the main editing screen of IDLE, the most noticeable issue is that there is no horizontal scroll bar even though the text will move left when you move the caret beyond the rightmost visible character.
That was a design decision by Guido to encourage keeping to 80 columns.
The scrollbar and status bar have an appearance that looks to be from Windows 2000, not Windows XP
Tk issue, maybe we can address it with theming.
and there is no resizing gripper on the right side of the status bar.
Although the corner can be dragged, that would be useful. As I recollect, we special-cased it so there is a space for the Mac gripper!
The tear off menus are ugly as well as being non-standard on all three major platforms.
Well, would you discard them? They can (occasionally) be useful.
Use the "Configure IDLE..." and an "idle" dialog appears that also looks to be from Windows 2000. I know Tk can do better than this as Git Gui (the Tk (8.5.8) program I use most often) at least shows XP themed buttons, scrollbars and other controls. However, the "idle" dialog (as well as Git Gui) shows the largest remaining problem for Tk user interfaces: keyboard navigation. When the "idle" dialog opens, try doing anything with the keyboard. Chances are nothing will happen. If you press Tab 16 times (yes, 16!) a focus rectangle will finally show on the "Bold" check box. Another Tab takes you to the "Indentation Width" slider. After that you don't see the focus until it wraps around to "Bold" again. The Enter key doesn't trigger OK and the Escape key doesn't let you escape.
The Find and Replace dialogs are better as focus works as do Enter and Escape but none of the buttons have mnemonics.
This may all sound like picking nits but details and consistency are important in user interfaces and this is just looking at the most easily discovered problems.
No, these are worthwhile improvements, and not too difficult. -- Thanks, KBK
Kurt B. Kaiser:
The tear off menus are ugly as well as being non-standard on all three major platforms.
Well, would you discard them? They can (occasionally) be useful.
Yes, I would replace the menus with ones missing the tear line. Most of the GUI toolkits experimented with tear-offs (Mac in late 80s, GTK+ up until 2002) and dropped them or hid them in a rarely visited API. The idea initially appeared reasonable ("I can have the Run and Check commands available with a single click") but was found to be too confusing in use. IDLE, because it uses a separate top-level window for each file and shell suffers more than most applications. A menu is torn off from one window and always applies to that window but shows no visual affinity with that window: its window is not even activated when a menu command acts on it. Neil
Neil Hodgson wrote:
Kurt B. Kaiser:
The tear off menus are ugly as well as being non-standard on all three major platforms. Well, would you discard them? They can (occasionally) be useful.
Yes, I would replace the menus with ones missing the tear line. Most of the GUI toolkits experimented with tear-offs (Mac in late 80s, GTK+ up until 2002) and dropped them or hid them in a rarely visited API. The idea initially appeared reasonable ("I can have the Run and Check commands available with a single click") but was found to be too confusing in use.
IDLE, because it uses a separate top-level window for each file and shell suffers more than most applications. A menu is torn off from one window and always applies to that window but shows no visual affinity with that window: its window is not even activated when a menu command acts on it.
I agree, the tear-off menus are an anachronism. I'd also like a pony in the form of easily-changeable sets of keystroke mappings. I have never found Alt-P and its cousins either memorable or comfortable. I won't raise an issue for this. There are enough IDLE tickets without it :-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Mon, Jul 12 2010, Steve Holden wrote:
I agree, the tear-off menus are an anachronism.
OK, thanks for the input. I use them rarely, myself.
I'd also like a pony in the form of easily-changeable sets of keystroke mappings. I have never found Alt-P and its cousins either memorable or comfortable.
Is Options / Configure IDLE / Keys what you are looking for? There are four built-in sets currently, and you can define your own based on one of those. -- KBK
On Mon, Jul 12, 2010 at 3:20 AM, Kurt B. Kaiser <kbk@shore.net> wrote:
As I recollect, much of what Scherer did in VIDLE related to running multiple IDLE copies.
For that reason, the VIDLE changes have to be evaluated carefully to determine what has already been incorporated. I believe I added a couple of his smaller changes, also.
Bruce, speaking of Dave Scherer, we've been trying to get a Python Contributor Agreement from him. Is that something you can help us with?
-- KBK
I don't recall that VIDLE has anything to do with running multiple IDLE copies. What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students. I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context. If you'll send me what you want from Scherer, I can contact him. Bruce Sherwood
On Mon, Jul 12 2010, Bruce Sherwood wrote:
I don't recall that VIDLE has anything to do with running multiple IDLE copies.
Well, I stole the ephemeral port idea from him!
What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students.
I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context.
I'd like to get all that incorporated so you can go back to dealing directly with us. Your students are the people we want to reach!
If you'll send me what you want from Scherer, I can contact him.
I'm copying our PSF Secretary/Administrator, Pat Campbell. She can work with you to get David Scherer's Contributor Agreement. We really appreciate your assistance with this, he's one of the last missing agreements. -- KBK
Hi Bruce: Please click on the link below to find the contributor agreement form along with instructions on how to send it. http://www.python.org/psf/contrib/ If you have any questions, please let me know. Thanks, Pat Campbell PSF Secretary & Administrator On Mon, Jul 12, 2010 at 9:34 PM, Kurt B. Kaiser <kbk@shore.net> wrote:
On Mon, Jul 12 2010, Bruce Sherwood wrote:
I don't recall that VIDLE has anything to do with running multiple IDLE copies.
Well, I stole the ephemeral port idea from him!
What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students.
I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context.
I'd like to get all that incorporated so you can go back to dealing directly with us. Your students are the people we want to reach!
If you'll send me what you want from Scherer, I can contact him.
I'm copying our PSF Secretary/Administrator, Pat Campbell. She can work with you to get David Scherer's Contributor Agreement. We really appreciate your assistance with this, he's one of the last missing agreements.
-- KBK
-- Pat Campbell PSF Administrator/Secretary patcam@python.org
Kurt B. Kaiser wrote:
Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native look&feel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it.
Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago.
I was referring to the integration of the new ttk widgets into IDLE, which still hasn't happened despite two years having gone by. Sorry for not being clear on that point. - Tal Einat
On Mon, Jul 12, 2010 at 9:20 AM, Kurt B. Kaiser <kbk@shore.net> wrote:
Also, the current right click edit action on Windows is to only open an edit window; no shell. And it uses the subprocess! So, some of the comments on this thread are not up to date.
The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool.
Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it.
That's great news! I TAed a freshman Python class this January, and Windows users ran into this problem a lot. Mostly when hitting 'x' in the upper right. Fortunately, some quick searching led me to the Python tracker where I found the workaround. :) (Somwhat off-topic): Another pain point students had was accidentally shadowing stdlib modules, like random. Renaming the file didn't solve the problem either, because it left behind .pycs, which I had to help them delete. Overall, I would say that IDLE worked very well in that situation, so while it does have its quirks, it worked very well for us. Imagine trying to get students started with Eclipse or NetBeans. Yuck! Reid
On Jul 12, 2010, at 11:36 AM, Reid Kleckner wrote:
(Somwhat off-topic): Another pain point students had was accidentally shadowing stdlib modules, like random. Renaming the file didn't solve the problem either, because it left behind .pycs, which I had to help them delete.
I feel your pain. It seems like every third person who starts playing with Twisted starts off by making a file called 'twisted.py' and then getting really confused by the behavior. I would love it if this could be fixed, but I haven't yet thought of a solution that would be less confusing than the problem itself.
On Mon, Jul 12, 2010 at 03:48:12PM -0400, Glyph Lefkowitz wrote:
I feel your pain. It seems like every third person who starts playing with Twisted starts off by making a file called 'twisted.py' and then getting really confused by the behavior. I would love it if this could be fixed, but I haven't yet thought of a solution that would be less confusing than the problem itself.
Doesn't absolute import help? Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman <phd@phd.pp.ru> wrote:
Doesn't absolute import help?
Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On 12/07/2010 22:33, Fred Drake wrote:
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman<phd@phd.pp.ru> wrote:
Doesn't absolute import help?
Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module.
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Michael Foord
-Fred
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems.
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On 12/07/2010 22:47, Fred Drake wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems.
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct.
It seems to bite every newbie at some point. The change would have to go through the usual deprecation cycle I guess. All the best, Michael Forod
-Fred
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drake <fdrake@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems.
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct.
Except that modules can often be executed as scripts... Antoine.
On 12/07/2010 22:59, Antoine Pitrou wrote:
On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drake<fdrake@acm.org> wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems.
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct.
Except that modules can often be executed as scripts...
Allowing a module-executed-as-script to be in sys.modules twice with different names and classes is still a recipe for problems. For example see this blog entry from Phil Hassey, an experienced Python developer, caused by this issue: http://www.philhassey.com/blog/2009/07/16/oddball-python-252-import-issue/ For scripts that need to be in sys.modules with their "real" name (e.g. modules executed with python -m) the following trivial workaround is possible: if __name__ == '__main__': sys.modules[real_name] = sys.modules['__main__'] That avoids the problem of error messages like: TypeError: unbound method foo() must be called with A instance as first argument (got A instance instead) (Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare. All the best, Michael
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
(Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare.
That particular issue can be resolved by automatically doing the shadowing at the sys.module level though (i.e. insert into sys.modules under the real module name as well as __main__ for runpy._run_module_as_main and just strip the directory and extension details from __file__ to determine where to insert the second reference for a directly executed script file). Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable. Trying to special case shadowing detection just because the shadowing module happens to also be the main module seems ugly as hell :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable.
One detail that may not have been obvious when I described the persistent object problem; when class references are pickled, they should be for the "real" name of the module, not __main__. Loading the file as __main__ and adding an alias in sys.modules simply isn't sufficient. Existing instances could be loaded, but new instances would cause references to the classes defined in __main__. To some degree, this sort of problem can be easily handled using a "don't do that" approach, and this isn't likely to burn someone just learning Python on the first day. (Well, maybe in the afternoon, once they've got the basics down.) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On 13/07/2010 14:00, Nick Coghlan wrote:
(Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare.
That particular issue can be resolved by automatically doing the shadowing at the sys.module level though (i.e. insert into sys.modules under the real module name as well as __main__ for runpy._run_module_as_main and just strip the directory and extension details from __file__ to determine where to insert the second reference for a directly executed script file).
Sure - there are trivial workarounds which is why I don't think there are *many* genuine use cases for a module reimporting itself with a different name. Michael
Making sure both __main__ and the corresponding importable name refers to the same module object seems reasonable. Trying to special case shadowing detection just because the shadowing module happens to also be the main module seems ugly as hell :)
Cheers, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Wed, Jul 14, 2010 at 2:25 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Sure - there are trivial workarounds which is why I don't think there are *many* genuine use cases for a module reimporting itself with a different name.
My concerns aren't about a module reimporting itself directly, they're about the case where a utility module is invoked as __main__ but is also imported normally somewhere else in a program (e.g. pdb is invoked as a top-level debugger, but is also imported directly for some reason). Currently that works as a non-circular import and will only cause hassles if there is top-level state in the affected module that absolutely must be a singleton within a given application. Either change (disallowing it completely as you suggest, or making it a circular import, as I suggest) runs the risk of breaking code that currently appears to work correctly. Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though.
Not sure about changing __name__ anywhere... I don't do that. When an "application" is defined more by operations on persistent data then what top-level script is run, we (Zope Corp.) often have many different __main__s that run with the same database; there's generally not any point in thinking of the script as a module at all; the fact that it's available as sys.modules['__main__'] isn't important. We generally avoid the problem by applying the don't-do-that rule. Our actual scripts are always generated, and don't live in module-space. Understanding what not to do is an important aspect of teaching, though. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On Wed, Jul 14, 2010 at 7:34 AM, Fred Drake <fdrake@acm.org> wrote:
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though.
Not sure about changing __name__ anywhere... I don't do that.
The interpreter does though (when it sets it to "__main__" instead of what it would have been if the module had been imported rather than executed). That fact is convincing me that we should leave this alone for now. A module imported as __main__ and a module imported under it's real name are *different*, and this is reflected in pickles they generate and anything else that remembers the values of __name__. Obscuring that by treating them as equivalent in some contexts (such as name shadowing) while they remain different in other significant ways is unlikely to help overall. I must say, this whole discussion is actually making me far more sympathetic to the ideas behind PEP 299 (which proposed __main__ functions as a replacement for __name__ == "__main__" blocks). Brett's rejected PEP 3122 and my own accepted PEP 366 were both a direct result of the interpreter lying about the real value of __name__. I don't have a particular good way forward though, and the one thing I can say about the status quo is that at least everyone is accustomed to having to work around it. And back to the topic of inadvertent shadowing when teaching new users: PEP 3147 should actually help in that regard, as the interpreter will now ignore any implicitly created .pyc files if the corresponding .py file has been removed. Only explicitly created .pyc files that live where the source file would have been can completely substitute for a missing source file now. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jul 13, 2010, at 5:02 PM, Nick Coghlan wrote:
My concerns aren't about a module reimporting itself directly, they're about the case where a utility module is invoked as __main__ but is also imported normally somewhere else in a program (e.g. pdb is invoked as a top-level debugger, but is also imported directly for some reason). Currently that works as a non-circular import and will only cause hassles if there is top-level state in the affected module that absolutely must be a singleton within a given application. Either change (disallowing it completely as you suggest, or making it a circular import, as I suggest) runs the risk of breaking code that currently appears to work correctly.
Fred's point about the practice of changing __name__ in the main module corrupting generated pickles is one I hadn't thought of before though.
It's not just pickle; anything that requires __name__ (or __module__) to be accurate for introspection or debugging is also problematic. I have long considered it a 'best practice' (ugh, I hate that phrase, but I can't think of what else to call it) to _always_ do this type of shadowing, and avoid defining _any_ names in the __name__ == '__main__' case, so that there's no ambiguity: <http://glyf.livejournal.com/60326.html>
I wrote:
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct.
On Mon, Jul 12, 2010 at 5:59 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Except that modules can often be executed as scripts...
Rest assured, I'm well aware of the history, and don't seriously expect the situation to change. Not all of us consider modules and scripts synonymous; I've considered them distinct for quite some time. The problem with a script being importable as a module, masking the intended module, is simply a symptom of this misfeature that has been identified as commonly biting newcomers. Glyph Lefkowitz wrote:
but ... isn't the whole point of 'python -m' to make scripts and modules _not_ be distinct?
That was never how I understood the intention. The point was to make modules that could be used as scripts easier to use as scripts. There have been proposals for main-functions in modules that would be invoked as a default entry point; those make -m more attractive. I'd be more likely to use -m if those were part of the package. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On Jul 12, 2010, at 5:47 PM, Fred Drake wrote:
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems.
Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct.
but ... isn't the whole point of 'python -m' to make scripts and modules _not_ be distinct?
Fred Drake wrote:
Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module.
I wonder whether this kind of problem would be less prevalent if the tutorials etc. encouraged naming top-level scripts with some extension *other* than .py? -- Greg
participants (15)
-
Antoine Pitrou -
Bruce Sherwood -
Fred Drake -
geremy condra -
Glyph Lefkowitz -
Greg Ewing -
Kurt B. Kaiser -
Michael Foord -
Neil Hodgson -
Nick Coghlan -
Oleg Broytman -
Pat Campbell -
Reid Kleckner -
Steve Holden -
Tal Einat