Simpler syntax for basic iterations
Summary: Visual environments based on using simple functions without using variables have been found to be useful to introduce programming concepts to young learners. While Python is an ideal language for beginners, the Python construct for iterations, namely for var in range(n): # block # of # code does require a variable and is needlessly complicated for beginners. A simpler construct like: repeat n: # n is a specific integer # block # of # code would be useful to have in such contexts. Other keywords could be chosen instead of "repeat" used above. ==== For young (and perhaps not so young) students visual environments are an ideal choice to learn programming. A well-known example of a visual environment for beginners is Karel the Robot, invented by Richard Pattis in 1981. In this environment, a robot can perform a limited number of basic functions which can be combined to create complex tasks. In the original Karel the Robot, variables were not allowed. However, new procedures could be created. One essential concept that can be demonstrated in such worlds is that of iterations. In the original Karel, this was done using the following syntax: ITERATE n TIMES single_instruction or ITERATE n TIMES BEGIN single_instruction; other_instruction; END where "n" is a specific integer. In the above, indentation has been introduced only to make the code easier to read. A popular Python-like implementation of Pattis' idea is Guido van Robot [1], also known as GvR. In GvR, iteration is done as follows: do n: # block # of # code indented like Python To do something equivalent in Python requires to use: for var in range(n): # block # of # code which requires to use variables, which are not part of the original Karel the Robot philosophy, as well as an additional builtin function. I would argue that, for beginners, this is needlessly complicated. A better alternative would be to use a similar syntax to that used by Guido van Robot for this case. This would require to either introduce a new keyword (such as "do", "repeat", "iterate", or "loop") repeat n: # block # of # code An advantage of using one of these keywords would be for easier readability (for English speakers). The disadvantage is that some existing Python programs might use variables with the names suggested above. An alternative would be to reuse the "for" keyword by adding this new construct to the grammar: for n: # block # of # code This last choice, while perhaps not as immediately readable to English speakers as some of the previous ones, would have the advantage of not requiring any change to any existing Python programs; it could thus be implemented rather quickly without needing some transition time and the use of the __future__ module. There exists at least 4 different pure Python implementations of Karel the Robot where this new construct could, in principle, be immediately put to use: RUR-PLE [2], Rurple NG [3], both of which are desktop versions, Reeborg's World [4], a web version using Brython as a Python interpreter, and Monty Karel [5], an Eclipse plugin which is targeted at older students as it uses a not so simple OOP syntax even for the simplest programs. Young learners using any of the first three such implementations would likely benefit if they could learn programming first using this simpler construct. André Roberge [1] Guido van Robot: http://gvr.sourceforge.net/documents/languageRef/gvr.html [2] RUR-PLE: https://code.google.com/p/rur-ple/ [3] Rurple NG: http://www.lshift.net/downloads/dev.lshift.net/paul/rurple/manual.html [4] Reeborg's World documentation: http://reeborg.ca/docs/en/index.html World itself: http://reeborg.ca/world.html Python tutorial: http://reeborg.ca/docs/begin_py_en/ [5] Monty Karel: http://www.csis.pace.edu/~bergin/MontyKarel/MontyInEclipse.html
Just use: for _ in range(n): # magic here and tell them they'll figure out what the _ is later on. That's how I learned it... BTW, that Guido van Robot thing is kind of funny... :D On October 9, 2015 3:22:43 PM CDT, Andre Roberge <andre.roberge@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On 09/10/15 21:27, Ryan Gonzalez wrote:
Or, to make it look that little bit more "natural", spell it: for each in range(n): # magic ... and then one day, move on to explain that "each" is actually something you can USE rather than just being a fixed part of the syntax - at which point it can be spelled better according to what it actually is. An alternative suggestion to remove the need for the variable (rather than a new keyword) would be something like allowing the "var in" part to be optioinal: for <iterator>: # magic ... but the problem with that is that pretty much the ONLY use would be for this sort of "iterate n times" construct or something where you're relying on the iterator to have side-effects (which is pretty nasty): foo = myiter() for foo: bar(foo.getcurrentvalue()) It seems like a lot of effort just to hide a bit of syntax for a very specific use-case when you can just temporarily make that syntax look a bit nicer for your audience. E.
On Fri, Oct 9, 2015 at 6:27 PM, Erik <python@lucidity.plus.com> wrote:
I have been using a special builtin alternative (which can be translated into various human languages, as Reeborg's World is meant to support various languages) as def repeat(f, n): for i in range(n): f() and used as repeat(turn_left, 3) as seen here: http://reeborg.ca/docs/begin_py_en/repeat.html (and for the French version: http://reeborg.ca/docs/begin_py_fr/repeat.html ). In smaller tutorials, I sometimes use the standard "for .." construct instead of this repeat() function, but it always feels clumsy for beginners. However, repeat() has its own complexity in that it uses function arguments, which are inexistant in the original Karel the Robot approach and do not need to be used for simple worlds in Reeborg's World. And, just to put things in perspective: I first wrote RUR-PLE in 2004 and have been working on tutorials for it, discussing with many teachers using it during all these years. So, yes, I know I (and others) can make do without this special construct I am suggesting ... but at the cost of a larger hurdle for the students than would be required if the alternative construct existed. André
E.
On Friday, October 9, 2015, Andre Roberge <andre.roberge@gmail.com> wrote:
But also at the cost of introducting new syntaxatic sugar which is literally a few chars fewer, at the expense of teaching and explain using one or another, "longer standard" version and the shortcut, is not going to make students more productive. I think in general people are smart enough to make decision, recognize tricks. Time should spend on educating students on writing code. This feels like micro optimization. I would rather see for key, value in mydict.items(): And for index, element in enumerate(mylist) to be sugar-coated. This is more annoying to type than the problem being discussed. Everyone's mileage is different but I bet the use of items and enumerate is too frequent and yet there is no briefer version. And I also dont think repeat(..) is helpful for a few chars either. Nice to show how to abstract user from detail implementation (e.g complex repeated task). -- Sent from Jeff Dean's printf() mobile console
Indeed -- while python's for loop can be (and often is) used to repeat something a certain number of times, what it really is is a way to apply a block of code to each item in an iterable. Making a slightly shorter/easier way to do something n times will just make it harder to "get" what for loops really are later on. And aside from using it as a teaching tool, does one want to loop without using the index all that often to get special syntax? The Karel-style simplified languages may be a great teaching tool -- but that's not what Python is. -CHB
if anything is changed at all, then the for <iterator>: # magic seems to have the least impact and best addresses the original goal. repeat n: # saves 4 characters vs for range(n): # keeps syntax consistent Which (consistency vs save 4 characters) would you favour for a beginner? Not to mention that introducing a new keyword introduces many challenges.
On 10/9/2015 4:22 PM, Andre Roberge wrote:
...
...
It was once proposed that int n should be an abbreviation for range(n), at least in the context of a for statement, partly on the basis that counts can be defined in set theory as the set of previous counts, or a similar variation, but really for convenience. Guido vetoed the idea. --- I think trying to persuade core developers to mutilate Python a bit, at couple of years in the future, is futile. And unneeded. Instead, translate, say 'repeat n:' into 'for _ in range(n):' with something like 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) You could, for instance, patch IDLE two places (for shell and editor code) to run robotran on user code before compiling. You could also add 'repeat' to the list of keywords for colorizing. I would be willing to help (without any guarantee of code stability). Guido recently approved on idle-dev that we rethink IDLE for beginners. I have already thought about adding the necessary hooks so that education developers like you could define beginner Python dialects, such as you suggest here. This would open a world of possibilities, such as 'move 3' versus 'move(3)', and foreign language keywords. I just started a thread 'Running beginner Pythons'. -- Terry Jan Reedy
On Fri, Oct 9, 2015 at 11:30 PM, Terry Reedy <tjreedy@udel.edu> wrote:
It is unfortunate, given the original CP4E goal, but not altogether unexpected -- although, I do find the word "mutilate" to be a bit strong.
And unneeded.
I respectfully disagree (however see below). The reason is that I don't believe in students having to unlearn something (like a special repeat syntax available only in a specific environment) when they might have been under the impression that it was standard Python syntax. Furthermore, it might instill doubt in their mind about other construct they have learn (are they standard? ... or were they too something only available in the specific environment?...)
I don't use IDLE. To make things as easy as possible for beginners, I have moved away from desktop programs (RUR-PLE) which require a download, to a purely web version, accessible via a single URL. However, prompted by your suggestion, I did implement a simplified syntax for iteration (tentatively using "repeat"). If you click on the link below, it will bring up a concrete example, ready to run. (Note: the syntax used in the example may not work in the future ... say, in a few days from now, after I discuss with other users of my site about this new possible syntax.) If I do end up keeping something like this, I'll have to make sure it is flagged very clearly as being non-standard, so that the students are properly warned. http://reeborg.ca/world_dev.html?proglang=python-en&world=%7B%0A%20%20%22robots%22%3A%20%5B%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%22x%22%3A%201%2C%0A%20%20%20%20%20%20%22y%22%3A%201%2C%0A%20%20%20%20%20%20%22orientation%22%3A%200%2C%0A%20%20%20%20%20%20%22_prev_x%22%3A%201%2C%0A%20%20%20%20%20%20%22_prev_y%22%3A%201%2C%0A%20%20%20%20%20%20%22_prev_orientation%22%3A%200%2C%0A%20%20%20%20%20%20%22objects%22%3A%20%7B%7D%0A%20%20%20%20%7D%0A%20%20%5D%2C%0A%20%20%22walls%22%3A%20%7B%7D%2C%0A%20%20%22description%22%3A%20%22%22%2C%0A%20%20%22small_tiles%22%3A%20false%2C%0A%20%20%22rows%22%3A%2012%2C%0A%20%20%22cols%22%3A%2014%0A%7D&editor=from%20library%20import%20left%2C%20right%0A%0Arepeat%204%3A%0A%20%20%20%20move()%0A%20%20%20%20left()%0A%0Aright()%0A&library=left%20%3D%20turn_left%0A%20%20%20%20%0Adef%20right()%3A%0A%20%20%20%20repeat%203%3A%0A%20%20%20%20%20%20%20%20turn_left()%0A
I'll have a look. However, as I mentioned above, I'm not keen on introducing what amounts to a potentially completely different language. Python is a fantastic language for beginners (and advanced) programmers ... I was just hoping to make it a tiny bit easier to learn for complete beginners who are introduced to Python in visual environments (like the turtle module or a Karel the Robot clone). André Roberge
On 10/10/2015 9:44 PM, Andre Roberge wrote
To avoid mis-impressions, non-standard syntax might get a special syntax coloring, such as an orange 'warning color' background. Or it could be translated line-by-line on entry: enter 'for n' and the line is immediately replaced by 'for _ in range(n):'. (I might like that for my own use ;-). Or if the beginner language is really not Python, don't call it Python. I know I don't know how to teach beginning programming, especially to children, and I doubt anyone really knows the *best* way. So I am interested in facilitating experiments.
I think I understood at a pretty early age that training wheels were a special part of a beginner bike for little kids, only present for learning.
Your are asking for a special case of a special case of something already present. In my view, it is like a training wheel - very useful when needed, but not so thereafter. Since it is only needed for a short time for young beginners, it only need be present, in my view, in the environments used by such beginners. -- Terry Jan Reedy
Andre Roberge writes:
I have no objection to such a language, but it ain't Python. It's an important principle of Python that "There's one- and preferably only one -obvious way to do it." While the parenthetical "only one" is violated on occasion, it's still considered important.
for var in range(n): # suite
I just don't have a problem with this. It seems to me that on the occasions when I've taught programming[2], I've always had the most success when the student has a concrete problem in mind (sometimes they need to write programs to complete another project, but also when they take programming as a required course). Take the traditional make a square in turtle graphics: right = -90 length = 10 def make_square (turtle): for side in ('top', 'right', 'bottom', 'left'): turtle.forward(length) turtle.turn(right) Do you really have students writing code like for _ in range(20): print('yes') where the repetition is exact?
The goal called "CP4E" as I understood it was to give the *full* power of "computer programming" to "everyone", not to just provide a taste. The *power* of computer programming comes from small but expressive vocabularies, it seems to me.
So call the new language "Childrens-Python"[1] if you like.<wink/> Or "Woma" (which is a bit bigger than Children's Python) if that's too close to "Python".
So what? If they're going to do computer programming after they leave your class, they're surely going to encounter "specific environments". So many times I've typed an example into the interpreter only to discover that the author didn't explicitly import a function or identifier from a module, but it looks like it could be a builtin I hadn't used before.
It doesn't look to me like that's what Terry is talking about, though. I suppose that as usual there will be a "consenting adults" convention that "you could do that with this hook, but please, *not* in front of the children!" Rather, for cases where you don't need the full power of Python's expression syntax, you could eliminate parentheses from function calls and that kind of thing.
At the cost of requiring every Python programmer to beware of a new and infrequently syntax. Footnotes: [1] http://www.snakeranch.com.au/snake-profiles/childrens-python/ [2] Always at the college level or above, though.
I've felt the same need Andre described, and so far I have not seen a convincing argument against his proposal to accept this syntax: for n: # repeat block n times fd(100) lt(360/n) Where n is any expression that evaluates to an integer. The goal is to repeat some operation N times without creating a spurious variable. I prefer this simpler alternative than Ian's later proposal where n must be an iterable, involving a lot of machinery just to produce a value to be discarded. While we are at it, we could borrow Go's "forever" loop: for: # repeat forever spam() Although I am quite happy with `while True:` for that purpose. Cheers, Luciano On Sun, Oct 11, 2015 at 4:48 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho <luciano@ramalho.org> writes:
Huh? If ‘n’ is an expression that evaluates to one integer, then why are you also dividing by that one integer ‘n’ every time through? I don't claim it will convince you, but I find compelling the fact that this:: for n in range(FOO): fd(100) lt(360/n) already works fine and is quite clear. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney
On Sun, Oct 11, 2015 at 7:03 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
That's the classic formula for drawing an N-sided polygon in Logo. N can be any positive integer. Maybe this is clearer: for 3: # draw a triangle fd(100) lt(120)
It is quite clear for us. When teaching the first steps of programming to kids with the Turtle module, `for x in range(n):` leaves us in the unfortunate position of having to say: "we won't use that x for anything, and I can't explain what range this until much later..." Cheers, Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho <luciano@ramalho.org> writes:
Thank you, yes it's much clearer because you're not doing exactly the same division multiple times. So, to follow your clarification, this:: for __ in range(3): forward(100) turn_left(120) already works and is quite clear (though, again, I don't claim it will convince you).
Yes, the fact you weren't using it confused me too :-) Which is why we advocate a name, ‘__’, that stands out and is used only for dummy assignment. -- \ “How wonderful that we have met with a paradox. Now we have | `\ some hope of making progress.” —Niels Bohr | _o__) | Ben Finney
Argh! Here's why I don't like adding special syntax to do something N times. I didn't leave this out by accident 25 years ago. Python takes a stance against a common approach to beginners' programming education focused on counting and indexing arrays of data, rooted in machine language and FORTRAN. Standard problems and examples like "print 'hello world' 10 times" or "draw an N-sided polygon" are designed to teach students those counting and indexing skills. It's backwards to request that the language support counting better so those examples will look simpler. Python has so much richer data structures. Create problems to teach those! -- --Guido van Rossum (python.org/~guido)
On Sun, Oct 11, 2015 at 7:59 PM, Guido van Rossum <guido@python.org> wrote:
I agree that counting and indexing dominate many stupid introductory programming exercises. And I praise the design of Python's `for` command every time I teach the language or speak about it. However, in Logo, using a command like the one below, there is absolutely no indexing or counting in sight. REPEAT 3 [FD 100 RT 120] That's why we were advocating for a similar construct in Python. But obviously you're not going to entertain the idea, so I'll drop it. Cheers, Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On 10/11/2015 2:47 PM, Luciano Ramalho wrote:
Umm... https://www.python.org/dev/peps/pep-0284/ Emile
On Sun, Oct 11, 2015 at 11:12 PM, Guido van Rossum <guido@python.org> wrote:
Andre and I are not arguing for a special syntax to loop over numbers. We are arguing for special syntax to repeat a block a number of times. No indexing at all, and no variables need to be involved. for 3: fd(100) lt(120) Best, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On Mon, Oct 12, 2015 at 1:43 AM, Guido van Rossum <guido@python.org> wrote:
Well, that's even more limited.
Yep. That's the whole point.
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On Mon, Oct 12, 2015 at 10:28 AM, Luciano Ramalho <luciano@ramalho.org> wrote:
In discussions like this there are 3 – at least – interlocking parties with their conflicting interests. 1. Professional programmers 2. Language Designers/implementers 3. Programming/CS teachers It is unlikely to find people equal to all these but at least let us be clear that these 3 exist! [For those who find this too long, tl;dr at bottom ] To see that these viewpoints are inherently conflicting consider that a programmer may wish that his language precludes errors – a natural wish. Translated to the designer camp this means an automatic detection of errors – also known as the Halting Problem. Which is to show that the programmer's and the language-designer's needs are not just conflicting, they are inherently conflicting And so, in like manner the programming-teachers' needs are in inherent conflict with the needs of professional programmers and language designers. 3-4 decades ago this was widely understood and some sort of compromise was worked out: Beginners studied Pascal (or Basic); professionals lived inside Fortran, Cobol, PL-1 etc. With the coming of C, people began to imagine that C was sufficiently close to Pascal that a one-fit-all solution was possible. The result has been terribly detrimental <http://blog.languager.org/2013/02/c-in-education-and-software-engineering.ht...> to CS-edcuation The increasing widespreadness of languages like Python and Haskell may seem to improve this situation. IMHO it only worsens it: Sure Python is better to teach than C++ but its not better enough that its suitable as a teaching-language. [And as Haskell gallops towards Real-World <http://book.realworldhaskell.org/> status it also gallops towards C++-dom]. Specifically coming to the suggestion at hand: Pascal got one thing right that all its successors, starting C, got terribly wrong: the need to separate and *do equal justice to* Platonic world Mundane World Values Effects Expressions Statements functions procedures More about this 50 year-old error and a beginning gleam of light: a ACM CS Curriculum 2013 <http://blog.languager.org/2015/06/functional-programming-moving-target.html> and its prequel Timeline <http://blog.languager.org/2015/04/cs-history-1.html> The error of imagining imperative programming is easy to learn comes from people not seeing that imperative languages *as they exist* contain a subset functional language which is ineluctable. Also known as the rhs of assignment statements – with the '=' being the visible indicator of the infamous von Neumann bottleneck <https://www.cs.cmu.edu/%7Ecrary/819-f09/Backus78.pdf>. The functional programming folks seeing this error try to expand that expression world to cover all of programming needs. [Whether the results of these good-intentions eg Haskell are more teachable is another matter!] The alternative (eg Logo and I am guessing Luciano and Andre ) that for the 'atoms' of the statement world, instead of having assignment statements to have turtle-left/right etc. This renders the language useless for general purpose programming but can be a neat intro to algorithmic thinking tl;dr 1. Language designer/implementers may wish to ask themselves whether having a family of easily learnable but slightly inconsistent languages helps or hinders their language. 2. Teachers may wish to re-evaluate their fixed-cost/variable-cost (equivalently batch/interactive cost) outlay in the languages they teach and check whether implementing a cut-down subset of their chosen language doesn't speed up their students and themselves 3. General programmers need to remember – not only were they noobs at some stage, there is probably something they are learning right now to which noob-ness applies even to them.
Luciano Ramalho <luciano@ramalho.org> writes:
Andre and I are not arguing for a special syntax to loop over numbers. We are arguing for special syntax to repeat a block a number of times.
That's been clear, at least to my reading of your messages. What you haven't argued is any extraordinary utility of this new syntax, sufficient to overcome the high barrier that is rightly imposed on new syntax.
Since this is quite clearly expressed in existing Python syntax with:: for __ in range(3): forward(100) turn_left(120) the single use case doesn't IMO argue for benefit sufficient to overcome the enormous burden of new syntax. -- \ “I'm not a bad guy! I work hard, and I love my kids. So why | `\ should I spend half my Sunday hearing about how I'm going to | _o__) Hell?” —Homer Simpson | Ben Finney
"Sven R. Kunze" <srkunze@mail.de> writes:
What you cite as an advantage is exactly why I'd advise against it. Your example would lead me to ask “Is this a mistake? ‘each’ is a normal name, why isn't it being used?” Whereas ‘__’ is not a normal name, and like other unusual names in Python should lead the reader to say “Okay, obviously the person writing this had something odd in mind. I'd better find out what.” That is more likely to teach about the ‘__’ convention, than to be seen as a mistake by experienced programmers. -- \ “You don't change the world by placidly finding your bliss — | `\ you do it by focusing your discontent in productive ways.” | _o__) —Paul Z. Myers, 2011-08-31 | Ben Finney
On 13.10.2015 21:49, Ben Finney wrote:
What you cite as an advantage is exactly why I'd advise against it.
Feel free to do so as do I.
Your example would lead me to ask “Is this a mistake? ‘each’ is a normal name, why isn't it being used?”
You as an experienced Python developer. That thread is about students learning programming. Not learning Python.
Python convention necessary when the student need to write real Python. Best, Sven
On Wed, Oct 14, 2015 at 06:49:39AM +1100, Ben Finney wrote: [...]
I'd just like to point out that using __ as a loop variable (or any other variable) is incompatible with the IPython convention for __. It is just wrong to talk about "the" __ convention, since there are at least two in common use, and using one necessarily conflicts with using the other. If anyone wants to argue the pros and cons of one convention versus the other, or what unused loop variables ought to be called (x, unused, each, _, __, dontcare, whatever...) please take it to python-list@python.org or comp.lang.python, as it is off-topic here. Thanks, -- Steve
On 14/10/15 01:01, Steven D'Aprano wrote:
The discussion of "what unused loop variables ought to be called" is in direct response to someone suggesting a syntax change to make things easier to teach. To suggest that they spell the loop differently to make it easier to teach whilst not requiring any syntax changes to the language is, I would argue, on-topic as a rebuttal to the change request. However, I agree with you that this particular discussion has probably run its course. E.
On 13/10/2015 18:59, Sven R. Kunze wrote:
No thanks. The current situation has suited the Python community for 25 years give or take, so if it ain't broke, there's no way it's going to get fixed, thank goodness. Can we move on please? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Like multi-line lambdas, multi-line with statements, null coalescing operators, and all the other topics that come up every other week? On October 13, 2015 5:19:46 PM CDT, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
Ryan Gonzalez writes: Avoid top-posting. It helps prevent posting merely to be contrary.<wink /> Reordering....
Mark Lawrence writes:
Stop pointlessly discussing something that simply is not going to happen.
There is a clear qualitative difference here. Mark is right about the "repeat n:" proposal, and your comparison is specious. ***** The rest of my post is an attempt to present my understanding of some aspects of Pythonic design thinking as relevant to discussions on Python-Ideas. As a running example, I try to argue why this thread should have ended with at most two posts in it. (Some might say it shouldn't have started because of PEP 284, but figuring out relevance of several hundred PEPs is a task more suited to scripture scholars than language designers.) Guido admits the benefits of all of the features Ryan mentions, and entertains *new* proposals of syntax to invoke them. That's not because he's a nice guy handing out warm fuzzies to would-be contributors. We currently don't have a good way to do them, where "good" involves both "concise" and "esthetically pleasing, especially to Guido". He really would like to serve the constituencies for those features (and might even warm up to them himself, given suitable syntax). Guido also values the educational use of Python, and when introducing new features he works hard to find syntax (including choice of keyword) that is "intuitive" to both new users of Python and new programmers. If anybody "gets" CP4E, Guido does. Of course there are different ways to get there, but arguing that lack of "repeat n:" is somehow contrary to CP4E is disrespectful. It's a different path to that end. *This proposal* to introduce a special syntax for pure repetition, however, obviously falls afoul of several principles *of Pythonic language design*. On the contrary, the arguments *for* the proposal are "non-Pythonic", which doesn't make them unimportant, much less invalid. It does, however, make them low-value on *this* list, which is for proposed improvements to the Python language. We're not here to discuss language improvements in general.[1] Here's my list: 1. The bar for new keywords is *very* high. I don't think the educational purpose would be well-served by twisting "for" into a knot with "for 4:"; that just doesn't correspond to valid English usage. "while 4:" is a little closer (IMO YMMV), but already has a meaning so it's out anyway due to backward compatibility. I think this proposal needs a new keyword, and "repeat" is excellent for the purpose. That's already a deal-killer for such a specialized construct. 2. We already have a good way to write "repeat 4:". The proposed syntax is just syntactic sugar, and even in its educational context, it's not much sweeter than (proper) use of the existing syntax. Watch one user's lips move as she draws a square: First I draw the top, then I go down the right, then I draw across the bottom, and then I connect the left up to the top. Now compare: repeat 4: forward(10) right(90) versus: for side in ('across top', 'down right', 'across bottom', 'up left'): forward(10) right(90) Which expresses her intent better? Is it really educational to have *this* user to think of a square as an abstract regular polygon that happens to have 4 sides? True, it's easy to cargo- cult the "repeat 4:" idiom the next time she needs a square, but in learning to use "repeat n:", has she learned anything about implementing her own procedures? (This is a variation on the individuality issue that Terry expressed with "kangaroo".) Note: this is a plausible example user, and I am asking whether *she* is served by the new syntax. I don't maintain that she is *the* typical user. I do think that educators should consider her needs as well as the question of how common her type is. While there probably is educational benefit to this change, it's far from clear to me what it is, or whether in fact the student's benefit is anywhere near as large as that to teachers who want to present one "simple" programming construct and move on quickly to another one. 3. The "repeat 4" idiom clearly involves counting (otherwise the program doesn't know when to stop), but it completely conceals the process. That violates "explicit is better than implicit", and furthermore makes the idiom very specialized, dramatically reducing the benefits it can have. It seems to me that the "for ... in" construct gets the balance just right. It exposes both counting as an isomorphism between concrete sets (above, repetitions of a subprocedure corresponding to named sides of a square), and abstractly using numbers merely to count (via "range(n)"). (Of course "range()" also provides a flexible way to denote various concrete sets of numbers.) 4. True, when you really do have an algorithm that simply cares about the number and repeats the same suite independently of the iteration count, exposing an iteration count variable is arguably a wart. But it's very small compared to the power of the "for ... in" idiom. Proposing to address that wart runs into "Special cases aren't special enough to break the rules." Now, all of these principles ("Read my lips: no new keywords!" and the three from the Zen) are pragmatic guidelines, not absolutes. Not even "no keywords". And they're Pythonic principles: they don't always generalize to other languages.[2] But when a proposal infringes so many Pythonic principles so flagrantly (IMHO, each is sufficient reason to deny the proposal by itself, though YMMV), it is indeed a non-starter on this list. Regards, Footnotes: [1] Note that several core Python developers have unsubscribed or muted this list completely, partly because of these off-target threads. [2] I have to admit that I'm thoroughly drunk on the Kool-Aid though, and tend to apply them to other languages, which inevitably fall short.
On October 14, 2015 12:28:07 AM CDT, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
... That was supposed to be a joke. :O
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On 13/10/15 23:19, Mark Lawrence wrote:
Huh? for each in range(3): foo() ... is already valid Python. In what way is that "not going to happen"? This spelling was just suggested as an alternative to the original poster who did not like having to explain the cryptic "___" spelling to students. Same construct, different spelling. E.
On 10/13/2015 8:01 PM, Erik wrote:
On 13/10/15 23:19, Mark Lawrence wrote:
What is not going to happen is that Python will not be changed to actually make a particular identifier a dummy, by not, for instance, letting it be used within the loop. I know you were not proposing that.
What I think will not and should not happen is that Guido and/or core devs 'bless' in PEP 8 any particular work for teaching beginners. Mark gets a bit over-anxious sometimes, but insofar as he meant 'its futile for us to try to decide on one spelling here', I think he is correct.
Same construct, different spelling.
Right, and I think 'each' if better than '_' or '__' for beginners. I recommend 'count' for range() and 'item' for a generic iterable. I also recommend that teachers of beginners experiment with various choices, and share their experiences with each other. Who knows, maybe kids would prefer 'for kangaroo in range(3):', or other personal choices. -- Terry Jan Reedy
On Wed, Oct 14, 2015 at 12:10 AM, Terry Reedy <tjreedy@udel.edu> wrote:
If a student is asking _ then it should be explained. Soon or later the students will probably see _ in other source code. Whether it is a 4-year old child or a 18 year-old college freshman. I wouldn't expect my nephew to understand everything I write, but they will grow up and have the "ah" moment.
On 10/11/2015 5:47 PM, Luciano Ramalho wrote:
I've felt the same need Andre described, and so far I have not seen a convincing argument against his proposal to accept this syntax:
Your logic is backwards. The default answer to 'add this' is 'No'. The burden of persuasion is on you. The people who have to be persuaded, by their own standards of goodness for Python, are Guido and core developers
Andre wanted, I believe, 'for <literal number>:' to avoid naming numbers, or at least variable quantities. But I am 'not convinced'. The above should be turn = 360/n for n: fd(100) lt(turn) Anyway, very young kids get the concept of 'variable quantity': number of days left to Christmas, number of cookies handed out, etc.
The goal is to repeat some operation N times without creating a spurious variable.
The fraction of for loops using range(n) is small, especially after enumerate was introduced, and especially if n is a constant. The fraction of such loops where the iteration count can never have any use is also small, because if the code has a bug, you will likely want the iteration count. Adding 'print(i, a, k)' to a loop, where a and k change with each loop is, for me, a very common debugging tool. Even without bugs, I believe that displaying iteration counts can help learning and program understanding. Right now, one could step through n = 17 for i in range(n): # i = number of chord already drawn fd(100) lt(360/n) with IDLE's debugger and see the step number increase just before a chord is drawn. Or one might want to add 'label(i)' at the top, where label(i) puts a small circled number near the current position. The more I think about this, the less I am convinced that the fraction of truly, permanently spurious loop counts is enough to support a new syntax. -- Terry Jan Reedy
On Monday, October 12, 2015 at 11:41:06 AM UTC+5:30, Terry Reedy wrote:
Just to clarify my earlier post: I dont regard this suggestion as a serious contender for python. I would however like it that if someone forked and added this to (a probably heavily cut-down) python, that fork be regarded as a friendly-by-default fork In my personal estimate: of such talk 1% will go from being vaporware to something others can actually try out Of that 1%, 0.1% can become a serious competitor for (C)Python
I just attended some lectures in which a gifted teacher used Jupyter (ipython) to give abstruse linear algebra intuitions to kids. So yes a good teacher can convey variables to kids. Is it a good idea to do so? I remember as a 10-11 year old having a hard time going from arithmetic to algebra. Current day imperative languages makes this (in my experience inherent) hardness harder on 2 more counts: - the variable is time-varying - the assignment is denoted with '=' which is a confusing synonym/homonym to the math equality And so the teacher trying to disentangle all this confusingness is to be supported (in my book) Its another matter that python is not a 'for-kids' language so it need not change to incorporate this.
Just use: for _ in range(n): # magic here and tell them they'll figure out what the _ is later on. That's how I learned it... BTW, that Guido van Robot thing is kind of funny... :D On October 9, 2015 3:22:43 PM CDT, Andre Roberge <andre.roberge@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On 09/10/15 21:27, Ryan Gonzalez wrote:
Or, to make it look that little bit more "natural", spell it: for each in range(n): # magic ... and then one day, move on to explain that "each" is actually something you can USE rather than just being a fixed part of the syntax - at which point it can be spelled better according to what it actually is. An alternative suggestion to remove the need for the variable (rather than a new keyword) would be something like allowing the "var in" part to be optioinal: for <iterator>: # magic ... but the problem with that is that pretty much the ONLY use would be for this sort of "iterate n times" construct or something where you're relying on the iterator to have side-effects (which is pretty nasty): foo = myiter() for foo: bar(foo.getcurrentvalue()) It seems like a lot of effort just to hide a bit of syntax for a very specific use-case when you can just temporarily make that syntax look a bit nicer for your audience. E.
On Fri, Oct 9, 2015 at 6:27 PM, Erik <python@lucidity.plus.com> wrote:
I have been using a special builtin alternative (which can be translated into various human languages, as Reeborg's World is meant to support various languages) as def repeat(f, n): for i in range(n): f() and used as repeat(turn_left, 3) as seen here: http://reeborg.ca/docs/begin_py_en/repeat.html (and for the French version: http://reeborg.ca/docs/begin_py_fr/repeat.html ). In smaller tutorials, I sometimes use the standard "for .." construct instead of this repeat() function, but it always feels clumsy for beginners. However, repeat() has its own complexity in that it uses function arguments, which are inexistant in the original Karel the Robot approach and do not need to be used for simple worlds in Reeborg's World. And, just to put things in perspective: I first wrote RUR-PLE in 2004 and have been working on tutorials for it, discussing with many teachers using it during all these years. So, yes, I know I (and others) can make do without this special construct I am suggesting ... but at the cost of a larger hurdle for the students than would be required if the alternative construct existed. André
E.
On Friday, October 9, 2015, Andre Roberge <andre.roberge@gmail.com> wrote:
But also at the cost of introducting new syntaxatic sugar which is literally a few chars fewer, at the expense of teaching and explain using one or another, "longer standard" version and the shortcut, is not going to make students more productive. I think in general people are smart enough to make decision, recognize tricks. Time should spend on educating students on writing code. This feels like micro optimization. I would rather see for key, value in mydict.items(): And for index, element in enumerate(mylist) to be sugar-coated. This is more annoying to type than the problem being discussed. Everyone's mileage is different but I bet the use of items and enumerate is too frequent and yet there is no briefer version. And I also dont think repeat(..) is helpful for a few chars either. Nice to show how to abstract user from detail implementation (e.g complex repeated task). -- Sent from Jeff Dean's printf() mobile console
Indeed -- while python's for loop can be (and often is) used to repeat something a certain number of times, what it really is is a way to apply a block of code to each item in an iterable. Making a slightly shorter/easier way to do something n times will just make it harder to "get" what for loops really are later on. And aside from using it as a teaching tool, does one want to loop without using the index all that often to get special syntax? The Karel-style simplified languages may be a great teaching tool -- but that's not what Python is. -CHB
if anything is changed at all, then the for <iterator>: # magic seems to have the least impact and best addresses the original goal. repeat n: # saves 4 characters vs for range(n): # keeps syntax consistent Which (consistency vs save 4 characters) would you favour for a beginner? Not to mention that introducing a new keyword introduces many challenges.
On 10/9/2015 4:22 PM, Andre Roberge wrote:
...
...
It was once proposed that int n should be an abbreviation for range(n), at least in the context of a for statement, partly on the basis that counts can be defined in set theory as the set of previous counts, or a similar variation, but really for convenience. Guido vetoed the idea. --- I think trying to persuade core developers to mutilate Python a bit, at couple of years in the future, is futile. And unneeded. Instead, translate, say 'repeat n:' into 'for _ in range(n):' with something like 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) You could, for instance, patch IDLE two places (for shell and editor code) to run robotran on user code before compiling. You could also add 'repeat' to the list of keywords for colorizing. I would be willing to help (without any guarantee of code stability). Guido recently approved on idle-dev that we rethink IDLE for beginners. I have already thought about adding the necessary hooks so that education developers like you could define beginner Python dialects, such as you suggest here. This would open a world of possibilities, such as 'move 3' versus 'move(3)', and foreign language keywords. I just started a thread 'Running beginner Pythons'. -- Terry Jan Reedy
On Fri, Oct 9, 2015 at 11:30 PM, Terry Reedy <tjreedy@udel.edu> wrote:
It is unfortunate, given the original CP4E goal, but not altogether unexpected -- although, I do find the word "mutilate" to be a bit strong.
And unneeded.
I respectfully disagree (however see below). The reason is that I don't believe in students having to unlearn something (like a special repeat syntax available only in a specific environment) when they might have been under the impression that it was standard Python syntax. Furthermore, it might instill doubt in their mind about other construct they have learn (are they standard? ... or were they too something only available in the specific environment?...)
I don't use IDLE. To make things as easy as possible for beginners, I have moved away from desktop programs (RUR-PLE) which require a download, to a purely web version, accessible via a single URL. However, prompted by your suggestion, I did implement a simplified syntax for iteration (tentatively using "repeat"). If you click on the link below, it will bring up a concrete example, ready to run. (Note: the syntax used in the example may not work in the future ... say, in a few days from now, after I discuss with other users of my site about this new possible syntax.) If I do end up keeping something like this, I'll have to make sure it is flagged very clearly as being non-standard, so that the students are properly warned. http://reeborg.ca/world_dev.html?proglang=python-en&world=%7B%0A%20%20%22robots%22%3A%20%5B%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%22x%22%3A%201%2C%0A%20%20%20%20%20%20%22y%22%3A%201%2C%0A%20%20%20%20%20%20%22orientation%22%3A%200%2C%0A%20%20%20%20%20%20%22_prev_x%22%3A%201%2C%0A%20%20%20%20%20%20%22_prev_y%22%3A%201%2C%0A%20%20%20%20%20%20%22_prev_orientation%22%3A%200%2C%0A%20%20%20%20%20%20%22objects%22%3A%20%7B%7D%0A%20%20%20%20%7D%0A%20%20%5D%2C%0A%20%20%22walls%22%3A%20%7B%7D%2C%0A%20%20%22description%22%3A%20%22%22%2C%0A%20%20%22small_tiles%22%3A%20false%2C%0A%20%20%22rows%22%3A%2012%2C%0A%20%20%22cols%22%3A%2014%0A%7D&editor=from%20library%20import%20left%2C%20right%0A%0Arepeat%204%3A%0A%20%20%20%20move()%0A%20%20%20%20left()%0A%0Aright()%0A&library=left%20%3D%20turn_left%0A%20%20%20%20%0Adef%20right()%3A%0A%20%20%20%20repeat%203%3A%0A%20%20%20%20%20%20%20%20turn_left()%0A
I'll have a look. However, as I mentioned above, I'm not keen on introducing what amounts to a potentially completely different language. Python is a fantastic language for beginners (and advanced) programmers ... I was just hoping to make it a tiny bit easier to learn for complete beginners who are introduced to Python in visual environments (like the turtle module or a Karel the Robot clone). André Roberge
On 10/10/2015 9:44 PM, Andre Roberge wrote
To avoid mis-impressions, non-standard syntax might get a special syntax coloring, such as an orange 'warning color' background. Or it could be translated line-by-line on entry: enter 'for n' and the line is immediately replaced by 'for _ in range(n):'. (I might like that for my own use ;-). Or if the beginner language is really not Python, don't call it Python. I know I don't know how to teach beginning programming, especially to children, and I doubt anyone really knows the *best* way. So I am interested in facilitating experiments.
I think I understood at a pretty early age that training wheels were a special part of a beginner bike for little kids, only present for learning.
Your are asking for a special case of a special case of something already present. In my view, it is like a training wheel - very useful when needed, but not so thereafter. Since it is only needed for a short time for young beginners, it only need be present, in my view, in the environments used by such beginners. -- Terry Jan Reedy
Andre Roberge writes:
I have no objection to such a language, but it ain't Python. It's an important principle of Python that "There's one- and preferably only one -obvious way to do it." While the parenthetical "only one" is violated on occasion, it's still considered important.
for var in range(n): # suite
I just don't have a problem with this. It seems to me that on the occasions when I've taught programming[2], I've always had the most success when the student has a concrete problem in mind (sometimes they need to write programs to complete another project, but also when they take programming as a required course). Take the traditional make a square in turtle graphics: right = -90 length = 10 def make_square (turtle): for side in ('top', 'right', 'bottom', 'left'): turtle.forward(length) turtle.turn(right) Do you really have students writing code like for _ in range(20): print('yes') where the repetition is exact?
The goal called "CP4E" as I understood it was to give the *full* power of "computer programming" to "everyone", not to just provide a taste. The *power* of computer programming comes from small but expressive vocabularies, it seems to me.
So call the new language "Childrens-Python"[1] if you like.<wink/> Or "Woma" (which is a bit bigger than Children's Python) if that's too close to "Python".
So what? If they're going to do computer programming after they leave your class, they're surely going to encounter "specific environments". So many times I've typed an example into the interpreter only to discover that the author didn't explicitly import a function or identifier from a module, but it looks like it could be a builtin I hadn't used before.
It doesn't look to me like that's what Terry is talking about, though. I suppose that as usual there will be a "consenting adults" convention that "you could do that with this hook, but please, *not* in front of the children!" Rather, for cases where you don't need the full power of Python's expression syntax, you could eliminate parentheses from function calls and that kind of thing.
At the cost of requiring every Python programmer to beware of a new and infrequently syntax. Footnotes: [1] http://www.snakeranch.com.au/snake-profiles/childrens-python/ [2] Always at the college level or above, though.
I've felt the same need Andre described, and so far I have not seen a convincing argument against his proposal to accept this syntax: for n: # repeat block n times fd(100) lt(360/n) Where n is any expression that evaluates to an integer. The goal is to repeat some operation N times without creating a spurious variable. I prefer this simpler alternative than Ian's later proposal where n must be an iterable, involving a lot of machinery just to produce a value to be discarded. While we are at it, we could borrow Go's "forever" loop: for: # repeat forever spam() Although I am quite happy with `while True:` for that purpose. Cheers, Luciano On Sun, Oct 11, 2015 at 4:48 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho <luciano@ramalho.org> writes:
Huh? If ‘n’ is an expression that evaluates to one integer, then why are you also dividing by that one integer ‘n’ every time through? I don't claim it will convince you, but I find compelling the fact that this:: for n in range(FOO): fd(100) lt(360/n) already works fine and is quite clear. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney
On Sun, Oct 11, 2015 at 7:03 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
That's the classic formula for drawing an N-sided polygon in Logo. N can be any positive integer. Maybe this is clearer: for 3: # draw a triangle fd(100) lt(120)
It is quite clear for us. When teaching the first steps of programming to kids with the Turtle module, `for x in range(n):` leaves us in the unfortunate position of having to say: "we won't use that x for anything, and I can't explain what range this until much later..." Cheers, Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
Luciano Ramalho <luciano@ramalho.org> writes:
Thank you, yes it's much clearer because you're not doing exactly the same division multiple times. So, to follow your clarification, this:: for __ in range(3): forward(100) turn_left(120) already works and is quite clear (though, again, I don't claim it will convince you).
Yes, the fact you weren't using it confused me too :-) Which is why we advocate a name, ‘__’, that stands out and is used only for dummy assignment. -- \ “How wonderful that we have met with a paradox. Now we have | `\ some hope of making progress.” —Niels Bohr | _o__) | Ben Finney
Argh! Here's why I don't like adding special syntax to do something N times. I didn't leave this out by accident 25 years ago. Python takes a stance against a common approach to beginners' programming education focused on counting and indexing arrays of data, rooted in machine language and FORTRAN. Standard problems and examples like "print 'hello world' 10 times" or "draw an N-sided polygon" are designed to teach students those counting and indexing skills. It's backwards to request that the language support counting better so those examples will look simpler. Python has so much richer data structures. Create problems to teach those! -- --Guido van Rossum (python.org/~guido)
On Sun, Oct 11, 2015 at 7:59 PM, Guido van Rossum <guido@python.org> wrote:
I agree that counting and indexing dominate many stupid introductory programming exercises. And I praise the design of Python's `for` command every time I teach the language or speak about it. However, in Logo, using a command like the one below, there is absolutely no indexing or counting in sight. REPEAT 3 [FD 100 RT 120] That's why we were advocating for a similar construct in Python. But obviously you're not going to entertain the idea, so I'll drop it. Cheers, Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On 10/11/2015 2:47 PM, Luciano Ramalho wrote:
Umm... https://www.python.org/dev/peps/pep-0284/ Emile
On Sun, Oct 11, 2015 at 6:59 PM, Emile van Sebille <emile@fenx.com> wrote:
Heh. "The whole point (15 years ago) of range() was to *avoid* needing syntax to specify a loop over numbers." I guess I'm nothing if not consistent. :-) -- --Guido van Rossum (python.org/~guido)
On Sun, Oct 11, 2015 at 11:12 PM, Guido van Rossum <guido@python.org> wrote:
Andre and I are not arguing for a special syntax to loop over numbers. We are arguing for special syntax to repeat a block a number of times. No indexing at all, and no variables need to be involved. for 3: fd(100) lt(120) Best, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On Mon, Oct 12, 2015 at 1:43 AM, Guido van Rossum <guido@python.org> wrote:
Well, that's even more limited.
Yep. That's the whole point.
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg
On Mon, Oct 12, 2015 at 10:28 AM, Luciano Ramalho <luciano@ramalho.org> wrote:
In discussions like this there are 3 – at least – interlocking parties with their conflicting interests. 1. Professional programmers 2. Language Designers/implementers 3. Programming/CS teachers It is unlikely to find people equal to all these but at least let us be clear that these 3 exist! [For those who find this too long, tl;dr at bottom ] To see that these viewpoints are inherently conflicting consider that a programmer may wish that his language precludes errors – a natural wish. Translated to the designer camp this means an automatic detection of errors – also known as the Halting Problem. Which is to show that the programmer's and the language-designer's needs are not just conflicting, they are inherently conflicting And so, in like manner the programming-teachers' needs are in inherent conflict with the needs of professional programmers and language designers. 3-4 decades ago this was widely understood and some sort of compromise was worked out: Beginners studied Pascal (or Basic); professionals lived inside Fortran, Cobol, PL-1 etc. With the coming of C, people began to imagine that C was sufficiently close to Pascal that a one-fit-all solution was possible. The result has been terribly detrimental <http://blog.languager.org/2013/02/c-in-education-and-software-engineering.ht...> to CS-edcuation The increasing widespreadness of languages like Python and Haskell may seem to improve this situation. IMHO it only worsens it: Sure Python is better to teach than C++ but its not better enough that its suitable as a teaching-language. [And as Haskell gallops towards Real-World <http://book.realworldhaskell.org/> status it also gallops towards C++-dom]. Specifically coming to the suggestion at hand: Pascal got one thing right that all its successors, starting C, got terribly wrong: the need to separate and *do equal justice to* Platonic world Mundane World Values Effects Expressions Statements functions procedures More about this 50 year-old error and a beginning gleam of light: a ACM CS Curriculum 2013 <http://blog.languager.org/2015/06/functional-programming-moving-target.html> and its prequel Timeline <http://blog.languager.org/2015/04/cs-history-1.html> The error of imagining imperative programming is easy to learn comes from people not seeing that imperative languages *as they exist* contain a subset functional language which is ineluctable. Also known as the rhs of assignment statements – with the '=' being the visible indicator of the infamous von Neumann bottleneck <https://www.cs.cmu.edu/%7Ecrary/819-f09/Backus78.pdf>. The functional programming folks seeing this error try to expand that expression world to cover all of programming needs. [Whether the results of these good-intentions eg Haskell are more teachable is another matter!] The alternative (eg Logo and I am guessing Luciano and Andre ) that for the 'atoms' of the statement world, instead of having assignment statements to have turtle-left/right etc. This renders the language useless for general purpose programming but can be a neat intro to algorithmic thinking tl;dr 1. Language designer/implementers may wish to ask themselves whether having a family of easily learnable but slightly inconsistent languages helps or hinders their language. 2. Teachers may wish to re-evaluate their fixed-cost/variable-cost (equivalently batch/interactive cost) outlay in the languages they teach and check whether implementing a cut-down subset of their chosen language doesn't speed up their students and themselves 3. General programmers need to remember – not only were they noobs at some stage, there is probably something they are learning right now to which noob-ness applies even to them.
Luciano Ramalho <luciano@ramalho.org> writes:
Andre and I are not arguing for a special syntax to loop over numbers. We are arguing for special syntax to repeat a block a number of times.
That's been clear, at least to my reading of your messages. What you haven't argued is any extraordinary utility of this new syntax, sufficient to overcome the high barrier that is rightly imposed on new syntax.
Since this is quite clearly expressed in existing Python syntax with:: for __ in range(3): forward(100) turn_left(120) the single use case doesn't IMO argue for benefit sufficient to overcome the enormous burden of new syntax. -- \ “I'm not a bad guy! I work hard, and I love my kids. So why | `\ should I spend half my Sunday hearing about how I'm going to | _o__) Hell?” —Homer Simpson | Ben Finney
"Sven R. Kunze" <srkunze@mail.de> writes:
What you cite as an advantage is exactly why I'd advise against it. Your example would lead me to ask “Is this a mistake? ‘each’ is a normal name, why isn't it being used?” Whereas ‘__’ is not a normal name, and like other unusual names in Python should lead the reader to say “Okay, obviously the person writing this had something odd in mind. I'd better find out what.” That is more likely to teach about the ‘__’ convention, than to be seen as a mistake by experienced programmers. -- \ “You don't change the world by placidly finding your bliss — | `\ you do it by focusing your discontent in productive ways.” | _o__) —Paul Z. Myers, 2011-08-31 | Ben Finney
On 13.10.2015 21:49, Ben Finney wrote:
What you cite as an advantage is exactly why I'd advise against it.
Feel free to do so as do I.
Your example would lead me to ask “Is this a mistake? ‘each’ is a normal name, why isn't it being used?”
You as an experienced Python developer. That thread is about students learning programming. Not learning Python.
Python convention necessary when the student need to write real Python. Best, Sven
On Wed, Oct 14, 2015 at 06:49:39AM +1100, Ben Finney wrote: [...]
I'd just like to point out that using __ as a loop variable (or any other variable) is incompatible with the IPython convention for __. It is just wrong to talk about "the" __ convention, since there are at least two in common use, and using one necessarily conflicts with using the other. If anyone wants to argue the pros and cons of one convention versus the other, or what unused loop variables ought to be called (x, unused, each, _, __, dontcare, whatever...) please take it to python-list@python.org or comp.lang.python, as it is off-topic here. Thanks, -- Steve
On 14/10/15 01:01, Steven D'Aprano wrote:
The discussion of "what unused loop variables ought to be called" is in direct response to someone suggesting a syntax change to make things easier to teach. To suggest that they spell the loop differently to make it easier to teach whilst not requiring any syntax changes to the language is, I would argue, on-topic as a rebuttal to the change request. However, I agree with you that this particular discussion has probably run its course. E.
On 13/10/2015 18:59, Sven R. Kunze wrote:
No thanks. The current situation has suited the Python community for 25 years give or take, so if it ain't broke, there's no way it's going to get fixed, thank goodness. Can we move on please? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Like multi-line lambdas, multi-line with statements, null coalescing operators, and all the other topics that come up every other week? On October 13, 2015 5:19:46 PM CDT, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
Ryan Gonzalez writes: Avoid top-posting. It helps prevent posting merely to be contrary.<wink /> Reordering....
Mark Lawrence writes:
Stop pointlessly discussing something that simply is not going to happen.
There is a clear qualitative difference here. Mark is right about the "repeat n:" proposal, and your comparison is specious. ***** The rest of my post is an attempt to present my understanding of some aspects of Pythonic design thinking as relevant to discussions on Python-Ideas. As a running example, I try to argue why this thread should have ended with at most two posts in it. (Some might say it shouldn't have started because of PEP 284, but figuring out relevance of several hundred PEPs is a task more suited to scripture scholars than language designers.) Guido admits the benefits of all of the features Ryan mentions, and entertains *new* proposals of syntax to invoke them. That's not because he's a nice guy handing out warm fuzzies to would-be contributors. We currently don't have a good way to do them, where "good" involves both "concise" and "esthetically pleasing, especially to Guido". He really would like to serve the constituencies for those features (and might even warm up to them himself, given suitable syntax). Guido also values the educational use of Python, and when introducing new features he works hard to find syntax (including choice of keyword) that is "intuitive" to both new users of Python and new programmers. If anybody "gets" CP4E, Guido does. Of course there are different ways to get there, but arguing that lack of "repeat n:" is somehow contrary to CP4E is disrespectful. It's a different path to that end. *This proposal* to introduce a special syntax for pure repetition, however, obviously falls afoul of several principles *of Pythonic language design*. On the contrary, the arguments *for* the proposal are "non-Pythonic", which doesn't make them unimportant, much less invalid. It does, however, make them low-value on *this* list, which is for proposed improvements to the Python language. We're not here to discuss language improvements in general.[1] Here's my list: 1. The bar for new keywords is *very* high. I don't think the educational purpose would be well-served by twisting "for" into a knot with "for 4:"; that just doesn't correspond to valid English usage. "while 4:" is a little closer (IMO YMMV), but already has a meaning so it's out anyway due to backward compatibility. I think this proposal needs a new keyword, and "repeat" is excellent for the purpose. That's already a deal-killer for such a specialized construct. 2. We already have a good way to write "repeat 4:". The proposed syntax is just syntactic sugar, and even in its educational context, it's not much sweeter than (proper) use of the existing syntax. Watch one user's lips move as she draws a square: First I draw the top, then I go down the right, then I draw across the bottom, and then I connect the left up to the top. Now compare: repeat 4: forward(10) right(90) versus: for side in ('across top', 'down right', 'across bottom', 'up left'): forward(10) right(90) Which expresses her intent better? Is it really educational to have *this* user to think of a square as an abstract regular polygon that happens to have 4 sides? True, it's easy to cargo- cult the "repeat 4:" idiom the next time she needs a square, but in learning to use "repeat n:", has she learned anything about implementing her own procedures? (This is a variation on the individuality issue that Terry expressed with "kangaroo".) Note: this is a plausible example user, and I am asking whether *she* is served by the new syntax. I don't maintain that she is *the* typical user. I do think that educators should consider her needs as well as the question of how common her type is. While there probably is educational benefit to this change, it's far from clear to me what it is, or whether in fact the student's benefit is anywhere near as large as that to teachers who want to present one "simple" programming construct and move on quickly to another one. 3. The "repeat 4" idiom clearly involves counting (otherwise the program doesn't know when to stop), but it completely conceals the process. That violates "explicit is better than implicit", and furthermore makes the idiom very specialized, dramatically reducing the benefits it can have. It seems to me that the "for ... in" construct gets the balance just right. It exposes both counting as an isomorphism between concrete sets (above, repetitions of a subprocedure corresponding to named sides of a square), and abstractly using numbers merely to count (via "range(n)"). (Of course "range()" also provides a flexible way to denote various concrete sets of numbers.) 4. True, when you really do have an algorithm that simply cares about the number and repeats the same suite independently of the iteration count, exposing an iteration count variable is arguably a wart. But it's very small compared to the power of the "for ... in" idiom. Proposing to address that wart runs into "Special cases aren't special enough to break the rules." Now, all of these principles ("Read my lips: no new keywords!" and the three from the Zen) are pragmatic guidelines, not absolutes. Not even "no keywords". And they're Pythonic principles: they don't always generalize to other languages.[2] But when a proposal infringes so many Pythonic principles so flagrantly (IMHO, each is sufficient reason to deny the proposal by itself, though YMMV), it is indeed a non-starter on this list. Regards, Footnotes: [1] Note that several core Python developers have unsubscribed or muted this list completely, partly because of these off-target threads. [2] I have to admit that I'm thoroughly drunk on the Kool-Aid though, and tend to apply them to other languages, which inevitably fall short.
On October 14, 2015 12:28:07 AM CDT, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
... That was supposed to be a joke. :O
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On 13/10/15 23:19, Mark Lawrence wrote:
Huh? for each in range(3): foo() ... is already valid Python. In what way is that "not going to happen"? This spelling was just suggested as an alternative to the original poster who did not like having to explain the cryptic "___" spelling to students. Same construct, different spelling. E.
On 10/13/2015 8:01 PM, Erik wrote:
On 13/10/15 23:19, Mark Lawrence wrote:
What is not going to happen is that Python will not be changed to actually make a particular identifier a dummy, by not, for instance, letting it be used within the loop. I know you were not proposing that.
What I think will not and should not happen is that Guido and/or core devs 'bless' in PEP 8 any particular work for teaching beginners. Mark gets a bit over-anxious sometimes, but insofar as he meant 'its futile for us to try to decide on one spelling here', I think he is correct.
Same construct, different spelling.
Right, and I think 'each' if better than '_' or '__' for beginners. I recommend 'count' for range() and 'item' for a generic iterable. I also recommend that teachers of beginners experiment with various choices, and share their experiences with each other. Who knows, maybe kids would prefer 'for kangaroo in range(3):', or other personal choices. -- Terry Jan Reedy
On Wed, Oct 14, 2015 at 12:10 AM, Terry Reedy <tjreedy@udel.edu> wrote:
If a student is asking _ then it should be explained. Soon or later the students will probably see _ in other source code. Whether it is a 4-year old child or a 18 year-old college freshman. I wouldn't expect my nephew to understand everything I write, but they will grow up and have the "ah" moment.
On 10/11/2015 5:47 PM, Luciano Ramalho wrote:
I've felt the same need Andre described, and so far I have not seen a convincing argument against his proposal to accept this syntax:
Your logic is backwards. The default answer to 'add this' is 'No'. The burden of persuasion is on you. The people who have to be persuaded, by their own standards of goodness for Python, are Guido and core developers
Andre wanted, I believe, 'for <literal number>:' to avoid naming numbers, or at least variable quantities. But I am 'not convinced'. The above should be turn = 360/n for n: fd(100) lt(turn) Anyway, very young kids get the concept of 'variable quantity': number of days left to Christmas, number of cookies handed out, etc.
The goal is to repeat some operation N times without creating a spurious variable.
The fraction of for loops using range(n) is small, especially after enumerate was introduced, and especially if n is a constant. The fraction of such loops where the iteration count can never have any use is also small, because if the code has a bug, you will likely want the iteration count. Adding 'print(i, a, k)' to a loop, where a and k change with each loop is, for me, a very common debugging tool. Even without bugs, I believe that displaying iteration counts can help learning and program understanding. Right now, one could step through n = 17 for i in range(n): # i = number of chord already drawn fd(100) lt(360/n) with IDLE's debugger and see the step number increase just before a chord is drawn. Or one might want to add 'label(i)' at the top, where label(i) puts a small circled number near the current position. The more I think about this, the less I am convinced that the fraction of truly, permanently spurious loop counts is enough to support a new syntax. -- Terry Jan Reedy
On Monday, October 12, 2015 at 11:41:06 AM UTC+5:30, Terry Reedy wrote:
Just to clarify my earlier post: I dont regard this suggestion as a serious contender for python. I would however like it that if someone forked and added this to (a probably heavily cut-down) python, that fork be regarded as a friendly-by-default fork In my personal estimate: of such talk 1% will go from being vaporware to something others can actually try out Of that 1%, 0.1% can become a serious competitor for (C)Python
I just attended some lectures in which a gifted teacher used Jupyter (ipython) to give abstruse linear algebra intuitions to kids. So yes a good teacher can convey variables to kids. Is it a good idea to do so? I remember as a 10-11 year old having a hard time going from arithmetic to algebra. Current day imperative languages makes this (in my experience inherent) hardness harder on 2 more counts: - the variable is time-varying - the assignment is denoted with '=' which is a confusing synonym/homonym to the math equality And so the teacher trying to disentangle all this confusingness is to be supported (in my book) Its another matter that python is not a 'for-kids' language so it need not change to incorporate this.
participants (16)
-
Andre Roberge -
Ben Finney -
Chris Barker - NOAA Federal -
Emile van Sebille -
Erik -
Guido van Rossum -
Ian -
John Wong -
Luciano Ramalho -
Mark Lawrence -
Rustom Mody -
Ryan Gonzalez -
Stephen J. Turnbull -
Steven D'Aprano -
Sven R. Kunze -
Terry Reedy