From tjreedy at udel.edu  Fri Oct  2 23:15:14 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 2 Oct 2015 17:15:14 -0400
Subject: [Idle-dev] IDLE: Integrated Development and Learning Environment?
Message-ID: <560EF3E2.1060300@udel.edu>

I propose that IDLE be renamed or at least viewed as a acronym for 
"Integrated Development and Learning Environment".  (See below for 
history.) The specific change would be to make the first line of 
idle.rst and derivatives read (something like) "IDLE is an Integrated 
Development and Learning Environment for Python, writen in Python with 
the tkinter GUI package."

Besides making 'IDLE' a proper acronym, this would better express what 
IDLE is meant to be, at least now.  A year ago, for instance, we added 
'Turtle Demo' to the IDLE menu for instructional, rather than program 
development purposes.

For another example, Mark and I hope to improve visualization of a 
program in action by adding a slowed-down run mode that highlights 
source lines (just as in manual mode now).  In other words, 
slideshow-like intelligent auto-stepping. https://bugs.python.org/issue25146
To me, this is as much for learning as for development of a specific 
program.  I think it would work well with Turtle demos and algorithm 
visualization demos.

The old version of README.txt (before the change a couple of days ago) 
starts "IDLE is Python's Tkinter-based Integrated DeveLopment 
Environment."  Note the capital 'L' in 'DeveLopement'.

help.txt and the derived idle.rst and help.html start "IDLE is the 
Python IDE built with the tkinter GUI toolkit.

-- 
Terry Jan Reedy


From mark at markroseman.com  Fri Oct  2 23:50:07 2015
From: mark at markroseman.com (Mark Roseman)
Date: Fri, 2 Oct 2015 14:50:07 -0700
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <560EF3E2.1060300@udel.edu>
References: <560EF3E2.1060300@udel.edu>
Message-ID: <40F1B251-3067-4865-9628-14D896B0E6B5@markroseman.com>

I like the idea of the name change, and that it encompasses ?learning'. As far as tag lines go, I?d be more inclined towards something like ?IDLE is Python?s Integrated Development and Learning Environment? (i.e. the tkinter stuff isn?t hugely important to the user audience, and the possessive ?Python?s? captures the ?for Python? as well as it?s built-in as part of Python.

Mark



> On Oct 2, 2015, at 2:15 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> I propose that IDLE be renamed or at least viewed as a acronym for "Integrated Development and Learning Environment".  (See below for history.) The specific change would be to make the first line of idle.rst and derivatives read (something like) "IDLE is an Integrated Development and Learning Environment for Python, writen in Python with the tkinter GUI package."


From interstar at gmail.com  Sat Oct  3 00:32:34 2015
From: interstar at gmail.com (phil jones)
Date: Fri, 2 Oct 2015 19:32:34 -0300
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <40F1B251-3067-4865-9628-14D896B0E6B5@markroseman.com>
References: <560EF3E2.1060300@udel.edu>
 <40F1B251-3067-4865-9628-14D896B0E6B5@markroseman.com>
Message-ID: <CAP97HnkGrCAtD_0m_RvPhdsrqnTpc0ohQKmu7m78KuYPhom20Q@mail.gmail.com>

"Integrated Development and Learning Environment" sounds excellent to me
... gets my vote.

On 2 October 2015 at 18:50, Mark Roseman <mark at markroseman.com> wrote:

> I like the idea of the name change, and that it encompasses ?learning'. As
> far as tag lines go, I?d be more inclined towards something like ?IDLE is
> Python?s Integrated Development and Learning Environment? (i.e. the tkinter
> stuff isn?t hugely important to the user audience, and the possessive
> ?Python?s? captures the ?for Python? as well as it?s built-in as part of
> Python.
>
> Mark
>
>
>
> > On Oct 2, 2015, at 2:15 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> > I propose that IDLE be renamed or at least viewed as a acronym for
> "Integrated Development and Learning Environment".  (See below for
> history.) The specific change would be to make the first line of idle.rst
> and derivatives read (something like) "IDLE is an Integrated Development
> and Learning Environment for Python, writen in Python with the tkinter GUI
> package."
>
> _______________________________________________
> 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/20151002/4cb598d0/attachment.html>

From tjreedy at udel.edu  Sat Oct  3 00:38:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 2 Oct 2015 18:38:19 -0400
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <40F1B251-3067-4865-9628-14D896B0E6B5@markroseman.com>
References: <560EF3E2.1060300@udel.edu>
 <40F1B251-3067-4865-9628-14D896B0E6B5@markroseman.com>
Message-ID: <mun113$pp6$1@ger.gmane.org>

On 10/2/2015 5:50 PM, Mark Roseman wrote:
> I like the idea of the name change, and that it encompasses
> ?learning'. As far as tag lines go, I?d be more inclined towards
> something like ?IDLE is Python?s Integrated Development and Learning
> Environment? (i.e. the tkinter stuff isn?t hugely important to the
> user audience, and the possessive ?Python?s? captures the ?for
> Python? as well as it?s built-in as part of Python.

OK.  The tkinter/tk part is not needed here in the user doc.  It is only 
really needed later to explain why IDLE windows, and in particular the 
Shell, act a bit differently from a console/terminal window.

>> On Oct 2, 2015, at 2:15 PM, Terry Reedy <tjreedy at udel.edu> wrote: I
>> propose that IDLE be renamed or at least viewed as a acronym for
>> "Integrated Development and Learning Environment".  (See below for
>> history.) The specific change would be to make the first line of
>> idle.rst and derivatives read (something like) "IDLE is an
>> Integrated Development and Learning Environment for Python, writen
>> in Python with the tkinter GUI package."

-- 
Terry Jan Reedy



From guido at python.org  Sat Oct  3 00:45:12 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 2 Oct 2015 15:45:12 -0700
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <560EF3E2.1060300@udel.edu>
References: <560EF3E2.1060300@udel.edu>
Message-ID: <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>

I like it. Though of course it's really named after Eric Idle. :-)

On Fri, Oct 2, 2015 at 2:15 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> I propose that IDLE be renamed or at least viewed as a acronym for
> "Integrated Development and Learning Environment".  (See below for
> history.) The specific change would be to make the first line of idle.rst
> and derivatives read (something like) "IDLE is an Integrated Development
> and Learning Environment for Python, writen in Python with the tkinter GUI
> package."
>
> Besides making 'IDLE' a proper acronym, this would better express what
> IDLE is meant to be, at least now.  A year ago, for instance, we added
> 'Turtle Demo' to the IDLE menu for instructional, rather than program
> development purposes.
>
> For another example, Mark and I hope to improve visualization of a program
> in action by adding a slowed-down run mode that highlights source lines
> (just as in manual mode now).  In other words, slideshow-like intelligent
> auto-stepping. https://bugs.python.org/issue25146
> To me, this is as much for learning as for development of a specific
> program.  I think it would work well with Turtle demos and algorithm
> visualization demos.
>
> The old version of README.txt (before the change a couple of days ago)
> starts "IDLE is Python's Tkinter-based Integrated DeveLopment
> Environment."  Note the capital 'L' in 'DeveLopement'.
>
> help.txt and the derived idle.rst and help.html start "IDLE is the Python
> IDE built with the tkinter GUI toolkit.
>
> --
> 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/20151002/283f6aac/attachment-0001.html>

From tjreedy at udel.edu  Sat Oct  3 00:59:43 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 02 Oct 2015 18:59:43 -0400
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>
References: <560EF3E2.1060300@udel.edu>
 <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>
Message-ID: <560F0C5F.4030602@udel.edu>

On 10/2/2015 6:45 PM, Guido van Rossum wrote:
> I like it. Though of course it's really named after Eric Idle. :-)

Until a couple of days ago, I was planning to propose changing 'IDLE' to 
'Idle', which is what I have writen.  I am willing to go with that 
change instead.  But I presumed that you must have preferred the 
all-caps version, or perhaps not directly naming it after Eric, and then 
I thought of how to make 'IDLE' an informative acronym rather than a 
clumbsy semi-acronyn.  So now I prefer to change the interpretation than 
the spelling.

-- 
Terry Jan Reedy


From guido at python.org  Sat Oct  3 02:16:42 2015
From: guido at python.org (Guido van Rossum)
Date: Fri, 2 Oct 2015 17:16:42 -0700
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <560F0C5F.4030602@udel.edu>
References: <560EF3E2.1060300@udel.edu>
 <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>
 <560F0C5F.4030602@udel.edu>
Message-ID: <CAP7+vJJosx-W25shSxH-_otPOPcxpEfWfTZUcFYC6mE-4+VN2w@mail.gmail.com>

I think I was reluctant to name it after a living person. I like the idea
of keeping it all caps and changing the interpretation.

On Fri, Oct 2, 2015 at 3:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 10/2/2015 6:45 PM, Guido van Rossum wrote:
>
>> I like it. Though of course it's really named after Eric Idle. :-)
>>
>
> Until a couple of days ago, I was planning to propose changing 'IDLE' to
> 'Idle', which is what I have writen.  I am willing to go with that change
> instead.  But I presumed that you must have preferred the all-caps version,
> or perhaps not directly naming it after Eric, and then I thought of how to
> make 'IDLE' an informative acronym rather than a clumbsy semi-acronyn.  So
> now I prefer to change the interpretation than the spelling.
>
> --
> Terry Jan Reedy
>
>


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

From ether.joe at gmail.com  Sat Oct  3 03:48:44 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Fri, 2 Oct 2015 18:48:44 -0700
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <CAP7+vJJosx-W25shSxH-_otPOPcxpEfWfTZUcFYC6mE-4+VN2w@mail.gmail.com>
References: <560EF3E2.1060300@udel.edu>
 <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>
 <560F0C5F.4030602@udel.edu>
 <CAP7+vJJosx-W25shSxH-_otPOPcxpEfWfTZUcFYC6mE-4+VN2w@mail.gmail.com>
Message-ID: <CAOFf2a0q8B6aFtVKszbrUMyXnzocYWgQ4qgwRNY8CsTBpfCfjg@mail.gmail.com>

Sounds good to me :)

On Fri, Oct 2, 2015 at 5:16 PM, Guido van Rossum <guido at python.org> wrote:

> I think I was reluctant to name it after a living person. I like the idea
> of keeping it all caps and changing the interpretation.
>
> On Fri, Oct 2, 2015 at 3:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> On 10/2/2015 6:45 PM, Guido van Rossum wrote:
>>
>>> I like it. Though of course it's really named after Eric Idle. :-)
>>>
>>
>> Until a couple of days ago, I was planning to propose changing 'IDLE' to
>> 'Idle', which is what I have writen.  I am willing to go with that change
>> instead.  But I presumed that you must have preferred the all-caps version,
>> or perhaps not directly naming it after Eric, and then I thought of how to
>> make 'IDLE' an informative acronym rather than a clumbsy semi-acronyn.  So
>> now I prefer to change the interpretation than the spelling.
>>
>> --
>> Terry Jan Reedy
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> 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/20151002/9c478115/attachment.html>

From tjreedy at udel.edu  Sat Oct  3 05:39:06 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 2 Oct 2015 23:39:06 -0400
Subject: [Idle-dev] IDLE: Integrated Development and Learning
	Environment?
In-Reply-To: <CAP7+vJJosx-W25shSxH-_otPOPcxpEfWfTZUcFYC6mE-4+VN2w@mail.gmail.com>
References: <560EF3E2.1060300@udel.edu>
 <CAP7+vJL6iBVV6pO05--J8-_PqiHdFEMw-pJyXgWXoX_UdLxtZg@mail.gmail.com>
 <560F0C5F.4030602@udel.edu>
 <CAP7+vJJosx-W25shSxH-_otPOPcxpEfWfTZUcFYC6mE-4+VN2w@mail.gmail.com>
Message-ID: <munil2$anf$1@ger.gmane.org>

On 10/2/2015 8:16 PM, Guido van Rossum wrote:
> I think I was reluctant to name it after a living person. I like the
> idea of keeping it all caps and changing the interpretation.

Done as part of #25224.

-- 
Terry Jan Reedy


From mark at markroseman.com  Mon Oct  5 17:31:54 2015
From: mark at markroseman.com (Mark Roseman)
Date: Mon, 5 Oct 2015 08:31:54 -0700
Subject: [Idle-dev] integration process for new UI changes
Message-ID: <EFECE745-D35C-48B8-BE0F-F18BFF4619AF@markroseman.com>

Not to put words in Terry?s mouth, but I believe he?s almost ready to start looking at integrating some of the broader UI changes I?ve been developing into IDLE. I thought it would therefore be a good time to raise issues surrounding what that process might look like.

While most IDLE changes recently have been in the form of standalone, fairly independent patches, some of this work ?feels? different, more like new, partially experimental, development. In particular:
	* many interdependent pieces, fairly hard to integrate individually
	* parts likely needing usage feedback before being included/finalized (or revised, or excluded)
	* usage and iteration will bring out other issues not yet known
	* limited automated testing, which even if more extensive would be misleading as to ?correctness?

As well, it would seem that a ?(re-)launch? in one form or another would be appropriate to get the word out and generate more interest from potential new helpers. :-)

All of this feels more like an alpha-beta-release process (i.e. the whole thing shows up at once) rather than incremental improvements over time and possibly spanning several Python releases.

From a development point of view, I?d normally approach this as a separate branch in the code repository, which would get integrated into the mainline on release. (I?ve kinda been doing that as I work through things myself, via github). What would be the best way to approach this for IDLE?

One possibility might be integrate things on the main (i.e. 3.6) branch, which I?m presuming won?t have an actual release of any kind for quite some time. 

That lets things get added more incrementally and tested by ourselves and others without it being inadvertently dropped on unsuspecting folk. It would be ok if at various times things were in an incomplete state. 

After a significant amount of integration, refinement and revision we might get to the point where as a group we?re ?satisfied? with the new state of IDLE as a whole, and those changes get ported all at once to 3.5.x and 2.7.x where they?d actually hitting real people.

I?ll throw that out there anyway.  I?m sure others have many different ideas on this. Anyone care to share their thoughts?

Mark


From tjreedy at udel.edu  Sat Oct 10 04:29:40 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 9 Oct 2015 22:29:40 -0400
Subject: [Idle-dev] Running beginner Pythons
Message-ID: <mv9t78$r0e$1@ger.gmane.org>

Reconceptualizing for beginners...

Many people working with kids have asked for various changes to Python 
in order to make it easier for kids, sometimes very young.  Some 
variations have been requested more than once.

1. Simple looping: 'repeat/do/loop/for n [times]:' (take your pick of 
keyword) versus 'for i in range(n):'.

  The latest request is by Andre Roberge, today on python-ideas, in 
"Simpler syntax for basic iterations".  This inspired me to write this 
post.  The education hook he offered is that the variation eliminates 
the need for a loop variable in a context where variables are not 
otherwise used.  He has worked on robot programming for kids.

2. Simple function call: 'move 3', 'turn 90' (Logo, I believe) versus 
'move(3)' 'turn(90)' (Turtle).

3. Simple Native language keywords.  String-within-code translation is 
not suited for this.

These are all things I think are wrong for Python itself but possibly 
right for various learning situations.  For 18 years I have watched 
people try to change Python in ways like the above, when I think the 
energy would be better directed to writing good quality translation 
functions.

Of course, the latter would be more inviting if there were a place to 
plug them in.  I think IDLE is quite well suited to be such a framework. 
It would be possible now for one one alter Idle with a small patch -- if 
the locations were documented.  But I am thinking more about altering 
Idle slightly to make patching unnecessary.

The API for a translation function is trivial: str -> str (or 
SyntaxError with standard details).  Default: "def notran(code): return 
code".  I believe there are 2 places, for Shell and for editor code, 
where this could be called before compiling.  Referring back to the 
variations above...

1. The code for a single new keyword only used at the beginning of lines 
is simple.

def robotrans(codetext):
     out = []
     for i, line in enumerate(codetext.splitlines()):
         if line.startswith('repeat'):
             <check rest of line and either append translation
               or raise SyntaxError with proper details>
         else:
             out.append(line)
     return '\n'.join(outlines)

With a properly initialized SyntaxError, the error location should be 
marked in the editor as it is today.

2. Multiple line-beginning names are a bit harder, but not much, and the 
reformatting of 'name arg' to 'name(arg)' is simpler.

3. Multiple names anywhere are even harder to find, but a single word 
substitution is even easier.

IDLE would need to read, colorize, and write .pyx files.  A hook should 
allow to adjust the list of keywords and builtins.  Multiple plug-ins 
should be allowed.  A .pyx file should identify the plug-in needed to 
run it.

A big issue is whether plug-in code should be in a module to be imported 
or in a config file to be exec'ed, and whether either should be in 
idlelib, .idlers, or in a user-specified directory.

Thoughts welcome.

-- 
Terry Jan Reedy


From interstar at gmail.com  Sat Oct 10 05:27:08 2015
From: interstar at gmail.com (phil jones)
Date: Sat, 10 Oct 2015 00:27:08 -0300
Subject: [Idle-dev] Running beginner Pythons
In-Reply-To: <mv9t78$r0e$1@ger.gmane.org>
References: <mv9t78$r0e$1@ger.gmane.org>
Message-ID: <CAP97HnmvWsSNGb5uib9cqLqqrvwiWSw9am6ribnO0QWyZYsMgw@mail.gmail.com>

Personally I'd say it doesn't smell right to be making a non-standard
Python through a pre-processor that only works in IDLE.

What's wrong with "while" if you want simple loops without getting into
range(n)?

Or just define a couple of new functions that are more English-like?

for i in count_to(4) :
    blah


while repeat_times(4) :
    blah

(where the repeat_times function would have to sneakily set some kind of
global counter that the child never sees).

Alternatively, I'd far rather see Python extended to provide more
"macro-like" behaviour.

One possibility would be block level decorators. I would love to be able to
have something like :

@do_times(4)
block :
   forward(100)
   right(90)

Here, the definition of do_times would look like a normal decorator. But it
would receive the block: as if it were a function that takes no arguments.
With this mechanism you could define quite rich DSLs

Phil


On 9 October 2015 at 23:29, Terry Reedy <tjreedy at udel.edu> wrote:

> Reconceptualizing for beginners...
>
> Many people working with kids have asked for various changes to Python in
> order to make it easier for kids, sometimes very young.  Some variations
> have been requested more than once.
>
> 1. Simple looping: 'repeat/do/loop/for n [times]:' (take your pick of
> keyword) versus 'for i in range(n):'.
>
>  The latest request is by Andre Roberge, today on python-ideas, in
> "Simpler syntax for basic iterations".  This inspired me to write this
> post.  The education hook he offered is that the variation eliminates the
> need for a loop variable in a context where variables are not otherwise
> used.  He has worked on robot programming for kids.
>
> 2. Simple function call: 'move 3', 'turn 90' (Logo, I believe) versus
> 'move(3)' 'turn(90)' (Turtle).
>
> 3. Simple Native language keywords.  String-within-code translation is not
> suited for this.
>
> These are all things I think are wrong for Python itself but possibly
> right for various learning situations.  For 18 years I have watched people
> try to change Python in ways like the above, when I think the energy would
> be better directed to writing good quality translation functions.
>
> Of course, the latter would be more inviting if there were a place to plug
> them in.  I think IDLE is quite well suited to be such a framework. It
> would be possible now for one one alter Idle with a small patch -- if the
> locations were documented.  But I am thinking more about altering Idle
> slightly to make patching unnecessary.
>
> The API for a translation function is trivial: str -> str (or SyntaxError
> with standard details).  Default: "def notran(code): return code".  I
> believe there are 2 places, for Shell and for editor code, where this could
> be called before compiling.  Referring back to the variations above...
>
> 1. The code for a single new keyword only used at the beginning of lines
> is simple.
>
> def robotrans(codetext):
>     out = []
>     for i, line in enumerate(codetext.splitlines()):
>         if line.startswith('repeat'):
>             <check rest of line and either append translation
>               or raise SyntaxError with proper details>
>         else:
>             out.append(line)
>     return '\n'.join(outlines)
>
> With a properly initialized SyntaxError, the error location should be
> marked in the editor as it is today.
>
> 2. Multiple line-beginning names are a bit harder, but not much, and the
> reformatting of 'name arg' to 'name(arg)' is simpler.
>
> 3. Multiple names anywhere are even harder to find, but a single word
> substitution is even easier.
>
> IDLE would need to read, colorize, and write .pyx files.  A hook should
> allow to adjust the list of keywords and builtins.  Multiple plug-ins
> should be allowed.  A .pyx file should identify the plug-in needed to run
> it.
>
> A big issue is whether plug-in code should be in a module to be imported
> or in a config file to be exec'ed, and whether either should be in idlelib,
> .idlers, or in a user-specified directory.
>
> Thoughts welcome.
>
> --
> 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/20151010/1fa833db/attachment.html>

From Bruce_Sherwood at ncsu.edu  Sat Oct 10 05:32:36 2015
From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood)
Date: Fri, 9 Oct 2015 21:32:36 -0600
Subject: [Idle-dev] Running beginner Pythons
In-Reply-To: <CAP97HnmvWsSNGb5uib9cqLqqrvwiWSw9am6ribnO0QWyZYsMgw@mail.gmail.com>
References: <mv9t78$r0e$1@ger.gmane.org>
 <CAP97HnmvWsSNGb5uib9cqLqqrvwiWSw9am6ribnO0QWyZYsMgw@mail.gmail.com>
Message-ID: <CAFDG03j9+FUsjixRZb=vfvoPCO4fF7Xxm_N=iAUZzC_KEfbjkA@mail.gmail.com>

For what it's worth: Science and engineering students in the college intro
physics course who use Python (VPython) to model physical systems typically
have no prior programming experience, so it is necessary in a crowded
physics curriculum to teach them only a very small minimalist subset of
Python programming concepts and forms. It is possible to go a very long
ways with "while" being the only iteration mechanism.

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

From tjreedy at udel.edu  Sat Oct 10 06:31:07 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Oct 2015 00:31:07 -0400
Subject: [Idle-dev] Running beginner Pythons
In-Reply-To: <CAP97HnmvWsSNGb5uib9cqLqqrvwiWSw9am6ribnO0QWyZYsMgw@mail.gmail.com>
References: <mv9t78$r0e$1@ger.gmane.org>
 <CAP97HnmvWsSNGb5uib9cqLqqrvwiWSw9am6ribnO0QWyZYsMgw@mail.gmail.com>
Message-ID: <mva4av$oab$1@ger.gmane.org>

On 10/9/2015 11:27 PM, phil jones wrote:
> Personally I'd say it doesn't smell right to be making a non-standard
> Python through a pre-processor that only works in IDLE.

A code translation function can be used anywhere one apply it.  Is it 
better for a non-standard Python to only work in a non-standard 
framework, rather than IDLE?  The answer partly depends on whether one 
approves or disapproves of training wheels, and wants to encourage or 
discourage their production, by making it easier or keeping it hard.


> What's wrong with "while" if you want simple loops without getting into
> range(n)?

Ask that of Andre Roberge on python-ideas ;-).

> Or just define a couple of new functions that are more English-like?
>
> for i in count_to(4) :
>      blah
>
>
> while repeat_times(4) :
>      blah
>
> (where the repeat_times function would have to sneakily set some kind of
> global counter that the child never sees).

Discussion of alternatives to Andre's proposal really belongs on the 
python-ideas list.  I am not the one that needs to be convinced.  As 
with this one, it is easily accessed via news.gmane.org as 
gmane.comp.python.ideas.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sat Oct 10 21:18:21 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Oct 2015 15:18:21 -0400
Subject: [Idle-dev] Running beginner Pythons
In-Reply-To: <mv9t78$r0e$1@ger.gmane.org>
References: <mv9t78$r0e$1@ger.gmane.org>
Message-ID: <mvboah$fm$1@ger.gmane.org>

On 10/9/2015 10:29 PM, Terry Reedy wrote:
> Reconceptualizing for beginners...
>
> Many people working with kids have asked for various changes to Python
> in order to make it easier for kids, sometimes very young.  Some
> variations have been requested more than once.
>
> 1. Simple looping:
> 2. Simple function call:
> 3. Simple Native language keywords.

4. Visible leading spaces (or even all spaces).  There is a unicode 
small middle dot char that is suitable for this.  It would have to be 
translated back to space before feeding to compile.  This could be a 
one-off hard-coded mechanism, but I would rather add a generic mechanism.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sat Oct 10 22:05:24 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Oct 2015 16:05:24 -0400
Subject: [Idle-dev] PSF Education WG Kids IDE
Message-ID: <mvbr2o$7qc$1@ger.gmane.org>

Nick Coughlin emailed me this link
https://docs.google.com/document/d/1rXM2-Up59PbOEXqZHbo_jj-zPFkhc---kVVMinPp6M4/edit

I believe everything on their wishlist is either more or less present or 
on our collective todo list, with the exception of replacing the menus 
with tool bar buttons.  That should be easy enough.

I am NOT suggesting that IDLE should be hard-coded to match a particular 
design like this.  Even members of this working group are not going to 
agree on every detail.  And clearly, experimentation is needed in real 
classrooms.  I am suggesting that IDLE should be more easily configured 
to meet different needs.

-- 
Terry Jan Reedy


From andre.roberge at gmail.com  Sun Oct 11 19:19:47 2015
From: andre.roberge at gmail.com (=?utf-8?b?QW5kcsOp?= Roberge)
Date: Sun, 11 Oct 2015 17:19:47 +0000 (UTC)
Subject: [Idle-dev] Running beginner Pythons
References: <mv9t78$r0e$1@ger.gmane.org>
Message-ID: <loom.20151011T184912-538@post.gmane.org>

Terry Reedy <tjreedy <at> udel.edu> writes:

> 
> Reconceptualizing for beginners...
> 
> Many people working with kids have asked for various changes to Python 
> in order to make it easier for kids, sometimes very young.  Some 
> variations have been requested more than once.
> 
> 1. Simple looping: 'repeat/do/loop/for n [times]:' (take your pick of 
> keyword) versus 'for i in range(n):'.
> 
>   The latest request is by Andre Roberge, today on python-ideas, in 
> "Simpler syntax for basic iterations".  This inspired me to write this 
> post.  The education hook he offered is that the variation eliminates 
> the need for a loop variable in a context where variables are not 
> otherwise used.  He has worked on robot programming for kids.

Thanks for bringing this topic here and making me aware of this 
discussion.

> 
> 2. Simple function call: 'move 3', 'turn 90' (Logo, I believe) versus 
> 'move(3)' 'turn(90)' (Turtle).
> 
> 3. Simple Native language keywords.  String-within-code translation is 
> not suited for this.

Since you asked for "our thoughts": 
I would not use these myself, even when teaching in French to children
that do not know English.  I like the idea of using a "real programming
 language" that children can easily grow into.  
This is what motivated to create RUR-PLE originally 
(a Karel the robot implementation in Python) even though I was
aware of the existence of the Python-like Guido van Robot.  

> 
> These are all things I think are wrong for Python itself but possibly 
> right for various learning situations.  For 18 years I have watched 
> people try to change Python in ways like the above, when I think the 
> energy would be better directed to writing good quality translation 
> functions.
> 
> Of course, the latter would be more inviting if there were a place to 
> plug them in.  I think IDLE is quite well suited to be such a 
framework. 
> It would be possible now for one one alter Idle with a small patch -- 
if 
> the locations were documented.  But I am thinking more about altering 
> Idle slightly to make patching unnecessary.
> 

[snip]

While I am definitely in favour of improving IDLE, 
I'm wondering if it would be possible to have an independent method,
something like the __future__ module that could be imported within
any context (i.e. not limited to IDLE), 
either explicitly (by the programmer) or implicitly
(by the environment).  I'm thinking of how one can, for example, write

from __future__ import print_funtion

to change the syntax used.  

In Reeborg's World (http://reeborg.ca/world.html), which also has
a complete separate French version (http://reeborg.ca/monde.html),
I have used this approach to make the functions defined in one language 
available in the other environment 
(and automatically updating the "help").  
The required line of code is something like

from reeborg_en import *

(reeborg_fr also exists; reeborg_es was working ... but is now broken.)

These imports do not modify the syntax, as it is pure Python
(except for implementing "repeat n:" 
instead of "for var in range(n):" yesterday...)
but they could easily be used to modify the syntax as well.

Currently, they are tied to the web environment, but they could, 
in theory, be made
into some independent module, useable anywhere (e.g. within IDLE...).

> 
> IDLE would need to read, colorize, and write .pyx files.  

Isn't the .pyx extension already used by cython?

Andr? Roberge

> Thoughts welcome.
> -- 
> Terry Jan Reedy


From storchaka at gmail.com  Mon Oct 12 07:35:44 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 08:35:44 +0300
Subject: [Idle-dev] Running beginner Pythons
In-Reply-To: <mv9t78$r0e$1@ger.gmane.org>
References: <mv9t78$r0e$1@ger.gmane.org>
Message-ID: <mvfgrh$csv$1@ger.gmane.org>

On 10.10.15 05:29, Terry Reedy wrote:
> Reconceptualizing for beginners...
>
> Many people working with kids have asked for various changes to Python
> in order to make it easier for kids, sometimes very young.  Some
> variations have been requested more than once.
>
> 1. Simple looping: 'repeat/do/loop/for n [times]:' (take your pick of
> keyword) versus 'for i in range(n):'.
>
>   The latest request is by Andre Roberge, today on python-ideas, in
> "Simpler syntax for basic iterations".  This inspired me to write this
> post.  The education hook he offered is that the variation eliminates
> the need for a loop variable in a context where variables are not
> otherwise used.  He has worked on robot programming for kids.
>
> 2. Simple function call: 'move 3', 'turn 90' (Logo, I believe) versus
> 'move(3)' 'turn(90)' (Turtle).
>
> 3. Simple Native language keywords.  String-within-code translation is
> not suited for this.
>
> These are all things I think are wrong for Python itself but possibly
> right for various learning situations.  For 18 years I have watched
> people try to change Python in ways like the above, when I think the
> energy would be better directed to writing good quality translation
> functions.

I would suggest to use other programming language. Logo or like. May be 
Ruby or Tcl. They have simple looping and simple function call, there 
are localized Logo dialects, and it is easy to localize Ruby and Tcl.

Please don't touch IDLE. At least while it is a part of Python. IDLE is 
*Python's* Integrated Development and Learning Environment, not Logo's, 
and shouldn't learn non-Python syntax.



From mark at markroseman.com  Thu Oct 22 18:25:43 2015
From: mark at markroseman.com (Mark Roseman)
Date: Thu, 22 Oct 2015 09:25:43 -0700
Subject: [Idle-dev] pending changes
Message-ID: <CB3ECBA0-91F8-4CCF-AA25-B36EE711657E@markroseman.com>

A few incremental issues still to be reviewed/integrated:

24455 (fix-mainloop2.patch) fix debugger crash caused by nested main loops
25313 (missingtheme.patch) isolate code to default to ?idle classic? on missing theme in one place
24750 (mainwin3.patch) correct visual inconsistencies in editor window (most jarring and noticeable on mac)

As my last message regarding integration plans for the broader changes (ttk integration, various redesigns, etc.) landed with a resounding thud, let me ask a simpler question:

	Can we begin to start checking in these changes into a non-shipping branch (e.g. 3.6), and when those changes reach a ?good enough feature complete? point they are ported en masse to shipping branch(es)?

As a reminder, a running snapshot with these improvements can be found at https://github.com/roseman/idle <https://github.com/roseman/idle>

Mark

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

From tjreedy at udel.edu  Mon Oct 26 01:15:56 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 26 Oct 2015 01:15:56 -0400
Subject: [Idle-dev] pending changes
In-Reply-To: <CB3ECBA0-91F8-4CCF-AA25-B36EE711657E@markroseman.com>
References: <CB3ECBA0-91F8-4CCF-AA25-B36EE711657E@markroseman.com>
Message-ID: <n0kcug$rkk$1@ger.gmane.org>

On 10/22/2015 12:25 PM, Mark Roseman wrote:
> A few incremental issues still to be reviewed/integrated:
>
> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main loops
> 25313 (missingtheme.patch) isolate code to default to ?idle classic? on
> missing theme in one place
> 24750 (mainwin3.patch) correct visual inconsistencies in editor window
> (most jarring and noticeable on mac)
>
> As my last message regarding integration plans for the broader changes
> (ttk integration, various redesigns, etc.) landed with a resounding
> thud, let me ask a simpler question:
>
> Can we begin to start checking in these changes into a non-shipping
> branch (e.g. 3.6), and when those changes reach a ?good enough feature
> complete? point they are ported en masse to shipping branch(es)?
>
> As a reminder, a running snapshot with these improvements can be found
> at https://github.com/roseman/idle

I will look at at least one of those tomorrow (later today, actually).

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Tue Oct 27 05:27:24 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 27 Oct 2015 05:27:24 -0400
Subject: [Idle-dev] pending changes
In-Reply-To: <n0kcug$rkk$1@ger.gmane.org>
References: <CB3ECBA0-91F8-4CCF-AA25-B36EE711657E@markroseman.com>
 <n0kcug$rkk$1@ger.gmane.org>
Message-ID: <n0ng1s$804$1@ger.gmane.org>

On 10/26/2015 1:15 AM, Terry Reedy wrote:
> On 10/22/2015 12:25 PM, Mark Roseman wrote:
>> A few incremental issues still to be reviewed/integrated:

Since pushing 12+ patches for 10 issues in 2 weeks (September/October), 
I have focused on Python/IDLE startup problems.  The changes for Windows 
in 3.5.0 introduced some new ones, some of which affect IDLE.  For 
instance, when IDLE starts from the icon, the usual case, it starts in 
/Windows/system32 instead of the install directory.  Two or three people 
reported problems with this.  These multiple unanticipated new problems 
have made me a bit more cautious.  Making IDLE pretty is not much good 
if people cannot run it.

>> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main
>> loops
>> 25313 (missingtheme.patch) isolate code to default to ?idle classic? on
>> missing theme in one place

I am nearly done with my alternative patch.  That is about next on my 
agenda.

>> 24750 (mainwin3.patch) correct visual inconsistencies in editor window
>> (most jarring and noticeable on mac

>> As my last message regarding integration plans for the broader changes
>> (ttk integration, various redesigns, etc.) landed with a resounding
>> thud,

idledev has mostly been quiet (dead) since I started reading it, early 
2013.  Last August was the liveliest month I have seen, not at all 
normal.  I still intend to comment on your recent posts.

>> Can we begin to start checking in these changes into a non-shipping
>> branch (e.g. 3.6), and when those changes reach a ?good enough feature
>> complete? point they are ported en masse to shipping branch(es)?

I want to continue with incremental patches for now.  Undertested 
re-writes tend to have unanticipated problems.

>> As a reminder, a running snapshot with these improvements can be found
>> at https://github.com/roseman/idle
>
> I will look at at least one of those tomorrow (later today, actually).

I instead wrote and pushed a patch inspired by a beginner who posted on 
python-list. I also researched and opened 
https://bugs.python.org/issue25488 about sys.path and possible buggy 
behavior.

-- 
Terry Jan Reedy



From mark at markroseman.com  Tue Oct 27 14:30:23 2015
From: mark at markroseman.com (Mark Roseman)
Date: Tue, 27 Oct 2015 11:30:23 -0700
Subject: [Idle-dev] pending changes
In-Reply-To: <n0ng1s$804$1@ger.gmane.org>
References: <CB3ECBA0-91F8-4CCF-AA25-B36EE711657E@markroseman.com>
 <n0kcug$rkk$1@ger.gmane.org> <n0ng1s$804$1@ger.gmane.org>
Message-ID: <777DB9D8-2869-42DB-8064-E2D409828403@markroseman.com>

On Oct 27, 2015, at 2:27 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> As my last message regarding integration plans for the broader changes
>>> (ttk integration, various redesigns, etc.) landed with a resounding
>>> thud,
> 
> idledev has mostly been quiet (dead) since I started reading it, early 2013.  Last August was the liveliest month I have seen, not at all normal.  I still intend to comment on your recent posts.
> 
> I want to continue with incremental patches for now.  Undertested re-writes tend to have unanticipated problems.


Looking forward to your comments and suggestions for moving things forward.

Mark