From tjreedy at udel.edu  Sat Aug  1 00:11:29 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 31 Jul 2015 18:11:29 -0400
Subject: [Idle-dev] put idle on github?
In-Reply-To: <CAP7+vJ+ouz+Tm_d=7hgTakHD2OPM0w5sqx+YYE9vxuDSSJAWow@mail.gmail.com>
References: <CAOFf2a2ZrTTDqz_PJWbydf+iJpYb=Qu=r6-K5opa_SEEQxeHbQ@mail.gmail.com>
 <CAP7+vJ+ouz+Tm_d=7hgTakHD2OPM0w5sqx+YYE9vxuDSSJAWow@mail.gmail.com>
Message-ID: <55BBF291.9060900@udel.edu>

On 7/25/2015 3:09 PM, Guido van Rossum wrote:

> I think eventually it should be removed from the stdlib -- but this is
> controversial, as educators often are forced to rely on the IDLE that is
> bundled with the Python installer.

David Ames: "Most of the schools I have been in restrict access to the 
command line for "security" reasons, they also often prevent the running 
of .bat files, and other similar scripts for the same reason."

https://bitbucket.org/lordmauve/pgzero/issues/23/add-a-way-of-invoking-pgzrun-on-the

 > But that's a longer discussion.

One objection to Idle is appearance.  Mark Roseman, a tk/ttk expert, has 
volunteered to fix that as much as possible, if we are not prevented 
from doing so.  See the "IDLE and ttk" thread.

-- 
Terry Jan Reedy


From mark at markroseman.com  Sat Aug  1 18:30:06 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sat, 1 Aug 2015 09:30:06 -0700
Subject: [Idle-dev] ttk appearance
Message-ID: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>

If anyone is curious, here is a ?before and after? as to what IDLE?s config dialog looks like on Mac, Windows and Linux when using the ttk widgets:

	http://www.tkdocs.com/images/idle_cfgfont_ttk.png <http://www.tkdocs.com/images/idle_cfgfont_ttk.png>

This is intentionally without any real layout/structure changes, and with only minor tweaking to spacing etc.

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150801/646c8a9e/attachment.html>

From tjreedy at udel.edu  Sat Aug  1 20:54:38 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 1 Aug 2015 14:54:38 -0400
Subject: [Idle-dev] ttk appearance
In-Reply-To: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
Message-ID: <mpj4ll$4vs$1@ger.gmane.org>

On 8/1/2015 12:30 PM, Mark Roseman wrote:
> If anyone is curious, here is a ?before and after? as to what IDLE?s
> config dialog looks like on Mac, Windows and Linux when using the ttk
> widgets:
>
> http://www.tkdocs.com/images/idle_cfgfont_ttk.png
>
> This is intentionally without any real layout/structure changes, and
> with only minor tweaking to spacing etc.

In the Windows part of the screenshot on
http://www.tkdocs.com/tutorial/complex.html#notebook
the active page 'Two' is clearly distinguished from the inactive and 
disabled tabs with a lighter color (just as with Linux). In the Windows 
part of the new screenshot, I do not see this at all, although the Linux 
version does have the improvement.  There is also a difference in tab 
corners in the two Windows versions.  Are you using a different Windows 
theme than before?

-- 
Terry Jan Reedy



From mark at markroseman.com  Sat Aug  1 21:52:16 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sat, 1 Aug 2015 12:52:16 -0700
Subject: [Idle-dev] ttk appearance
In-Reply-To: <mpj4ll$4vs$1@ger.gmane.org>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
 <mpj4ll$4vs$1@ger.gmane.org>
Message-ID: <F8FD2978-F5FF-464E-810B-15BFD31B4905@markroseman.com>

On Aug 1, 2015, at 11:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> In the Windows part of the screenshot on
> http://www.tkdocs.com/tutorial/complex.html#notebook
> the active page 'Two' is clearly distinguished from the inactive and disabled tabs with a lighter color (just as with Linux). In the Windows part of the new screenshot, I do not see this at all, although the Linux version does have the improvement.  There is also a difference in tab corners in the two Windows versions.  Are you using a different Windows theme than before?


Yes, the IDLE screenshot on Windows was set to use the ?winnative? theme (vs. I think the ?vista? theme which it goes to by default). Some of the other components seemed a bit nicer looking that way, but can revisit that later of course.


From mark at markroseman.com  Sat Aug  1 22:34:57 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sat, 1 Aug 2015 13:34:57 -0700
Subject: [Idle-dev] ttk appearance
In-Reply-To: <C1A66B95-5B33-47E3-92C1-96D90748E20E@twistedmatrix.com>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
 <C1A66B95-5B33-47E3-92C1-96D90748E20E@twistedmatrix.com>
Message-ID: <C7B7E2C1-87D4-4CCB-B530-E98A199D1C7C@markroseman.com>

On Aug 1, 2015, at 1:21 PM, Glyph <glyph at twistedmatrix.com> wrote:
> This looks great!  Does this mean that user applications built with Tkinter can use these too?  Are they built into Python?
> 
> Screenshot pro-tip, by the way: if you want to precisely capture one window with a nice drop shadow, you can do ?-shift-4, hit spacebar, and then click on a window.  I can see that these shots were captured by carefully dragging a border around a window to crop it :).

To answer your first question, you bet they?re built in! For the most breathtakingly awesome explanation of how to use these improved widgets, see http://www.tkdocs.com <http://www.tkdocs.com/>  :-)

Thanks for the screenshot tip. Now if it would only grab windows from inside Linux and Windows virtual machines?!

Mark



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150801/ec84bb43/attachment.html>

From glyph at twistedmatrix.com  Sat Aug  1 22:38:05 2015
From: glyph at twistedmatrix.com (Glyph)
Date: Sat, 1 Aug 2015 13:38:05 -0700
Subject: [Idle-dev] ttk appearance
In-Reply-To: <C7B7E2C1-87D4-4CCB-B530-E98A199D1C7C@markroseman.com>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
 <C1A66B95-5B33-47E3-92C1-96D90748E20E@twistedmatrix.com>
 <C7B7E2C1-87D4-4CCB-B530-E98A199D1C7C@markroseman.com>
Message-ID: <0AD76FB5-EB46-4B23-BC4D-4E1B5F4CD850@twistedmatrix.com>


> On Aug 1, 2015, at 1:34 PM, Mark Roseman <mark at markroseman.com> wrote:
> 
> Thanks for the screenshot tip. Now if it would only grab windows from inside Linux and Windows virtual machines?!
> 

If you use VMWare Fusion and Unity mode, you can actually get the same effect :).

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150801/c4445dd8/attachment.html>

From glyph at twistedmatrix.com  Sat Aug  1 22:21:57 2015
From: glyph at twistedmatrix.com (Glyph)
Date: Sat, 1 Aug 2015 13:21:57 -0700
Subject: [Idle-dev] ttk appearance
In-Reply-To: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
Message-ID: <C1A66B95-5B33-47E3-92C1-96D90748E20E@twistedmatrix.com>


> On Aug 1, 2015, at 9:30 AM, Mark Roseman <mark at markroseman.com> wrote:
> 
> If anyone is curious, here is a ?before and after? as to what IDLE?s config dialog looks like on Mac, Windows and Linux when using the ttk widgets:
> 
> 	http://www.tkdocs.com/images/idle_cfgfont_ttk.png <http://www.tkdocs.com/images/idle_cfgfont_ttk.png>
> 
> This is intentionally without any real layout/structure changes, and with only minor tweaking to spacing etc.
> 
> Mark

This looks great!  Does this mean that user applications built with Tkinter can use these too?  Are they built into Python?

Screenshot pro-tip, by the way: if you want to precisely capture one window with a nice drop shadow, you can do ?-shift-4, hit spacebar, and then click on a window.  I can see that these shots were captured by carefully dragging a border around a window to crop it :).

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150801/cbb30bbe/attachment.html>

From mark at markroseman.com  Sat Aug  1 23:00:25 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sat, 1 Aug 2015 14:00:25 -0700
Subject: [Idle-dev] ttk appearance
In-Reply-To: <0AD76FB5-EB46-4B23-BC4D-4E1B5F4CD850@twistedmatrix.com>
References: <AFE7B8E8-8ABC-4157-9241-7706BCBBFD03@markroseman.com>
 <C1A66B95-5B33-47E3-92C1-96D90748E20E@twistedmatrix.com>
 <C7B7E2C1-87D4-4CCB-B530-E98A199D1C7C@markroseman.com>
 <0AD76FB5-EB46-4B23-BC4D-4E1B5F4CD850@twistedmatrix.com>
Message-ID: <C32E3850-BA32-48DC-A184-FD9F44C9A836@markroseman.com>

Another quick example, tiny changes to maybe 20 lines of code. Swapping in the ttk widgets helps, but so do some quick layout and spacing tweaks.
	http://www.tkdocs.com/images/idle_find_ttk.png <http://www.tkdocs.com/images/idle_find_ttk.png>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150801/44c59372/attachment-0001.html>

From mark at markroseman.com  Sun Aug  2 23:37:47 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sun, 2 Aug 2015 14:37:47 -0700
Subject: [Idle-dev] IDLE configuration dialogs
Message-ID: <E89136AB-43E6-4B17-BEC8-13A52B0B379C@markroseman.com>

FYI, there are a few active items on the bug tracker related to some of the IDLE dialogs, if anyone wants to chime in on some potential changes:

http://bugs.python.org/issue24776 <http://bugs.python.org/issue24776>	Improve Fonts/Tabs UX for IDLE
http://bugs.python.org/issue23218 <http://bugs.python.org/issue23218>	Modernize the IDLE Find/Replace/Find in Files dialogs
http://bugs.python.org/issue24781 <http://bugs.python.org/issue24781>	Improve UX of IDLE Highlighting configuration tab
http://bugs.python.org/issue24782 <http://bugs.python.org/issue24782>	Merge 'configure extensions' into main IDLE config dialog
http://bugs.python.org/issue24760 <http://bugs.python.org/issue24760>	IDLE settings dialog shouldn't be modal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150802/043c7a72/attachment.html>

From chris at codingclub.co.uk  Tue Aug  4 12:53:06 2015
From: chris at codingclub.co.uk (Chris Roffey)
Date: Tue, 4 Aug 2015 11:53:06 +0100
Subject: [Idle-dev] IDLE in UK Schools
Message-ID: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>

Hi everyone. This is my first post to the list but I have been reading through the archives before joining. 

Python is now the most popular programming language in UK schools in 11-18 age group with something like 80% of GCSE Computer Science students now submitting code for these exams (at age 16) in Python.

I have a love of Python and IDLE similar to that described by Al Sweigart in his talk on re-imagining IDLE for education:
https://www.youtube.com/watch?v=u58DiW_t2lM <https://www.youtube.com/watch?v=u58DiW_t2lM>

I have a similar background in that I write some books (codingclub.co.uk <http://codingclub.co.uk/>) teaching Python as a first programming language (usually after experiencing Scratch). My, very short, books are primarily aimed at 10-14 year old and try to provide the foundations for students going on to GCSE. I have very similar experiences to Al in my post bag. In addition, as an 11-18 year old teacher I run Code Clubs and teach Python more formally in school. I see first hand the difficulties these young, average ability (as CS is now compulsory for all students in the UK) students have starting their first text based programming language. I also have one unusual quality for a programmer that loves coding - I find it pretty difficult. This enables me to empathise with these students. (Explanation - I am actually a Chemistry teacher whose long-standing hobby has taken off in the last few years.)

In my opinion, as a self-taught Java programmer who has since looked at many other languages, Python 3 is by far the best language to introduce text based programming that is currently available. As Al mentioned in his talk, the easy start up, the clear syntax and the lack of semi-colons and curly brackets, the easy install on all major platforms and then immediately having the well-chosen standard library available is awesome.

It is no surprise therefore that school children in the UK and increasingly around the world are being asked to learn Python. I think they therefore deserve, in addition to the best language, a fantastic IDE. Currently in my opinion IDLE is the best for Python teaching as it is so clean and code focussed. Nothing is perfect though and so I am in agreement with Al (and it was why I first started reading this list) that it would be fantastic if IDLE could be re-imagined with solely beginners in mind. I hope I will be able to contribute positively if this idea is taken further. 

It will be a tough call to provide the best IDE for beginners as there are so many fantastic developments currently being undertaken. Al points to Scratch and Code Academy. I would add one other example to Al?s list of developments we could learn from - Greenfoot is currently being re-imagined here: http://www.greenfoot.org/frames/ <http://www.greenfoot.org/frames/>

Best wishes
Chris Roffey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150804/fa89f147/attachment.html>

From guido at python.org  Tue Aug  4 18:34:17 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 4 Aug 2015 18:34:17 +0200
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
Message-ID: <CAP7+vJKohcy8HNkSZBWrBZJnS6co3N+D0SHXVb_E_q+pvLRjjA@mail.gmail.com>

I like the proposal. Let's re-imagine IDLE with solely beginners in mind.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150804/05acb96c/attachment.html>

From mark at markroseman.com  Tue Aug  4 19:14:21 2015
From: mark at markroseman.com (Mark Roseman)
Date: Tue, 4 Aug 2015 10:14:21 -0700
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
Message-ID: <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>

I agree, IDLE as solely a learning tool makes a lot of sense if it?s going to continue to exist as part of Python.  There?s a lot in there now that is beyond the scope of what learners need. 

While I?m happy to help with the UI improvements to what?s there now, I have to admit part of my motivation in making it look not so yucky (especially on Mac) is that in its present state it probably discourages future changes and improvements (i.e. why bother, if we?re stuck with Tkinter). I too really liked the kinds of ideas Al brought up in his proposal, and think they?re entirely doable.

Mark


From al at inventwithpython.com  Tue Aug  4 20:07:17 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Tue, 4 Aug 2015 14:07:17 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
Message-ID: <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>

Hi, this is Al. I haven't had much time to work on IDLE Reimagined in
recent months, but I'd like to get back on it in a couple weeks. Mostly
I've been following a rabbit hole of:

* I need to make this project approachable for new contributors...
* So I want to document the code...
* But first I should refactor it to simplify it...
* But first I should make the unit tests complete to avoid breaking
anything...
* But first I need to learn tkinter for the gui tests...

etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool that
is bundled with Python.

-Al

On Tue, Aug 4, 2015 at 1:14 PM, Mark Roseman <mark at markroseman.com> wrote:

> I agree, IDLE as solely a learning tool makes a lot of sense if it?s going
> to continue to exist as part of Python.  There?s a lot in there now that is
> beyond the scope of what learners need.
>
> While I?m happy to help with the UI improvements to what?s there now, I
> have to admit part of my motivation in making it look not so yucky
> (especially on Mac) is that in its present state it probably discourages
> future changes and improvements (i.e. why bother, if we?re stuck with
> Tkinter). I too really liked the kinds of ideas Al brought up in his
> proposal, and think they?re entirely doable.
>
> Mark
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150804/51104338/attachment.html>

From mark at markroseman.com  Tue Aug  4 23:40:55 2015
From: mark at markroseman.com (Mark Roseman)
Date: Tue, 4 Aug 2015 14:40:55 -0700
Subject: [Idle-dev] moving IDLE forward (was Re:  IDLE in UK Schools)
In-Reply-To: <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
Message-ID: <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>

> Hi, this is Al. I haven't had much time to work on IDLE Reimagined in recent months, but I'd like to get back on it in a couple weeks. Mostly I've been following a rabbit hole of:
> 
> * I need to make this project approachable for new contributors...
> * So I want to document the code...
> * But first I should refactor it to simplify it...
> * But first I should make the unit tests complete to avoid breaking anything...
> * But first I need to learn tkinter for the gui tests...
> 
> etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool that is bundled with Python.


Hi Al,

That is awesome! Let?s make sure we don?t duplicate effort, particularly in the ?prep? work to improve/simplify the current code.

As someone who is very familiar with Tk (see. http://www.tkdocs.com <http://www.tkdocs.com/>), I?ve been working the last week or so at updating the current appearance, and subsequently expect to simplify lots of the underlying code. As I?ve been working with it, I see lots of great opportunities to make it easier for people to modify it.

One big issue that Terry is presently working hard to sort through (see http://bugs.python.org/issue24759 <http://bugs.python.org/issue24759>) is the ?backwards compatibility? aspect, which from my current reading suggests we?d be stuck with both ?old? and ?new? UI code side-by-side until Python 3.6.  That makes the maintenance and modification more difficult of course. I?m still trying to get my head fully around all the implications.

Some of the structural aspects (refactoring, reorganizing dialogs, etc.) could be addressed to simplify the code before an option to use ttk widgets is added. But, as Terry points out, if there are people out there using *pieces* from idlelib, doing too much in the way of structural changes could mess things up for them.  So significant structural changes to the current code base seem out.

Instead, new UI code (based more on ttk) would go in brand new files, not having any backwards compatibility constraint. Those ones can be reorganized/restructured to everyone?s heart?s content, may not even resemble corresponding parts of the existing code, and could serve as a great base for more significant changes that might better facilitate its use for learners. 

So it?s almost like we have a fork and an original sitting side-by-side in stdlib until at least 3.6. How do we decide which to use?

	- programs using pieces of idlelib, and people with Tk 8.4:
		- they run the code as it exists now (current UI, current structure)

	- for people running IDLE (as a whole) and having Tk 8.5+:
		- for now, by default, they get the old code (current UI, current structure)
		- if they want, they can flip an ?experimental? switch to try the new code (improved UI, improved structure)
		- at some point in the future (when the new stuff is stable enough), we change things so they get the new code by default

The old code gets marked as deprecated, with plans to remove it altogether at some point in the future.

Two things I would be fairly nervous to see happening:
	- requests for (non-trivial) UI improvements (which will be in the ?new UI? code) to be ?ported? to the existing code (which can?t have major structural changes).
	- the new UI code having to support both Tk 8.4 (which doesn?t have ttk) and Tk 8.5+

Any thoughts?

Mark















-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150804/2a3b352e/attachment-0001.html>

From tjreedy at udel.edu  Wed Aug  5 04:43:32 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 4 Aug 2015 22:43:32 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
Message-ID: <mprt8o$5pr$1@ger.gmane.org>

On 8/4/2015 6:53 AM, Chris Roffey wrote:
> Hi everyone. This is my first post to the list but I have been reading
> through the archives before joining.

Welcome.

> Python is now the most popular programming language in UK schools in
> 11-18 age group with something like 80% of GCSE Computer Science
> students now submitting code for these exams (at age 16) in Python.

Wow.

> I have a love of Python and IDLE similar to that described by Al
> Sweigart in his talk on re-imagining IDLE for education:
> https://www.youtube.com/watch?v=u58DiW_t2lM

I will get back to this.

> it would be fantastic if IDLE could be re-imagined with solely
> beginners in mind.

As a user of Idle for several years, and not a beginner, I disagree with 
'only'.  That aside, I consider it unnecessary and diversionary from the 
numerous known issues that will benefit *everyone*.

Back to I.R.,
https://github.com/asweigart/idle-reimagined/wiki
https://github.com/asweigart/idle-reimagined/wiki/Killer-App

 From my viewpoint, forking Idle would mostly be a diversionary waste of 
energy.  But Al has to decide for himself what he wants to do. As it is, 
I have applied 4 of his patches this year, soon after being posted. The 
5th one, renaming idlelib files to pep8 standards, is something I wanted 
to do a year or two ago and would have if it were allowed.

Most of the "features that will distinguish IR", so he claims, are 
issues on the tracker awaiting commit ready patches.

2. Tabbed file editor: 5 years ago, I asked on pydev whether we could 
use ttk.Notebook to do this, for both shell and editor, and opened
https://bugs.python.org/issue9262
Today I finally got a positive answer from Nick Coughlin after changing 
'replace with ttk' to 'add ttk as optional'.

1.a Single window with multiple simultaneously visible panes: I have 
floated this idea multiple times multiple places, which I believe 
includes other issues on the tracker.  There are people who like having 
a taskbar item per window, and will thereby oppose this and 2. above. I 
have not opened a tracker issue because 2. above has to come first.

1.b stacked vertically: a mini shell is inadequate for real exploration. 
I think horizontal stacking, with tabs in both panes, would be much better.

3. Foreign language support: better called non-English support, i18n, or 
  internationalization.  Again, approved in principle, but development 
work and patches needed. I and other devs commented extensively on 
https://bugs.python.org/issue17776

4. Autosave: issue already linked (https://bugs.python.org/issue19042)

5. Integrated PIP: see https://bugs.python.org/issue23551 to add a PIP gui.

6. Pastebin: nice idea, but use of the trademark initially confused me. 
codetrade.python.org would not be specific to Idle. Access to it could 
be done either as an Idle extension or as an external program accessed 
from Idle (see 10b.)

7. Better tracebacks, local variables: Already available as Debug => 
Stack Viewer.  This needs improvement, so I opened
https://bugs.python.org/issue24790
Stack Viewer is no hotkey.  Perhaps the author considered viewing locals 
as a non-beginner activity.

IndexError discussions: I would like bad index also, but...
https://bugs.python.org/issue18162 why not a slam dunk issue
https://bugs.python.org/issue21911 (closed as dup)
https://bugs.python.org/issue1534607 (ditto)

8. Error explanations: I think the writing and translating should be 
done for general use and not just for Idle.  I have had in mind that 
there should be a HOWTO explaining tracebacks and then listing 
problematic error messages and explainations.  If there were such a 
thing, then "SyntaxError: EOL while scanning string literal" itself 
could be underlined as a link.  Translations of Python docs are handled 
by national groups.

This gives me another idea: in the traceback, underline 'line ####' as a 
link so that clicking takes one to the line.  This would be easier and 
more obvious than rt click, move cursor down, left click.  (Ditto for 
grep output.)

9. Detect/warn 2 code run on 3: compile() already detects, raises, and 
marks the spot of an error.  I think doing more is the job of 3rd party 
code-checkers. See #10b for using with Idle a checker that does this, if 
one exists.

10a. Real-time lint: I would like this too for things that are actually 
possible.  It would involve existing or new Delegator layers. Colorizer 
already detects 'abc\ndef' in the sense that it only colors 'abc', so I 
believe it could take action when \n is entered. The hints from smart 
indenting could be documented. "if a\n", without an indent is a signal 
that ':' was not entered, because if it were, Idle would insert the 
indent and the user would see 'if a:\n    ".

10b. https://github.com/asweigart/idle-reimagined/wiki/Real-Time-Lint
"The idea of having a style checker (such as for PEP8) was already 
considered and rejected."

This is, at best, misleading. The proposal to incorporate the specific 
code checker named "pep8", disliked by many core developers, *was* 
rejected.  But I *accepted* the general idea of accessing code checkers 
from Idle. The patch on https://bugs.python.org/issue21880 is perhaps 
90% ready. I am hoping that Mark will help me finish reviewing and maybe 
revising.

This patch is about extending Idle without writing Idle specific 
extensions. The generalization would be to run any external program that 
takes a filename as input, not just a code checker. The patch include 
the ability to set other arguments.

11. Tutorial plugin system: I believe this has been discussed elsewhere, 
with the idea of using the Python tutorial as the first example.  But 
this should be a standalone tkinter app.


Minor issues

1. Line numbers: issue already linked
https://bugs.python.org/issue17535
I believe this is 90% done. I am hoping that Mark will help me finish 
reviewing and maybe revising.

2. Detect disk changes: Notepad++ checks when the app or a window 
becomes active.  For changed windows, it gives me the choice to update 
the file in the editor, or not.  Useful. Someone open an issue and 
submit a patch.

3. Start maximized: rejected as mandatory, accepted as startup option.
https://bugs.python.org/issue23937
This would be more useful with horizonatally stacked panes.

I have about 40 unposted ideas on my private list. Perhaps I should open 
more issues.  In any case, ideas are common, commit-ready patches are rare.

-- 
Terry Jan Reedy


From guido at python.org  Wed Aug  5 11:55:10 2015
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Aug 2015 11:55:10 +0200
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <mprt8o$5pr$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
Message-ID: <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>

On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> As a user of Idle for several years, and not a beginner, I disagree with
> 'only'.  That aside, I consider it unnecessary and diversionary from the
> numerous known issues that will benefit *everyone*.
>

I was worried that you'd respond like this. *No* change to IDLE will
benefit *everyone*, for the simple reason that few people outside the
(non-higher) educational field use it. IDLE should not try to compete with
things like PyCharm, nor with the Emacs/Vim world (and I consider most
every text editor professional coders like to use these days on
Linux/Mac/Windows to be in that world, from Sublime Text to Atom). IDLE's
one redeeming feature is that it's bundled with Python, and this is a
benefit mostly for classrooms where Python is taught as the first
text-based programming language after e.g. Scratch.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/025b8174/attachment.html>

From Bruce_Sherwood at ncsu.edu  Wed Aug  5 16:05:02 2015
From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood)
Date: Wed, 5 Aug 2015 08:05:02 -0600
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
Message-ID: <CAFDG03ikq5ARbw8pqF2ttsWNtX4_D7=VOMv49d+Jsj0cpBJ3vQ@mail.gmail.com>

Guido, the use of IDLE isn't limited to precollege. The Matter &
Interactions curriculum and textbook developed by Ruth Chabay and me (
matterandinteractions.org) is for first-year university science and
engineering students. Unlike most intro physics courses and textbooks,
which take a 19th century perspective and stop around 1865, we offer a
contemporary perspective on intro physics. One of the contemporary aspects
is a serious introduction to computational modeling, and the language is
Python. The great majority of these first-year technical students have
never written a program before, and the clarity and simplicity of Python is
crucial to being able to have the students model physical systems
computationally. Matter & Interactions is used at a number of major
universities that include NCSU, Purdue, Georgia Tech, and U Texas Austin,
and at many four-year liberal arts colleges that include Wellesley,
Haverford, Union, Carleton, and St. Olaf.

Students in this curriculum use the VPython module (vpython.org) to
visualize system behavior in 3D. In the last 12 months there were 70,000
downloads of VPython, many of which were surely by university students
using Matter & Interactions. They use IDLE, in a slightly modified version
(called VIDLE for clarity). In a crowded physics course we are constrained
to teach a very small but sufficient subset of Python, and teaching a
sophisticated editing environment is absolutely out of the question, nor is
it necessary. Python and IDLE are key to what we do.

Steve Spicklemire and I are the current developers and maintainers of
VPython, and I do all of my Python programming very happily in (V)IDLE, so
its utility is not limited to beginners. (I use Eclipse for C++ and
JavaScript project work.)

Bruce Sherwood

P.S. I'm also the developer of a version of VPython that runs in a browser (
glowscript.org), thanks to the RapydScript Python-to-JavaScript compiler
(plus some preprocessing to implement the VPython API), which does an
adequate job for the typical uses to which VPython is put. There is a third
version of VPython called ivisual, a pure Python implementation by John
Coady for the IPython environment, in which the 3D rendering in the IPython
notebook is done by invoking the GlowScript graphics libraries, which are
based on WebGL. A fourth variant of VPython is offered by trinket.io, which
bundles the GlowScript VPython compiler and execution into a package that
one can place on one's own web page.

At glowscript.org you can run a sizable number of VPython examples, and
this browser instantiation has the great advantage that one can email a
link to someone who doesn't have Python installed and they can immediately
run the program. Here's a simple example:

http://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/Bounce-VPython

P.P.S. For a few months at the start of the GlowScript project in 2011
David Scherer, the originator of VPython, played a key role in creating the
foundations for the project.

On Wed, Aug 5, 2015 at 3:55 AM, Guido van Rossum <guido at python.org> wrote:

> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> As a user of Idle for several years, and not a beginner, I disagree with
>> 'only'.  That aside, I consider it unnecessary and diversionary from the
>> numerous known issues that will benefit *everyone*.
>>
>
> I was worried that you'd respond like this. *No* change to IDLE will
> benefit *everyone*, for the simple reason that few people outside the
> (non-higher) educational field use it. IDLE should not try to compete with
> things like PyCharm, nor with the Emacs/Vim world (and I consider most
> every text editor professional coders like to use these days on
> Linux/Mac/Windows to be in that world, from Sublime Text to Atom). IDLE's
> one redeeming feature is that it's bundled with Python, and this is a
> benefit mostly for classrooms where Python is taught as the first
> text-based programming language after e.g. Scratch.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/14533d92/attachment.html>

From Bruce_Sherwood at ncsu.edu  Wed Aug  5 16:52:14 2015
From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood)
Date: Wed, 5 Aug 2015 08:52:14 -0600
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAFDG03ikq5ARbw8pqF2ttsWNtX4_D7=VOMv49d+Jsj0cpBJ3vQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
 <CAFDG03ikq5ARbw8pqF2ttsWNtX4_D7=VOMv49d+Jsj0cpBJ3vQ@mail.gmail.com>
Message-ID: <CAFDG03ga_uz6-uQ_Hd-nP5eKbUHsJM=y17-ZeT-2ExcrEPseuQ@mail.gmail.com>

In my previous note I tried to document the rather extensive past and
current use of IDLE in higher education. For the near future, those of us
involved in the development and use of VPython see as the best way forward
two environments, the GlowScript environment (which requires no software
installation), and the use of John Coady's ivisual module, running Python
in an IPython server with output in IPython notebooks, using the GlowScript
WebGL libraries, typically in the context of a full distribution such as
Anaconda.

It is difficult to continue development of the original "classic" VPython,
because the core is written C++ with the use of the Boost libraries, which
has meant that only four people since its creation in 2000 have ever made
significant contributions to the code. It uses antiquated CPU-based OpenGL
graphics instead of the GPU. Installation can be problematic in some
environments.

There are some things that need to be done to make ivisual fully ready for
prime time, but they look doable. The API isn't quite right, execution is
slow because the module is pure Python, and the notebook environment needs
some customization to make it usable by novices. We think that Cython can
give us the execution speed we need, and Coady has already done some
experimentation with this; it will be a big win to have the code in Python
rather than C++. He has also done some preliminary experimentation with
customizing the notebook. Several of us expect to help out on this.

This means that at some point in the not distant future IDLE will cease to
be important for our purposes, but I did want to document how important it
has been.

Incidentally, one of the important aspects of the GlowScript environment is
that it is not uncommon, especially in high schools and community colleges,
for IT departments to refuse to install Python "because open source
software is very dangerous." Recently Chabay and I ran a VPython workshop
where for the first time we used GlowScript, which meant that participants
didn't have to install any software on their laptops. In the workshop was a
high school physics teacher who brought a school Chromebook and expressed
delight that he could write and run VPython programs on it, which gave him
the only way he and his students could use Python and VPython.

Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/024c6ebf/attachment.html>

From guido at python.org  Wed Aug  5 18:40:44 2015
From: guido at python.org (Guido van Rossum)
Date: Wed, 5 Aug 2015 18:40:44 +0200
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAFDG03ikq5ARbw8pqF2ttsWNtX4_D7=VOMv49d+Jsj0cpBJ3vQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
 <CAFDG03ikq5ARbw8pqF2ttsWNtX4_D7=VOMv49d+Jsj0cpBJ3vQ@mail.gmail.com>
Message-ID: <CAP7+vJJB9+WfL7rsmmsaPLCAZphiCEM8U8bHaJO0J83nWd3Zpg@mail.gmail.com>

On Wed, Aug 5, 2015 at 4:05 PM, Bruce Sherwood <Bruce_Sherwood at ncsu.edu>
wrote:

> Guido, the use of IDLE isn't limited to precollege.
>

Sure, but don't you think the key audiences for IDLE all have something in
common?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/f8c9c091/attachment-0001.html>

From mark at markroseman.com  Wed Aug  5 18:43:45 2015
From: mark at markroseman.com (Mark Roseman)
Date: Wed, 5 Aug 2015 09:43:45 -0700
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <mprt8o$5pr$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
Message-ID: <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>

> As a user of Idle for several years, and not a beginner, I disagree with 'only'.  That aside, I consider it unnecessary and diversionary from the numerous known issues that will benefit *everyone*.
> Most of the "features that will distinguish IR", so he claims, are issues on the tracker awaiting commit ready patches.


I?m new here, and really want to avoid stepping on toes. Open source has its own way of doing things, and a hesitancy to accept changes if there is opposition. Which too often leads to a proliferation of options and features, rather than design.  And because these projects aren?t resourced like a ?typical? project, the notion of ?enforcing? priorities is kinda mushy. 

If IDLE is to be a *great* tool for learning out of the box, anything that distracts from or interferes with that purpose shouldn?t (appear to) be part of it.  Examples would include most configuration, including:
	* the notion of extensions, especially installing, enabling/disabling or configuring them
	* choosing or editing key sets
	* customizing syntax highlighting (though choosing from some built-in themes might be an option, more likely dark vs. light background)
	* likely font changes (except for increase/decrease size) 

If there is actual agreement that IDLE?s main purpose is to be a great learning tool, but to allow for some additional support for ?non-learners?, it doesn?t preclude any of those things being around, but they shouldn?t be there out of the box (think turning on a power user mode). Extra work in terms of development, and increased maintenance, but in the free labour economy, if someone wants to do it, and it can be done in a way that doesn?t diminish the primary goal, it?s probably not a horrible thing. 

(I raise those examples as improving the existing dialogs is something I?m willing to do if there?s interest and to reduce friction, but would be the first person to say most of that stuff should be completely hidden out of the box, and it would be ok with me if power user configuration, if supported at all, involved manually editing config files.)

To put it another way: how would a bug report and patch be received to remove the ?Configure Extensions? dialog from the menu? Or remove the ?Keys? tab from preferences dialog?

That doesn?t preclude all those things being part of the architecture, or for example a plugin architecture being created to hook in code checkers. But out of the box, if a code checker is something that will help learners, it should just be there automatically, and no messing around choosing, installing or configuring one. 

Or if there is a choice of two user interaction models (A and B), where A will work very well for learners but not at all for non-learners, and B will work ok for both learners and non-learners, the app should support A out of the box, with B nowhere to be seen. If someone really wants, a choice between A and B can still be in the code and maybe exposed in ?power user? mode if its there.

Even in open source, there can be a cost to not making choices so you can support more diversity. Trust me, I cringed through the Tcl?s community refusing to standardize on a single object system for years. ;-)

Mark


From al at inventwithpython.com  Wed Aug  5 19:29:11 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Wed, 5 Aug 2015 13:29:11 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
Message-ID: <CAM=hmROKb9LgsO3UY399MH=NUpeg+ua=x1WDY-fBUVj1jqmv3w@mail.gmail.com>

Can we collect a list of software that uses idlelib? I'm not sure if it
would affect a significant number of projects. Since IDLE has always been
an application rather than a standard library module with a published API,
I don't feel like this should hold back IDLE development. (Or am I wrong in
this view of idlelib?)

Many of the changes that I'd like to see are cosmetic or new features
instead of restructuring. The single window, tabbed design is the only
non-trivial UI change, and even then it's reusing PyShellEditorWindow and
OutputWindow instead of creating new UI components.

Using the post-8.5 widgets really would improve the look of IDLE, but
personally I don't mind if these have to be held off until 3.6. We'll have
our work cut out even without maintaining two sets of widgets just for 3.5.

Overall, I'd defer to Mark and Terry's judgement. My current plan is to get
more familiar with ttk (Mark's book has been great!) and the code base, and
also think of what "new contributor" documents we should write up.

Are there any bug issues and mailing list threads that would be in
particular good for new contributors? Also, any questions in this thread I
haven't addressed?

-Al

On Tue, Aug 4, 2015 at 5:40 PM, Mark Roseman <mark at markroseman.com> wrote:

> Hi, this is Al. I haven't had much time to work on IDLE Reimagined in
> recent months, but I'd like to get back on it in a couple weeks. Mostly
> I've been following a rabbit hole of:
>
> * I need to make this project approachable for new contributors...
> * So I want to document the code...
> * But first I should refactor it to simplify it...
> * But first I should make the unit tests complete to avoid breaking
> anything...
> * But first I need to learn tkinter for the gui tests...
>
> etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool
> that is bundled with Python.
>
>
>
> Hi Al,
>
> That is awesome! Let?s make sure we don?t duplicate effort, particularly
> in the ?prep? work to improve/simplify the current code.
>
> As someone who is very familiar with Tk (see. http://www.tkdocs.com),
> I?ve been working the last week or so at updating the current appearance,
> and subsequently expect to simplify lots of the underlying code. As I?ve
> been working with it, I see lots of great opportunities to make it easier
> for people to modify it.
>
> One big issue that Terry is presently working hard to sort through (see
> http://bugs.python.org/issue24759) is the ?backwards compatibility?
> aspect, which from my current reading suggests we?d be stuck with both
> ?old? and ?new? UI code side-by-side until Python 3.6.  That makes the
> maintenance and modification more difficult of course. I?m still trying to
> get my head fully around all the implications.
>
> Some of the structural aspects (refactoring, reorganizing dialogs, etc.)
> could be addressed to simplify the code before an option to use ttk widgets
> is added. But, as Terry points out, if there are people out there using
> *pieces* from idlelib, doing too much in the way of structural changes
> could mess things up for them.  So significant structural changes to the
> current code base seem out.
>
> Instead, new UI code (based more on ttk) would go in brand new files, not
> having any backwards compatibility constraint. Those ones can be
> reorganized/restructured to everyone?s heart?s content, may not even
> resemble corresponding parts of the existing code, and could serve as a
> great base for more significant changes that might better facilitate its
> use for learners.
>
> So it?s almost like we have a fork and an original sitting side-by-side in
> stdlib until at least 3.6. How do we decide which to use?
>
> - programs using pieces of idlelib, and people with Tk 8.4:
> - they run the code as it exists now (current UI, current structure)
>
> - for people running IDLE (as a whole) and having Tk 8.5+:
> - for now, by default, they get the old code (current UI, current
> structure)
> - if they want, they can flip an ?experimental? switch to try the new code
> (improved UI, improved structure)
> - at some point in the future (when the new stuff is stable enough), we
> change things so they get the new code by default
>
> The old code gets marked as deprecated, with plans to remove it altogether
> at some point in the future.
>
> Two things I would be fairly nervous to see happening:
> - requests for (non-trivial) UI improvements (which will be in the ?new
> UI? code) to be ?ported? to the existing code (which can?t have major
> structural changes).
> - the new UI code having to support both Tk 8.4 (which doesn?t have ttk)
> and Tk 8.5+
>
> Any thoughts?
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/aa6b7b1a/attachment.html>

From al at inventwithpython.com  Wed Aug  5 21:11:22 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Wed, 5 Aug 2015 15:11:22 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
Message-ID: <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>

To be clear, I don't want to fork IDLE. The prime benefit of IDLE is that
it is bundle in Python installers and requires zero configuration. Forking
it would indeed be a waste of energy (there are already plenty of good IDEs
out there, and IDLE shouldn't even try to compete with them).

I'll start going through the issue tracker for other IDLE features and link
to them from the wiki. I'm not surprised that a lot of things I brought up
in the IDLE Reimagined doc are already on the issue tracker.

I meant "pastebin" as in the generic sense, rather than specifically
pastebin.com. We'd of course have to work out the details of where these
pastes would be hosted. But the idea here is to make it easy to share code
without getting the whitespace mangled.

If changing Python's error messages isn't a problem, then that'd be a nice
freebie for IDLE. I only hesitated proposing this because I didn't know if
these messages were cast in stone, due to Python code out there relying on
the exact error message strings.

I saw on the issue tracker that the pep8 style checker
http://bugs.python.org/issue18704 had been set to "rejected" resolution a
couple years ago. I don't mean to be misleading. I'm not against a style
checker feature if not on by default, imo. By "real time lint", I meant a
feature that could point out syntax errors and variable name typos, rather
than code style.

IDLE itself is already a standalone tkinter app, and any Python tutorial
system itself would need an IDE anyway. Having an IDE bundled with the
language itself makes Python stand out from all other languages. Having
something to train the next generation of Python coders that doesn't
involve typing code into a website would be excellent for the language, imo.

Thanks for your patches and hard work, Terry. I've filed a bug for the
"detect disk changes" feature: https://bugs.python.org/issue24799 Do post
your ideas to the bug tracker. After August, I'll have much more time to
spend on IDLE. I don't mean to only talk about ideas, I just wanted to have
a plan before I start writing patches.

-Al

On Wed, Aug 5, 2015 at 12:43 PM, Mark Roseman <mark at markroseman.com> wrote:

> > As a user of Idle for several years, and not a beginner, I disagree with
> 'only'.  That aside, I consider it unnecessary and diversionary from the
> numerous known issues that will benefit *everyone*.
> > Most of the "features that will distinguish IR", so he claims, are
> issues on the tracker awaiting commit ready patches.
>
>
> I?m new here, and really want to avoid stepping on toes. Open source has
> its own way of doing things, and a hesitancy to accept changes if there is
> opposition. Which too often leads to a proliferation of options and
> features, rather than design.  And because these projects aren?t resourced
> like a ?typical? project, the notion of ?enforcing? priorities is kinda
> mushy.
>
> If IDLE is to be a *great* tool for learning out of the box, anything that
> distracts from or interferes with that purpose shouldn?t (appear to) be
> part of it.  Examples would include most configuration, including:
>         * the notion of extensions, especially installing,
> enabling/disabling or configuring them
>         * choosing or editing key sets
>         * customizing syntax highlighting (though choosing from some
> built-in themes might be an option, more likely dark vs. light background)
>         * likely font changes (except for increase/decrease size)
>
> If there is actual agreement that IDLE?s main purpose is to be a great
> learning tool, but to allow for some additional support for ?non-learners?,
> it doesn?t preclude any of those things being around, but they shouldn?t be
> there out of the box (think turning on a power user mode). Extra work in
> terms of development, and increased maintenance, but in the free labour
> economy, if someone wants to do it, and it can be done in a way that
> doesn?t diminish the primary goal, it?s probably not a horrible thing.
>
> (I raise those examples as improving the existing dialogs is something I?m
> willing to do if there?s interest and to reduce friction, but would be the
> first person to say most of that stuff should be completely hidden out of
> the box, and it would be ok with me if power user configuration, if
> supported at all, involved manually editing config files.)
>
> To put it another way: how would a bug report and patch be received to
> remove the ?Configure Extensions? dialog from the menu? Or remove the
> ?Keys? tab from preferences dialog?
>
> That doesn?t preclude all those things being part of the architecture, or
> for example a plugin architecture being created to hook in code checkers.
> But out of the box, if a code checker is something that will help learners,
> it should just be there automatically, and no messing around choosing,
> installing or configuring one.
>
> Or if there is a choice of two user interaction models (A and B), where A
> will work very well for learners but not at all for non-learners, and B
> will work ok for both learners and non-learners, the app should support A
> out of the box, with B nowhere to be seen. If someone really wants, a
> choice between A and B can still be in the code and maybe exposed in ?power
> user? mode if its there.
>
> Even in open source, there can be a cost to not making choices so you can
> support more diversity. Trust me, I cringed through the Tcl?s community
> refusing to standardize on a single object system for years. ;-)
>
> Mark
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/8b637546/attachment-0001.html>

From al at inventwithpython.com  Wed Aug  5 21:16:35 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Wed, 5 Aug 2015 15:16:35 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
Message-ID: <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>

And to echo Mark and Guido, IDLE's prime benefit is that it is bundled with
Python. We should definitely be open to make large design changes to
benefit new programmers. Adding another checkbox to the configuration
window makes IDLE more versatile, but it also brings it closer to a VCR
with 50 buttons instead of an iPod with just the circle-wheel button.
That's the opposite of what new programmers (both kids and adults) want.

On Wed, Aug 5, 2015 at 3:11 PM, Al Sweigart <al at inventwithpython.com> wrote:

> To be clear, I don't want to fork IDLE. The prime benefit of IDLE is that
> it is bundle in Python installers and requires zero configuration. Forking
> it would indeed be a waste of energy (there are already plenty of good IDEs
> out there, and IDLE shouldn't even try to compete with them).
>
> I'll start going through the issue tracker for other IDLE features and
> link to them from the wiki. I'm not surprised that a lot of things I
> brought up in the IDLE Reimagined doc are already on the issue tracker.
>
> I meant "pastebin" as in the generic sense, rather than specifically
> pastebin.com. We'd of course have to work out the details of where these
> pastes would be hosted. But the idea here is to make it easy to share code
> without getting the whitespace mangled.
>
> If changing Python's error messages isn't a problem, then that'd be a nice
> freebie for IDLE. I only hesitated proposing this because I didn't know if
> these messages were cast in stone, due to Python code out there relying on
> the exact error message strings.
>
> I saw on the issue tracker that the pep8 style checker
> http://bugs.python.org/issue18704 had been set to "rejected" resolution a
> couple years ago. I don't mean to be misleading. I'm not against a style
> checker feature if not on by default, imo. By "real time lint", I meant a
> feature that could point out syntax errors and variable name typos, rather
> than code style.
>
> IDLE itself is already a standalone tkinter app, and any Python tutorial
> system itself would need an IDE anyway. Having an IDE bundled with the
> language itself makes Python stand out from all other languages. Having
> something to train the next generation of Python coders that doesn't
> involve typing code into a website would be excellent for the language, imo.
>
> Thanks for your patches and hard work, Terry. I've filed a bug for the
> "detect disk changes" feature: https://bugs.python.org/issue24799 Do post
> your ideas to the bug tracker. After August, I'll have much more time to
> spend on IDLE. I don't mean to only talk about ideas, I just wanted to have
> a plan before I start writing patches.
>
> -Al
>
> On Wed, Aug 5, 2015 at 12:43 PM, Mark Roseman <mark at markroseman.com>
> wrote:
>
>> > As a user of Idle for several years, and not a beginner, I disagree
>> with 'only'.  That aside, I consider it unnecessary and diversionary from
>> the numerous known issues that will benefit *everyone*.
>> > Most of the "features that will distinguish IR", so he claims, are
>> issues on the tracker awaiting commit ready patches.
>>
>>
>> I?m new here, and really want to avoid stepping on toes. Open source has
>> its own way of doing things, and a hesitancy to accept changes if there is
>> opposition. Which too often leads to a proliferation of options and
>> features, rather than design.  And because these projects aren?t resourced
>> like a ?typical? project, the notion of ?enforcing? priorities is kinda
>> mushy.
>>
>> If IDLE is to be a *great* tool for learning out of the box, anything
>> that distracts from or interferes with that purpose shouldn?t (appear to)
>> be part of it.  Examples would include most configuration, including:
>>         * the notion of extensions, especially installing,
>> enabling/disabling or configuring them
>>         * choosing or editing key sets
>>         * customizing syntax highlighting (though choosing from some
>> built-in themes might be an option, more likely dark vs. light background)
>>         * likely font changes (except for increase/decrease size)
>>
>> If there is actual agreement that IDLE?s main purpose is to be a great
>> learning tool, but to allow for some additional support for ?non-learners?,
>> it doesn?t preclude any of those things being around, but they shouldn?t be
>> there out of the box (think turning on a power user mode). Extra work in
>> terms of development, and increased maintenance, but in the free labour
>> economy, if someone wants to do it, and it can be done in a way that
>> doesn?t diminish the primary goal, it?s probably not a horrible thing.
>>
>> (I raise those examples as improving the existing dialogs is something
>> I?m willing to do if there?s interest and to reduce friction, but would be
>> the first person to say most of that stuff should be completely hidden out
>> of the box, and it would be ok with me if power user configuration, if
>> supported at all, involved manually editing config files.)
>>
>> To put it another way: how would a bug report and patch be received to
>> remove the ?Configure Extensions? dialog from the menu? Or remove the
>> ?Keys? tab from preferences dialog?
>>
>> That doesn?t preclude all those things being part of the architecture, or
>> for example a plugin architecture being created to hook in code checkers.
>> But out of the box, if a code checker is something that will help learners,
>> it should just be there automatically, and no messing around choosing,
>> installing or configuring one.
>>
>> Or if there is a choice of two user interaction models (A and B), where A
>> will work very well for learners but not at all for non-learners, and B
>> will work ok for both learners and non-learners, the app should support A
>> out of the box, with B nowhere to be seen. If someone really wants, a
>> choice between A and B can still be in the code and maybe exposed in ?power
>> user? mode if its there.
>>
>> Even in open source, there can be a cost to not making choices so you can
>> support more diversity. Trust me, I cringed through the Tcl?s community
>> refusing to standardize on a single object system for years. ;-)
>>
>> Mark
>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/3fdb68ba/attachment.html>

From tjreedy at udel.edu  Wed Aug  5 23:30:06 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 5 Aug 2015 17:30:06 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
Message-ID: <mptv93$nbm$1@ger.gmane.org>

On 8/5/2015 5:55 AM, Guido van Rossum wrote:
> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>     As a user of Idle for several years, and not a beginner, I disagree
>     with 'only'.  That aside, I consider it unnecessary and diversionary
>     from the numerous known issues that will benefit *everyone*.

The core of this comment is "unnecessary and diversionary ...".

As for 'unnecessary', what does adding 'only' add to the discussion? 
Does that mean that we should reject features that also benefit 
non-beginners? If not, what does it mean?  What extra design guidance 
does it add?

As for 'divisionary', see, besides the above, my questions that follow 
the 'PyCharm' quote.

Please note that I volunteer my time to improve Idle *because* it is 
primarily used by students and secondarily, perhaps, by others who are 
not professional programmers.

> I was worried that you'd respond like this. *No* change to IDLE will
> benefit *everyone*,

Please give me the benefit of the doubt and assume that I am saying 
something sensible. By 'everyone', I mean "everyone who uses Idle" and 
in relation to a particular issue, 'everyone who use the feature in 
question' and in relation of OS-specific issues, 'everyone using that 
OS'.  With those meanings, my statement is reasonably true.

 > for the simple reason that few people outside the
 > (non-higher) educational field use it.

Bruce already covered colleges.

There are also post-beginners, but not professional programmers, like my 
daughter, who are so far happy with Idle and do not yet need the 
advanced features of other Python shells.

And there are Windows users.  Windows Command Prompt is awful. 
Interactive Python in Command Prompt suffers its sins. I believe most 
Windows users who try Idle Shell find it to be a better experience. One 
of the other core devs once (blushingly) admitted on pydev to using 
Shell on Windows for this reason.

 > IDLE should not try to compete with things like PyCharm ...

What does this mean in terms of Idle design decisions?  Can you give me 
examples of what you think should not be added?

You and Kurt each have twice given general advice that Idle should be 
kept 'simple' and not have 'advanced' features added.  But I have 
trouble turning that general advice into concrete decision making.  Are 
there any enhancement requests on the tracker you would reject as too 
complex or advanced?  (To make checking easy, I can send or post a 
complete, categorized list.)

A couple of the features at the end of Al's list strike me as the sort 
of things you are saying not to do in the advice above.  Do you agree?

In particular, consider post-installation switchable multiple language 
support. That would, in general, be of most benefit to the youngest 
beginners.  It is also a rare and rather advanced feature, and complex 
not only in terms of the programming, but in the need for coordination 
with an internationalization group separate from Idle maintainers 
themselves.  Should we avoid competing with more advanced programs and 
leave this out?

 > , nor with the Emacs/Vim world (and I consider most every text editor 
 > professional coders like to use these days on Linux/Mac/Windows to be 
 > in that world, from Sublime Text to Atom).

Notepad++ had been recommend as a multiple (50) programming language 
editor for Windows on python-list.  I have also seen it mentioned on 
Stackoverflow.

 > IDLE's one redeeming feature is that it's bundled with Python,

As installed, Idle
1. Colorizes Python code
2. Converts \t to '    '
3. Saves in utf-8 (3.x)
4. Checks syntax before running and marks the location of error in the 
editor
5. Runs the file in -i mode
6. Displays tracebacks and print output in a window with normal cut and 
paste
7. and can jump to the error line of any file in tracebacks
8. ...

As installed, Notepad++ does 1.  With some searching through the 
extensive settings menus, one of which is not obvious, it can do 2, 3, 
and 5. By running in Idle or another external, installed program instead 
of command prompt, it can get 6.  As far as I know, it can never do 4, 
or 7 in the sense of jumping back to Notepad++.  With respect to this 7 
points, Idle is the better choice for developing Idle programs.

I presume that some of the other programs you mention match Idle in 
features 4 and 7, which I find *very* useful. But I think you have an 
overly narrow view of the virtues of the program you help create ;-).

And to repeat, Idle makes the interactive mode of Python, as installed, 
a joy rather than barely tolerable. If it were removed, another 
replacement for command prompt should be found.

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Thu Aug  6 04:01:08 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 5 Aug 2015 22:01:08 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
Message-ID: <mpuf58$vbg$2@ger.gmane.org>

On 8/4/2015 5:40 PM, Mark Roseman wrote:
>> Hi, this is Al. I haven't had much time to work on IDLE Reimagined in
>> recent months, but I'd like to get back on it in a couple weeks.
>> Mostly I've been following a rabbit hole of:
>>
>> * I need to make this project approachable for new contributors...
>> * So I want to document the code...
>> * But first I should refactor it to simplify it...
>> * But first I should make the unit tests complete to avoid breaking
>> anything...
>> * But first I need to learn tkinter for the gui tests...
>>
>> etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool
>> that is bundled with Python.
>
>
> Hi Al,
>
> That is awesome! Let?s make sure we don?t duplicate effort, particularly
> in the ?prep? work to improve/simplify the current code.
>
> As someone who is very familiar with Tk (see. http://www.tkdocs.com),
> I?ve been working the last week or so at updating the current
> appearance, and subsequently expect to simplify lots of the underlying
> code. As I?ve been working with it, I see lots of great opportunities to
> make it easier for people to modify it.
>
> One big issue that Terry is presently working hard to sort through (see
> http://bugs.python.org/issue24759) is the ?backwards compatibility?
> aspect, which from my current reading suggests we?d be stuck with both
> ?old? and ?new? UI code side-by-side until Python 3.6.  That makes the
> maintenance and modification more difficult of course. I?m still trying
> to get my head fully around all the implications.
>
> Some of the structural aspects (refactoring, reorganizing dialogs, etc.)
> could be addressed to simplify the code before an option to use ttk
> widgets is added. But, as Terry points out, if there are people out
> there using *pieces* from idlelib, doing too much in the way of
> structural changes could mess things up for them.  So significant
> structural changes to the current code base seem out.
>
> Instead, new UI code (based more on ttk) would go in brand new files,
> not having any backwards compatibility constraint. Those ones can be
> reorganized/restructured to everyone?s heart?s content, may not even
> resemble corresponding parts of the existing code, and could serve as a
> great base for more significant changes that might better facilitate its
> use for learners.
>
> So it?s almost like we have a fork and an original sitting side-by-side
> in stdlib until at least 3.6. How do we decide which to use?
>
> - programs using pieces of idlelib, and people with Tk 8.4:
> - they run the code as it exists now (current UI, current structure)
>
> - for people running IDLE (as a whole) and having Tk 8.5+:
> - for now, by default, they get the old code (current UI, current structure)

Nick suggests making the new code the default, at least for 3.5.1.  He 
posted the following (and a bit more) to issue 24759.

"For 3.5.1+, I think there's no question that we want to show IDLE in 
the best possible light, and we want to try to do that by default. That 
means modernising it to use the best cross-platform features that Tcl/Tk 
has to offer (including ttk)."

We can make the final decision for each version just before the 
corresponding release by how we set use_ttk in config_main.def. Before 
that, I will have it on to test the new code. Before releases, we should 
ask others who can build python to also test. I also hope we can add 
additional unittests for the modules affected.

> - if they want, they can flip an ?experimental? switch to try the new
> code (improved UI, improved structure)

> - at some point in the future (when the new stuff is stable enough), we
> change things so they get the new code by default
>
> The old code gets marked as deprecated, with plans to remove it
> altogether at some point in the future.
>
> Two things I would be fairly nervous to see happening:
> - requests for (non-trivial) UI improvements (which will be in the ?new
> UI? code) to be ?ported? to the existing code (which can?t have major
> structural changes).

Once there is a ttk version of the file, I intend to generally leave the 
old versions alone. They are being kept for back-compatibility. That is 
why I asked to you for a 're-arrangement' patch before the ttk 
conversion patch for your configuration tab makeovers.  The only tab 
with overt bugs is the Keys tab.  If we can fix some of them before 
conversion, that would be nice, but it is not a blocker.  Ditto for 
enhancements to the extension configuration.

Once there are parallel files, the default answer to trans-port requests 
with be 'No'.

> - the new UI code having to support both Tk 8.4 (which doesn?t have ttk)
> and Tk 8.5+

Will not be done. For 3.6, Ned hopes to only compile for 8.6.  I presume 
that means 3.5 will be the last version supported for OS 10.5.

-- 
Terry Jan Reedy



From guido at python.org  Thu Aug  6 11:02:07 2015
From: guido at python.org (Guido van Rossum)
Date: Thu, 6 Aug 2015 11:02:07 +0200
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <mptv93$nbm$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
 <mptv93$nbm$1@ger.gmane.org>
Message-ID: <CAP7+vJJDM3HiLGw+QBS=_NN1SU=XD6fA6VfKkM9WQy0JEsJ1Rw@mail.gmail.com>

I am not interested in this discussion. You all can do what you want.

On Wed, Aug 5, 2015 at 11:30 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 8/5/2015 5:55 AM, Guido van Rossum wrote:
>
>> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu
>> <mailto:tjreedy at udel.edu>> wrote:
>>
>>     As a user of Idle for several years, and not a beginner, I disagree
>>     with 'only'.  That aside, I consider it unnecessary and diversionary
>>     from the numerous known issues that will benefit *everyone*.
>>
>
> The core of this comment is "unnecessary and diversionary ...".
>
> As for 'unnecessary', what does adding 'only' add to the discussion? Does
> that mean that we should reject features that also benefit non-beginners?
> If not, what does it mean?  What extra design guidance does it add?
>
> As for 'divisionary', see, besides the above, my questions that follow the
> 'PyCharm' quote.
>
> Please note that I volunteer my time to improve Idle *because* it is
> primarily used by students and secondarily, perhaps, by others who are not
> professional programmers.
>
> I was worried that you'd respond like this. *No* change to IDLE will
>> benefit *everyone*,
>>
>
> Please give me the benefit of the doubt and assume that I am saying
> something sensible. By 'everyone', I mean "everyone who uses Idle" and in
> relation to a particular issue, 'everyone who use the feature in question'
> and in relation of OS-specific issues, 'everyone using that OS'.  With
> those meanings, my statement is reasonably true.
>
> > for the simple reason that few people outside the
> > (non-higher) educational field use it.
>
> Bruce already covered colleges.
>
> There are also post-beginners, but not professional programmers, like my
> daughter, who are so far happy with Idle and do not yet need the advanced
> features of other Python shells.
>
> And there are Windows users.  Windows Command Prompt is awful. Interactive
> Python in Command Prompt suffers its sins. I believe most Windows users who
> try Idle Shell find it to be a better experience. One of the other core
> devs once (blushingly) admitted on pydev to using Shell on Windows for this
> reason.
>
> > IDLE should not try to compete with things like PyCharm ...
>
> What does this mean in terms of Idle design decisions?  Can you give me
> examples of what you think should not be added?
>
> You and Kurt each have twice given general advice that Idle should be kept
> 'simple' and not have 'advanced' features added.  But I have trouble
> turning that general advice into concrete decision making.  Are there any
> enhancement requests on the tracker you would reject as too complex or
> advanced?  (To make checking easy, I can send or post a complete,
> categorized list.)
>
> A couple of the features at the end of Al's list strike me as the sort of
> things you are saying not to do in the advice above.  Do you agree?
>
> In particular, consider post-installation switchable multiple language
> support. That would, in general, be of most benefit to the youngest
> beginners.  It is also a rare and rather advanced feature, and complex not
> only in terms of the programming, but in the need for coordination with an
> internationalization group separate from Idle maintainers themselves.
> Should we avoid competing with more advanced programs and leave this out?
>
> > , nor with the Emacs/Vim world (and I consider most every text editor >
> professional coders like to use these days on Linux/Mac/Windows to be > in
> that world, from Sublime Text to Atom).
>
> Notepad++ had been recommend as a multiple (50) programming language
> editor for Windows on python-list.  I have also seen it mentioned on
> Stackoverflow.
>
> > IDLE's one redeeming feature is that it's bundled with Python,
>
> As installed, Idle
> 1. Colorizes Python code
> 2. Converts \t to '    '
> 3. Saves in utf-8 (3.x)
> 4. Checks syntax before running and marks the location of error in the
> editor
> 5. Runs the file in -i mode
> 6. Displays tracebacks and print output in a window with normal cut and
> paste
> 7. and can jump to the error line of any file in tracebacks
> 8. ...
>
> As installed, Notepad++ does 1.  With some searching through the extensive
> settings menus, one of which is not obvious, it can do 2, 3, and 5. By
> running in Idle or another external, installed program instead of command
> prompt, it can get 6.  As far as I know, it can never do 4, or 7 in the
> sense of jumping back to Notepad++.  With respect to this 7 points, Idle is
> the better choice for developing Idle programs.
>
> I presume that some of the other programs you mention match Idle in
> features 4 and 7, which I find *very* useful. But I think you have an
> overly narrow view of the virtues of the program you help create ;-).
>
> And to repeat, Idle makes the interactive mode of Python, as installed, a
> joy rather than barely tolerable. If it were removed, another replacement
> for command prompt should be found.
>
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150806/84bf6554/attachment.html>

From chris at codingclub.co.uk  Thu Aug  6 12:22:50 2015
From: chris at codingclub.co.uk (Chris Roffey)
Date: Thu, 6 Aug 2015 11:22:50 +0100
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAP7+vJJDM3HiLGw+QBS=_NN1SU=XD6fA6VfKkM9WQy0JEsJ1Rw@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
 <mptv93$nbm$1@ger.gmane.org>
 <CAP7+vJJDM3HiLGw+QBS=_NN1SU=XD6fA6VfKkM9WQy0JEsJ1Rw@mail.gmail.com>
Message-ID: <B8EAB6D5-0064-4116-9E0C-300B91C0DD69@codingclub.co.uk>

Oh dear,

I have been away for a day celebrating my Mum?s 60th anniversary and so not been able to contribute further. I have followed the discussions with interest and been very excited by them. The enthusiasm and hard work that has gone into making such a useful tool was refreshing and all open source. I was a little embarrassed to be someone suggesting things and yet not having the technical skills to help so ?listened? for a while.

There is so much enthusiasm for Python and Computer Science in UK schools that I think this is very important. I started bebras.uk <http://bebras.uk/> two years ago and we got 21,000 students in our first year, the next 40,000. Success of Computing in the UK is in no way certain as we are chronically short of trained teachers but there is still a momentum.

I personally feel there is no real conflict between the different views expressed in the last two days. I believe it would be fantastic if we can re-think how to make IDLE the most user friendly IDE for beginners and I would add some cosmetic differences (the ttk stuff looks like it would be a big help in improving the professional look). However I would not remove anything! I had in mind a ?Workspace? drop down menu where users call up different facilities. The basics being "script mode" (the shell) and ?script mode?. I would also add at least a ?Turtle" arrangement and a ?Professional? set-up. Would hope that if this is done well, fans of IDLE will be pleased, students and teachers would be pleased AND more professionals would stick with it too - everyone wants an IDE that does not distract from writing code and lets you get on with what you want intuitively. Kids want an IDE that they can grow with so providing pro-features that can be selected as their skills develop is ideal.

I have some of my own ideas that I have not presented here as I did not want to be too pushy having just joined this group, and as I said I probably do not have the skill to help out. However, I originally was not able to go to PyCon UK this year (in September) but with some encouragement from you guys will try and cadge a late ticket and see if I can drum up some feedback, support, talent and possibly even money if it is required. PyCon UK has a dedicated Education track which this year is being run by the Raspberry Pi foundation. They and ARM sponsor the Bebras comp which I run (now in partnership with Oxford Uni). I am name dropping to show there are some potential powerful advocates with many skills in the UK. I also have friendly contacts in Microsoft and Google. All these people and organisations want to make sure the UK and ultimately the rest of the world have a fantastic CS programme with the best of tools. They are also great fans of Python 3 as an education tool.

I am off on holiday for a week today but will continue to watch my emails and try to formulate some ideas I am comfortable to share.

Best wishes
Chris

> On 6 Aug 2015, at 10:02, Guido van Rossum <guido at python.org> wrote:
> 
> I am not interested in this discussion. You all can do what you want.
> 
> On Wed, Aug 5, 2015 at 11:30 PM, Terry Reedy <tjreedy at udel.edu <mailto:tjreedy at udel.edu>> wrote:
> On 8/5/2015 5:55 AM, Guido van Rossum wrote:
> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu <mailto:tjreedy at udel.edu>
> <mailto:tjreedy at udel.edu <mailto:tjreedy at udel.edu>>> wrote:
> 
>     As a user of Idle for several years, and not a beginner, I disagree
>     with 'only'.  That aside, I consider it unnecessary and diversionary
>     from the numerous known issues that will benefit *everyone*.
> 
> The core of this comment is "unnecessary and diversionary ...".
> 
> As for 'unnecessary', what does adding 'only' add to the discussion? Does that mean that we should reject features that also benefit non-beginners? If not, what does it mean?  What extra design guidance does it add?
> 
> As for 'divisionary', see, besides the above, my questions that follow the 'PyCharm' quote.
> 
> Please note that I volunteer my time to improve Idle *because* it is primarily used by students and secondarily, perhaps, by others who are not professional programmers.
> 
> I was worried that you'd respond like this. *No* change to IDLE will
> benefit *everyone*,
> 
> Please give me the benefit of the doubt and assume that I am saying something sensible. By 'everyone', I mean "everyone who uses Idle" and in relation to a particular issue, 'everyone who use the feature in question' and in relation of OS-specific issues, 'everyone using that OS'.  With those meanings, my statement is reasonably true.
> 
> > for the simple reason that few people outside the
> > (non-higher) educational field use it.
> 
> Bruce already covered colleges.
> 
> There are also post-beginners, but not professional programmers, like my daughter, who are so far happy with Idle and do not yet need the advanced features of other Python shells.
> 
> And there are Windows users.  Windows Command Prompt is awful. Interactive Python in Command Prompt suffers its sins. I believe most Windows users who try Idle Shell find it to be a better experience. One of the other core devs once (blushingly) admitted on pydev to using Shell on Windows for this reason.
> 
> > IDLE should not try to compete with things like PyCharm ...
> 
> What does this mean in terms of Idle design decisions?  Can you give me examples of what you think should not be added?
> 
> You and Kurt each have twice given general advice that Idle should be kept 'simple' and not have 'advanced' features added.  But I have trouble turning that general advice into concrete decision making.  Are there any enhancement requests on the tracker you would reject as too complex or advanced?  (To make checking easy, I can send or post a complete, categorized list.)
> 
> A couple of the features at the end of Al's list strike me as the sort of things you are saying not to do in the advice above.  Do you agree?
> 
> In particular, consider post-installation switchable multiple language support. That would, in general, be of most benefit to the youngest beginners.  It is also a rare and rather advanced feature, and complex not only in terms of the programming, but in the need for coordination with an internationalization group separate from Idle maintainers themselves.  Should we avoid competing with more advanced programs and leave this out?
> 
> > , nor with the Emacs/Vim world (and I consider most every text editor > professional coders like to use these days on Linux/Mac/Windows to be > in that world, from Sublime Text to Atom).
> 
> Notepad++ had been recommend as a multiple (50) programming language editor for Windows on python-list.  I have also seen it mentioned on Stackoverflow.
> 
> > IDLE's one redeeming feature is that it's bundled with Python,
> 
> As installed, Idle
> 1. Colorizes Python code
> 2. Converts \t to '    '
> 3. Saves in utf-8 (3.x)
> 4. Checks syntax before running and marks the location of error in the editor
> 5. Runs the file in -i mode
> 6. Displays tracebacks and print output in a window with normal cut and paste
> 7. and can jump to the error line of any file in tracebacks
> 8. ...
> 
> As installed, Notepad++ does 1.  With some searching through the extensive settings menus, one of which is not obvious, it can do 2, 3, and 5. By running in Idle or another external, installed program instead of command prompt, it can get 6.  As far as I know, it can never do 4, or 7 in the sense of jumping back to Notepad++.  With respect to this 7 points, Idle is the better choice for developing Idle programs.
> 
> I presume that some of the other programs you mention match Idle in features 4 and 7, which I find *very* useful. But I think you have an overly narrow view of the virtues of the program you help create ;-).
> 
> And to repeat, Idle makes the interactive mode of Python, as installed, a joy rather than barely tolerable. If it were removed, another replacement for command prompt should be found.
> 
> 
> -- 
> Terry Jan Reedy
> 
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org <mailto:IDLE-dev at python.org>
> https://mail.python.org/mailman/listinfo/idle-dev <https://mail.python.org/mailman/listinfo/idle-dev>
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150806/dce16f53/attachment.html>

From al at inventwithpython.com  Thu Aug  6 18:34:43 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Thu, 6 Aug 2015 09:34:43 -0700
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <B8EAB6D5-0064-4116-9E0C-300B91C0DD69@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <CAP7+vJJPCKK=8c6yFL5nVoUQfMsSSYBVj8tSwhBYNWrCwfK+Jg@mail.gmail.com>
 <mptv93$nbm$1@ger.gmane.org>
 <CAP7+vJJDM3HiLGw+QBS=_NN1SU=XD6fA6VfKkM9WQy0JEsJ1Rw@mail.gmail.com>
 <B8EAB6D5-0064-4116-9E0C-300B91C0DD69@codingclub.co.uk>
Message-ID: <CAM=hmROhBr3JJRHfRUycSME_gYZXPRn8VM1D-2hSmLdo=zuOTQ@mail.gmail.com>

I also don't really see a conflict here. Nobody is advocating for the
removal of the interactive shell. In the single-window design I have on the
IR wiki, the shell is on the bottom just so that it is always visible
(though the pane can be resized to take up more of the window when needed.)
One very common problem that I get from readers is that they enter code
into the shell instead of the file editor, or vice versa. Since the
interactive shell looks so similar to the file editor, having it always be
on the bottom gives an obvious spatial cue, rather than looking for the
(much smaller) >>> prompt.

Chris, the good things about IDLE is that 1) it is bundled with Python, 2)
doesn't require configuration (good for classrooms), and 3) is simple.
Adding script mode/shell mode/turtle mode/professional mode would be a lot
of work and also add to the complexity. We don't want to compete with
PyCharm and other professional IDEs, and folks can move on to those IDEs
after they get some experience.

Turtle mode doesn't require it's own dedicated mode either; it runs pretty
well from the interactive shell in IDLE right now. What were your ui design
ideas for a turtle arrangement?

-Al

On Thu, Aug 6, 2015 at 3:22 AM, Chris Roffey <chris at codingclub.co.uk> wrote:

> Oh dear,
>
> I have been away for a day celebrating my Mum?s 60th anniversary and so
> not been able to contribute further. I have followed the discussions with
> interest and been very excited by them. The enthusiasm and hard work that
> has gone into making such a useful tool was refreshing and all open source.
> I was a little embarrassed to be someone suggesting things and yet not
> having the technical skills to help so ?listened? for a while.
>
> There is so much enthusiasm for Python and Computer Science in UK schools
> that I think this is very important. I started bebras.uk two years ago
> and we got 21,000 students in our first year, the next 40,000. Success of
> Computing in the UK is in no way certain as we are chronically short of
> trained teachers but there is still a momentum.
>
> I personally feel there is no real conflict between the different views
> expressed in the last two days. I believe it would be fantastic if we can
> re-think how to make IDLE the most user friendly IDE for beginners and I
> would add some cosmetic differences (the ttk stuff looks like it would be a
> big help in improving the professional look). However I would not remove
> anything! I had in mind a ?Workspace? drop down menu where users call up
> different facilities. The basics being "script mode" (the shell) and
> ?script mode?. I would also add at least a ?Turtle" arrangement and a
> ?Professional? set-up. Would hope that if this is done well, fans of IDLE
> will be pleased, students and teachers would be pleased AND more
> professionals would stick with it too - everyone wants an IDE that does not
> distract from writing code and lets you get on with what you want
> intuitively. Kids want an IDE that they can grow with so providing
> pro-features that can be selected as their skills develop is ideal.
>
> I have some of my own ideas that I have not presented here as I did not
> want to be too pushy having just joined this group, and as I said I
> probably do not have the skill to help out. However, I originally was not
> able to go to PyCon UK this year (in September) but with some encouragement
> from you guys will try and cadge a late ticket and see if I can drum up
> some feedback, support, talent and possibly even money if it is required.
> PyCon UK has a dedicated Education track which this year is being run by
> the Raspberry Pi foundation. They and ARM sponsor the Bebras comp which I
> run (now in partnership with Oxford Uni). I am name dropping to show there
> are some potential powerful advocates with many skills in the UK. I also
> have friendly contacts in Microsoft and Google. All these people and
> organisations want to make sure the UK and ultimately the rest of the world
> have a fantastic CS programme with the best of tools. They are also great
> fans of Python 3 as an education tool.
>
> I am off on holiday for a week today but will continue to watch my emails
> and try to formulate some ideas I am comfortable to share.
>
> Best wishes
> Chris
>
> On 6 Aug 2015, at 10:02, Guido van Rossum <guido at python.org> wrote:
>
> I am not interested in this discussion. You all can do what you want.
>
> On Wed, Aug 5, 2015 at 11:30 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> On 8/5/2015 5:55 AM, Guido van Rossum wrote:
>>
>>> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu
>>> <mailto:tjreedy at udel.edu>> wrote:
>>>
>>>     As a user of Idle for several years, and not a beginner, I disagree
>>>     with 'only'.  That aside, I consider it unnecessary and diversionary
>>>     from the numerous known issues that will benefit *everyone*.
>>>
>>
>> The core of this comment is "unnecessary and diversionary ...".
>>
>> As for 'unnecessary', what does adding 'only' add to the discussion? Does
>> that mean that we should reject features that also benefit non-beginners?
>> If not, what does it mean?  What extra design guidance does it add?
>>
>> As for 'divisionary', see, besides the above, my questions that follow
>> the 'PyCharm' quote.
>>
>> Please note that I volunteer my time to improve Idle *because* it is
>> primarily used by students and secondarily, perhaps, by others who are not
>> professional programmers.
>>
>> I was worried that you'd respond like this. *No* change to IDLE will
>>> benefit *everyone*,
>>>
>>
>> Please give me the benefit of the doubt and assume that I am saying
>> something sensible. By 'everyone', I mean "everyone who uses Idle" and in
>> relation to a particular issue, 'everyone who use the feature in question'
>> and in relation of OS-specific issues, 'everyone using that OS'.  With
>> those meanings, my statement is reasonably true.
>>
>> > for the simple reason that few people outside the
>> > (non-higher) educational field use it.
>>
>> Bruce already covered colleges.
>>
>> There are also post-beginners, but not professional programmers, like my
>> daughter, who are so far happy with Idle and do not yet need the advanced
>> features of other Python shells.
>>
>> And there are Windows users.  Windows Command Prompt is awful.
>> Interactive Python in Command Prompt suffers its sins. I believe most
>> Windows users who try Idle Shell find it to be a better experience. One of
>> the other core devs once (blushingly) admitted on pydev to using Shell on
>> Windows for this reason.
>>
>> > IDLE should not try to compete with things like PyCharm ...
>>
>> What does this mean in terms of Idle design decisions?  Can you give me
>> examples of what you think should not be added?
>>
>> You and Kurt each have twice given general advice that Idle should be
>> kept 'simple' and not have 'advanced' features added.  But I have trouble
>> turning that general advice into concrete decision making.  Are there any
>> enhancement requests on the tracker you would reject as too complex or
>> advanced?  (To make checking easy, I can send or post a complete,
>> categorized list.)
>>
>> A couple of the features at the end of Al's list strike me as the sort of
>> things you are saying not to do in the advice above.  Do you agree?
>>
>> In particular, consider post-installation switchable multiple language
>> support. That would, in general, be of most benefit to the youngest
>> beginners.  It is also a rare and rather advanced feature, and complex not
>> only in terms of the programming, but in the need for coordination with an
>> internationalization group separate from Idle maintainers themselves.
>> Should we avoid competing with more advanced programs and leave this out?
>>
>> > , nor with the Emacs/Vim world (and I consider most every text editor >
>> professional coders like to use these days on Linux/Mac/Windows to be > in
>> that world, from Sublime Text to Atom).
>>
>> Notepad++ had been recommend as a multiple (50) programming language
>> editor for Windows on python-list.  I have also seen it mentioned on
>> Stackoverflow.
>>
>> > IDLE's one redeeming feature is that it's bundled with Python,
>>
>> As installed, Idle
>> 1. Colorizes Python code
>> 2. Converts \t to '    '
>> 3. Saves in utf-8 (3.x)
>> 4. Checks syntax before running and marks the location of error in the
>> editor
>> 5. Runs the file in -i mode
>> 6. Displays tracebacks and print output in a window with normal cut and
>> paste
>> 7. and can jump to the error line of any file in tracebacks
>> 8. ...
>>
>> As installed, Notepad++ does 1.  With some searching through the
>> extensive settings menus, one of which is not obvious, it can do 2, 3, and
>> 5. By running in Idle or another external, installed program instead of
>> command prompt, it can get 6.  As far as I know, it can never do 4, or 7 in
>> the sense of jumping back to Notepad++.  With respect to this 7 points,
>> Idle is the better choice for developing Idle programs.
>>
>> I presume that some of the other programs you mention match Idle in
>> features 4 and 7, which I find *very* useful. But I think you have an
>> overly narrow view of the virtues of the program you help create ;-).
>>
>> And to repeat, Idle makes the interactive mode of Python, as installed, a
>> joy rather than barely tolerable. If it were removed, another replacement
>> for command prompt should be found.
>>
>>
>> --
>> Terry Jan Reedy
>>
>>
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150806/642993dc/attachment-0001.html>

From chris at codingclub.co.uk  Fri Aug  7 00:35:25 2015
From: chris at codingclub.co.uk (Chris Roffey)
Date: Thu, 6 Aug 2015 23:35:25 +0100
Subject: [Idle-dev] IDLE in UK Schools
Message-ID: <F871A0DB-785A-496B-987C-C60B30EBA6A7@codingclub.co.uk>

Hi Al

The kind of thing I am looking for is a combination of what is great in IDLE plus adapted good ideas from such educational sites as Greenfoot, Scratch, etc.

I do not get so much of the mix up with shell and script from my readers. Possibly because we start only working in the Shell which we call ?Interactive Mode? and then move on to "Script mode" with regular ?Interactive sessions? to try out snippets of code or do little experiments with new functions to see how they work - another fantastic feature of Python and IDLE - straight out of the box!

The sort of direction I would like to see IDLE developing would be that it opens by default into a simple shell but with the ability to turn on a few other panels that stick to each other while being resizable by dragging the margins. (This stops students losing windows.)
e.g. http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-shell.png <http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-shell.png>
In addition to the documentation and suggestions functionality it would also be great if mispelt words (i.e those that have not been declared or are not in the python library) are underlined with squiggly red lines, like in word processors before code is run.

The turtle module is fantastic for education, especially since you can mix turtle graphics with the power of Python seamlessly! The only issue as far as I am concerned is again windows disappearing behind each other. An interface which controls this might look something like this:
http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-turtle.png <http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-turtle.png>

Finally script mode by default (i.e. File, New script) would appear with three panels: tabbed scripts, output section and a Console (shell) at the bottom. However other panels could be added by ticking them to show in the Workspace (or View if preferred) menu looking something like this:
http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-tkinter.png <http://codingclub.co.uk/IDLE4Ed/IDLE4Ed-tkinter.png>

These last two examples show how mixing the best of IDLE and a simplified Frames model can come up trumps. I believe having tried the Greenfoot tutorial that the interface takes a lot of teaching whereas my suggestion I believe is intuitive. It gets rid of the problems I see kids have by messing up the number of spaces/tabs needed when indenting and negates the need for indent, dedent and code out functions currently in IDLE. Instead students press a colon and the current frame extends and adds a blank new one within it. Other frames can be dragged into any other frame with automatic indenting.
There should of course be a save as text facility for backward compatibility as much as anything else. Oh I would also have show/hide number lines as options. Sometimes they are helpful to a teacher - others not so.

Although a huge amount of work, I believe (but I am open to correction here) that the auto-correct, the suggestions, the documentation and the languages could all be added with ?alias libraries?. In fact, would it not be possible to have all of Python?s key words (32 isn?t it?) run in the background but have any number of language aliases for display?

Instead of being modest this time, I have suggested most of what I would like to see so that others can feel free to knock them down or, perhaps be inspired to think of new and better ideas.

I would also take on board on all of your suggestions except the tutorial mode as I see this as digressing from the core value of providing a great IDE focussed on writing code.

What do you think?

Best wishes
Chris

> I also don't really see a conflict here. Nobody is advocating for the removal of the interactive shell. In the single-window design I have on the IR wiki, the shell is on the bottom just so that it is always visible (though the pane can be resized to take up more of the window when needed.) One very common problem that I get from readers is that they enter code into the shell instead of the file editor, or vice versa. Since the interactive shell looks so similar to the file editor, having it always be on the bottom gives an obvious spatial cue, rather than looking for the (much smaller) >>> prompt.
> 
> Chris, the good things about IDLE is that 1) it is bundled with Python, 2) doesn't require configuration (good for classrooms), and 3) is simple. Adding script mode/shell mode/turtle mode/professional mode would be a lot of work and also add to the complexity. We don't want to compete with PyCharm and other professional IDEs, and folks can move on to those IDEs after they get some experience.
> 
> Turtle mode doesn't require it's own dedicated mode either; it runs pretty well from the interactive shell in IDLE right now. What were your ui design ideas for a turtle arrangement?
> 
> -Al
> 
> On Thu, Aug 6, 2015 at 3:22 AM, Chris Roffey <chris at codingclub.co.uk <mailto:chris at codingclub.co.uk>> wrote:
> Oh dear,
> 
> I have been away for a day celebrating my Mum?s 60th anniversary and so not been able to contribute further. I have followed the discussions with interest and been very excited by them. The enthusiasm and hard work that has gone into making such a useful tool was refreshing and all open source. I was a little embarrassed to be someone suggesting things and yet not having the technical skills to help so ?listened? for a while.
> 
> There is so much enthusiasm for Python and Computer Science in UK schools that I think this is very important. I started bebras.uk <http://bebras.uk/> two years ago and we got 21,000 students in our first year, the next 40,000. Success of Computing in the UK is in no way certain as we are chronically short of trained teachers but there is still a momentum.
> 
> I personally feel there is no real conflict between the different views expressed in the last two days. I believe it would be fantastic if we can re-think how to make IDLE the most user friendly IDE for beginners and I would add some cosmetic differences (the ttk stuff looks like it would be a big help in improving the professional look). However I would not remove anything! I had in mind a ?Workspace? drop down menu where users call up different facilities. The basics being "script mode" (the shell) and ?script mode?. I would also add at least a ?Turtle" arrangement and a ?Professional? set-up. Would hope that if this is done well, fans of IDLE will be pleased, students and teachers would be pleased AND more professionals would stick with it too - everyone wants an IDE that does not distract from writing code and lets you get on with what you want intuitively. Kids want an IDE that they can grow with so providing pro-features that can be selected as their skills develop is ideal.
> 
> I have some of my own ideas that I have not presented here as I did not want to be too pushy having just joined this group, and as I said I probably do not have the skill to help out. However, I originally was not able to go to PyCon UK this year (in September) but with some encouragement from you guys will try and cadge a late ticket and see if I can drum up some feedback, support, talent and possibly even money if it is required. PyCon UK has a dedicated Education track which this year is being run by the Raspberry Pi foundation. They and ARM sponsor the Bebras comp which I run (now in partnership with Oxford Uni). I am name dropping to show there are some potential powerful advocates with many skills in the UK. I also have friendly contacts in Microsoft and Google. All these people and organisations want to make sure the UK and ultimately the rest of the world have a fantastic CS programme with the best of tools. They are also great fans of Python 3 as an education tool.
> 
> I am off on holiday for a week today but will continue to watch my emails and try to formulate some ideas I am comfortable to share.
> 
> Best wishes
> Chris
> 
>> On 6 Aug 2015, at 10:02, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
>> 
>> I am not interested in this discussion. You all can do what you want.
>> 
>> On Wed, Aug 5, 2015 at 11:30 PM, Terry Reedy <tjreedy at udel.edu <mailto:tjreedy at udel.edu>> wrote:
>> On 8/5/2015 5:55 AM, Guido van Rossum wrote:
>> On Wed, Aug 5, 2015 at 4:43 AM, Terry Reedy <tjreedy at udel.edu <mailto:tjreedy at udel.edu>
>> <mailto:tjreedy at udel.edu <mailto:tjreedy at udel.edu>>> wrote:
>> 
>>     As a user of Idle for several years, and not a beginner, I disagree
>>     with 'only'.  That aside, I consider it unnecessary and diversionary
>>     from the numerous known issues that will benefit *everyone*.
>> 
>> The core of this comment is "unnecessary and diversionary ...".
>> 
>> As for 'unnecessary', what does adding 'only' add to the discussion? Does that mean that we should reject features that also benefit non-beginners? If not, what does it mean?  What extra design guidance does it add?
>> 
>> As for 'divisionary', see, besides the above, my questions that follow the 'PyCharm' quote.
>> 
>> Please note that I volunteer my time to improve Idle *because* it is primarily used by students and secondarily, perhaps, by others who are not professional programmers.
>> 
>> I was worried that you'd respond like this. *No* change to IDLE will
>> benefit *everyone*,
>> 
>> Please give me the benefit of the doubt and assume that I am saying something sensible. By 'everyone', I mean "everyone who uses Idle" and in relation to a particular issue, 'everyone who use the feature in question' and in relation of OS-specific issues, 'everyone using that OS'.  With those meanings, my statement is reasonably true.
>> 
>> > for the simple reason that few people outside the
>> > (non-higher) educational field use it.
>> 
>> Bruce already covered colleges.
>> 
>> There are also post-beginners, but not professional programmers, like my daughter, who are so far happy with Idle and do not yet need the advanced features of other Python shells.
>> 
>> And there are Windows users.  Windows Command Prompt is awful. Interactive Python in Command Prompt suffers its sins. I believe most Windows users who try Idle Shell find it to be a better experience. One of the other core devs once (blushingly) admitted on pydev to using Shell on Windows for this reason.
>> 
>> > IDLE should not try to compete with things like PyCharm ...
>> 
>> What does this mean in terms of Idle design decisions?  Can you give me examples of what you think should not be added?
>> 
>> You and Kurt each have twice given general advice that Idle should be kept 'simple' and not have 'advanced' features added.  But I have trouble turning that general advice into concrete decision making.  Are there any enhancement requests on the tracker you would reject as too complex or advanced?  (To make checking easy, I can send or post a complete, categorized list.)
>> 
>> A couple of the features at the end of Al's list strike me as the sort of things you are saying not to do in the advice above.  Do you agree?
>> 
>> In particular, consider post-installation switchable multiple language support. That would, in general, be of most benefit to the youngest beginners.  It is also a rare and rather advanced feature, and complex not only in terms of the programming, but in the need for coordination with an internationalization group separate from Idle maintainers themselves.  Should we avoid competing with more advanced programs and leave this out?
>> 
>> > , nor with the Emacs/Vim world (and I consider most every text editor > professional coders like to use these days on Linux/Mac/Windows to be > in that world, from Sublime Text to Atom).
>> 
>> Notepad++ had been recommend as a multiple (50) programming language editor for Windows on python-list.  I have also seen it mentioned on Stackoverflow.
>> 
>> > IDLE's one redeeming feature is that it's bundled with Python,
>> 
>> As installed, Idle
>> 1. Colorizes Python code
>> 2. Converts \t to '    '
>> 3. Saves in utf-8 (3.x)
>> 4. Checks syntax before running and marks the location of error in the editor
>> 5. Runs the file in -i mode
>> 6. Displays tracebacks and print output in a window with normal cut and paste
>> 7. and can jump to the error line of any file in tracebacks
>> 8. ...
>> 
>> As installed, Notepad++ does 1.  With some searching through the extensive settings menus, one of which is not obvious, it can do 2, 3, and 5. By running in Idle or another external, installed program instead of command prompt, it can get 6.  As far as I know, it can never do 4, or 7 in the sense of jumping back to Notepad++.  With respect to this 7 points, Idle is the better choice for developing Idle programs.
>> 
>> I presume that some of the other programs you mention match Idle in features 4 and 7, which I find *very* useful. But I think you have an overly narrow view of the virtues of the program you help create ;-).
>> 
>> And to repeat, Idle makes the interactive mode of Python, as installed, a joy rather than barely tolerable. If it were removed, another replacement for command prompt should be found.
>> 
>> 
>> -- 
>> Terry Jan Reedy
>> 
>> 
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org <mailto:IDLE-dev at python.org>
>> https://mail.python.org/mailman/listinfo/idle-dev <https://mail.python.org/mailman/listinfo/idle-dev>
>> 
>> 
>> 
>> -- 
>> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org <mailto:IDLE-dev at python.org>
>> https://mail.python.org/mailman/listinfo/idle-dev <https://mail.python.org/mailman/listinfo/idle-dev>
> 
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org <mailto:IDLE-dev at python.org>
> https://mail.python.org/mailman/listinfo/idle-dev <https://mail.python.org/mailman/listinfo/idle-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150806/ac64d470/attachment-0001.html>

From tjreedy at udel.edu  Fri Aug  7 04:18:37 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 6 Aug 2015 22:18:37 -0400
Subject: [Idle-dev] Current Idle issues
Message-ID: <mq14i2$1hi$1@ger.gmane.org>

A year or two ago, a couple of people announced a plan for a database of 
Idle issues on a public site.  I don't remember anything about it later. 
  Last year, I finally 'bit the bullet' and created the following so I 
could close duplicates, add myself as nosy to existing issues, and get 
an overview of what needs to be done.  Perhaps this will help others, 
but excuse the sloppiness of notes meant to be private.  If it is 
helpful, I can repost occasionally when significantly changes.  I am 
hoping it will shrink, though I plan to convert some of the xxxxx 
entries to real tracker entries.
----------------------------------------------

A listing of Idle tracker issues, 2015 Aug 6.  Most items are listed
under a menu (or configure tab) item, actual or proposed.  A few are
listed under idlelib or test.

* issue has patch to review.
# I uploaded patch to finish and commit.

IDLELIB

13504 meta-issue (check that each item is a separate issue, and close)
10079 meta-issue? Polo gsoc enhancements
24225 mass file rename (Swiegart), thoughts added, patch rejected
24671 finish 2.7 print conversion
24039 min max and modal dialogs, mostly search
24760 Dialogs (config to start) modal?
24759 Add ttk as option
17397 tkinter.ttk list of theme names
15313 Remove bare excepts
18152 Document 2.7 backport issues
17776 Internationalization, i18n, foreign language
xxxxx SCriptBinding, ln 93, 2.7 r'\r' versus '\r'
xxxxx Modernize, refactor, text subdir?

File

-File Reload (proposed)
1721083

-Class Browser
20827 Display function arguments
1612262 Show nested classes
6171  TreeWidget draw, repeated selections (Ubuntu, ood?) good idea anyway?
xxxxx rename Class Browser as Module browser
       Make both scrollable, with wheel, like Win Explorer
       Reconsider if need both, and how should interact.
       Dont' cramp into tiny windows

-Path Browser

-Save
6699  Warn about overwriting newer version
15347 Debugger activation disrupts closing even after debugger closed 
(Debugger)
17822 Editor: Save on close dialog
11838 Shell code as runnable script
21140 Output Window should default to .txt
21152 Timed autosave
22897 Mac Save with non-ascii without encoding
23666 Saving/logging Shell (fix no Save on Close box)

-Save AS
15363 ~x.py fails and closes Idle (new patch, *nix review)
21603 Document extension hiding on Macs.
4832  (closed) Document automatic .py extension.

-Print Window
1528593 Print setup dialog

-Close
15347 Debugger activation disrupts closing even after debugger closed 
(Debugger)
20167 Exception on closing (fixed, root cause?)
14440 On *nix, close user process if Idle closes abnormally

-Reload proposed

Edit
13179 Separate tkinter vars for each editor window
18875 Auto close parens, etc (extension, default off)
17822 Editor: Save on close dialog
9262  Tabbed shell and edit windows
2053  Standardize dialogs, mostly editor
4630  Cursor noblink option
1207613 Horizontal scrollbar
6804  Detect Python file even if not .py (or force hilite).
24750 ttk scrollbars, tweak editor base window
##### On activation of Idle or window, detect disk changes, offer update.
nnnnn Detect file changed when window active, as with Notepad++, option 
relead.
xxxxx ping with 'xxxx\n, other real-time checks?

23672 Filename with non-BMP char stops Idle
21084 Handle astral chars better
22742 Print astral chars
13153 Fail pasting astral chars
14304 New 'codec' for astral chars


-Undo
23616 Undo active while code running, delete visible back to >>>

-Paste
2053  Should replace selection on *nix as elsewhere (optional)
24801 Mac and right-click not work

-Paste Code (proposed)
1178  remove >>> and ... (complements save without)

-Select All useful in shell?
-Select block (at least in Shell)
xxxxx  Select statement or output block

-Find
22179 Found text not highlighted on Windows
18590 Found text not highlighted on Windows within ''.
23216* Find, Grep, etc docstrings
23039 Dialog boxes maximize, don't minimize.  Make like config ext.
xxxxx Search/replace/ff not modal?
##### [close] at bottom?
eeeee Replace with Tal's SearchBar extension on PyPI

-Find in Files
14929 Improve file decoding before re.search
23218* Grep redesign
aaaaa underline file/line (see traceback)
----- Trying to find 'Tk(' does not work right
##### not disappear? do can re-search without re-entering same stuff.
##### find in open files, all files, from find dialog
##### autotag target as Found

-Replace
22460 Replace all in selection
13586 Replace selected not consistent with find (should grab selection).
18590# Found text not always highlighted by Replace dialog
xxxxx replacedialog.replace_all, chars not used (is in do replace)

-Show surrounding parens
21756 ParenMatch closer fails with multiline expresssions

-Show Calltip
16638 Multiline docstring sig (especially 2.7)
19903 Use inspect.signature
1350  Full docstring in new window
24028 Add calltip subsubsection
24570 Mac, 8.5.18-specific malfunction (completions also)
xxxxx Display sig on status line; access cursor in name? rt. click? ^\

-Show Completions
17238 Enhance import statement completion
18766 Complete for un-imported modules
13504 Complete dictionary keys
15786 Code completion problems with mouse
23961 Select from box with single tab
18903 File completions case sensitive, should not be on Windows
16198 Tabbing in string brings up completion, should not
22554 Popup window for names also

Shell (startup)
13582 pythonw.exe stderr/out problem
22133 Correct WM_CLASS on X11
22121 Start in HOME directory
16123 Deprecate -n no subprocess
18823 Pipes insteadof sockets
13262 Opens partly hidden
22893 Handling of __future__ in idle/pythonstartup
23546 Windows, 'Edit with Idle', and multiple versons
24212 idlelib.__main__ in 2.7
24265 Crash when start with -sc
xxxxx Add option to run module directly instead of loading in editor
       in order to get full BMP output.
aaaaa Catch all .idlerc/* TclErrors and continue?  Or command line 
option to ignore all?
 
https://stackoverflow.com/questions/28876035/cant-make-idle-working-on-mac
yyyyy Live doc mode for, eg, totorial.  Text in text color (yellow 
back?), fill in code,
       run, live output, live prompt, ... , blank display next text and 
code. .pyx?
       Needs to be separate from run shell.

-Restart Shell (shell itself)
3449  Pasted \n different from typed \n
3559  Entered \n versus pasted \n
7676  Stop using tabs
14326 Support locales/codecs
21937 Make title bar *-* mean 'unsaved'
5233  Exec PYTHON/IDLE/STARTUP each time
5594  Store startup code in user config.
13659 Help() viewer
19903 Console encoding
15809 Console encoding wrong for 2.7
2704  Make Shell more like terminal
1529353 Squeezer - large output in Shell
6143  Extension to clear shell
1442493 Slow when long lines
13657 Sys.ps1, ps2
19808 Response to input() should not be color coded
10909 Threads and prints hang shell
13220 Print disabled during multiprocessing
11820 os.system, multiprocessing output lost
aaaaa prompt to save or autosave on closing (see 21937)
xxxxx undo error and re-edit
xxxxx menu (pathbrowser) dead while program running, at least with input()
xxxxx trackback go/to only when can, Explanation for Traceback, >>>, 
XError (from howto)
       or click on uneditbale and display or goto and goto
xxxxx Tab in past area can open completion box.

-Tracebacks
24252 Traceback clipped.
24294 option to print deprecatin warnings from user code.filterwarnings 
or sys.warnoptions.
aaaaa underline file/line as link
nnnnn More info in traceback (optional?) such as locals
       https://github.com/asweigart/idle-reimagined/wiki/Better-Tracebacks

-Interrupt Execution
15308 ^C is shortcut, and others

Debug
Currently only for Shell.  Find is applicable to OutputWindow

-Debugger
17942 Improve gui
15335 Steps over Idle rpc code, but into Idle print code
22083 Refactor breakpoint methods
14111 Handle interrupts
15347 Debugger activation disrupts closing even after debugger closed 
(Close)
15348*Closing [x] while active freezes shell (Serwy x 2)
24455 Closing twice while running caused crash.
24090 Send name value, possible truncated, to clipboard
xxxxx Inspect attributes of global/local object, possible rt. click?
yyyyy Highlight in text disappear when lose focus?  Win only?de
zzzzz At each step, color changed values.

-Stack Viewer
23544 Freezes Idle when debug active. Ignore when code running.
24790 Improve in several ways

Format

-Tabify Region
16023 Freeze with OSX Cocoa Tk8.5

-Reindent (proposed)
5150  Access reindent.py

-Strip tailing whitespace
23667 on/off config, auto for .py,, delete trailing blanka also

Run

-Check Module
nnnnn Checking syntax should not shift focux to Shell.  Then no need for 
box.
       'Syntax Error' is useless.
xxxxx Check matching parentheses before compile, or with check mod?

-Run Module
21192 Add filename to Restart bar
5680* Add command line arguments for running script
19042 Option to Autosave Untitled to temp (--general)
23069 Run module should set imter compiler flags for interactive input
24718 Alternate interpreter ?

_Run in console (proposal, detached, output to console)
nnnnn run 'cmd python -m file' when cannot get same behavior in Idle
       kbhit https://stackoverflow.com/questions/26820251/
python-3-program-works-in-command-line-not-idle/26822944#26822944
       color 
https://stackoverflow.com/questions/29315467/changing-colour-in-python-3-4

-Run selection (request more than once)
nnnnn hot key Alt-F5?, r click?

-Run code checkers (proposed)
21880
https://stackoverflow.com/questions/27327886/issues-intercepting-subprocess-output-in-real-time

Options
13319* Conflict between Format and Options

-Configure IDLE
11437 Startup fails with typo in config-keys.cfg
21973 Startup fails with corrupted user config file
8231  Startup fails without HOME write access
15862 Startup fails if HOME dir does not exist
14576 Use of Windows ENV vare for ~ expansion
15862 Startup fails
xxxxx Expand both ways, key has scrolling!


--Font tab
24776 Fonts/Tabs UX
17642 Font resizing hot keys
14440 Use multiple alphabets in example

--Highlight tab
22083 Highlight python code within non-python files
22354 Highlight tabs
7949  Color problems with dark GTK or KDE color schemes; retro-black theme
24781 Inprove highligt tab UX
xxxxx Get list of current bindings sorted by key so see what available.
yyyyy Suppress unusable keys (meta on windows), auto convert instead of dup?

--Keys tab
6092  Changed shortcuts do not show in menu
1074333 Numlock-off keypad keys not recognized on Linux
20580 Platform-specific config defaults
17583 refuse invalid key bindings
21519 Validity check
12387 Caps-lock problems
694339 Dedent with shift-tab
4765  Delete Custom Key Set incomplete
20579  	OS X <option-> keyboard accelerators misbehave with Cocoa Tk
1080387 Make key/theme config more robust
18444 HOME and other key problems on Mac
17060 HOME problem on Mac
15808 Custom key bindings for Help sources
xxxxx ability to add key bindings rather than replace

--General tab
19042 Option to Autosave Untitled to temp (--general)
23937 Option to start maximized (or remove and just remember on exit).
kkkkk wider, could add url for sources

--Startup tab (proposed 5534)

-Configure Extensions
3068  News and doc
22704 enable should not be needed if enable_xyy (see CodeContext)
22705* add option-help option for doc, validation (sahutd)
22706 write [x] and [x_binding] sections together
22707 make options affect immediately or doc
24782 Merge into main dialog.
22726* add help to both dialogs

-Code Context
22703 Separate current and future editor window config
22823 Use set literal in code.

-Line Numbering (proposed)
17535 Line numbers, optional, on left side of editor window

Windows

-Zoomheight
       Fix so respects the taskbar.

Help

xxxxx Add initial width, height params to textViewer

-About IDLE
24199 Remove idlever.py and use in aboutDialog.py

-IDLE Help (.rst)
16893# Copy idle.html to idlelib
21995 Document pseudofiles and consequences
22820 Editor: run in batch mode -i; need print for output
23220 backspace, other ^chars, different on Shell, console
24028 Add calltip subsubsection (see calltips also)
xxxxx access and disply doc entry for callables, etc.
sssss Update Startup / Command line usage with all options in pyshell.py 
(above main)
24330 Add OSX specific notes
##### update idle command line options (see -h result).
----- Status: Editor starts as line 1, col 0, inherit from tk and tkinter.

- command line versus Idle, differenced
kbhit not work in Idle
textcolor + colorame not work in Idle
threading.activeCount 2 versus 1 in Idle

-Install packages (proposed)
23551 Run gui front end to pip

-IDLE What's New
21961 New doc, or improve and display news
(closed, need to doc procedure for updating news)

-IDLE HowTo (proposed)
17583 prototype
---

Tests

-test/test_idle smf general
20567 test_idle causes test_ttk_guionly problem (add line, support.py)
21842 Require unicode
22629 Revise htest, use Toplevel (pushed up to top of grep)Issue
24137 Force no-default-root Idle (not -n) and Idle tests
xxxxx get key,mouse event simulation from tkinter
xxxxx test installed Idle in preliminary releases; icon, .chm, ???, 3 
platforms
xxxxx Add Test Idle to Help menu

-idlelib/idle_test specifics
xxxxx get key,mouse event simulation from tkinter
xxxxx autocomplete has bugs test should have caught? I did not review claims
20640 configHelpSourceEdit
23977 Delegator (more)
20792 PathBrowser: proposed htest changes
21939 Percolator
21676 ReplaceDialog
18410 SearchDialog
18910 textView
21703 UndoDelegator
-- 
Terry Jan Reedy


From tjreedy at udel.edu  Fri Aug  7 04:50:09 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 6 Aug 2015 22:50:09 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <CAM=hmROKb9LgsO3UY399MH=NUpeg+ua=x1WDY-fBUVj1jqmv3w@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
 <CAM=hmROKb9LgsO3UY399MH=NUpeg+ua=x1WDY-fBUVj1jqmv3w@mail.gmail.com>
Message-ID: <mq16d5$qki$1@ger.gmane.org>

On 8/5/2015 1:29 PM, Al Sweigart wrote:
> Can we collect a list of software that uses idlelib?

Check 'code search' sites (there seem to be several, but Google's is 
gone) for idlelib imports other than idle or pyshell.main.  If possible, 
separate idle extensions from other software.  In the stdlib, turtledemo 
imports a couple of modules, and something else does too. But this is 
not as issue as we can edit turtledemo.__main__ as needed.

 > I'm not sure if it would affect a significant number of projects.

This would be nice to know.  Research results would be welcome

 >  Since IDLE has always
> been an application rather than a standard library module with a
> published API, I don't feel like this should hold back IDLE development.
> (Or am I wrong in this view of idlelib?)

No. PEP 434 (2013) defines idlelib other than defines entry sites as 
'private' (and I need to document this better).

A *limited* exemption is made for extensions, especially those using the 
defined interface.  How many poke elsewhere? Don't know.  I am going to 
try to add deprecation warnings.

> Many of the changes that I'd like to see are cosmetic or new features
> instead of restructuring. The single window, tabbed design is the only
> non-trivial UI change, and even then it's reusing PyShellEditorWindow
> and OutputWindow instead of creating new UI components.
>
> Using the post-8.5 widgets really would improve the look of IDLE, but
> personally I don't mind if these have to be held off until 3.6.

No need.

> We'll have our work cut out even without maintaining
 > two sets of widgets just for 3.5.

I do not intend to do that. The old files will be left alone once new 
files are in place.

> Overall, I'd defer to Mark and Terry's judgement. My current plan is to
> get more familiar with ttk (Mark's book has been great!)

It and his arrival gave me the confidence that we could go ahead.

> and the code
> base, and also think of what "new contributor" documents we should write up.

Bug me in a week to make a draft of a file list that you can review and 
revise.

> Are there any bug issues and mailing list threads that would be in
> particular good for new contributors?

I just posted a list of all open Idle issues categorized mostly by menu 
items.

Since you listed a pip gui as a killer feature, how about working on 
that?  https://bugs.python.org/issue23551  If you do, ask 'sahutd' if he 
will share whatever he has done.  Also see Donald Stufft's offer to help 
with the pip side.  It is a 'nice' issue from my viewpoint because Mark 
and others can review as well as I.  Integration into a menu is close to 
trivial.  There is a possibility that it might live other than in 
idlelib, so as to be obviously available more generally.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Fri Aug  7 05:55:07 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 6 Aug 2015 23:55:07 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
Message-ID: <mq1a70$fbq$1@ger.gmane.org>

On 8/5/2015 3:11 PM, Al Sweigart wrote:
> To be clear, I don't want to fork IDLE.

Even if you ever do, it would be better to wait until we do the 90+% we 
agree on ;-)

> I meant "pastebin" as in the generic sense,

I did not know it had become generic;-).

> But the idea here is to
> make it easy to share code without getting the whitespace mangled.

This is the key point.  I have recently received code stripped of 
spaces.  I expect this for tabs, but not spaces.

> If changing Python's error messages isn't a problem,

There are intentionally not part of the API, but we do not change them 
in bugfix releases.  For new versions, code depending of exact wording 
should have tests that fail, and that are run before x.y.0 is released.

In the issue I linked, Raymond pointed out a harder issue with adding a 
data argument.  There are millions of IndexError() calls in Python and C 
code.  What happens to those if an arg is added?  This is typical of the 
opposing forces of improvement and compatibility.  I can think of 
solutions, but they are not pretty.  I am not wasting my energy on this one.

> By "real time lint", I
> meant a feature that could point out syntax errors and variable name
> typos, rather than code style.

For the benefit of interactive mode, compile() can check partial 
statements (at the end of a line).  Idle shell used this also.  If might 
be feasible to use the same, at least somewhat, in the editor.  This 
would be an interesting challenge.

Name typo checking is impossible with 'import *', which is why I want to 
convert 'from tkinter import *' to 'from tkinter import x, y, z'.
Using name completion helps with names in imported modules.  I used 
extension config to shorten the delay time.

> Thanks for your patches and hard work, Terry. I've filed a bug for the
> "detect disk changes" feature: https://bugs.python.org/issue24799

Since you did not add terry.reedy as nosy, it did not make my list 
before posting.  I would have seen it anyway, tomorrow, when the new 
issues list is posted (every Friday).  Please don't mark security patch 
only versions, 3.2 and 3.3.

-- 
Terry Jan Reedy


From glyph at twistedmatrix.com  Fri Aug  7 06:14:59 2015
From: glyph at twistedmatrix.com (Glyph)
Date: Thu, 6 Aug 2015 21:14:59 -0700
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <mq1a70$fbq$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <mq1a70$fbq$1@ger.gmane.org>
Message-ID: <88395164-0180-4F53-B449-687C6E816130@twistedmatrix.com>


> On Aug 6, 2015, at 8:55 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
>> I meant "pastebin" as in the generic sense,
> 
> I did not know it had become generic;-).

FYI, just off the top of my head:

http://hastebin.com <http://hastebin.com/>
https://gist.github.com <https://gist.github.com/>
http://codepad.org <http://codepad.org/>
http://paste.pound-python.org <http://paste.pound-python.org/>
https://bitbucket.org/snippets/ <https://bitbucket.org/snippets/>

There's a lot of them :-).

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150806/a7ae88a8/attachment.html>

From tjreedy at udel.edu  Fri Aug  7 07:09:33 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 7 Aug 2015 01:09:33 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
Message-ID: <mq1eii$cg3$1@ger.gmane.org>

On 8/5/2015 3:16 PM, Al Sweigart wrote:
> We should definitely be open to make large design changes
> to benefit new programmers.

I have been dreaming of and working toward this for 5 years.
Learning source control and tkinter was a step.
PEP 434 was a step.
Adding a unittest framework and some tests (more needed) was a step. 
Adding a human test framework and nearly all needed tests was a step. 
Rethinking how to add ttk while keeping back compatibility was a step.
Persuading other core developers to accept the plan was, I hope, the 
last preparation step.  Now we just have to start doing it.

> Adding another checkbox to the configuration
> window makes IDLE more versatile, but it also brings it closer to a VCR
> with 50 buttons instead of an iPod with just the circle-wheel button.
> That's the opposite of what new programmers (both kids and adults) want.

Yet, we (I) constantly get requests to add options, or to add features 
that will only be added if made optional.  Consider
https://bugs.python.org/issue1207613
(and the closed duplicate) It is available as an optional extension. It 
could be added without needing the extension, but only as an option.

A phone home (help us improve the user experience) feature would have to 
be optional.

Until this week, I have never seen a request to remove options.

I am, however, in favor of simplification, at least on the item by item 
(scalpel) level.  I agree to combining Shell and Run menus.  At present, 
if a person open Idle in edit-only mode, there is no way to open Shell 
without running the file. Mark had two good ideas: simplify Configure 
Extensions and then merge it back into the main dialog.  I think we 
should simplify more by removing some of the options, such as being able 
to disable Run Module.  With one dialog again, why not open it when 
Options is clicked, instead of requiring a separate click on 'Idle 
preferences'?  I already said I think we could be rid of the 'go to 
line' box.  We might also make 'go to file/line' visual and eliminate 
the option from Debug and context menus.  Half the content of Stack 
Viewer should go. I think Debug only needs one StackViewer entry.  There 
is some duplication between the two browsers and also, I believe, some 
inconsistency.  Some of these should be easy issues.

-- 
Terry Jan Reedy


From breamoreboy at yahoo.co.uk  Fri Aug  7 09:10:23 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Fri, 7 Aug 2015 08:10:23 +0100
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mq16d5$qki$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
 <CAM=hmROKb9LgsO3UY399MH=NUpeg+ua=x1WDY-fBUVj1jqmv3w@mail.gmail.com>
 <mq16d5$qki$1@ger.gmane.org>
Message-ID: <mq1lla$rfb$2@ger.gmane.org>

On 07/08/2015 03:50, Terry Reedy wrote:
> On 8/5/2015 1:29 PM, Al Sweigart wrote:
>> Can we collect a list of software that uses idlelib?
>
> Check 'code search' sites (there seem to be several, but Google's is
> gone) for idlelib imports other than idle or pyshell.main.  If possible,
> separate idle extensions from other software.  In the stdlib, turtledemo
> imports a couple of modules, and something else does too. But this is
> not as issue as we can edit turtledemo.__main__ as needed.
>

I'd suggest http://nullege.com/ "Nullege is a search engine for Python 
source code."

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From storchaka at gmail.com  Fri Aug  7 12:16:24 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 13:16:24 +0300
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mpuf58$vbg$2@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
 <mpuf58$vbg$2@ger.gmane.org>
Message-ID: <mq20hp$847$1@ger.gmane.org>

On 06.08.15 05:01, Terry Reedy wrote:
> Will not be done. For 3.6, Ned hopes to only compile for 8.6.  I presume
> that means 3.5 will be the last version supported for OS 10.5.

3.5 supports only Tk 8.5+.



From mark at markroseman.com  Fri Aug  7 16:54:53 2015
From: mark at markroseman.com (Mark Roseman)
Date: Fri, 7 Aug 2015 07:54:53 -0700
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mq1eii$cg3$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
Message-ID: <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>

> Terry Reedy <tjreedy at udel.edu> wrote:
> 
> Al Sweigart wrote:
>> We should definitely be open to make large design changes to benefit new programmers.
> 
> I have been dreaming of and working toward this for 5 years.
> Yet, we (I) constantly get requests to add options, or to add features that will only be added if made optional.  
> Until this week, I have never seen a request to remove options.

As you know, I?m a firm believer in the notion that if you try to be all things to everyone, you don?t end up doing a very good job for anyone. And from my background in HCI, I know that every (visible) feature added has a cognitive cost associated with it.

One of the stumbling blocks to experimenting with simplified or other interaction models, and why people feel a need to fork IDLE entirely, is that there are some rather monolithic pieces to the code that make fine-grained changes or reuse in novel ways difficult. What we can consider ?model? and ?view? code is pretty intermingled. Coupling is high and cohesion is low. I?m guessing that?s one of the reasons the whole extension thing came about, as an effort to not make it worse.

I?d glad some testing was added. This will help if we are to make the architectural changes needed to incorporate new designs. Which has the potential to break things, but is necessary.

Mark

p.s. speaking of testing, I?m genuinely curious? has anyone (yourself, with students, or others you know) really used IDLE on OS X?


From kw at codebykevin.com  Fri Aug  7 17:49:23 2015
From: kw at codebykevin.com (Kevin Walzer)
Date: Fri, 7 Aug 2015 11:49:23 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
Message-ID: <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>

I do.  It's my main Python IDE.

> On Aug 7, 2015, at 10:54 AM, Mark Roseman <mark at markroseman.com> wrote:
> 
> p.s. speaking of testing, I?m genuinely curious? has anyone (yourself, with students, or others you know) really used IDLE on OS X?

From chris at codingclub.co.uk  Fri Aug  7 18:28:03 2015
From: chris at codingclub.co.uk (chris@codingclub.co.uk Mail)
Date: Fri, 7 Aug 2015 17:28:03 +0100
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
Message-ID: <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>

I do too. It is also my main IDE but I take screenshots from Raspberry Pi for books and test code on Windows too. Very important that IDLE runs similarly on all platforms otherwise teachers cannot set homeworks because schools do not control what students have at home.
- Chris

Sent from my iPhone

> On 7 Aug 2015, at 16:49, Kevin Walzer <kw at codebykevin.com> wrote:
> 
> I do.  It's my main Python IDE.
> 
>> On Aug 7, 2015, at 10:54 AM, Mark Roseman <mark at markroseman.com> wrote:
>> 
>> p.s. speaking of testing, I?m genuinely curious? has anyone (yourself, with students, or others you know) really used IDLE on OS X?
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev

From tjreedy at udel.edu  Fri Aug  7 22:20:38 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 7 Aug 2015 16:20:38 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
Message-ID: <mq33us$di2$1@ger.gmane.org>

I am leaving for a few days, with internet access iffy, but I want to 
mention that I like the idea of adding a turtle output window to Idle. 
We already have most of the needed pieces in turtledemo (which I helped 
revise a year ago). It can be run either from Idle's Help menu or with 
'python -m turtledemo'.  Replace the read-only text window with an 
editor window (or notebook), add a mini shell under for print() output, 
and the result would be close to the mockup Chris showed.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Fri Aug  7 22:24:59 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 7 Aug 2015 16:24:59 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mq20hp$847$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
 <mpuf58$vbg$2@ger.gmane.org> <mq20hp$847$1@ger.gmane.org>
Message-ID: <mq3471$i57$1@ger.gmane.org>

On 8/7/2015 6:16 AM, Serhiy Storchaka wrote:
> On 06.08.15 05:01, Terry Reedy wrote:
>> Will not be done. For 3.6, Ned hopes to only compile for 8.6.  I presume
>> that means 3.5 will be the last version supported for OS 10.5.
>
> 3.5 supports only Tk 8.5+.

I thought Ned said that 3.5 still includes the 32-bit binary compiled 
for 10.5 (++) and tk 8.4.  Does not really matter, though, for the 
question and answer.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sat Aug  8 06:14:16 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 8 Aug 2015 00:14:16 -0400
Subject: [Idle-dev] IDLE in UK Schools
In-Reply-To: <CAP7+vJKohcy8HNkSZBWrBZJnS6co3N+D0SHXVb_E_q+pvLRjjA@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <CAP7+vJKohcy8HNkSZBWrBZJnS6co3N+D0SHXVb_E_q+pvLRjjA@mail.gmail.com>
Message-ID: <55C58218.5060809@udel.edu>

On 8/4/2015 12:34 PM, Guido van Rossum wrote:
> I like the proposal. Let's re-imagine IDLE with solely beginners in mind.

I want to retry responding to Chris and Guido.

I am delighted that others are re-thinking, re-conceptualizing, 
re-imagining Idle.

I am delighted that Guido approves.  This initially surprised me, but 
let's ignore that. Guido, the main thing we needed from you was just 
this, approval to make real changes. I think we are otherwise good to go.

The main things I want are the same things that everyone here seems to want:
1. Debug and polish the features and displays we have now;
this includes adding the ttk option, simplyfing, and re-arranging.
2. Extend the use of tabs to editor panes and other frames.
3. Combine frames and panes into an coherent application rather than 
have a separate window for everything.

PEP 434 permits change 1 in all versions.  But it requires further 
discussion before applying changes 2 and 3 in current versions.  I 
believe use of a tabbed editor in a window could easily be optional, as 
planned for ttk.  Then the same logic for applying to current versions 
might be accepted.  I will bring that up with Nick and others when a 
patch is ready.  Change 3 is currently too far off to worry about.

I think beginners might benefit from better support for drawing and 
simple games.  When we have an application window, a turtle screen could 
be added by copying code from turtledemo.

What might help would be a tkinter module that includes a simple Plot 
class, an m x n GameBoard class, an Animation class based on tk's 
.after(milliseconds) method, some basic animation functions, and some 
other things. This would not be in idlelib, and would at least start on 
PyPI. Checking PyPI now, I found a few games implemented in tkinter but 
no library classes like the above.

I will likely not have internet access for a few days.

-- 
Terry Jan Reedy



From storchaka at gmail.com  Sun Aug  9 12:41:00 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 09 Aug 2015 13:41:00 +0300
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mq3471$i57$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <D3B9F430-9867-46FF-81A7-77B00576ED09@markroseman.com>
 <CAM=hmROjYCBJZhnv7xi-3qejX6+TONWy8qQiPZrB0b141-xZaQ@mail.gmail.com>
 <B0E59FBB-9833-4EFC-9A45-23499F1BF95F@markroseman.com>
 <mpuf58$vbg$2@ger.gmane.org> <mq20hp$847$1@ger.gmane.org>
 <mq3471$i57$1@ger.gmane.org>
Message-ID: <mq7ans$4kd$1@ger.gmane.org>

On 07.08.15 23:24, Terry Reedy wrote:
> On 8/7/2015 6:16 AM, Serhiy Storchaka wrote:
>> On 06.08.15 05:01, Terry Reedy wrote:
>>> Will not be done. For 3.6, Ned hopes to only compile for 8.6.  I presume
>>> that means 3.5 will be the last version supported for OS 10.5.
>>
>> 3.5 supports only Tk 8.5+.
>
> I thought Ned said that 3.5 still includes the 32-bit binary compiled
> for 10.5 (++) and tk 8.4.  Does not really matter, though, for the
> question and answer.

I'm not sure that 3.5 can be built or correctly work with Tcl/Tk 8.4. If 
this is required for OSX 10.5, perhaps we should restore 8.4 support in 
3.5. Or drop the support of OSX 10.5 in 3.5.


From al at inventwithpython.com  Sun Aug  9 22:59:38 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Sun, 9 Aug 2015 13:59:38 -0700
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <mq14i2$1hi$1@ger.gmane.org>
References: <mq14i2$1hi$1@ger.gmane.org>
Message-ID: <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>

Thanks, this is a great list to consult to before I file new issues. Idle
has a big backlog and I don't want to add duplicates.

On Thu, Aug 6, 2015 at 7:18 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> A year or two ago, a couple of people announced a plan for a database of
> Idle issues on a public site.  I don't remember anything about it later.
> Last year, I finally 'bit the bullet' and created the following so I could
> close duplicates, add myself as nosy to existing issues, and get an
> overview of what needs to be done.  Perhaps this will help others, but
> excuse the sloppiness of notes meant to be private.  If it is helpful, I
> can repost occasionally when significantly changes.  I am hoping it will
> shrink, though I plan to convert some of the xxxxx entries to real tracker
> entries.
> ----------------------------------------------
>
> A listing of Idle tracker issues, 2015 Aug 6.  Most items are listed
> under a menu (or configure tab) item, actual or proposed.  A few are
> listed under idlelib or test.
>
> * issue has patch to review.
> # I uploaded patch to finish and commit.
>
> IDLELIB
>
> 13504 meta-issue (check that each item is a separate issue, and close)
> 10079 meta-issue? Polo gsoc enhancements
> 24225 mass file rename (Swiegart), thoughts added, patch rejected
> 24671 finish 2.7 print conversion
> 24039 min max and modal dialogs, mostly search
> 24760 Dialogs (config to start) modal?
> 24759 Add ttk as option
> 17397 tkinter.ttk list of theme names
> 15313 Remove bare excepts
> 18152 Document 2.7 backport issues
> 17776 Internationalization, i18n, foreign language
> xxxxx SCriptBinding, ln 93, 2.7 r'\r' versus '\r'
> xxxxx Modernize, refactor, text subdir?
>
> File
>
> -File Reload (proposed)
> 1721083
>
> -Class Browser
> 20827 Display function arguments
> 1612262 Show nested classes
> 6171  TreeWidget draw, repeated selections (Ubuntu, ood?) good idea anyway?
> xxxxx rename Class Browser as Module browser
>       Make both scrollable, with wheel, like Win Explorer
>       Reconsider if need both, and how should interact.
>       Dont' cramp into tiny windows
>
> -Path Browser
>
> -Save
> 6699  Warn about overwriting newer version
> 15347 Debugger activation disrupts closing even after debugger closed
> (Debugger)
> 17822 Editor: Save on close dialog
> 11838 Shell code as runnable script
> 21140 Output Window should default to .txt
> 21152 Timed autosave
> 22897 Mac Save with non-ascii without encoding
> 23666 Saving/logging Shell (fix no Save on Close box)
>
> -Save AS
> 15363 ~x.py fails and closes Idle (new patch, *nix review)
> 21603 Document extension hiding on Macs.
> 4832  (closed) Document automatic .py extension.
>
> -Print Window
> 1528593 Print setup dialog
>
> -Close
> 15347 Debugger activation disrupts closing even after debugger closed
> (Debugger)
> 20167 Exception on closing (fixed, root cause?)
> 14440 On *nix, close user process if Idle closes abnormally
>
> -Reload proposed
>
> Edit
> 13179 Separate tkinter vars for each editor window
> 18875 Auto close parens, etc (extension, default off)
> 17822 Editor: Save on close dialog
> 9262  Tabbed shell and edit windows
> 2053  Standardize dialogs, mostly editor
> 4630  Cursor noblink option
> 1207613 Horizontal scrollbar
> 6804  Detect Python file even if not .py (or force hilite).
> 24750 ttk scrollbars, tweak editor base window
> ##### On activation of Idle or window, detect disk changes, offer update.
> nnnnn Detect file changed when window active, as with Notepad++, option
> relead.
> xxxxx ping with 'xxxx\n, other real-time checks?
>
> 23672 Filename with non-BMP char stops Idle
> 21084 Handle astral chars better
> 22742 Print astral chars
> 13153 Fail pasting astral chars
> 14304 New 'codec' for astral chars
>
>
> -Undo
> 23616 Undo active while code running, delete visible back to >>>
>
> -Paste
> 2053  Should replace selection on *nix as elsewhere (optional)
> 24801 Mac and right-click not work
>
> -Paste Code (proposed)
> 1178  remove >>> and ... (complements save without)
>
> -Select All useful in shell?
> -Select block (at least in Shell)
> xxxxx  Select statement or output block
>
> -Find
> 22179 Found text not highlighted on Windows
> 18590 Found text not highlighted on Windows within ''.
> 23216* Find, Grep, etc docstrings
> 23039 Dialog boxes maximize, don't minimize.  Make like config ext.
> xxxxx Search/replace/ff not modal?
> ##### [close] at bottom?
> eeeee Replace with Tal's SearchBar extension on PyPI
>
> -Find in Files
> 14929 Improve file decoding before re.search
> 23218* Grep redesign
> aaaaa underline file/line (see traceback)
> ----- Trying to find 'Tk(' does not work right
> ##### not disappear? do can re-search without re-entering same stuff.
> ##### find in open files, all files, from find dialog
> ##### autotag target as Found
>
> -Replace
> 22460 Replace all in selection
> 13586 Replace selected not consistent with find (should grab selection).
> 18590# Found text not always highlighted by Replace dialog
> xxxxx replacedialog.replace_all, chars not used (is in do replace)
>
> -Show surrounding parens
> 21756 ParenMatch closer fails with multiline expresssions
>
> -Show Calltip
> 16638 Multiline docstring sig (especially 2.7)
> 19903 Use inspect.signature
> 1350  Full docstring in new window
> 24028 Add calltip subsubsection
> 24570 Mac, 8.5.18-specific malfunction (completions also)
> xxxxx Display sig on status line; access cursor in name? rt. click? ^\
>
> -Show Completions
> 17238 Enhance import statement completion
> 18766 Complete for un-imported modules
> 13504 Complete dictionary keys
> 15786 Code completion problems with mouse
> 23961 Select from box with single tab
> 18903 File completions case sensitive, should not be on Windows
> 16198 Tabbing in string brings up completion, should not
> 22554 Popup window for names also
>
> Shell (startup)
> 13582 pythonw.exe stderr/out problem
> 22133 Correct WM_CLASS on X11
> 22121 Start in HOME directory
> 16123 Deprecate -n no subprocess
> 18823 Pipes insteadof sockets
> 13262 Opens partly hidden
> 22893 Handling of __future__ in idle/pythonstartup
> 23546 Windows, 'Edit with Idle', and multiple versons
> 24212 idlelib.__main__ in 2.7
> 24265 Crash when start with -sc
> xxxxx Add option to run module directly instead of loading in editor
>       in order to get full BMP output.
> aaaaa Catch all .idlerc/* TclErrors and continue?  Or command line option
> to ignore all?
>
> https://stackoverflow.com/questions/28876035/cant-make-idle-working-on-mac
> yyyyy Live doc mode for, eg, totorial.  Text in text color (yellow back?),
> fill in code,
>       run, live output, live prompt, ... , blank display next text and
> code. .pyx?
>       Needs to be separate from run shell.
>
> -Restart Shell (shell itself)
> 3449  Pasted \n different from typed \n
> 3559  Entered \n versus pasted \n
> 7676  Stop using tabs
> 14326 Support locales/codecs
> 21937 Make title bar *-* mean 'unsaved'
> 5233  Exec PYTHON/IDLE/STARTUP each time
> 5594  Store startup code in user config.
> 13659 Help() viewer
> 19903 Console encoding
> 15809 Console encoding wrong for 2.7
> 2704  Make Shell more like terminal
> 1529353 Squeezer - large output in Shell
> 6143  Extension to clear shell
> 1442493 Slow when long lines
> 13657 Sys.ps1, ps2
> 19808 Response to input() should not be color coded
> 10909 Threads and prints hang shell
> 13220 Print disabled during multiprocessing
> 11820 os.system, multiprocessing output lost
> aaaaa prompt to save or autosave on closing (see 21937)
> xxxxx undo error and re-edit
> xxxxx menu (pathbrowser) dead while program running, at least with input()
> xxxxx trackback go/to only when can, Explanation for Traceback, >>>,
> XError (from howto)
>       or click on uneditbale and display or goto and goto
> xxxxx Tab in past area can open completion box.
>
> -Tracebacks
> 24252 Traceback clipped.
> 24294 option to print deprecatin warnings from user code.filterwarnings or
> sys.warnoptions.
> aaaaa underline file/line as link
> nnnnn More info in traceback (optional?) such as locals
>       https://github.com/asweigart/idle-reimagined/wiki/Better-Tracebacks
>
> -Interrupt Execution
> 15308 ^C is shortcut, and others
>
> Debug
> Currently only for Shell.  Find is applicable to OutputWindow
>
> -Debugger
> 17942 Improve gui
> 15335 Steps over Idle rpc code, but into Idle print code
> 22083 Refactor breakpoint methods
> 14111 Handle interrupts
> 15347 Debugger activation disrupts closing even after debugger closed
> (Close)
> 15348*Closing [x] while active freezes shell (Serwy x 2)
> 24455 Closing twice while running caused crash.
> 24090 Send name value, possible truncated, to clipboard
> xxxxx Inspect attributes of global/local object, possible rt. click?
> yyyyy Highlight in text disappear when lose focus?  Win only?de
> zzzzz At each step, color changed values.
>
> -Stack Viewer
> 23544 Freezes Idle when debug active. Ignore when code running.
> 24790 Improve in several ways
>
> Format
>
> -Tabify Region
> 16023 Freeze with OSX Cocoa Tk8.5
>
> -Reindent (proposed)
> 5150  Access reindent.py
>
> -Strip tailing whitespace
> 23667 on/off config, auto for .py,, delete trailing blanka also
>
> Run
>
> -Check Module
> nnnnn Checking syntax should not shift focux to Shell.  Then no need for
> box.
>       'Syntax Error' is useless.
> xxxxx Check matching parentheses before compile, or with check mod?
>
> -Run Module
> 21192 Add filename to Restart bar
> 5680* Add command line arguments for running script
> 19042 Option to Autosave Untitled to temp (--general)
> 23069 Run module should set imter compiler flags for interactive input
> 24718 Alternate interpreter ?
>
> _Run in console (proposal, detached, output to console)
> nnnnn run 'cmd python -m file' when cannot get same behavior in Idle
>       kbhit https://stackoverflow.com/questions/26820251/
> python-3-program-works-in-command-line-not-idle/26822944#26822944
>       color
> https://stackoverflow.com/questions/29315467/changing-colour-in-python-3-4
>
> -Run selection (request more than once)
> nnnnn hot key Alt-F5?, r click?
>
> -Run code checkers (proposed)
> 21880
>
> https://stackoverflow.com/questions/27327886/issues-intercepting-subprocess-output-in-real-time
>
> Options
> 13319* Conflict between Format and Options
>
> -Configure IDLE
> 11437 Startup fails with typo in config-keys.cfg
> 21973 Startup fails with corrupted user config file
> 8231  Startup fails without HOME write access
> 15862 Startup fails if HOME dir does not exist
> 14576 Use of Windows ENV vare for ~ expansion
> 15862 Startup fails
> xxxxx Expand both ways, key has scrolling!
>
>
> --Font tab
> 24776 Fonts/Tabs UX
> 17642 Font resizing hot keys
> 14440 Use multiple alphabets in example
>
> --Highlight tab
> 22083 Highlight python code within non-python files
> 22354 Highlight tabs
> 7949  Color problems with dark GTK or KDE color schemes; retro-black theme
> 24781 Inprove highligt tab UX
> xxxxx Get list of current bindings sorted by key so see what available.
> yyyyy Suppress unusable keys (meta on windows), auto convert instead of
> dup?
>
> --Keys tab
> 6092  Changed shortcuts do not show in menu
> 1074333 Numlock-off keypad keys not recognized on Linux
> 20580 Platform-specific config defaults
> 17583 refuse invalid key bindings
> 21519 Validity check
> 12387 Caps-lock problems
> 694339 Dedent with shift-tab
> 4765  Delete Custom Key Set incomplete
> 20579   OS X <option-> keyboard accelerators misbehave with Cocoa Tk
> 1080387 Make key/theme config more robust
> 18444 HOME and other key problems on Mac
> 17060 HOME problem on Mac
> 15808 Custom key bindings for Help sources
> xxxxx ability to add key bindings rather than replace
>
> --General tab
> 19042 Option to Autosave Untitled to temp (--general)
> 23937 Option to start maximized (or remove and just remember on exit).
> kkkkk wider, could add url for sources
>
> --Startup tab (proposed 5534)
>
> -Configure Extensions
> 3068  News and doc
> 22704 enable should not be needed if enable_xyy (see CodeContext)
> 22705* add option-help option for doc, validation (sahutd)
> 22706 write [x] and [x_binding] sections together
> 22707 make options affect immediately or doc
> 24782 Merge into main dialog.
> 22726* add help to both dialogs
>
> -Code Context
> 22703 Separate current and future editor window config
> 22823 Use set literal in code.
>
> -Line Numbering (proposed)
> 17535 Line numbers, optional, on left side of editor window
>
> Windows
>
> -Zoomheight
>       Fix so respects the taskbar.
>
> Help
>
> xxxxx Add initial width, height params to textViewer
>
> -About IDLE
> 24199 Remove idlever.py and use in aboutDialog.py
>
> -IDLE Help (.rst)
> 16893# Copy idle.html to idlelib
> 21995 Document pseudofiles and consequences
> 22820 Editor: run in batch mode -i; need print for output
> 23220 backspace, other ^chars, different on Shell, console
> 24028 Add calltip subsubsection (see calltips also)
> xxxxx access and disply doc entry for callables, etc.
> sssss Update Startup / Command line usage with all options in pyshell.py
> (above main)
> 24330 Add OSX specific notes
> ##### update idle command line options (see -h result).
> ----- Status: Editor starts as line 1, col 0, inherit from tk and tkinter.
>
> - command line versus Idle, differenced
> kbhit not work in Idle
> textcolor + colorame not work in Idle
> threading.activeCount 2 versus 1 in Idle
>
> -Install packages (proposed)
> 23551 Run gui front end to pip
>
> -IDLE What's New
> 21961 New doc, or improve and display news
> (closed, need to doc procedure for updating news)
>
> -IDLE HowTo (proposed)
> 17583 prototype
> ---
>
> Tests
>
> -test/test_idle smf general
> 20567 test_idle causes test_ttk_guionly problem (add line, support.py)
> 21842 Require unicode
> 22629 Revise htest, use Toplevel (pushed up to top of grep)Issue
> 24137 Force no-default-root Idle (not -n) and Idle tests
> xxxxx get key,mouse event simulation from tkinter
> xxxxx test installed Idle in preliminary releases; icon, .chm, ???, 3
> platforms
> xxxxx Add Test Idle to Help menu
>
> -idlelib/idle_test specifics
> xxxxx get key,mouse event simulation from tkinter
> xxxxx autocomplete has bugs test should have caught? I did not review
> claims
> 20640 configHelpSourceEdit
> 23977 Delegator (more)
> 20792 PathBrowser: proposed htest changes
> 21939 Percolator
> 21676 ReplaceDialog
> 18410 SearchDialog
> 18910 textView
> 21703 UndoDelegator
> --
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150809/c8472c12/attachment-0001.html>

From taleinat at gmail.com  Mon Aug 10 16:44:58 2015
From: taleinat at gmail.com (Tal Einat)
Date: Mon, 10 Aug 2015 17:44:58 +0300
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
Message-ID: <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>

Indeed, this is great!

Perhaps this could be kept as an online document of some form so that it
could be kept up-to-date, e.g. a wiki page or a Google doc of some sort?
Google docs could allow you to control who can edit it, and e.g. allow
others to comment without actually editing the doc.

On Sun, Aug 9, 2015 at 11:59 PM, Al Sweigart <al at inventwithpython.com>
wrote:

> Thanks, this is a great list to consult to before I file new issues. Idle
> has a big backlog and I don't want to add duplicates.
>
> On Thu, Aug 6, 2015 at 7:18 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> A year or two ago, a couple of people announced a plan for a database of
>> Idle issues on a public site.  I don't remember anything about it later.
>> Last year, I finally 'bit the bullet' and created the following so I could
>> close duplicates, add myself as nosy to existing issues, and get an
>> overview of what needs to be done.  Perhaps this will help others, but
>> excuse the sloppiness of notes meant to be private.  If it is helpful, I
>> can repost occasionally when significantly changes.  I am hoping it will
>> shrink, though I plan to convert some of the xxxxx entries to real tracker
>> entries.
>> ----------------------------------------------
>>
>> A listing of Idle tracker issues, 2015 Aug 6.  Most items are listed
>> under a menu (or configure tab) item, actual or proposed.  A few are
>> listed under idlelib or test.
>>
>> * issue has patch to review.
>> # I uploaded patch to finish and commit.
>>
>> IDLELIB
>>
>> 13504 meta-issue (check that each item is a separate issue, and close)
>> 10079 meta-issue? Polo gsoc enhancements
>> 24225 mass file rename (Swiegart), thoughts added, patch rejected
>> 24671 finish 2.7 print conversion
>> 24039 min max and modal dialogs, mostly search
>> 24760 Dialogs (config to start) modal?
>> 24759 Add ttk as option
>> 17397 tkinter.ttk list of theme names
>> 15313 Remove bare excepts
>> 18152 Document 2.7 backport issues
>> 17776 Internationalization, i18n, foreign language
>> xxxxx SCriptBinding, ln 93, 2.7 r'\r' versus '\r'
>> xxxxx Modernize, refactor, text subdir?
>>
>> File
>>
>> -File Reload (proposed)
>> 1721083
>>
>> -Class Browser
>> 20827 Display function arguments
>> 1612262 Show nested classes
>> 6171  TreeWidget draw, repeated selections (Ubuntu, ood?) good idea
>> anyway?
>> xxxxx rename Class Browser as Module browser
>>       Make both scrollable, with wheel, like Win Explorer
>>       Reconsider if need both, and how should interact.
>>       Dont' cramp into tiny windows
>>
>> -Path Browser
>>
>> -Save
>> 6699  Warn about overwriting newer version
>> 15347 Debugger activation disrupts closing even after debugger closed
>> (Debugger)
>> 17822 Editor: Save on close dialog
>> 11838 Shell code as runnable script
>> 21140 Output Window should default to .txt
>> 21152 Timed autosave
>> 22897 Mac Save with non-ascii without encoding
>> 23666 Saving/logging Shell (fix no Save on Close box)
>>
>> -Save AS
>> 15363 ~x.py fails and closes Idle (new patch, *nix review)
>> 21603 Document extension hiding on Macs.
>> 4832  (closed) Document automatic .py extension.
>>
>> -Print Window
>> 1528593 Print setup dialog
>>
>> -Close
>> 15347 Debugger activation disrupts closing even after debugger closed
>> (Debugger)
>> 20167 Exception on closing (fixed, root cause?)
>> 14440 On *nix, close user process if Idle closes abnormally
>>
>> -Reload proposed
>>
>> Edit
>> 13179 Separate tkinter vars for each editor window
>> 18875 Auto close parens, etc (extension, default off)
>> 17822 Editor: Save on close dialog
>> 9262  Tabbed shell and edit windows
>> 2053  Standardize dialogs, mostly editor
>> 4630  Cursor noblink option
>> 1207613 Horizontal scrollbar
>> 6804  Detect Python file even if not .py (or force hilite).
>> 24750 ttk scrollbars, tweak editor base window
>> ##### On activation of Idle or window, detect disk changes, offer update.
>> nnnnn Detect file changed when window active, as with Notepad++, option
>> relead.
>> xxxxx ping with 'xxxx\n, other real-time checks?
>>
>> 23672 Filename with non-BMP char stops Idle
>> 21084 Handle astral chars better
>> 22742 Print astral chars
>> 13153 Fail pasting astral chars
>> 14304 New 'codec' for astral chars
>>
>>
>> -Undo
>> 23616 Undo active while code running, delete visible back to >>>
>>
>> -Paste
>> 2053  Should replace selection on *nix as elsewhere (optional)
>> 24801 Mac and right-click not work
>>
>> -Paste Code (proposed)
>> 1178  remove >>> and ... (complements save without)
>>
>> -Select All useful in shell?
>> -Select block (at least in Shell)
>> xxxxx  Select statement or output block
>>
>> -Find
>> 22179 Found text not highlighted on Windows
>> 18590 Found text not highlighted on Windows within ''.
>> 23216* Find, Grep, etc docstrings
>> 23039 Dialog boxes maximize, don't minimize.  Make like config ext.
>> xxxxx Search/replace/ff not modal?
>> ##### [close] at bottom?
>> eeeee Replace with Tal's SearchBar extension on PyPI
>>
>> -Find in Files
>> 14929 Improve file decoding before re.search
>> 23218* Grep redesign
>> aaaaa underline file/line (see traceback)
>> ----- Trying to find 'Tk(' does not work right
>> ##### not disappear? do can re-search without re-entering same stuff.
>> ##### find in open files, all files, from find dialog
>> ##### autotag target as Found
>>
>> -Replace
>> 22460 Replace all in selection
>> 13586 Replace selected not consistent with find (should grab selection).
>> 18590# Found text not always highlighted by Replace dialog
>> xxxxx replacedialog.replace_all, chars not used (is in do replace)
>>
>> -Show surrounding parens
>> 21756 ParenMatch closer fails with multiline expresssions
>>
>> -Show Calltip
>> 16638 Multiline docstring sig (especially 2.7)
>> 19903 Use inspect.signature
>> 1350  Full docstring in new window
>> 24028 Add calltip subsubsection
>> 24570 Mac, 8.5.18-specific malfunction (completions also)
>> xxxxx Display sig on status line; access cursor in name? rt. click? ^\
>>
>> -Show Completions
>> 17238 Enhance import statement completion
>> 18766 Complete for un-imported modules
>> 13504 Complete dictionary keys
>> 15786 Code completion problems with mouse
>> 23961 Select from box with single tab
>> 18903 File completions case sensitive, should not be on Windows
>> 16198 Tabbing in string brings up completion, should not
>> 22554 Popup window for names also
>>
>> Shell (startup)
>> 13582 pythonw.exe stderr/out problem
>> 22133 Correct WM_CLASS on X11
>> 22121 Start in HOME directory
>> 16123 Deprecate -n no subprocess
>> 18823 Pipes insteadof sockets
>> 13262 Opens partly hidden
>> 22893 Handling of __future__ in idle/pythonstartup
>> 23546 Windows, 'Edit with Idle', and multiple versons
>> 24212 idlelib.__main__ in 2.7
>> 24265 Crash when start with -sc
>> xxxxx Add option to run module directly instead of loading in editor
>>       in order to get full BMP output.
>> aaaaa Catch all .idlerc/* TclErrors and continue?  Or command line option
>> to ignore all?
>>
>> https://stackoverflow.com/questions/28876035/cant-make-idle-working-on-mac
>> yyyyy Live doc mode for, eg, totorial.  Text in text color (yellow
>> back?), fill in code,
>>       run, live output, live prompt, ... , blank display next text and
>> code. .pyx?
>>       Needs to be separate from run shell.
>>
>> -Restart Shell (shell itself)
>> 3449  Pasted \n different from typed \n
>> 3559  Entered \n versus pasted \n
>> 7676  Stop using tabs
>> 14326 Support locales/codecs
>> 21937 Make title bar *-* mean 'unsaved'
>> 5233  Exec PYTHON/IDLE/STARTUP each time
>> 5594  Store startup code in user config.
>> 13659 Help() viewer
>> 19903 Console encoding
>> 15809 Console encoding wrong for 2.7
>> 2704  Make Shell more like terminal
>> 1529353 Squeezer - large output in Shell
>> 6143  Extension to clear shell
>> 1442493 Slow when long lines
>> 13657 Sys.ps1, ps2
>> 19808 Response to input() should not be color coded
>> 10909 Threads and prints hang shell
>> 13220 Print disabled during multiprocessing
>> 11820 os.system, multiprocessing output lost
>> aaaaa prompt to save or autosave on closing (see 21937)
>> xxxxx undo error and re-edit
>> xxxxx menu (pathbrowser) dead while program running, at least with input()
>> xxxxx trackback go/to only when can, Explanation for Traceback, >>>,
>> XError (from howto)
>>       or click on uneditbale and display or goto and goto
>> xxxxx Tab in past area can open completion box.
>>
>> -Tracebacks
>> 24252 Traceback clipped.
>> 24294 option to print deprecatin warnings from user code.filterwarnings
>> or sys.warnoptions.
>> aaaaa underline file/line as link
>> nnnnn More info in traceback (optional?) such as locals
>>       https://github.com/asweigart/idle-reimagined/wiki/Better-Tracebacks
>>
>> -Interrupt Execution
>> 15308 ^C is shortcut, and others
>>
>> Debug
>> Currently only for Shell.  Find is applicable to OutputWindow
>>
>> -Debugger
>> 17942 Improve gui
>> 15335 Steps over Idle rpc code, but into Idle print code
>> 22083 Refactor breakpoint methods
>> 14111 Handle interrupts
>> 15347 Debugger activation disrupts closing even after debugger closed
>> (Close)
>> 15348*Closing [x] while active freezes shell (Serwy x 2)
>> 24455 Closing twice while running caused crash.
>> 24090 Send name value, possible truncated, to clipboard
>> xxxxx Inspect attributes of global/local object, possible rt. click?
>> yyyyy Highlight in text disappear when lose focus?  Win only?de
>> zzzzz At each step, color changed values.
>>
>> -Stack Viewer
>> 23544 Freezes Idle when debug active. Ignore when code running.
>> 24790 Improve in several ways
>>
>> Format
>>
>> -Tabify Region
>> 16023 Freeze with OSX Cocoa Tk8.5
>>
>> -Reindent (proposed)
>> 5150  Access reindent.py
>>
>> -Strip tailing whitespace
>> 23667 on/off config, auto for .py,, delete trailing blanka also
>>
>> Run
>>
>> -Check Module
>> nnnnn Checking syntax should not shift focux to Shell.  Then no need for
>> box.
>>       'Syntax Error' is useless.
>> xxxxx Check matching parentheses before compile, or with check mod?
>>
>> -Run Module
>> 21192 Add filename to Restart bar
>> 5680* Add command line arguments for running script
>> 19042 Option to Autosave Untitled to temp (--general)
>> 23069 Run module should set imter compiler flags for interactive input
>> 24718 Alternate interpreter ?
>>
>> _Run in console (proposal, detached, output to console)
>> nnnnn run 'cmd python -m file' when cannot get same behavior in Idle
>>       kbhit https://stackoverflow.com/questions/26820251/
>> python-3-program-works-in-command-line-not-idle/26822944#26822944
>>       color
>> https://stackoverflow.com/questions/29315467/changing-colour-in-python-3-4
>>
>> -Run selection (request more than once)
>> nnnnn hot key Alt-F5?, r click?
>>
>> -Run code checkers (proposed)
>> 21880
>>
>> https://stackoverflow.com/questions/27327886/issues-intercepting-subprocess-output-in-real-time
>>
>> Options
>> 13319* Conflict between Format and Options
>>
>> -Configure IDLE
>> 11437 Startup fails with typo in config-keys.cfg
>> 21973 Startup fails with corrupted user config file
>> 8231  Startup fails without HOME write access
>> 15862 Startup fails if HOME dir does not exist
>> 14576 Use of Windows ENV vare for ~ expansion
>> 15862 Startup fails
>> xxxxx Expand both ways, key has scrolling!
>>
>>
>> --Font tab
>> 24776 Fonts/Tabs UX
>> 17642 Font resizing hot keys
>> 14440 Use multiple alphabets in example
>>
>> --Highlight tab
>> 22083 Highlight python code within non-python files
>> 22354 Highlight tabs
>> 7949  Color problems with dark GTK or KDE color schemes; retro-black theme
>> 24781 Inprove highligt tab UX
>> xxxxx Get list of current bindings sorted by key so see what available.
>> yyyyy Suppress unusable keys (meta on windows), auto convert instead of
>> dup?
>>
>> --Keys tab
>> 6092  Changed shortcuts do not show in menu
>> 1074333 Numlock-off keypad keys not recognized on Linux
>> 20580 Platform-specific config defaults
>> 17583 refuse invalid key bindings
>> 21519 Validity check
>> 12387 Caps-lock problems
>> 694339 Dedent with shift-tab
>> 4765  Delete Custom Key Set incomplete
>> 20579   OS X <option-> keyboard accelerators misbehave with Cocoa Tk
>> 1080387 Make key/theme config more robust
>> 18444 HOME and other key problems on Mac
>> 17060 HOME problem on Mac
>> 15808 Custom key bindings for Help sources
>> xxxxx ability to add key bindings rather than replace
>>
>> --General tab
>> 19042 Option to Autosave Untitled to temp (--general)
>> 23937 Option to start maximized (or remove and just remember on exit).
>> kkkkk wider, could add url for sources
>>
>> --Startup tab (proposed 5534)
>>
>> -Configure Extensions
>> 3068  News and doc
>> 22704 enable should not be needed if enable_xyy (see CodeContext)
>> 22705* add option-help option for doc, validation (sahutd)
>> 22706 write [x] and [x_binding] sections together
>> 22707 make options affect immediately or doc
>> 24782 Merge into main dialog.
>> 22726* add help to both dialogs
>>
>> -Code Context
>> 22703 Separate current and future editor window config
>> 22823 Use set literal in code.
>>
>> -Line Numbering (proposed)
>> 17535 Line numbers, optional, on left side of editor window
>>
>> Windows
>>
>> -Zoomheight
>>       Fix so respects the taskbar.
>>
>> Help
>>
>> xxxxx Add initial width, height params to textViewer
>>
>> -About IDLE
>> 24199 Remove idlever.py and use in aboutDialog.py
>>
>> -IDLE Help (.rst)
>> 16893# Copy idle.html to idlelib
>> 21995 Document pseudofiles and consequences
>> 22820 Editor: run in batch mode -i; need print for output
>> 23220 backspace, other ^chars, different on Shell, console
>> 24028 Add calltip subsubsection (see calltips also)
>> xxxxx access and disply doc entry for callables, etc.
>> sssss Update Startup / Command line usage with all options in pyshell.py
>> (above main)
>> 24330 Add OSX specific notes
>> ##### update idle command line options (see -h result).
>> ----- Status: Editor starts as line 1, col 0, inherit from tk and tkinter.
>>
>> - command line versus Idle, differenced
>> kbhit not work in Idle
>> textcolor + colorame not work in Idle
>> threading.activeCount 2 versus 1 in Idle
>>
>> -Install packages (proposed)
>> 23551 Run gui front end to pip
>>
>> -IDLE What's New
>> 21961 New doc, or improve and display news
>> (closed, need to doc procedure for updating news)
>>
>> -IDLE HowTo (proposed)
>> 17583 prototype
>> ---
>>
>> Tests
>>
>> -test/test_idle smf general
>> 20567 test_idle causes test_ttk_guionly problem (add line, support.py)
>> 21842 Require unicode
>> 22629 Revise htest, use Toplevel (pushed up to top of grep)Issue
>> 24137 Force no-default-root Idle (not -n) and Idle tests
>> xxxxx get key,mouse event simulation from tkinter
>> xxxxx test installed Idle in preliminary releases; icon, .chm, ???, 3
>> platforms
>> xxxxx Add Test Idle to Help menu
>>
>> -idlelib/idle_test specifics
>> xxxxx get key,mouse event simulation from tkinter
>> xxxxx autocomplete has bugs test should have caught? I did not review
>> claims
>> 20640 configHelpSourceEdit
>> 23977 Delegator (more)
>> 20792 PathBrowser: proposed htest changes
>> 21939 Percolator
>> 21676 ReplaceDialog
>> 18410 SearchDialog
>> 18910 textView
>> 21703 UndoDelegator
>> --
>> Terry Jan Reedy
>>
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
>>
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150810/f5f3f953/attachment-0001.html>

From paul.james.barry at gmail.com  Wed Aug 12 16:24:31 2015
From: paul.james.barry at gmail.com (Paul Barry)
Date: Wed, 12 Aug 2015 15:24:31 +0100
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
Message-ID: <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>

I do, too, and have used IDLE (successfully) on Mac OS X for years now.
Granted - like Chris - this may have more to do with the fact that I'm a
Python author as well as a 3rd level educator (who teaches Python to
undergrads), but I really do have a soft-spot for IDLE.... something like
PyCharm, for instance, drives me bananas... then again, I'm a fan of vim,
too (so maybe - after 25 years using that editor - I'm damaged beyond
repair).  ;-)

Paul.

On 7 August 2015 at 17:28, chris at codingclub.co.uk Mail <
chris at codingclub.co.uk> wrote:

> I do too. It is also my main IDE but I take screenshots from Raspberry Pi
> for books and test code on Windows too. Very important that IDLE runs
> similarly on all platforms otherwise teachers cannot set homeworks because
> schools do not control what students have at home.
> - Chris
>
> Sent from my iPhone
>
> > On 7 Aug 2015, at 16:49, Kevin Walzer <kw at codebykevin.com> wrote:
> >
> > I do.  It's my main Python IDE.
> >
> >> On Aug 7, 2015, at 10:54 AM, Mark Roseman <mark at markroseman.com> wrote:
> >>
> >> p.s. speaking of testing, I?m genuinely curious? has anyone (yourself,
> with students, or others you know) really used IDLE on OS X?
> > _______________________________________________
> > IDLE-dev mailing list
> > IDLE-dev at python.org
> > https://mail.python.org/mailman/listinfo/idle-dev
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>



-- 
Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry at itcarlow.ie
Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150812/82e43747/attachment.html>

From ether.joe at gmail.com  Wed Aug 12 19:35:32 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Wed, 12 Aug 2015 10:35:32 -0700
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
Message-ID: <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>

Yet another IDLE on OSX and Vim maniac. That makes at least two !

On Wed, Aug 12, 2015 at 7:24 AM, Paul Barry <paul.james.barry at gmail.com>
wrote:

> I do, too, and have used IDLE (successfully) on Mac OS X for years now.
> Granted - like Chris - this may have more to do with the fact that I'm a
> Python author as well as a 3rd level educator (who teaches Python to
> undergrads), but I really do have a soft-spot for IDLE.... something like
> PyCharm, for instance, drives me bananas... then again, I'm a fan of vim,
> too (so maybe - after 25 years using that editor - I'm damaged beyond
> repair).  ;-)
>
> Paul.
>
> On 7 August 2015 at 17:28, chris at codingclub.co.uk Mail <
> chris at codingclub.co.uk> wrote:
>
>> I do too. It is also my main IDE but I take screenshots from Raspberry Pi
>> for books and test code on Windows too. Very important that IDLE runs
>> similarly on all platforms otherwise teachers cannot set homeworks because
>> schools do not control what students have at home.
>> - Chris
>>
>> Sent from my iPhone
>>
>> > On 7 Aug 2015, at 16:49, Kevin Walzer <kw at codebykevin.com> wrote:
>> >
>> > I do.  It's my main Python IDE.
>> >
>> >> On Aug 7, 2015, at 10:54 AM, Mark Roseman <mark at markroseman.com>
>> wrote:
>> >>
>> >> p.s. speaking of testing, I?m genuinely curious? has anyone (yourself,
>> with students, or others you know) really used IDLE on OS X?
>> > _______________________________________________
>> > IDLE-dev mailing list
>> > IDLE-dev at python.org
>> > https://mail.python.org/mailman/listinfo/idle-dev
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
>>
>
>
>
> --
> Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry at itcarlow.ie
> Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
>


-- 
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150812/502d347b/attachment.html>

From breamoreboy at yahoo.co.uk  Wed Aug 12 23:07:20 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Wed, 12 Aug 2015 22:07:20 +0100
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
 <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
Message-ID: <mqgci9$p4h$1@ger.gmane.org>

On 12/08/2015 18:35, Sean Felipe Wolfe wrote:
> Yet another IDLE on OSX and Vim maniac. That makes at least two !
>

It always intrigues me, an overrated, overpriced product from the most 
overrated company in the world, and yet another reference to a domestic 
cleaner?  What gives, apart from fools and their money are easily parted?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From paul.james.barry at gmail.com  Thu Aug 13 11:26:05 2015
From: paul.james.barry at gmail.com (Paul Barry)
Date: Thu, 13 Aug 2015 10:26:05 +0100
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mqgci9$p4h$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
 <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
 <mqgci9$p4h$1@ger.gmane.org>
Message-ID: <CAFwVEOQWK5g756dN_NX6GQ0FBe3PctJ8N_7W4L-r0xtiU-tHoQ@mail.gmail.com>

What a mature comment.  Thanks, Mark.  Very helpful.


On 12 August 2015 at 22:07, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:

> On 12/08/2015 18:35, Sean Felipe Wolfe wrote:
>
>> Yet another IDLE on OSX and Vim maniac. That makes at least two !
>>
>>
> It always intrigues me, an overrated, overpriced product from the most
> overrated company in the world, and yet another reference to a domestic
> cleaner?  What gives, apart from fools and their money are easily parted?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>



-- 
Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry at itcarlow.ie
Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150813/b8ca1e14/attachment-0001.html>

From al at inventwithpython.com  Thu Aug 13 18:56:40 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Thu, 13 Aug 2015 09:56:40 -0700
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <CAFwVEOQWK5g756dN_NX6GQ0FBe3PctJ8N_7W4L-r0xtiU-tHoQ@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
 <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
 <mqgci9$p4h$1@ger.gmane.org>
 <CAFwVEOQWK5g756dN_NX6GQ0FBe3PctJ8N_7W4L-r0xtiU-tHoQ@mail.gmail.com>
Message-ID: <CAM=hmRPczPhirboACSkAuDek87Jtf8SSmEPScsfg+A0ZHXtQMw@mail.gmail.com>

In general, it seems that most experienced developers either want a full
featured IDE like Eclipse or PyCharm, or they want something simpler in
which case they go with a text editor like Vim or Sublime Text. Idle can't
(and shouldn't) compete with either of those categories.

On Thu, Aug 13, 2015 at 2:26 AM, Paul Barry <paul.james.barry at gmail.com>
wrote:

> What a mature comment.  Thanks, Mark.  Very helpful.
>
>
> On 12 August 2015 at 22:07, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>
>> On 12/08/2015 18:35, Sean Felipe Wolfe wrote:
>>
>>> Yet another IDLE on OSX and Vim maniac. That makes at least two !
>>>
>>>
>> It always intrigues me, an overrated, overpriced product from the most
>> overrated company in the world, and yet another reference to a domestic
>> cleaner?  What gives, apart from fools and their money are easily parted?
>>
>> --
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>>
>> Mark Lawrence
>>
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
>>
>
>
>
> --
> Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry at itcarlow.ie
> Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150813/9a402e61/attachment.html>

From mark at markroseman.com  Thu Aug 13 20:21:20 2015
From: mark at markroseman.com (Mark Roseman)
Date: Thu, 13 Aug 2015 11:21:20 -0700
Subject: [Idle-dev] my work plans
Message-ID: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>

I just wanted to give a quick update on some of the things I?ve been working on in terms of IDLE UI improvements. Any comments or feedback appreciated.


Short-term - incremental improvements to existing behaviours:

  * (patch done) minor cosmetic updates to the editor window (#24750, #24745)

  * (patch done) changes to make existing preferences and about dialogs non-modal (#24760)

  * (patch done) modified about dialog to display credits, readme, etc. inline rather than launching further (modal) windows

  * (patch done) mac-specific bug fixes to workaround problems in Tk (#24801, #24570)

  * (patch done) centralize creation of ui components in a new ?uifactory? module. This is now used by about/prefs (#24760), and soon others. This module will also be in charge of choosing to use ?ttk? or ?non-ttk? based components (#24759)

  * (patch done) utilities to help with functional/integration testing across application via tkinter introspection/event generation (#24845); much more to come

  * (in progress) replacement for simpledialog calls: adding ttk option, some behaviour fixes (e.g. #24812), displaying errors inline rather than launching another modal dialog; integrate in uifactory

  * (in progress) ttk-based redesign of preferences+extensions dialog, when running Tk >= 8.5 (#24759, #24776, #24782, etc.)

  * (in progress) ttk-based version of find dialogs, with minor enhancements

  * (in progress) new ?tkextras? module, to centralize some of the small tricks, wrappers and workarounds that get used multiple places in the code

  * (soon) make find dialogs non-modal, integrate with uifactory


The next things I plan on having a look at:

  * create a 'stand-alone' canvas-based tab widget (modelled after the one in textmate) to later be used as the ui to handle switching between multiple editors/shell within same window (#9262, #24826)

  * separate UI of debugger from underlying internals (so ui can be attached ?on the fly?), make it runnable as a frame (so can embed in toplevel or panedwindow), and improve UI

  * menu handling, in particular enabling/disabling items according to app state (#24814 etc.)


For others making or planning broad changes, the main thing to note of at this point is the ?uifactory? addition, as well as some of the module decoupling that?s happening as a result of other changes like making things non-modal. The functional testing pieces are early stages, but I hope it can fill in some gaps and also replace a subset of the manual ?htest? tests with automation.

Mark


From ether.joe at gmail.com  Thu Aug 13 23:36:09 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Thu, 13 Aug 2015 14:36:09 -0700
Subject: [Idle-dev] my work plans
In-Reply-To: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>
References: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>
Message-ID: <CAOFf2a3ZGaHQ3eyvQmo6QK9MqZgCUOsA8_p3NF7xU9s68zUsVw@mail.gmail.com>

I didn't parse this all, but happy to see more IDLE development on the way!
We'll fight our way out !!

On Thu, Aug 13, 2015 at 11:21 AM, Mark Roseman <mark at markroseman.com> wrote:

> I just wanted to give a quick update on some of the things I?ve been
> working on in terms of IDLE UI improvements. Any comments or feedback
> appreciated.
>
>
> Short-term - incremental improvements to existing behaviours:
>
>   * (patch done) minor cosmetic updates to the editor window (#24750,
> #24745)
>
>   * (patch done) changes to make existing preferences and about dialogs
> non-modal (#24760)
>
>   * (patch done) modified about dialog to display credits, readme, etc.
> inline rather than launching further (modal) windows
>
>   * (patch done) mac-specific bug fixes to workaround problems in Tk
> (#24801, #24570)
>
>   * (patch done) centralize creation of ui components in a new ?uifactory?
> module. This is now used by about/prefs (#24760), and soon others. This
> module will also be in charge of choosing to use ?ttk? or ?non-ttk? based
> components (#24759)
>
>   * (patch done) utilities to help with functional/integration testing
> across application via tkinter introspection/event generation (#24845);
> much more to come
>
>   * (in progress) replacement for simpledialog calls: adding ttk option,
> some behaviour fixes (e.g. #24812), displaying errors inline rather than
> launching another modal dialog; integrate in uifactory
>
>   * (in progress) ttk-based redesign of preferences+extensions dialog,
> when running Tk >= 8.5 (#24759, #24776, #24782, etc.)
>
>   * (in progress) ttk-based version of find dialogs, with minor
> enhancements
>
>   * (in progress) new ?tkextras? module, to centralize some of the small
> tricks, wrappers and workarounds that get used multiple places in the code
>
>   * (soon) make find dialogs non-modal, integrate with uifactory
>
>
> The next things I plan on having a look at:
>
>   * create a 'stand-alone' canvas-based tab widget (modelled after the one
> in textmate) to later be used as the ui to handle switching between
> multiple editors/shell within same window (#9262, #24826)
>
>   * separate UI of debugger from underlying internals (so ui can be
> attached ?on the fly?), make it runnable as a frame (so can embed in
> toplevel or panedwindow), and improve UI
>
>   * menu handling, in particular enabling/disabling items according to app
> state (#24814 etc.)
>
>
> For others making or planning broad changes, the main thing to note of at
> this point is the ?uifactory? addition, as well as some of the module
> decoupling that?s happening as a result of other changes like making things
> non-modal. The functional testing pieces are early stages, but I hope it
> can fill in some gaps and also replace a subset of the manual ?htest? tests
> with automation.
>
> Mark
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>



-- 
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150813/677c0691/attachment.html>

From tjreedy at udel.edu  Fri Aug 14 16:24:32 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 14 Aug 2015 10:24:32 -0400
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <CAM=hmRPczPhirboACSkAuDek87Jtf8SSmEPScsfg+A0ZHXtQMw@mail.gmail.com>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
 <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
 <mqgci9$p4h$1@ger.gmane.org>
 <CAFwVEOQWK5g756dN_NX6GQ0FBe3PctJ8N_7W4L-r0xtiU-tHoQ@mail.gmail.com>
 <CAM=hmRPczPhirboACSkAuDek87Jtf8SSmEPScsfg+A0ZHXtQMw@mail.gmail.com>
Message-ID: <mqktn2$c66$1@ger.gmane.org>

On 8/13/2015 12:56 PM, Al Sweigart wrote:
> In general, it seems that most experienced developers either want a full
> featured IDE like Eclipse or PyCharm, or they want something simpler in
> which case they go with a text editor like Vim or Sublime Text. Idle
> can't (and shouldn't) compete with either of those categories.

I agree. Idle fills a niche in between those categories -- a simple 
python-only ide.  On Windows at least, it is also a replacement for the 
wretched interactive console.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Fri Aug 14 16:48:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 14 Aug 2015 10:48:19 -0400
Subject: [Idle-dev] my work plans
In-Reply-To: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>
References: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>
Message-ID: <mqkv3m$3kr$1@ger.gmane.org>

On 8/13/2015 2:21 PM, Mark Roseman wrote:

>    * (patch done) centralize creation of ui components in a new ?uifactory? module. This is now used by about/prefs (#24760), and soon others. This module will also be in charge of choosing to use ?ttk? or ?non-ttk? based components (#24759)

Because menu creation is mostly 'data' driven, with a hierarchical 
structure, it will be relatively easy to collect and translate the 
strings in the menu ('File', 'Open', etc) for i18n without wrapping each 
literal string with _(...).  If other UIs were similarly data driven, 
rather than code-driven as now, i18n for other UIs would be similarly 
easy.  So I am curious as to your approach.

>    * menu handling, in particular enabling/disabling items according to app state (#24814 etc.)

I think most of the features currently implemented as 'optional 
extensions' should be incorporated as always present features and the 
disable option removed.  Their menu entries would then be moved into the 
main menudefs in bindings.py.  If it becomes easy to disable or even 
remove menu entries for disabled features, then we could move *all* main 
menu menudefs into bindings.menudefs.

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Fri Aug 14 16:52:29 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 14 Aug 2015 10:52:29 -0400
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
 <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
Message-ID: <mqkvbg$7sb$1@ger.gmane.org>

On 8/10/2015 10:44 AM, Tal Einat wrote:
> Indeed, this is great!
>
> Perhaps this could be kept as an online document of some form so that it
> could be kept up-to-date, e.g. a wiki page or a Google doc of some sort?
> Google docs could allow you to control who can edit it, and e.g. allow
> others to comment without actually editing the doc.

With two votes for updated availability, I will think about this.

> On Sun, Aug 9, 2015 at 11:59 PM, Al Sweigart <al at inventwithpython.com
> <mailto:al at inventwithpython.com>> wrote:
>
>     Thanks, this is a great list to consult to before I file new issues.
>     Idle has a big backlog and I don't want to add duplicates.
>
>     On Thu, Aug 6, 2015 at 7:18 PM, Terry Reedy <tjreedy at udel.edu
>     <mailto:tjreedy at udel.edu>> wrote:
>
>         A year or two ago, a couple of people announced a plan for a
>         database of Idle issues on a public site.  I don't remember
>         anything about it later.  Last year, I finally 'bit the bullet'
>         and created the following so I could close duplicates, add
>         myself as nosy to existing issues, and get an overview of what
>         needs to be done.  Perhaps this will help others, but excuse the
>         sloppiness of notes meant to be private.  If it is helpful, I
>         can repost occasionally when significantly changes.  I am hoping
>         it will shrink, though I plan to convert some of the xxxxx
>         entries to real tracker entries.
>         ----------------------------------------------
>
>         A listing of Idle tracker issues, 2015 Aug 6.  Most items are listed
>         under a menu (or configure tab) item, actual or proposed.  A few are
>         listed under idlelib or test.
>
>         * issue has patch to review.
>         # I uploaded patch to finish and commit.
>
>         IDLELIB
>
>         13504 meta-issue (check that each item is a separate issue, and
>         close)


-- 
Terry Jan Reedy


From interstar at gmail.com  Fri Aug 14 17:09:13 2015
From: interstar at gmail.com (phil jones)
Date: Fri, 14 Aug 2015 12:09:13 -0300
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <mqkvbg$7sb$1@ger.gmane.org>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
 <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
 <mqkvbg$7sb$1@ger.gmane.org>
Message-ID: <CAP97Hn=h4BravASUNXqHEhwgyjSS=P9DsSCy9O3yZSvONkoGQA@mail.gmail.com>

If IDLE *was* on, say, GitHub, wouldn't a public up-to-date bug / todo /
issue list and wiki be part of that?

Phil

On 14 August 2015 at 11:52, Terry Reedy <tjreedy at udel.edu> wrote:

> On 8/10/2015 10:44 AM, Tal Einat wrote:
>
>> Indeed, this is great!
>>
>> Perhaps this could be kept as an online document of some form so that it
>> could be kept up-to-date, e.g. a wiki page or a Google doc of some sort?
>> Google docs could allow you to control who can edit it, and e.g. allow
>> others to comment without actually editing the doc.
>>
>
> With two votes for updated availability, I will think about this.
>
> On Sun, Aug 9, 2015 at 11:59 PM, Al Sweigart <al at inventwithpython.com
>> <mailto:al at inventwithpython.com>> wrote:
>>
>>     Thanks, this is a great list to consult to before I file new issues.
>>     Idle has a big backlog and I don't want to add duplicates.
>>
>>     On Thu, Aug 6, 2015 at 7:18 PM, Terry Reedy <tjreedy at udel.edu
>>     <mailto:tjreedy at udel.edu>> wrote:
>>
>>         A year or two ago, a couple of people announced a plan for a
>>         database of Idle issues on a public site.  I don't remember
>>         anything about it later.  Last year, I finally 'bit the bullet'
>>         and created the following so I could close duplicates, add
>>         myself as nosy to existing issues, and get an overview of what
>>         needs to be done.  Perhaps this will help others, but excuse the
>>         sloppiness of notes meant to be private.  If it is helpful, I
>>         can repost occasionally when significantly changes.  I am hoping
>>         it will shrink, though I plan to convert some of the xxxxx
>>         entries to real tracker entries.
>>         ----------------------------------------------
>>
>>         A listing of Idle tracker issues, 2015 Aug 6.  Most items are
>> listed
>>         under a menu (or configure tab) item, actual or proposed.  A few
>> are
>>         listed under idlelib or test.
>>
>>         * issue has patch to review.
>>         # I uploaded patch to finish and commit.
>>
>>         IDLELIB
>>
>>         13504 meta-issue (check that each item is a separate issue, and
>>         close)
>>
>
>
> --
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150814/17d0614d/attachment.html>

From tjreedy at udel.edu  Fri Aug 14 17:44:51 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 14 Aug 2015 11:44:51 -0400
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <CAP97Hn=h4BravASUNXqHEhwgyjSS=P9DsSCy9O3yZSvONkoGQA@mail.gmail.com>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
 <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
 <mqkvbg$7sb$1@ger.gmane.org>
 <CAP97Hn=h4BravASUNXqHEhwgyjSS=P9DsSCy9O3yZSvONkoGQA@mail.gmail.com>
Message-ID: <mql2dm$rdd$1@ger.gmane.org>

On 8/14/2015 11:09 AM, phil jones wrote:
> If IDLE *was* on, say, GitHub, wouldn't a public up-to-date bug / todo /
> issue list and wiki be part of that?

The Python tracker can give you such a list.  Go to
https://bugs.python.org/issue?@template=search&status=1
select Components IDLE and go. At the moment you get a list of 180 
issues sorted by last activity, resortable by other characteristics. 
What you cannot get, and I presume would not get on GitHub either, is a 
list sorted by Idle feature, as is my list. (If my presumption about 
GitHub is wrong, please say so.) This sorting makes it much easier to 
find specific issues.

My list also has 'possible' issues.  Some I will open on the tracker now 
that other people are looking as issues on the tracker.

-- 
Terry Jan Reedy


From mark at markroseman.com  Fri Aug 14 19:08:07 2015
From: mark at markroseman.com (Mark Roseman)
Date: Fri, 14 Aug 2015 10:08:07 -0700
Subject: [Idle-dev] my work plans
In-Reply-To: <mqkv3m$3kr$1@ger.gmane.org>
References: <A9541E61-773F-4D98-B62B-2F2CFAB71390@markroseman.com>
 <mqkv3m$3kr$1@ger.gmane.org>
Message-ID: <3F4D3A03-2C75-4624-BDD9-B42753EC8974@markroseman.com>

> On Aug 14, 2015, at 7:48 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>>  * (patch done) centralize creation of ui components in a new ?uifactory? module. This is now used by about/prefs (#24760), and soon others. This module will also be in charge of choosing to use ?ttk? or ?non-ttk? based components (#24759)
> 
> Because menu creation is mostly 'data' driven, with a hierarchical structure, it will be relatively easy to collect and translate the strings in the menu ('File', 'Open', etc) for i18n without wrapping each literal string with _(...).  If other UIs were similarly data driven, rather than code-driven as now, i18n for other UIs would be similarly easy.  So I am curious as to your approach.

At this point it?s not about i18n or anything ambitious, just one place to centralize the ?do I use classic- or ttk-flavoured versions of this dialog?? for large components, not individual widgets. Plus keeping track of these various non-editor windows, which becomes an issue as some of them change to modeless. So rather than an EditorWindow instantiating the preferences dialog directly, it would ask the uifactory to do so. While there will inevitably be a bit of that "call a method to call a method to call a method to? actually get work done", I?ll do my best to minimize that!

Moving to a central string table so the interface could be localized would be great. Later. ;-)


>   * menu handling, in particular enabling/disabling items according to app state (#24814 etc.)
> 
> I think most of the features currently implemented as 'optional extensions' should be incorporated as always present features and the disable option removed.  Their menu entries would then be moved into the main menudefs in bindings.py.  If it becomes easy to disable or even remove menu entries for disabled features, then we could move *all* main menu menudefs into bindings.menudefs.

I?m all for incorporating the optional extensions. By disabling here though I was referring to things like a ?Copy? menu item being disabled (inactive) if no text is selected in the active editor, etc.

Mark



From interstar at gmail.com  Fri Aug 14 19:33:37 2015
From: interstar at gmail.com (phil jones)
Date: Fri, 14 Aug 2015 14:33:37 -0300
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <mql2dm$rdd$1@ger.gmane.org>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
 <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
 <mqkvbg$7sb$1@ger.gmane.org>
 <CAP97Hn=h4BravASUNXqHEhwgyjSS=P9DsSCy9O3yZSvONkoGQA@mail.gmail.com>
 <mql2dm$rdd$1@ger.gmane.org>
Message-ID: <CAP97Hn=n8OL2XS+RYS4=8JHjD+rkzDE707gy4S=oyNs4tD4z5w@mail.gmail.com>

OK. Understood.

Just seems that so many tools these days, from Trac to GitHub integrate
wiki with the tracker, allowing you to hand-roll custom lists like these
but still easily integrate / hyperlink them into the tracker.

Going to Google Docs seems a fairly awkward way to do this. Is there a wiki
integrated into the main Python tracker?

Phil

On 14 August 2015 at 12:44, Terry Reedy <tjreedy at udel.edu> wrote:

> On 8/14/2015 11:09 AM, phil jones wrote:
>
>> If IDLE *was* on, say, GitHub, wouldn't a public up-to-date bug / todo /
>> issue list and wiki be part of that?
>>
>
> The Python tracker can give you such a list.  Go to
> https://bugs.python.org/issue?@template=search&status=1
> select Components IDLE and go. At the moment you get a list of 180 issues
> sorted by last activity, resortable by other characteristics. What you
> cannot get, and I presume would not get on GitHub either, is a list sorted
> by Idle feature, as is my list. (If my presumption about GitHub is wrong,
> please say so.) This sorting makes it much easier to find specific issues.
>
> My list also has 'possible' issues.  Some I will open on the tracker now
> that other people are looking as issues on the tracker.
>
>
> --
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150814/807be816/attachment.html>

From tjreedy at udel.edu  Sat Aug 15 19:47:06 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 15 Aug 2015 13:47:06 -0400
Subject: [Idle-dev] Current Idle issues
In-Reply-To: <CAP97Hn=n8OL2XS+RYS4=8JHjD+rkzDE707gy4S=oyNs4tD4z5w@mail.gmail.com>
References: <mq14i2$1hi$1@ger.gmane.org>
 <CAM=hmRMjDF7a2kdjXsGpO0zpfVL9m6D+JQg2z7QZAFCMnqbviA@mail.gmail.com>
 <CALWZvp7_CK=Dk8P+sd=KnhWFqTqJVauvX8+C1-FaHg-9aMF_Uw@mail.gmail.com>
 <mqkvbg$7sb$1@ger.gmane.org>
 <CAP97Hn=h4BravASUNXqHEhwgyjSS=P9DsSCy9O3yZSvONkoGQA@mail.gmail.com>
 <mql2dm$rdd$1@ger.gmane.org>
 <CAP97Hn=n8OL2XS+RYS4=8JHjD+rkzDE707gy4S=oyNs4tD4z5w@mail.gmail.com>
Message-ID: <mqntut$65l$1@ger.gmane.org>

On 8/14/2015 1:33 PM, phil jones wrote:
> OK. Understood.
>
> Just seems that so many tools these days, from Trac to GitHub integrate
> wiki with the tracker, allowing you to hand-roll custom lists like these
> but still easily integrate / hyperlink them into the tracker.

> Going to Google Docs seems a fairly awkward way to do this. Is there a
> wiki integrated into the main Python tracker?

Not being able to click on an issue number -- and to to the issue -- is 
the thing I most dislike about my text file.  You are right that a 
Google doc would not solve this.  As far as I know,
https://wiki.python.org/moin/FrontPage#use
is not integrated with bugs.python.org.  I may wait until the workflow 
re-organizaiton plans are announced.

People sometimes use 'index issues' on the tracker to make point to 
multiple issues, but messages cannot be edited. I could submit a 
metatracker issue, but they seen to get less response than tracker issues.

-- 
Terry Jan Reedy


From ether.joe at gmail.com  Sat Aug 15 20:24:55 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Sat, 15 Aug 2015 11:24:55 -0700
Subject: [Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)
In-Reply-To: <mqktn2$c66$1@ger.gmane.org>
References: <BA42DDB0-D73E-41FE-B00F-17FD59AFEBF4@codingclub.co.uk>
 <mprt8o$5pr$1@ger.gmane.org>
 <47246654-4C11-41FB-98AB-A7FE79304E8B@markroseman.com>
 <CAM=hmROJyO22Dn7k6583hEO-H+Vp43pGkq5Jd35dAw5GByCLqQ@mail.gmail.com>
 <CAM=hmROiC-25aTDTXEKc9M=xQQVgfM6nngSQVHQR6raxz-qpog@mail.gmail.com>
 <mq1eii$cg3$1@ger.gmane.org>
 <31546773-50EB-4874-B8E7-6C5CF149282E@markroseman.com>
 <018DB779-FC43-4029-B5CD-F829BDCA6E22@codebykevin.com>
 <57AB08D5-0D0B-4424-BE12-33352C5CCDBE@codingclub.co.uk>
 <CAFwVEOT50zZ7_9UybbqtvRXJy+NODgNX=Jj54DEcQC08EeeoZQ@mail.gmail.com>
 <CAOFf2a1T=h=rQqLhe-ni_f-kUaSSOwGG82PUyaYjHP2ONMBZ3A@mail.gmail.com>
 <mqgci9$p4h$1@ger.gmane.org>
 <CAFwVEOQWK5g756dN_NX6GQ0FBe3PctJ8N_7W4L-r0xtiU-tHoQ@mail.gmail.com>
 <CAM=hmRPczPhirboACSkAuDek87Jtf8SSmEPScsfg+A0ZHXtQMw@mail.gmail.com>
 <mqktn2$c66$1@ger.gmane.org>
Message-ID: <CAOFf2a1cqHvrjN0X=pKyyaPHzyvYW1KUy9q5uF1XjN1mpDJ4Og@mail.gmail.com>

Sorry, looking back on my post I think it could be interpreted as
sarcastic. Actually I was completely serious -- I use IDLE on the Mac and
Vim as my main editor at my job.

So yah, seriously, I love vim and idle. Always great to see more interest.
On Aug 14, 2015 7:24 AM, "Terry Reedy" <tjreedy at udel.edu> wrote:

> On 8/13/2015 12:56 PM, Al Sweigart wrote:
>
>> In general, it seems that most experienced developers either want a full
>> featured IDE like Eclipse or PyCharm, or they want something simpler in
>> which case they go with a text editor like Vim or Sublime Text. Idle
>> can't (and shouldn't) compete with either of those categories.
>>
>
> I agree. Idle fills a niche in between those categories -- a simple
> python-only ide.  On Windows at least, it is also a replacement for the
> wretched interactive console.
>
> --
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150815/c26195e0/attachment.html>

From mark at markroseman.com  Thu Aug 20 03:35:54 2015
From: mark at markroseman.com (Mark Roseman)
Date: Wed, 19 Aug 2015 18:35:54 -0700
Subject: [Idle-dev] stack viewer vs. debugger
Message-ID: <3528D5CC-6BAA-4B57-9697-8F1828C19EBB@markroseman.com>

Innocent question? why are the ?stack viewer? and the ?debugger? two different things?


From tjreedy at udel.edu  Thu Aug 20 08:57:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 20 Aug 2015 02:57:19 -0400
Subject: [Idle-dev] stack viewer vs. debugger
In-Reply-To: <3528D5CC-6BAA-4B57-9697-8F1828C19EBB@markroseman.com>
References: <3528D5CC-6BAA-4B57-9697-8F1828C19EBB@markroseman.com>
Message-ID: <mr3toh$6t3$1@ger.gmane.org>

On 8/19/2015 9:35 PM, Mark Roseman wrote:
> Innocent question? why are the ?stack viewer? and the ?debugger? two different things?

What sort of answer do you want?  Because they do different things? 
Because they are two different (and incomplete) experiments?

I think the stackviewer will actually be useful once simplified by 
removing noise.
<http://bugs.python.org/issue24790>





-- 
Terry Jan Reedy



From mark at markroseman.com  Thu Aug 20 15:53:40 2015
From: mark at markroseman.com (Mark Roseman)
Date: Thu, 20 Aug 2015 06:53:40 -0700
Subject: [Idle-dev] stack viewer vs. debugger
In-Reply-To: <mr3toh$6t3$1@ger.gmane.org>
References: <3528D5CC-6BAA-4B57-9697-8F1828C19EBB@markroseman.com>
 <mr3toh$6t3$1@ger.gmane.org>
Message-ID: <438AE350-DF6C-4C8B-9800-20561B6592DA@markroseman.com>

On Aug 19, 2015, at 11:57 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/19/2015 9:35 PM, Mark Roseman wrote:
>> Innocent question? why are the ?stack viewer? and the ?debugger? two different things?
> 
> What sort of answer do you want?  Because they do different things? Because they are two different (and incomplete) experiments?
> 
> I think the stackviewer will actually be useful once simplified by removing noise.
> <http://bugs.python.org/issue24790>


They both show a stack trace. They both let you look at locals and globals at each stack frame.

Yet they?re different windows, with different user interfaces. I?d like to know if there?s a reason that if you get an exception it wouldn?t just show up in the debugger window instead of what it does now. It doesn?t make sense to me and I don?t recall seeing anything similar elsewhere. 

If it?s just because they were two independent hacks, that?s fine. And I get that there may be two different underlying mechanisms that they use to extract the data from the program state or exception. But is there any reason they couldn?t (shouldn?t) be unified as far as the user is concerned?

Mark


From mark at markroseman.com  Fri Aug 21 01:19:29 2015
From: mark at markroseman.com (Mark Roseman)
Date: Thu, 20 Aug 2015 16:19:29 -0700
Subject: [Idle-dev] mockup of shell/editor/debugger integration
Message-ID: <7423AC38-534A-4E44-88BE-E08D34EAEF58@markroseman.com>

I spent a couple of hours today coding up a mockup of what I think would be possible to do as far as (optional) single window integration.  Screenshot here:

	http://www.tkdocs.com/images/idle_onewindow.png

Amount of space for each area is user controlled.  And this would also nicely complement doing a tabbed editor thing for the top part of the window of course. 

Thoughts??

Mark



From tjreedy at udel.edu  Fri Aug 21 02:50:06 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 20 Aug 2015 20:50:06 -0400
Subject: [Idle-dev] stack viewer vs. debugger
In-Reply-To: <438AE350-DF6C-4C8B-9800-20561B6592DA@markroseman.com>
References: <3528D5CC-6BAA-4B57-9697-8F1828C19EBB@markroseman.com>
 <mr3toh$6t3$1@ger.gmane.org>
 <438AE350-DF6C-4C8B-9800-20561B6592DA@markroseman.com>
Message-ID: <mr5sk1$eck$1@ger.gmane.org>

On 8/20/2015 9:53 AM, Mark Roseman wrote:
> On Aug 19, 2015, at 11:57 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 8/19/2015 9:35 PM, Mark Roseman wrote:
>>> Innocent question? why are the ?stack viewer? and the ?debugger?
>>> two different things?
>>
>> What sort of answer do you want?  Because they do different things?
>> Because they are two different (and incomplete) experiments?
>>
>> I think the stackviewer will actually be useful once simplified by
>> removing noise. <http://bugs.python.org/issue24790>

Rearranging your post ...

 > If it?s just because they were two independent hacks, that?s fine.

Let us take that as the historical reason and leave it at that.

 > But is there any reason they couldn?t (shouldn?t) be unified as
 > far as the user is concerned?

Based on my newly acquired knowledge of StackViewer and a careful 
comparison with Debugger UI, I believe they can be unified and therefore 
should be unified, using the 'best' features of each.

 > And I get that there may be two different underlying mechanisms that
 > they use to extract the data from the program state or exception.

The new UI would need a new mode attribute to take care of this.  The 
mode would also determine title and whether the debugger control panel 
is displayed.

 > They both show a stack trace. They both let you look at locals and
> globals at each stack frame.

Stackviewer allows users to see multiple globals and locals, debugger 
one of each.  As explained on the stackviewer issue, I think the merged 
UI should display one globals and possible many locals. The values 
corresponding to names should be displayed the way debugger does it. I 
said more on the stackviewer issue.

-- 
Terry Jan Reedy



From interstar at gmail.com  Fri Aug 21 05:10:28 2015
From: interstar at gmail.com (phil jones)
Date: Fri, 21 Aug 2015 00:10:28 -0300
Subject: [Idle-dev] mockup of shell/editor/debugger integration
In-Reply-To: <7423AC38-534A-4E44-88BE-E08D34EAEF58@markroseman.com>
References: <7423AC38-534A-4E44-88BE-E08D34EAEF58@markroseman.com>
Message-ID: <CAP97Hn=UURAd74ynmN_iYb3K4ES3XonD+T0WPYfhvfqL+MUFkw@mail.gmail.com>

I like the "tape" controls at the top of the debugger.

How about a permanent bar with tape-controls for run and stop at the top of
the window, with extra debugger buttons appearing when relevant?

Phil

On 20 August 2015 at 20:19, Mark Roseman <mark at markroseman.com> wrote:

> I spent a couple of hours today coding up a mockup of what I think would
> be possible to do as far as (optional) single window integration.
> Screenshot here:
>
>         http://www.tkdocs.com/images/idle_onewindow.png
>
> Amount of space for each area is user controlled.  And this would also
> nicely complement doing a tabbed editor thing for the top part of the
> window of course.
>
> Thoughts??
>
> Mark
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150821/993663e5/attachment.html>

From tjreedy at udel.edu  Thu Aug 27 20:44:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Aug 2015 14:44:19 -0400
Subject: [Idle-dev] ttk on linux
Message-ID: <mrnlqb$7e1$1@ger.gmane.org>

I just posted this on pydev

---
None of the linux buildbots run with X enabled.  Consequently none of 
the tkinter (or tkinter user) gui tests are run on Linux.  It was thus 
pointed out to me, during discussion of using ttk widgets in Idle, that 
we do not really know if ttk works on the variety of Linux systems 
(beyond the one Serhiy uses) and that I should look into this.

I asked on python-list for help, by linux users running
python3 -m test -ugui test_tk test_ttk_guionly test_idle

Seven people did so with Debian Jessie, Debian Wheezy, Gentoo, Mint, 
openSUSE, and Ubuntu (x2). One machine failed once with the ttk test, 
and then passed.  Another failed the tk test until a mis-configuration 
was fixed.  So tkinter, and ttk in particular, seems to be working on linux.
---

So I will start looking at use-ttk patches.

-- 
Terry Jan Reedy


From mark at markroseman.com  Thu Aug 27 21:06:35 2015
From: mark at markroseman.com (Mark Roseman)
Date: Thu, 27 Aug 2015 12:06:35 -0700
Subject: [Idle-dev] ttk on linux
In-Reply-To: <mrnlqb$7e1$1@ger.gmane.org>
References: <mrnlqb$7e1$1@ger.gmane.org>
Message-ID: <68609760-7CE7-4FC7-8BD3-523C2B284FA9@markroseman.com>

Awesome, thanks for doing that Terry!  Please let me know what else you?ll need regarding any of the newer pieces?
Mark


From al at inventwithpython.com  Thu Aug 27 22:04:47 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Thu, 27 Aug 2015 13:04:47 -0700
Subject: [Idle-dev] ttk on linux
In-Reply-To: <68609760-7CE7-4FC7-8BD3-523C2B284FA9@markroseman.com>
References: <mrnlqb$7e1$1@ger.gmane.org>
 <68609760-7CE7-4FC7-8BD3-523C2B284FA9@markroseman.com>
Message-ID: <CAM=hmROK_GMkSkE6UQFTBkC_VWFC08UWe0byz9Ceyei7X-L6Lw@mail.gmail.com>

Thanks, Terry!

On Thu, Aug 27, 2015 at 12:06 PM, Mark Roseman <mark at markroseman.com> wrote:

> Awesome, thanks for doing that Terry!  Please let me know what else you?ll
> need regarding any of the newer pieces?
> Mark
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150827/6cd0de85/attachment.html>

From tjreedy at udel.edu  Thu Aug 27 23:49:18 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Aug 2015 17:49:18 -0400
Subject: [Idle-dev] Opinions wanted: RESTART label
Message-ID: <mro0l6$rht$1@ger.gmane.org>

In https://bugs.python.org/issue21192, I changed the label from a constant

 >>> ===================================RESTART=======================

to a more imformative

 >>>
=============================== RESTART Shell =========================
 >>>
====================== RUN C:\Programs\Python34\tem.py =================
'output from tem.py'
 >>>

Raymond Hettinger, in a message near the end, after the ACKS commit, 
says that some people found the change 'confusing'. I've posted a patch 
to change the above to

 >>>
=============================== RESTART: Shell =========================
 >>>
================ RESTART: C:\Programs\Python34\tem.py =================
'output from tem.py'
 >>>

Any bikeshed opinions before I commit this?

When I did the original patch I was not thinking about
a) When running Idle in one process with -n, 'Run Module F5' does not 
restart the shell, but rather, it runs the file in the current session.
b) We might want to add the ability to do this (Run in Session) even 
when running with a subprocess.  I have thought of this before, but 
msg249045, 3 days ago, on the remove -n issue
https://bugs.python.org/issue16123
brought it back to mind.

-- 
Terry Jan Reedy


From mark at markroseman.com  Mon Aug 31 21:44:27 2015
From: mark at markroseman.com (Mark Roseman)
Date: Mon, 31 Aug 2015 12:44:27 -0700
Subject: [Idle-dev] walkthrough/snapshot of IDLE user interface improvements
	to date
Message-ID: <4508C042-0ECC-4E69-BD54-F68299B2269C@markroseman.com>

As I?ve been making changes to various pieces of IDLE?s user interface, I?ve been documenting the updates in the form of a case study. I hope that will be useful to others modernizing a Tk-based application. I?ve put a draft of that, as well as a snapshot of the current code, here:

	http://www.tkdocs.com/tutorial/idle.html

I?m looking forward to helping do whatever I can to migrate some of these changes into IDLE?s official codebase. But in the meantime if anyone can take a read or try the code, that would be great!

Some of the deeper changes to allow (cleanly) for more of a single window model will probably have to wait until a few more of these preliminaries find their way in.

Mark