From andre.roberge at gmail.com Thu May 6 12:29:31 2021 From: andre.roberge at gmail.com (=?UTF-8?Q?Andr=C3=A9_Roberge?=) Date: Thu, 6 May 2021 13:29:31 -0300 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On Wed, Apr 28, 2021 at 3:52 AM Terry Reedy wrote: > 3.10.0b1 is due to be released next Monday. The big change for IDLE is > in the Shell. The first line of entered statement will line up with > continuation lines and indents will be spaces instead of tabs. The > '>>>' prompt will be either above on a line by itself or to the left in > a Shell sidebar. This is just a quick report after a brief test. I just **love** the way the prompt is now shown. I am convinced that beginners will be much less confused with understanding indentation when using IDLE. I also did a quick test with friendly (formally known as friendly-traceback) and can happily report that support for custom excepthook appears to have been unaffected by the latest changes. I will do more testing in the near future (and likely do a brief demo during a presentation at the upcoming PyCon Education Summit). I do not plan to report further on this list unless I find problems. Thank you all for the work done to constantly improve IDLE. Andr? Roberge > ___________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Thu May 6 14:32:46 2021 From: taleinat at gmail.com (Tal Einat) Date: Thu, 6 May 2021 21:32:46 +0300 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On Thu, May 6, 2021 at 7:30 PM Andr? Roberge wrote: > > On Wed, Apr 28, 2021 at 3:52 AM Terry Reedy wrote: > >> 3.10.0b1 is due to be released next Monday. The big change for IDLE is >> in the Shell. The first line of entered statement will line up with >> continuation lines and indents will be spaces instead of tabs. The >> '>>>' prompt will be either above on a line by itself or to the left in >> a Shell sidebar. > > > This is just a quick report after a brief test. I just **love** the way > the prompt is now shown. I am convinced that beginners will be much less > confused with understanding indentation when using IDLE. > > I also did a quick test with friendly (formally known as > friendly-traceback) and can happily report that support for custom > excepthook appears to have been unaffected by the latest changes. > > I will do more testing in the near future (and likely do a brief demo > during a presentation at the upcoming PyCon Education Summit). I do not > plan to report further on this list unless I find problems. > > Thank you all for the work done to constantly improve IDLE. > > Andr? Roberge > Many thanks for testing this, for the feedback and for the kind words, Andr?! It means very much coming from you. - Tal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Thu May 6 19:21:53 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 6 May 2021 19:21:53 -0400 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: <5590ae38-291a-0189-3731-e35654219d1b@udel.edu> On 4/28/2021 2:52 AM, Terry Reedy wrote: > 3.10.0b1 is due to be released next Monday.? The big change for IDLE is > in the Shell.? The first line of entered statement will line up with > continuation lines and indents will be spaces instead of tabs.? The > '>>>' prompt will be either above on a line by itself or to the left in > a Shell sidebar The 'above' option is not in .0b1. We hope to have it in .0b2 in a few weeks. We included an option to zip together prompts from the sidebar with lines from the shell. Here is an example that includes the errect of another patch about to be merged. >>> try: abx ... except NameError: ... print(int.reel('fff', 32)) ... ... Traceback (most recent call last): File "", line 1, in try: abx NameError: name 'abx' is not defined. Did you mean: 'abs'? During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 3, in print(int.reel('fff', 32)) AttributeError: type object 'int' has no attribute 'reel'. Did you mean: 'real'? >>> > This release will be missing somethings and may We intially added an option to copy to clipboard only code input, without prompts, so that the result could be pasted in a file. We ran into a glitch and hope to fix before the next beta. > otherwise have bugs.? We want to get user testing and feedback > (idle-dev at python.org) before the 3.10.0 release and before backporting > to 3.9 (maybe in late June). Still the plan. > Terry Jan Reedy -- Terry Jan Reedy From tjreedy at udel.edu Thu May 6 19:29:24 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 6 May 2021 19:29:24 -0400 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 5/6/2021 12:29 PM, Andr? Roberge wrote: > This is just a quick report after a brief test. I just **love** the way > the prompt is now shown. I am convinced that beginners will be much less > confused with understanding indentation when using IDLE. > > I also did a quick test with friendly (formally known as > friendly-traceback) and can happily report that support for custom > excepthook appears to have been unaffected by the latest changes. Please see my other followup post. When code is run in the system console/terminal, name and attribute error messages may be augmented with a suggestion at to what one meant. These hints are not directly accessible from python code. But we figured out how to get them indirectly (https://bugs.python.org/issue44026). My other post has an example using the current version of the patch. > I will do more testing in the near future (and likely do a brief demo > during a presentation at the upcoming PyCon Education Summit). I do not > plan to report further on this list unless I find problems. When we backport to 3.9, I would like to inform educators that they might want to upgrade to 3.9.5 or 3.10 when released. I will be happy for you to start the process. I will ask you later for advice. > Thank you all for the work done to constantly improve IDLE. Thank you for the feedback. -- Terry Jan Reedy From alan.gauld at yahoo.co.uk Thu May 13 16:22:10 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Thu, 13 May 2021 21:22:10 +0100 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 28/04/2021 07:52, Terry Reedy wrote: > 3.10.0b1 is due to be released next Monday. The big change for IDLE is > in the Shell. The first line of entered statement will line up with > continuation lines and indents will be spaces instead of tabs. Great news, that will eliminate a whole category of problems we see on the tutor list with IDLE. PS. Sorry I'm late to the party, I only check this list once a month or so... > to 3.9 (maybe in late June). The last maintenance release of 3.8 is > also next Monday, so it will never get this patch. Pity, I'm still on 3.8... This might be sufficient reason to upgrade to 3.9... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From tjreedy at udel.edu Thu May 13 17:32:29 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 13 May 2021 17:32:29 -0400 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 5/13/2021 4:22 PM, Alan Gauld via IDLE-dev wrote: > On 28/04/2021 07:52, Terry Reedy wrote: >> 3.10.0b1 is due to be released next Monday. The big change for IDLE is >> in the Shell. The first line of entered statement will line up with >> continuation lines and indents will be spaces instead of tabs. > > Great news, that will eliminate a whole category of problems > we see on the tutor list with IDLE. Could you summarize your experience here with a post on "Beginner problems with IDLE"? I follow the python-idle tag on SO (and answer questions there) and a few fixes have come from that experience. A couple had never been mentioned on the bugs.python.org tracker. One issue resulted in 4 independent questions. *That* made it a priority. What else is still an issue? Things that bug me are a priority, but things that bug multiple beginners follow closely. Given that there has be and maybe will be more opposition to this change, another authoritative statement on the bpo issue(s) that this will help beginners would have been and might in the future be a help. Do you ever refer people to the IDLE doc, accessible as Help => IDLE Help? (I will soon change the menu item to IDLE Doc, as it now is a copy of the doc chapter.) > PS. Sorry I'm late to the party, I only check this list > once a month or so... > >> to 3.9 (maybe in late June). The last maintenance release of 3.8 is >> also next Monday, so it will never get this patch. > > Pity, I'm still on 3.8... This might be sufficient reason > to upgrade to 3.9... I will announce here when this is backported to 3.9. -- Terry Jan Reedy From alan.gauld at yahoo.co.uk Thu May 13 19:27:14 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Fri, 14 May 2021 00:27:14 +0100 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 13/05/2021 22:32, Terry Reedy wrote: >> Great news, that will eliminate a whole category of problems >> we see on the tutor list with IDLE. > > Could you summarize your experience here with a post on > "Beginner problems with IDLE"? Without trawling through the archives I can't be scientific, however, here are my anecdotal memories...and in no particular order: 1) The indentation issues being addressed in the current change 2) The inability to paste code from web sites into IDLE (you have to do it one line at a time and wait for the interspersed results. This is, of course, due to the interpreter in the shell, not really an IDLE issue but complete beginners don't understand that. 3) The inability to save an interactive session then reload/replay it. This is more interesting. The old VAX debugger used to be able to do that by simply prefixing everything with a comment marker when saving and then interpreting lines beginning with comment+prompt (#DBG>) on reload. Something similar could probably be done in IDLE although multi-line commands make it more tricky.. 4) The ability to copy/paste code (without the prompts) into a file (either a project or a web post/email request) while retaining formatting. There are other Python IDEs that already offer this (PyCharm is one such, I believe) 5) Tabbed edit windows (already in IdleX). 6) How to pass command line arguments when running a program. (Yes, it's possible, but not intuitive to a beginner, but much better than before) As for suggestions/solutions from the tutor list members they tend to be: 1) Danny Yoo's excellent but ancient tutorial (from Python 2 days?) https://www.hashcollision.org/hkn/python/idle_intro/ 2) The IDLE page on python.org https://docs.python.org/3/library/idle.html 3) The IDLE help page 4) Any of several videos on YouTube. 5) This list... 6) Stop using IDLE, use instead. PyCharm or MS Code being the current favourites. 7) Switch to IdleX instead... (My personal solution of choice for most things ;-) In about that order of popularity. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From tjreedy at udel.edu Tue May 18 01:22:30 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 18 May 2021 01:22:30 -0400 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 5/13/2021 7:27 PM, Alan Gauld via IDLE-dev wrote: > On 13/05/2021 22:32, Terry Reedy wrote: > >>> Great news, that will eliminate a whole category of problems >>> we see on the tutor list with IDLE. >> >> Could you summarize your experience here with a post on >> "Beginner problems with IDLE"? > Without trawling through the archives I can't be scientific, > however, here are my anecdotal memories...and in no > particular order: This is *very* helpful. Guido has said (parapharsing) "Keep IDLE for beginners; don't imitate professional IDEs". But how do I tell the difference. All your items except shell indents and tabbed windows are about more easily saving and running code, including code from elsewhere. This is a nice goal list for the next year. > 1) The indentation issues being addressed in the current change > 2) The inability to paste code from web sites into IDLE (you > have to do it one line at a time and wait for the > interspersed results. This is, of course, due to the > interpreter in the shell, not really an IDLE issue but > complete beginners don't understand that. In IDLE Shell, one can paste a *statement* rather than just a line. History recall also recalls statements rather than lines. One can instead paste multiple statements into the editor and run. There is an issue, I believe, to be able to run without 'saveas'. The pseudofile name used in tracebacks could be rather than (for shell entry). I have though about the possibility of allowing multi-statement pasting into Shell by using ast.parse to separate into top level statements. A different between IDLE and console REPL is that IDLE allows one to check and edit pastes before running. I don't want to lose that. But the important point you have revealed is that beginners do a lot of copy-pasting-running of code from elsewhere and would like it to be even easier. > 3) The inability to save an interactive session then We intended to have 'save code' in the recently .0b1 release. But it also saved responses to `input(prompt)` in user code. So we first have to fix such input getting the same tag. A variation could be 'save code & output', where output would be in comments. But what to do with input() response? > reload/replay it. This is more interesting. We could add 'Simulate interaction' to the 'Run custom' box. Print a statement, wait for output, print a statement, ... See below. > The old VAX > debugger used to be able to do that by simply prefixing > everything with a comment marker when saving and then > interpreting lines beginning with comment+prompt (#DBG>) I have a separate idea about using the debugger to 'animate' a program -- step through at a user controllable speed. > on reload. Something similar could probably be done in > IDLE although multi-line commands make it more tricky.. ast.parse should solve this. > 4) The ability to copy/paste code (without the prompts) > into a file (either a project or a web post/email request) > while retaining formatting. What does 'retaining formatting' mean? > 5) Tabbed edit windows (already in IdleX). Tabbed windows, with not just editors on tabs, was one of my initial goals 11 years ago, along with using ttk widgets (done). Other things, including a bit of opposition, keep intervening. I will increment its priority. After Roger Sewey, IdleX author, got the commit bit, at my suggestion, he fixed about 10 issues in a few months, and then disappeared and quit contributing. To do tabbed windows, he must have made some preliminary changes that could have already been merged. (Separate the editor window into a menu window and a frame.) But no one else has yet dived into his tabbed window code to see if it is usable. Mark Roseman also said he did the same but I have not seen his code either. Part of the holdup is that the current class inheritance tree is wrong and needs to be refactored, without breaking things. > 6) How to pass command line arguments when running a program. > (Yes, it's possible, but not intuitive to a beginner, > but much better than before) There is nothing 'intuitive' about running an editor window as if the corresponding file had been run from a command line. What we did is give people a partial command line for the part that comes after 'python -i '. Should we say that on the form? -- Terry Jan Reedy From andre.roberge at gmail.com Tue May 18 04:29:28 2021 From: andre.roberge at gmail.com (=?UTF-8?Q?Andr=C3=A9_Roberge?=) Date: Tue, 18 May 2021 05:29:28 -0300 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On Tue, May 18, 2021 at 2:22 AM Terry Reedy wrote: > On 5/13/2021 7:27 PM, Alan Gauld via IDLE-dev wrote: > > On 13/05/2021 22:32, Terry Reedy wrote: > > > ... > > > 6) How to pass command line arguments when running a program. > > (Yes, it's possible, but not intuitive to a beginner, > > but much better than before) > > There is nothing 'intuitive' about running an editor window as if the > corresponding file had been run from a command line. What we did is > give people a partial command line for the part that comes after 'python > -i '. Should we say that on the form? > > (jumping in this excellent thread...) While you're at it, is there any possibility to add something *before* the filename? I would very much like to be able to do something like python -i -m friendly Andr? Roberge > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.gauld at yahoo.co.uk Tue May 18 14:23:20 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Tue, 18 May 2021 19:23:20 +0100 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 18/05/2021 06:22, Terry Reedy wrote: >> 2) The inability to paste code from web sites into IDLE (you >> have to do it one line at a time and wait for the >> interspersed results. This is, of course, due to the >> interpreter in the shell, not really an IDLE issue but >> complete beginners don't understand that. > > In IDLE Shell, one can paste a *statement* rather than just a line. > History recall also recalls statements rather than lines. I think the problem stems from folks following web tutorials. They see a function definition and grab it and paste it. But if the code includes blank lines the interpreter gets confused and spits out errors. >> The old VAX >> debugger used to be able to do that by simply prefixing >> everything with a comment marker when saving and then >> interpreting lines beginning with comment+prompt (#DBG>) > > I have a separate idea about using the debugger to 'animate' a program > -- step through at a user controllable speed. To be fair beginners tend not to mess with the debugger so don't have any requirements. My reference to the VAX was purely its ability to save a session and replay it. (We used to create a lot of white-box test scripts that way!) >> 4) The ability to copy/paste code (without the prompts) >> into a file (either a project or a web post/email request) >> while retaining formatting. > > What does 'retaining formatting' mean? Mostly the indentation I guess. In other words I write a bit of code comprising multiple statements in the interactive shell. I then want to copy all of that into a file I'm creating, but don't want the prompts (or output) in my file, but I do want the indentation to be consistent after the prompts are removed. (Hmm, that's getting very close to an agile user story!) >> 5) Tabbed edit windows (already in IdleX). > > Tabbed windows, with not just editors on tabs, was one of my initial > goals 11 years ago, along with using ttk widgets (done). Other things, > including a bit of opposition, keep intervening. I will increment its > priority. > > After Roger Sewey, IdleX author, got the commit bit, at my suggestion, > he fixed about 10 issues in a few months, and then disappeared and quit > contributing. Shame. I wondered why I hadn't seen any new IdleX releases recently. >> 6) How to pass command line arguments when running a program. >> (Yes, it's possible, but not intuitive to a beginner, >> but much better than before) > > There is nothing 'intuitive' about running an editor window as if the > corresponding file had been run from a command line. What we did is > give people a partial command line for the part that comes after 'python > -i '. Should we say that on the form? Yes, and i have no problem with the current implementation (athough being able to add python interpreter arguments too would be nice. But beginners probably wouldn't care. One issue is the current menu option is not obvious: "Run...Customized" does not scream "add arguments" it sounds like some way to modify the interpreter or somesuch. In fact, this might be where to add the interpreter options. "Run with arguments" might be a more obvious spelling. Anyways, I'm happy to see any and all progress on IDLE and I hope my musings are of some use. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From mark at markroseman.com Tue May 18 20:22:10 2021 From: mark at markroseman.com (Mark Roseman) Date: Tue, 18 May 2021 17:22:10 -0700 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: > On May 17, 2021, at 10:22 PM, Terry Reedy wrote: > 5) Tabbed edit windows (already in IdleX). > > Tabbed windows, with not just editors on tabs, was one of my initial goals 11 years ago, along with using ttk widgets (done). Other things, including a bit of opposition, keep intervening. I will increment its priority. > > After Roger Sewey, IdleX author, got the commit bit, at my suggestion, he fixed about 10 issues in a few months, and then disappeared and quit contributing. To do tabbed windows, he must have made some preliminary changes that could have already been merged. (Separate the editor window into a menu window and a frame.) But no one else has yet dived into his tabbed window code to see if it is usable. Mark Roseman also said he did the same but I have not seen his code either. > > Part of the holdup is that the current class inheritance tree is wrong and needs to be refactored, without breaking things. Is there interest in building something akin to https://tkdocs.com/images/idle_onewindow.png into IDLE in the foreseeable future? I?ve considered updating the code I did a while back (https://github.com/roseman/idle ) but getting it from where it was to a series of patches that would actually find it?s way into IDLE I thought would be challenging due to multiple steps needed. As you say, restructuring things so that editors, shells, debuggers etc. are assumed to fit in frames and not be their own toplevel was a starting point (e.g., I introduced a generic ?Component? class). And to be honest, how to determine what is considered an ?acceptable" UI change for IDLE remains wholly opaque to me. There are still many things in there that leave me scratching my head. Some things would be simplified now (e.g., at that point ttk wasn?t assumed) but I?m still not confident about reworking that, with proper testing, etc. to the point that it would be accepted into the main codebase. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Thu May 20 17:19:29 2021 From: taleinat at gmail.com (Tal Einat) Date: Fri, 21 May 2021 00:19:29 +0300 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On Wed, May 19, 2021 at 4:01 AM Mark Roseman wrote: > > > > On May 17, 2021, at 10:22 PM, Terry Reedy wrote: >> 5) Tabbed edit windows (already in IdleX). >> >> Tabbed windows, with not just editors on tabs, was one of my initial goals 11 years ago, along with using ttk widgets (done). Other things, including a bit of opposition, keep intervening. I will increment its priority. >> >> After Roger Sewey, IdleX author, got the commit bit, at my suggestion, he fixed about 10 issues in a few months, and then disappeared and quit contributing. To do tabbed windows, he must have made some preliminary changes that could have already been merged. (Separate the editor window into a menu window and a frame.) But no one else has yet dived into his tabbed window code to see if it is usable. Mark Roseman also said he did the same but I have not seen his code either. >> >> Part of the holdup is that the current class inheritance tree is wrong and needs to be refactored, without breaking things. >> > > Is there interest in building something akin to https://tkdocs.com/images/idle_onewindow.png into IDLE in the foreseeable future? > > I?ve considered updating the code I did a while back (https://github.com/roseman/idle) but getting it from where it was to a series of patches that would actually find it?s way into IDLE I thought would be challenging due to multiple steps needed. > > As you say, restructuring things so that editors, shells, debuggers etc. are assumed to fit in frames and not be their own toplevel was a starting point (e.g., I introduced a generic ?Component? class). > > And to be honest, how to determine what is considered an ?acceptable" UI change for IDLE remains wholly opaque to me. There are still many things in there that leave me scratching my head. > > Some things would be simplified now (e.g., at that point ttk wasn?t assumed) but I?m still not confident about reworking that, with proper testing, etc. to the point that it would be accepted into the main codebase. Hi Mark, good to have you join this conversation! I've been through much of what you describe, including having my own fork of IDLE and trying to bring some of its improvements into CPython's IDLE... Like Roger Serwy, I was also given commit permissions to CPython to do this work, but could only manage to do rather little before running out of time and energy. Partly this is because getting something into CPython's IDLE is much harder, more so than I expected. Still, I've been able to continue contributing over the years. In recent years Terry J. Reedy has taken the lead on IDLE. Terry has been doing a fantastic job of moving IDLE forward while also fixing many bugs and making it more robust. He's also been very responsible in deciding which changes to make. Thanks to his stewardship, I think now is the best time in the past 15 years or so to attempt to bring such improvements into IDLE proper. I encourage you to try! Start with something significant, but not huge. Perhaps discuss this with us in advance, so that we can decide together what we'd like done and on the general approach, to avoid working a lot on something that is eventually rejected (I've gone through that too many times!). - Tal From mark at markroseman.com Mon May 24 11:09:40 2021 From: mark at markroseman.com (Mark Roseman) Date: Mon, 24 May 2021 08:09:40 -0700 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: <292DEA37-383F-4961-98E0-581CE50744FD@markroseman.com> On May -20- 2021, at 2:19 PM, Tal Einat wrote: > In recent years Terry J. Reedy has taken the lead on IDLE. Terry has > been doing a fantastic job of moving IDLE forward while also fixing > many bugs and making it more robust. He's also been very responsible > in deciding which changes to make. Thanks to his stewardship, I think > now is the best time in the past 15 years or so to attempt to bring > such improvements into IDLE proper. > > I encourage you to try! Start with something significant, but not > huge. Perhaps discuss this with us in advance, so that we can decide > together what we'd like done and on the general approach, to avoid > working a lot on something that is eventually rejected (I've gone > through that too many times!). Thanks for your advice Tal. Here are a couple of longstanding things (dating from 2015) that I?d love to see move forward: 1. Improve appearance, get rid of modal behaviour in about dialog https://bugs.python.org/issue24813 2. Improve debugger UI https://bugs.python.org/issue17942 Both of these have mockups done, patches (now very outdated), and what appears to be some early agreement that the basic ideas at least would be worth pursuing. Both are currently stalled. Terry (and others), are these things you?d still like to see move forward? What steps would be necessary for these to be completed and integrated? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Wed May 26 06:45:32 2021 From: taleinat at gmail.com (Tal Einat) Date: Wed, 26 May 2021 13:45:32 +0300 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: Alan and Andr?, since you've both given positive feedback about this change, I'm interested in your perspectives about two problems which Raymond Hettinger brought up on the bpo issue [1]: 1. Reduced clarity of separation between input and output lines. 2. Increased indentation of outputs reduces horizontal screen real-estate, which is an issue for examples in presentations and books. Others are welcome to offer their perspectives too, of course :) - Tal [1] https://bugs.python.org/issue37903#msg393237 On Thu, May 13, 2021 at 11:22 PM Alan Gauld via IDLE-dev < idle-dev at python.org> wrote: > On 28/04/2021 07:52, Terry Reedy wrote: > > 3.10.0b1 is due to be released next Monday. The big change for IDLE is > > in the Shell. The first line of entered statement will line up with > > continuation lines and indents will be spaces instead of tabs. > > Great news, that will eliminate a whole category of problems > we see on the tutor list with IDLE. > > PS. Sorry I'm late to the party, I only check this list > once a month or so... > > > to 3.9 (maybe in late June). The last maintenance release of 3.8 is > > also next Monday, so it will never get this patch. > > Pity, I'm still on 3.8... This might be sufficient reason > to upgrade to 3.9... > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > http://www.amazon.com/author/alan_gauld > Follow my photo-blog on Flickr at: > http://www.flickr.com/photos/alangauldphotos > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.gauld at yahoo.co.uk Sat May 29 03:38:10 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Sat, 29 May 2021 08:38:10 +0100 Subject: [Idle-dev] Big change to IDLE Shell In-Reply-To: References: <47f9e7f8-28b7-b091-d7cf-ee31d5dceb3c@udel.edu> Message-ID: On 26/05/2021 11:45, Tal Einat wrote: > Alan and Andr?, since you've both given positive feedback about this > change, I'm interested in your perspectives about two problems which > Raymond Hettinger brought up on the bpo issue [1]: > > 1. Reduced clarity of separation between input and output lines. Since I haven't seen the new presentation yet, I'm still on 3.8, I can't really comment. Cound output lines not easily be made more (or less) prominent by a simple change of font/colour? It sounds like it should be easy to fix if a problem. > 2. Increased indentation of outputs reduces horizontal screen > real-estate, which is an issue for examples in presentations and books. I can sympathise with this since my recent book on curses had to be formatted to fit the narrow pages on a kindle and at times I was reduced to 2-space indents etc. But I don't think Idle should be constrained too much by that. It's certainly not something that beginners are going to care about. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos