From roger.serwy at gmail.com Tue Jun 12 01:54:13 2012 From: roger.serwy at gmail.com (serwy) Date: Mon, 11 Jun 2012 18:54:13 -0500 Subject: [Idle-dev] Deprecate running IDLE without a subprocess Message-ID: <4FD68525.3040706@illinois.edu> IDLE developers, In the interest of simplifying IDLE's code, I suggest that running IDLE *without* a subprocess be deprecated. Since 2009, IDLE could have multiple instances running while using a subprocess. See http://bugs.python.org/issue1529142 Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI can not be used to stop a program. This can be irritating to Python beginners if an accidental infinite loop arises and the user's only recourse is to restart IDLE, losing any unsaved work in the editor windows. What are your thoughts? - Roger From Bruce_Sherwood at ncsu.edu Tue Jun 12 01:58:20 2012 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Mon, 11 Jun 2012 17:58:20 -0600 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: <4FD68525.3040706@illinois.edu> References: <4FD68525.3040706@illinois.edu> Message-ID: I'm not sure I understand this issue, but I'll comment that this is just one of many reasons why the user's file should always be saved before a run, a feature introduced by David Scherer 12 years ago but which may get periodically lost. Bruce Sherwood On Mon, Jun 11, 2012 at 5:54 PM, serwy wrote: > IDLE developers, > > In the interest of simplifying IDLE's code, I suggest that running IDLE > *without* a subprocess ?be deprecated. Since 2009, IDLE could have multiple > instances running while using a subprocess. See > http://bugs.python.org/issue1529142 > > Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI can > not be used to stop a program. This can be irritating to Python beginners if > an accidental infinite loop arises and the user's only recourse is to > restart IDLE, losing any unsaved work in the editor windows. > > What are your thoughts? > > - Roger > > > > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From roger.serwy at gmail.com Tue Jun 12 02:24:41 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Mon, 11 Jun 2012 19:24:41 -0500 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: References: <4FD68525.3040706@illinois.edu> Message-ID: <4FD68C49.3000802@gmail.com> The auto-saving feature only saves the one editor window, not all of them. It is possible to lose unsaved work in yet-to-be executed code in other editor windows. Presently, PyShell.py and a few other extensions have code paths to handle running with and without the subprocess. Requiring a subprocess would be simplify the code. On 06/11/2012 06:58 PM, Bruce Sherwood wrote: > I'm not sure I understand this issue, but I'll comment that this is > just one of many reasons why the user's file should always be saved > before a run, a feature introduced by David Scherer 12 years ago but > which may get periodically lost. > > Bruce Sherwood > > On Mon, Jun 11, 2012 at 5:54 PM, serwy wrote: >> IDLE developers, >> >> In the interest of simplifying IDLE's code, I suggest that running IDLE >> *without* a subprocess be deprecated. Since 2009, IDLE could have multiple >> instances running while using a subprocess. See >> http://bugs.python.org/issue1529142 >> >> Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI can >> not be used to stop a program. This can be irritating to Python beginners if >> an accidental infinite loop arises and the user's only recourse is to >> restart IDLE, losing any unsaved work in the editor windows. >> >> What are your thoughts? >> >> - Roger >> >> >> >> >> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From cben at users.sf.net Tue Jun 12 13:45:57 2012 From: cben at users.sf.net (Beni Cherniavsky-Paskin) Date: Tue, 12 Jun 2012 14:45:57 +0300 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: References: <4FD68525.3040706@illinois.edu> Message-ID: I'd say unsaved source is rare case; the more precious thing lost is the shell window - commands history and outputs. This is a problem both when you have kill IDLE itself because the executed code is stuck, and when you just want ensure a clean run - without Restart Shell functionality, you have to close and reopen IDLE, again losing shell history (one could remember to always Save As the shell window, but there's no convenient way to load it inside IDLE). On Tue, Jun 12, 2012 at 2:58 AM, Bruce Sherwood wrote: > I'm not sure I understand this issue, but I'll comment that this is > just one of many reasons why the user's file should always be saved > before a run, a feature introduced by David Scherer 12 years ago but > which may get periodically lost. > > Bruce Sherwood > > On Mon, Jun 11, 2012 at 5:54 PM, serwy wrote: > > IDLE developers, > > > > In the interest of simplifying IDLE's code, I suggest that running IDLE > > *without* a subprocess be deprecated. Since 2009, IDLE could have > multiple > > instances running while using a subprocess. See > > http://bugs.python.org/issue1529142 > > > > Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI > can > > not be used to stop a program. This can be irritating to Python > beginners if > > an accidental infinite loop arises and the user's only recourse is to > > restart IDLE, losing any unsaved work in the editor windows. > > > > What are your thoughts? > > > > - Roger > > > > > > > > > > > > _______________________________________________ > > IDLE-dev mailing list > > IDLE-dev at python.org > > http://mail.python.org/mailman/listinfo/idle-dev > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Wed Jun 13 03:41:39 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 12 Jun 2012 21:41:39 -0400 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: <4FD68525.3040706@illinois.edu> References: <4FD68525.3040706@illinois.edu> Message-ID: On 6/11/2012 7:54 PM, serwy wrote: > In the interest of simplifying IDLE's code, I suggest that running IDLE > *without* a subprocess be deprecated. I have had the same thought for the same reason > Since 2009, IDLE could have > multiple instances running while using a subprocess. See > http://bugs.python.org/issue1529142 and the presumption that some (all?) of the reasons for -n are obsolete > Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI > can not be used to stop a program. This can be irritating to Python > beginners if an accidental infinite loop arises and the user's only > recourse is to restart IDLE, losing any unsaved work in the editor windows. and with the thought that running user code and idle interface code in the process is slightly crazy, especially if not necessary. > What are your thoughts? Is there any need left for no-subproccess on the three supported platforms? -- Terry Jan Reedy From alan.gauld at btinternet.com Thu Jun 14 18:47:04 2012 From: alan.gauld at btinternet.com (Alan Gauld) Date: Thu, 14 Jun 2012 17:47:04 +0100 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 17/01/12 01:00, Terry Reedy wrote: > In http://bugs.python.org/issue7676 msg151418 > I conclude that putting a prompt on the first user entry line of each > statement is a mistake that can only be solved by removing it. I see > three alternatives. Discussion here or there welcome. > Having a prompt *only* on the first line is bad. Not having any prompt would be worse. Doing what the standard interpreter does would be best (and consistent for users of both). ie: >>> if True: ... pass ... >>> Where both prompt characters can be user defined for bonus credits... Being able to strip the prompts when copy/pasting (like PyCrust does) would earn a gold star. IMHO, -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ From tjreedy at udel.edu Thu Jun 14 23:38:29 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 14 Jun 2012 17:38:29 -0400 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 6/14/2012 12:47 PM, Alan Gauld wrote: > On 17/01/12 01:00, Terry Reedy wrote: >> In http://bugs.python.org/issue7676 msg151418 >> I conclude that putting a prompt on the first user entry line of each >> statement is a mistake that can only be solved by removing it. I see >> three alternatives. Discussion here or there welcome. >> > > Having a prompt *only* on the first line is bad. > Not having any prompt would be worse. Two of my three alternatives are to put the prompt *elsewhere*, either above or to left (with secondary prompts) of the user entry area, but in any case, cease mixing it with the user entry area in the way it is no > Doing what the standard interpreter does The standard interpreter on Windows puts fixed-pixel width prompts (not so important, but not completely unimportant either) in a separate fixed-width column (critical) to the left that can be omitted when copying (also important). That *is* one of my three proposals. So I take you comment as a vote for that one. > would be best (and consistent for users of both). ie: The question is whether this is possible with tk. The secondary prompt works best with fixed pitch fonts and the ability to copy rectangular blocks. Issue 7676 is about switching from tabs to 4 spaces for indents. Unicode fonts are variable pitch. With variable-pitch font and 4 space indents, ... takes much less space than >>> and consequently the first indent may not look like an indent. Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ', so that the first indent is visually a dedent! This is not acceptible. So visually, the result is not at all like the standard interpreter. So again, the question is whether it is possible to segregate a fixed-width read-only column in a tk text box that properly scrolls with the main part of the box (and which is omitted from selections). Notepad++ does this but perhaps it uses native widgets. (Since it is GPL open source, I could check, but have not.) Notepad++ also grays out the line-number column, so that there is visually a straight, vertical, text margin. > Where both prompt characters can be user defined for bonus credits... > Being able to strip the prompts when copy/pasting (like PyCrust does) > would earn a gold star. Best would be the possibility to simply not select prompts. -- Terry Jan Reedy From alan.gauld at btinternet.com Sat Jun 16 13:11:42 2012 From: alan.gauld at btinternet.com (Alan Gauld) Date: Sat, 16 Jun 2012 12:11:42 +0100 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 14/06/12 22:38, Terry Reedy wrote: >> Doing what the standard interpreter does > > The standard interpreter on Windows puts fixed-pixel width prompts (not > so important, but not completely unimportant either) in a separate > fixed-width column (critical) to the left I'm not sure wyhat you mean. The standard prompt I meant was the vanilla interpreter whivch, onm Windows, runs in a terminal window(aka DOS box) and has the usual >>> and ... prompts. Are you referring to the Pythonwin GUI or something else? > The question is whether this is possible with tk. Sure just add a (read only) text box down the side of the editing pane. But its a bit of a pig keeping the prompt in the right position wrt the editing pane. > >>> and consequently the first indent may not look like an indent. > Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ', > so that the first indent is visually a dedent! This is not acceptible. But better than the current situation with no secondary prompt - at least you can see that there is some kind of indent wrt the prompt. But in Python anyone who uses non mono-spaced fonts for coding is asking for trouble IMHO! -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ From tjreedy at udel.edu Sun Jun 17 03:12:09 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 16 Jun 2012 21:12:09 -0400 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 6/16/2012 7:11 AM, Alan Gauld wrote: > On 14/06/12 22:38, Terry Reedy wrote: > >>> Doing what the standard interpreter does >> >> The standard interpreter on Windows puts fixed-pixel width prompts (not >> so important, but not completely unimportant either) in a separate >> fixed-width column (critical) to the left > > I'm not sure wyhat you mean. The standard prompt I meant was the vanilla > interpreter whivch, onm Windows, runs in a terminal window(aka DOS box) > and has the usual >>> and ... prompts. That is exactly what I mean. The first four *fixed width* characters are off limits to the user. > Are you referring to the Pythonwin GUI or something else? > >> The question is whether this is possible with tk. > > Sure just add a (read only) text box down the side of the editing pane. > But its a bit of a pig keeping the prompt in the right position wrt the > editing pane. >> >>> and consequently the first indent may not look like an indent. >> Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ', >> so that the first indent is visually a dedent! This is not acceptible. > > But better than the current situation with no secondary prompt - at > least you can see that there is some kind of indent wrt the prompt. I consider having the first indented line start to the *left* of the unindented line above to be worse than the current situation. > But in Python anyone who uses non mono-spaced fonts for coding is asking > for trouble IMHO! I do it regularly, with little problem. In Python 3, both text and identifiers are unicode. I do not know that there are any fixed-pitch unicode fonts. It would make ascii chars spaced too far apart. Idle 3.x has to accommodate Python 3.x code, which include unicode identifiers as well as strings. -- Terry Jan Reedy From alan.gauld at btinternet.com Thu Jun 21 01:51:20 2012 From: alan.gauld at btinternet.com (Alan Gauld) Date: Thu, 21 Jun 2012 00:51:20 +0100 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 17/06/12 02:12, Terry Reedy wrote: > That is exactly what I mean. The first four *fixed width* characters are > off limits to the user. OK, I see what you mean now. And that's a by-product of the DOS box only allowing mono-spaced fonts (I think, its been a while since I used Windows DOS boxes!) >>> >>> and consequently the first indent may not look like an indent. >>> Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ', >>> so that the first indent is visually a dedent! This is not acceptible. >> >> But better than the current situation with no secondary prompt - at >> least you can see that there is some kind of indent wrt the prompt. > > I consider having the first indented line start to the *left* of the > unindented line above to be worse than the current situation. But that is the current situation in IDLE? With no secondary prompt the first indented line often starts to the left of the unindented line above. >> But in Python anyone who uses non mono-spaced fonts for coding is asking >> for trouble IMHO! > > I do it regularly, with little problem. In Python 3, both text and > identifiers are unicode. I do not know that there are any fixed-pitch > unicode fonts. It would make ascii chars spaced too far apart. Hmm, you've lost me there. What difference does Unicode make to the display? Surely Unicode only affects how many bits are used to store the characters not how they are displayed? > has to accommodate Python 3.x code, which include unicode identifiers as > well as strings. Sure, Python can work with non mono-spaced fonts - always has - but they can mess up indentation so that off-by-one-space errors are hard to spot. (Not so big an issue if you always use tabs for indents I guess...but that's another debate! :-) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ From guido at python.org Thu Jun 21 02:28:40 2012 From: guido at python.org (Guido van Rossum) Date: Wed, 20 Jun 2012 17:28:40 -0700 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On Wed, Jun 20, 2012 at 4:51 PM, Alan Gauld wrote: > On 17/06/12 02:12, Terry Reedy wrote: > >> That is exactly what I mean. The first four *fixed width* characters are >> off limits to the user. > > > OK, I see what you mean now. And that's a by-product of the DOS box only > allowing mono-spaced fonts (I think, its been a while since I used Windows > DOS boxes!) > > >>>> ?>>> and consequently the first indent may not look like an indent. >>>> Indeed, with Lucida Sans Unicode, '... ? ? ' is *shorter* than '>>> ', >>>> so that the first indent is visually a dedent! This is not acceptible. >>> >>> >>> But better than the current situation with no secondary prompt - at >>> least you can see that there is some kind of indent wrt the prompt. >> >> >> I consider having the first indented line start to the *left* of the >> unindented line above to be worse than the current situation. > > > But that is the current situation in IDLE? With no secondary prompt the > first indented line often starts to the left of the unindented line above. Really? For me, Idle's shell window defaults to one TAB for indentation, and that's intentional. Since a tab is 8 spaces, this indents the first indented line 4 spaces beyond the first indented line. In the interactive prompt, you rarely need more, but if you do, you'll get 8-space indents. >>> But in Python anyone who uses non mono-spaced fonts for coding is asking >>> for trouble IMHO! >> >> >> I do it regularly, with little problem. In Python 3, both text and >> identifiers are unicode. I do not know that there are any fixed-pitch >> unicode fonts. It would make ascii chars spaced too far apart. > > > Hmm, you've lost me there. What difference does Unicode make to the display? > Surely Unicode only affects how many bits are used to store the characters > not how they are displayed? Some unicode characters are so much wider than the latin alphabet that displaying them all at the same width would make no sense. Check out any Chinese website. >> has to accommodate Python 3.x code, which include unicode identifiers as >> well as strings. > > > Sure, Python can work with non mono-spaced fonts - always has - but they can > mess up indentation so that off-by-one-space errors are hard to spot. (Not > so big an issue if you always use tabs for indents I guess...but that's > another debate! :-) Actually detecting off-by-one-space errors isn't the biggie here. It's the indentation of continuation lines inside parentheses (e.g. calls). Most programmers carefully indent the parameters to be aligned with the first character inside the most recent unclosed left-paren (Emacs does this automatically for me). But this habit almost universally only works with monospaced fonts. For example (from zipfile.py: def __init__(self, fileobj, mode, zipinfo, decrypter=None, close_fileobj=False): self._fileobj = fileobj ... The intent is that 'close_fileobj' starts at the same position as 'self'. This is why I still prefer monospace fonts. --Guido > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev -- --Guido van Rossum (python.org/~guido) From roger.serwy at gmail.com Thu Jun 21 03:07:35 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 20 Jun 2012 20:07:35 -0500 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: References: <4FD68525.3040706@illinois.edu> Message-ID: <4FE273D7.7020202@gmail.com> On 06/12/2012 06:45 AM, Beni Cherniavsky-Paskin wrote: > I'd say unsaved source is rare case; the more precious thing lost is > the shell window - commands history and outputs. > This is a problem both when you have kill IDLE itself because the > executed code is stuck, > and when you just want ensure a clean run - without Restart Shell > functionality, you have to close and reopen IDLE, again losing shell > history > (one could remember to always Save As the shell window, but there's no > convenient way to load it inside IDLE). > When you say shell history, do you mean IdleHistory.py's History object or the contents of the shell window? I have written an extension to automatically save and restore the History object for IDLE, as part of IdleX. From roger.serwy at gmail.com Thu Jun 21 03:16:30 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 20 Jun 2012 20:16:30 -0500 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: <4FE275EE.2010109@gmail.com> On 06/20/2012 06:51 PM, Alan Gauld wrote: > On 17/06/12 02:12, Terry Reedy wrote: > >> That is exactly what I mean. The first four *fixed width* characters are >> off limits to the user. > > OK, I see what you mean now. And that's a by-product of the DOS box > only allowing mono-spaced fonts (I think, its been a while since I > used Windows DOS boxes!) > >>>> >>> and consequently the first indent may not look like an indent. >>>> Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ', >>>> so that the first indent is visually a dedent! This is not acceptible. >>> >>> But better than the current situation with no secondary prompt - at >>> least you can see that there is some kind of indent wrt the prompt. >> >> I consider having the first indented line start to the *left* of the >> unindented line above to be worse than the current situation. > > But that is the current situation in IDLE? With no secondary prompt > the first indented line often starts to the left of the unindented > line above. > Tkinter's Text widget allows for separate font configuration based on tags, meaning that the ps1 and ps2 prompts can be tagged with fixed-width fonts, while the rest of the window may contain variable-width fonts. The IPython's Qt Console has Qt's text widget equivalent and extra code to make sure that the ps1 and ps2 prompts don't get modified. Adding the ps2 prompt should be "simple." The ModifiedUndoDelegator in PyShell.py can be modified to prevent changes to prompt tags, as well as handle multi-line pasting of code (filling in the ps2 prompts as needed). The "runit" method in PyShell.py would need to be modified to remove and ps2 text from "line". I could write a patch to allow ps2 prompts if there's any serious interest. - Roger From tjreedy at udel.edu Thu Jun 21 06:29:36 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 21 Jun 2012 00:29:36 -0400 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: Message-ID: On 6/20/2012 7:51 PM, Alan Gauld wrote: > But that is the current situation in IDLE? With no secondary prompt the > first indented line often starts to the left of the unindented line above. No, because the tab indent is somehow bigger than PS1 in any font I have tried. But perhaps you meant that an unindented subheader line starts to the left. >>> if a: print('if') else: print('else') > Hmm, you've lost me there. What difference does Unicode make to the > display? Surely Unicode only affects how many bits are used to store the > characters not how they are displayed? As I meant to say and Guido did, it affects whether monospace is practical. That is why there are no monospace unicode fonts that I know of. There is something else that was at the back of my mind. See https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms There are asian ascii chars that are *defined* as half the width of 'standard' asian chars. > Sure, Python can work with non mono-spaced fonts - always has - but they > can mess up indentation so that off-by-one-space errors are hard to > spot. (Not so big an issue if you always use tabs for indents I > guess...but that's another debate! :-) Idle is designed so you can indent with tab and dedent with (one) delete even while converting tabs to the number of spaces you specify. -- Terry Jan Reedy From tjreedy at udel.edu Thu Jun 21 06:34:46 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 21 Jun 2012 00:34:46 -0400 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: <4FE275EE.2010109@gmail.com> References: <4FE275EE.2010109@gmail.com> Message-ID: On 6/20/2012 9:16 PM, Roger Serwy wrote: > Tkinter's Text widget allows for separate font configuration based on > tags, meaning that the ps1 and ps2 prompts can be tagged with > fixed-width fonts, while the rest of the window may contain > variable-width fonts. > > The IPython's Qt Console has Qt's text widget equivalent and extra code > to make sure that the ps1 and ps2 prompts don't get modified. Adding the > ps2 prompt should be "simple." The ModifiedUndoDelegator in PyShell.py > can be modified to prevent changes to prompt tags, as well as handle > multi-line pasting of code (filling in the ps2 prompts as needed). The > "runit" method in PyShell.py would need to be modified to remove and > ps2 text from "line". It already ignores ps1 text on the first line. > I could write a patch to allow ps2 prompts if there's any serious interest. Definitely. Would it be possible to have ps2s omitted from selections if ps1/2 is omitted on the first line of a selection? -- Terry Jan Reedy From roger.serwy at gmail.com Thu Jun 21 06:57:21 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 20 Jun 2012 23:57:21 -0500 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: <4FE275EE.2010109@gmail.com> Message-ID: <4FE2A9B1.1050807@gmail.com> On 06/20/2012 11:34 PM, Terry Reedy wrote: > On 6/20/2012 9:16 PM, Roger Serwy wrote: > >> Tkinter's Text widget allows for separate font configuration based on >> tags, meaning that the ps1 and ps2 prompts can be tagged with >> fixed-width fonts, while the rest of the window may contain >> variable-width fonts. >> >> The IPython's Qt Console has Qt's text widget equivalent and extra code >> to make sure that the ps1 and ps2 prompts don't get modified. Adding the >> ps2 prompt should be "simple." The ModifiedUndoDelegator in PyShell.py >> can be modified to prevent changes to prompt tags, as well as handle >> multi-line pasting of code (filling in the ps2 prompts as needed). The >> "runit" method in PyShell.py would need to be modified to remove and >> ps2 text from "line". > > It already ignores ps1 text on the first line. Yes, the ModifiedUndoDelegator checks if the cursor is before "iomark". > >> I could write a patch to allow ps2 prompts if there's any serious >> interest. > > Definitely. Would it be possible to have ps2s omitted from selections > if ps1/2 is omitted on the first line of a selection? > The "sel" tags are contiguous in Tk. However, with some trickery with the Tcl/Tk interface, any copy to clipboard may be intercepted and then changed to omit the ps2 tags. However, this likely won't work with X11's selection buffer. From alan.gauld at btinternet.com Thu Jun 21 10:39:33 2012 From: alan.gauld at btinternet.com (Alan Gauld) Date: Thu, 21 Jun 2012 09:39:33 +0100 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: <4FE275EE.2010109@gmail.com> References: <4FE275EE.2010109@gmail.com> Message-ID: On 21/06/12 02:16, Roger Serwy wrote: > I could write a patch to allow ps2 prompts if there's any serious interest. I would love that. This is one of the most common issues I get from users of my web tutorial. At least one email per month from beginners confused by IDLEs indentation. If they are on Windows I just tell them to use Pythonwin but on MacOS/Linux it's not so easy. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ From roger.serwy at gmail.com Thu Jun 21 19:08:52 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Thu, 21 Jun 2012 12:08:52 -0500 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: <4FE275EE.2010109@gmail.com> Message-ID: <4FE35524.6040802@gmail.com> On 06/21/2012 03:39 AM, Alan Gauld wrote: > On 21/06/12 02:16, Roger Serwy wrote: > >> I could write a patch to allow ps2 prompts if there's any serious >> interest. > > I would love that. > > This is one of the most common issues I get from users of my web > tutorial. At least one email per month from beginners confused by > IDLEs indentation. If they are on Windows I just tell them to use > Pythonwin but on MacOS/Linux it's not so easy. > > There is an issue for supporting ps1 and ps2. See http://bugs.python.org/issue13657 I'll start writing a patch later today. Does allowing the cursor to leave the prompt considered a benefit or a detriment for teaching beginners? The last system I remember using that allowed for the cursor to leave the prompt was a line-number BASIC from the 1980's. I haven't used any interactive systems since then that allowed the cursor to leave the prompt. From tjreedy at udel.edu Thu Jun 21 23:10:55 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 21 Jun 2012 17:10:55 -0400 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: <4FE35524.6040802@gmail.com> References: <4FE275EE.2010109@gmail.com> <4FE35524.6040802@gmail.com> Message-ID: On 6/21/2012 1:08 PM, Roger Serwy wrote: > Does allowing the cursor to leave the prompt considered a benefit or a > detriment for teaching beginners? The last system I remember using that > allowed for the cursor to leave the prompt was a line-number BASIC from > the 1980's. I haven't used any interactive systems since then that > allowed the cursor to leave the prompt. Moving the cursor (with keys or mouse) is one way to rerun a previous line. It is also the way to select previous input or output. Windows Command Prompt (CP) gets around freezing the cursor to one line by having a *separate* mouse-only select cursor (box when click, versus underline for entry). That means that one can only correct mistakes *on the same line* with backspace (destructive) or home/left arrow. As near as I can tell, it is impossible to edit a previous line of a multiline statement. Ugh. There is a reason I use Idle as my shell. Also note that click on previous *statement* and hit enter copies the entire statement (rather than just one line of a multiline statement) and does not clear the current entry line. (So to rerun a previous multiline statement, one must redo it line by line.) So if I do >>> and I decide I want to use the expression as part of another statement (say, assignment) I can do >>> a = and click enter the expression and I have the assignment statement I want. In CP, one must copy first, jump back with HOME, and then add 'a ='. In Idle, one can also build a statement from more than one previous statement. >>> expr1 xxx >>> expr2 yyy >>> if and : ... This is impossible in CP due to erase-before-copy. In other words, do not cripple Idle the way Windows Prompt is! -- Terry Jan Reedy From roger.serwy at gmail.com Fri Jun 22 01:22:34 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Thu, 21 Jun 2012 18:22:34 -0500 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: References: <4FE275EE.2010109@gmail.com> <4FE35524.6040802@gmail.com> Message-ID: <4FE3ACBA.5060608@gmail.com> On 06/21/2012 04:10 PM, Terry Reedy wrote: > On 6/21/2012 1:08 PM, Roger Serwy wrote: > >> Does allowing the cursor to leave the prompt considered a benefit or a >> detriment for teaching beginners? The last system I remember using that >> allowed for the cursor to leave the prompt was a line-number BASIC from >> the 1980's. I haven't used any interactive systems since then that >> allowed the cursor to leave the prompt. > > Moving the cursor (with keys or mouse) is one way to rerun a previous > line. It is also the way to select previous input or output. Windows > Command Prompt (CP) gets around freezing the cursor to one line by > having a *separate* mouse-only select cursor (box when click, versus > underline for entry). That means that one can only correct mistakes > *on the same line* with backspace (destructive) or home/left arrow. As > near as I can tell, it is impossible to edit a previous line of a > multiline statement. Ugh. There is a reason I use Idle as my shell. I'm not suggesting an implementation of Window's CP behavior, as I find it too limited as well. On Linux, up/down arrows at the command prompt cycle through the command history. Many other interactive programs behave the same way, like Octave, Matlab, R, Python, etc. For some reason, IDLE has this very different behavior for its prompt. I opened this report a long time ago, which has some discussion along these lines: http://bugs.python.org/issue2704 IdleX has the Terminal.py extension included which makes IDLE behave how I think it should behave. > Also note that click on previous *statement* and hit enter copies the > entire statement (rather than just one line of a multiline statement) > and does not clear the current entry line. (So to rerun a previous > multiline statement, one must redo it line by line.) Alt+P and Alt-N are not discoverable in IDLE, except as a keybinding in the configuration dialog. The "shell" menu should have these commands. Cycling through the history recovers multi-line commands. > > So if I do > >>> > and I decide I want to use the expression as part of another statement > (say, assignment) I can do > >>> a = > and click enter the expression and I have the assignment statement I > want. In CP, one must copy first, jump back with HOME, and then add 'a > ='. In Idle, one can also build a statement from more than one > previous statement. > > >>> expr1 > xxx > >>> expr2 > yyy > >>> if and : ... > This is impossible in CP due to erase-before-copy. > > In other words, do not cripple Idle the way Windows Prompt is! > From alan.gauld at btinternet.com Fri Jun 22 01:50:37 2012 From: alan.gauld at btinternet.com (Alan Gauld) Date: Fri, 22 Jun 2012 00:50:37 +0100 Subject: [Idle-dev] The '>>> ' prompt is bad In-Reply-To: <4FE3ACBA.5060608@gmail.com> References: <4FE275EE.2010109@gmail.com> <4FE35524.6040802@gmail.com> <4FE3ACBA.5060608@gmail.com> Message-ID: On 22/06/12 00:22, Roger Serwy wrote: > I'm not suggesting an implementation of Window's CP behavior, as I find > it too limited as well. On Linux, up/down arrows at the command prompt > cycle through the command history. FWIW the windows prompt does the same thing once you switch off the "DOS compatibility" mode. There's not that much difference between a bash prompt and a Windows prompt in functionality, just bash has more commands available... But that's completely beside the point of how IDLE's prompt should behave. :-) My personal preference is the way PyShell works in the wxPython bundle. If it weren't such a CPU hog I'd probably use PyShell as my standard Python shell window. But I'd like to see IDLE work that way because unlike wxPython its part of the standard download. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ From cben at users.sf.net Sun Jun 24 10:09:24 2012 From: cben at users.sf.net (Beni Cherniavsky-Paskin) Date: Sun, 24 Jun 2012 11:09:24 +0300 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: <4FE273D7.7020202@gmail.com> References: <4FD68525.3040706@illinois.edu> <4FE273D7.7020202@gmail.com> Message-ID: On Thu, Jun 21, 2012 at 4:07 AM, Roger Serwy wrote: > On 06/12/2012 06:45 AM, Beni Cherniavsky-Paskin wrote: > >> I'd say unsaved source is rare case; the more precious thing lost is the >> shell window - commands history and outputs. >> This is a problem both when you have kill IDLE itself because the >> executed code is stuck, >> and when you just want ensure a clean run - without Restart Shell >> functionality, you have to close and reopen IDLE, again losing shell history >> (one could remember to always Save As the shell window, but there's no >> convenient way to load it inside IDLE). >> >> When you say shell history, do you mean IdleHistory.py's History object > or the contents of the shell window? Both. > > I have written an extension to automatically save and restore the History > object for IDLE, as part of IdleX. > > Nice. Even with it, the experience in single-process mode would be annoying. Anyway, the question is not so much whether one can be happy with the single-process mode, but whether anybody is unable to use subprocess mode. -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Sun Jun 24 12:32:11 2012 From: taleinat at gmail.com (Tal Einat) Date: Sun, 24 Jun 2012 13:32:11 +0300 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: <4FD68525.3040706@illinois.edu> References: <4FD68525.3040706@illinois.edu> Message-ID: On Tue, Jun 12, 2012 at 2:54 AM, serwy wrote: > IDLE developers, > > In the interest of simplifying IDLE's code, I suggest that running IDLE > *without* a subprocess be deprecated. Since 2009, IDLE could have multiple > instances running while using a subprocess. See http://bugs.python.org/** > issue1529142 > > Running without a subprocess has a flaw in that Ctrl+C from the IDLE GUI > can not be used to stop a program. This can be irritating to Python > beginners if an accidental infinite loop arises and the user's only > recourse is to restart IDLE, losing any unsaved work in the editor windows. > > What are your thoughts? > IIRC, the major reason for keeping around no-subprocess mode was because IDLE always used the same port for communicating with its subprocess. Therefore, running more than one instance of IDLE at the same time would never work, and even closing IDLE and running it again quickly would sometimes fail. This is no longer an issue since IDLE now uses a random port given by the OS (by opening the socket on TCP port zero - it took me years to discover that trick!). Other reasons for keeping no-subprocess mode around: * debugging IDLE is significantly easier when everything is in a single process * some firewall software would occasionally block the connection to the subprocess, or perhaps just raise a warning (but I guess this is no longer a real issue; the old firewall warning message has been removed) In my opinion, if the IDLE developers are confident in their ability to debug IDLE running with a sub-process, then there is no significant reason not to remove the no-subprocess mode. From what I remember about the code, this would allow simplifying things significantly in many places. - Tal Einat -------------- next part -------------- An HTML attachment was scrubbed... URL: