Re: [Idle-dev] Big change to IDLE Shell

[Alan Gauld via IDLE-dev]

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


___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Tal Einat]

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@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@python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Mark Roseman]

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











___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Tal Einat]

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
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Mark Roseman]

> 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

___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Alan Gauld via IDLE-dev]

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


___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[André Roberge]

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@python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Terry Reedy]

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

___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Alan Gauld via IDLE-dev]

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


___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Terry Reedy]

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
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Alan Gauld via IDLE-dev]

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@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Terry Reedy]

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


___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Terry Reedy]

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@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

___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[Tal Einat]

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
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Re: [Idle-dev] Big change to IDLE Shell

[André Roberge]

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@python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev