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. -- -- Terry Jan Reedy
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/
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(Continue reading)
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!(Continue reading)
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.(Continue reading)
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(Continue reading)
On Wed, Jun 20, 2012 at 4:51 PM, Alan Gauld <alan.gauld <at> btinternet.com> 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(Continue reading)
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(Continue reading)
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
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.(Continue reading)
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/
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.
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 >>> <some non-trivial expression> 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(Continue reading)
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)(Continue reading)
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/
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
(Continue reading)
RSS Feed