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