More classical for-loop
Here is a summary of my idea about for-loop. It focuses on readability and does not take in account possible technical nuances. This is my first attempt to write a full proposal and I suppose it is ok to post it here. Many things (readability) can raise opinion based dispute, so it is sort of my opinion. I am not sure how topical/realistic is it, or contains technical flaws, so your note and recommendations are welcome. Proposal -------- Introduce a more classical, "Fortran-ish" loop syntax. The simplest syntax could be: for i somekeyword 10 : which logically will be the same as for i in range(10) : Keyword supposed to have sense only inside the statement, thus not interfere with variables and other keywords. At this moment the proposal will be to use the word "over": for i over 10 : The choice of the word is based only on its look - middle sized, has related meaning(?), and easy to type. Of course, if a better word can be found, it can be used. Note: the meaning of the word is of much less importance than optical qualities. Other good looking options: for i count 10 : for i range 10 : for i steps 10 : for i sieve 10 : Parameters same as in range(): for i over a, b, step : is the same as for i in range(a, b, step) : Rationale ----------- Removing the brackets will help concentrate on other parts of code, though it has some price, since if more than one range parameter is used, it loses some emphasis. This is easiliy compensated by IDE's syntax highlighting, namely by slightly graying out the keyword. Currently the loop statement uses the word "in". This word creates rather unpleasant visual 'stick and hole' effect on eyes due to its short size. Is quite noticable, especially in case of one-letter varaibles (e.g. for i in ...). And the 'bulky' range() part is bit too heavy. More problems to 'holes' effect, especially in monospaced editors, adds the form of glyphs "i" and "n" which both have vertical stick structure and also interfere with the very common variable name "i". Also new sytax needs less typing. Examples -------- Common use case: L = [1,3,5,7] for i over len(L): e = L[i] or: length = len(L) for i over length: e = L[i] Nested: for y over 0,480 : for x over 0,640 : putpixel (x, y) or: width = 640 height = 480 for y over 0, height : for x over 0, width : putpixel (x, y) Surprisingly good result is achieved if simply remove the keyword and put more space: for y 0, height : for x 0, width : putpixel (x, y) But similar effect can be achieved by graying out the word with syntax highlighting. Compare with existing syntax: for y in range(0,480) : for x in range(0,640) : putpixel (x, y) for y in range(0, height) : for x in range(0, width) : putpixel (x, y) Notes ------- Although it is true that the whole idea is more about cosmetics, still the for-loop is important structural component and slight improvement could count. Mikhail
On 17 February 2017 at 04:59, Chris Angelico <rosuav@gmail.com> wrote:
This would be more compact, yet less readable, more error prone variant. I'd avoid it it all costs and even if I don't need the index further in loop body, (which happens rarely in my experience) I write e=L[i] in second line to make the code more verbose and keep the flow order. So your variant (and those proposed in PEP-212) could serve in list comprehensions for example, but for common 'expanded' code I find it decline of readability, and creating totally different variants for same iteration idea. But partially that could be simply matter of habit and love to contractions. Mikhail
On Sat, Feb 18, 2017 at 3:30 AM, Mikhail V <mikhailwas@gmail.com> wrote:
If you don't need the index, why not just iterate over the list directly? for e in L: That's the single most obvious way to step through a collection in Python. What do you need to count up to the length for? ChrisA
On 17 February 2017 at 17:37, Chris Angelico <rosuav@gmail.com> wrote:
I have said I need the index, probably you've misread my last comment. Further more I explained why I think iteration over index should be the preferred way, it help with readability a lot. All my learning years ended up with rewriting most code to "for i in range()" and I slap myself when I start to write "for e in L". It is exactly where TOOWTDI applies perfectly and it is integer iteration for me. Mikhail
On Sat, Feb 18, 2017 at 4:31 AM, Mikhail V <mikhailwas@gmail.com> wrote:
Further discussion probably should be redirected to python-list, but I'll elaborate here to explain why I do not support your proposal. You have a shelf of books. I ask you to go through the books and read their titles out. How do you do it? * Point your finger to the first book - probably the leftmost one, but you might use some other order. * Read out the title of that book. * Point your finger to the next book. * Read out that book's title. * Continue until you reach the end of the shelf. This corresponds to this code: for book in books: print(book.title) Your style of iteration would be more like this: * See how many books there are * Locate the first book on the shelf * Read out the title of book #1 * Locate the second book on the shelf * Read out book title #2 * Continue until you've read as many titles as you originally counted books. This is the code: for i in range(len(books)): print(books[i].title) Which of these real-world algorithms is more natural? The only reason the iteration counter feels more readable to you is that you're accustomed to it. It's not an objective measure, it's an entirely subjective one. That's not to say that it's unimportant for that reason, but your line of argument must be "this feels more comfortable TO ME", rather than "this is more readable". Further elaboration on python-list, as mentioned above. ChrisA
On 17 February 2017 at 18:40, Chris Angelico <rosuav@gmail.com> wrote:
Further discussion probably should be redirected to python-list, but I'll elaborate here to explain why I do not support your proposal.
I don't see why you want redirect me to python-list, and how exactly do you see it, start a related discussion there?
You have a shelf of books. I ask you to go through the books and read their titles out. How do you do it?
I think first I would suppose that probably I'll need not all of the books, but say 20, or want to count something. And that is life - if I want to batch process 100 movie files obviously I'll first try to process one file. And then, if all is ok, I'll uncomment the full loop line and comment out the partial loop line. It is not known how much percent of processing algorithms does not require index *at all*. For me it is probably 20% or so. I do math, all sorts of batch processings and even in unexpected cases "for in range()" comes in handy, e.g: D = {"a":5, "b":10, "c":15} keys = D.keys() d = len(D) for i in range(0, d) : key = keys[i] print "progress:", i So I'd say there is a big amount of cases where it is natural and the proposal should not contradict with current usage, but rather is a syntactic sugar for 'for in range()" which, IMO has some purpose due to frequent usage, hence there are some PEPs related to this. Mikhail
Further more I explained why I think iteration over index should be the preferred way, it help with readability a lot.
I think you'll find this statement at odds with most of the Python community, especially Guido. I find looping over objects in a collection is what you want to do 90% of the time so adding an extra step just adds noise. I find that most people who prefer looping over indexes do so because they are more familiar with languages like C, not because it is inherently more readable. Being more comfortable with a worse way of doing something isn't a good justification for changing the language. On Fri, Feb 17, 2017 at 11:31 AM, Mikhail V <mikhailwas@gmail.com> wrote:
I think fundamentally by special-casing a for-loop variant, you have a construct with limited/no generality that's simply an additional burden to learn. You're kind of doing the opposite of converting print from a statement into a function. I far prefer the print function because it's a function like every other and doesn't have it's own curious syntax (if only assert was also fixed..., assert(cond, reason) has bit me a few times) It's nice that you can put *anything* that supports the iterator protocol after "for x in" and Python will "iterate" over it, however that is defined for the object. The thing might not have a useful integer index at all (dictionaries, file systems...) and the loop doesn't care. If you *do* want that index, you can enumerate() or range(len()), which I sometimes do if modifying a list in-place, but it's kinda icky as David suggests. Nick On Fri, Feb 17, 2017 at 4:31 PM, David Mertz <mertz@gnosis.cx> wrote:
A short Meta-note: I see most people are bottom-replying and still many do top-reply, namely you Nick always do. I dont know if there is a rule, but it makes quite hard to manage/read post with mixed posting style. On 17 February 2017 at 23:51, Nick Timkovich <prometheus235@gmail.com> wrote:
I see it is almost a tradition to give negative comments, and that is ok in many cases. But I am slightly worried how *quick* you make judgements. In what sense iteration over integer is limited? It cannot write a program for you, no doubt. If you look through examples I made, including iterating over dictionary, you will see that you can do everything with simple iteration, including cases where you do not even have any sequence which you can put in, e.g. simple loop with constant parameters, which comes in extremely handy, e.g. in simple batch scripts. Probably you mean that it can come in play with Python's inner mechanics which will lead to performance loss - yes, can be, but I was not going to argue that. "burden to learn" - I hope you are not serious :)
On 18 February 2017 at 00:27, Mikhail V <mikhailwas@gmail.com> wrote:
This is not quick - it is based on 25+ years of Python history, with iterating over object collections. And still with you being able to do: r = range for i in r(20): pass if you really need. Now, if you haven't noticed, unlike some other proposes with extended threads, there is really no one that supports this idea here. Not a single point raised, or agreed by anyone else than you that would objectively improve the language. (Ok, half it, I thin k I saw someone commenting that such a syntax could have a use in comprehension one liners). On the other hand, yu have being pointed to this being a complete Python anti-pattern. Anyway, if you don't think it is time for you to concede this is not a good idea at all, maybe it is time to use common sense, and send one last e-mail asking for any support for this idea at all. If no one else steps up suppoting at least some aspect of your proposal , I don't see the point in continuing this thread.
You can still use range.
It is not a matter of performance: it leads to readability loss. And no gain at all.
"burden to learn" - I hope you are not serious :)
No, this is serious. You duplicate the syntax possibilities of one ot he most basics syntactic elements on the language - when most of us have agreed that "There should be one-- and preferably only one --obvious way to do it". One can start coding in Python if after a couple minutes of tutorial, he learns about "for", "if", "def" and a couple data primitives - and maybe "print" and "input" for some UI. So, out of 3 needed statements to start coding, you are doubling the syntax possibilities on one of them. There s no kidding about augmenting the "burden to learn" here. (By the way, one of your arguments is about the keyword "in" being too short and hard to read - I should point that certainly most Python code these days is read in a tool that does syntax highlighting, and "in" shows in a very distinct way of the variables and expressions needed to the "for" loop - and that includes even the interactive environment as provided by ipython).
On Sat, Feb 18, 2017 at 2:13 PM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
And if you want a point of comparison, look at JavaScript's for loop. What's the difference between "for (x in y)" and "for (x of y)"? When should you use each one? More ways to use a fundamental statement == more confusion. ChrisA
On 18 February 2017 at 04:13, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
You can still use range. Yes thats what I do, see my proposal
How do you count duplicate? And what is the sense to speak about 'burden to learn' before the new syntax get approved? If it will be the new syntax, then you will need to learn the new syntax only. You want throw iterables in it, do it: for e over Sequence : I see this probably could have some ambiguity problems but is it such an unsolvable problem? For integers write e.g. like this: for i over 0, N : or for i over *N : What is the problem?
it leads to readability loss What exactly are you talking about?
most Python code these days is read in a tool that does syntax highlighting
You suppose I don't know about it? Then you are extremely underestimating me. Mikhail
On Feb 18, 2017 02:30, "Mikhail V" <mikhailwas@gmail.com> wrote: On 18 February 2017 at 04:13, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
There is no point discussing an idea on this mailing list if there is no chance it is going to be implemented. You can talk about it on the general list, as has been suggested to you before. But once an idea has been largely rejected, as this one has, this mailing list is no longer the right place for it.
How do you count duplicate? And what is the sense to speak about 'burden to learn' before the new syntax get approved? If it will be the new syntax, then you will need to learn the new syntax only. The existing syntax will not be removed. It would break all python code ever written in the most fundamental way. That is never going to happen. You want throw iterables in it, do it: for e over Sequence : I see this probably could have some ambiguity problems but is it such an unsolvable problem? For integers write e.g. like this: for i over 0, N : or for i over *N : What is the problem? So anyone learning python would need to know both syntaxes to be able to work with other peoples' code. But we would end up with two syntaxes that do exactly the same thing except with either an integer or two or three integers separated by commas, in which case they behave completely differently. That will be confusing even to experienced developers.
On Sat, Feb 18, 2017 at 03:27:00AM +0100, Mikhail V wrote:
In what sense iteration over integer is limited?
It cannot iterate over something where the length is unknown in advance, or infinite, or not meaningfully indexed by integers. Here are four for-loops. How would you re-write this using indexing? Don't forget the list comprehension! for directory, subdirs, files in os.walk(top): files.sort() for f in files: print(os.path.join(top, directory, f)) # skip .git and .hg directories, and those ending with ~ for d in ('.git', '.hg'): try: subdirs.remove(d) except ValueError: pass subdirs[:] = [d for d in subdirs if not d.endswith('~')] subdirs.sort() -- Steve
On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote:
Your concept of readability is clearly radically different from that of the majority of the Python community.
All my learning years ended up with rewriting most code to "for i in range()"
How do you cope with generators and iterators that don't have a length? How do you cope with iterables which are infinite?
It sounds like Python is not a good match for the way you think. I don't say that as a put-down, but perhaps you would be happier if you found another language that works the way you would like, instead of trying to force Python to be something it isn't? -- Steve
On 18 February 2017 at 05:43, Steven D'Aprano <steve@pearwood.info> wrote:
You mean what my proposal would bring technically better than e.g.: for i,e in enumerate(Seq) Well, nothing, and I will simply use it, with only difference it could be: for i,e over enumerate(Seq) In this case only space holes will be smoothed out, so pure optical fix. As for my comment about indexing preference- something inside me would push me to write something like: for i index Seq: e = Seq[i] One could call the second line 'noise', but I can't explain why, it helps me to read, and I am not biased to C style or anything. Also it probably has to do with variables names, and here I see it on the second line, note that it is not always 'e' and they often make sense, e.g. 'files', 'dirs'. Mikhail
On 18/02/17 19:35, Mikhail V wrote:
But you also make the language's structure not make sense. For good or bad, English is the language that the keywords are written in so it makes sense for the Python language constructs to follow English constructs. An iterable in Python (something that can be the target of a 'for' loop) is a collection of objects (whether they represent a sequence of integers, a set of unique values, a list of random things, whatever). It is valid English to say "for each object in my collection, I will do the following:". It is not valid English to say "for each object over my collection, I will do the following:". In that respect, "in" is the correct keyword for Python to use. In the physical world, if the "collection" is some coins in your pocket, would you say "for each coin over my pocket, I will take it out and look at it"? Other than that, I also echo Stephen's comments that not all iterables' lengths can be known in advance, and not all iterables can be indexed, so looping using length and indexing is a subset of what the 'for' loop can do today. Why introduce new syntax for a restricted subset of what can already be done? Soon, someone else will propose another syntax for a different subset. This is why people are talking about the "burden" of learning these extra syntaxes. Rather than 10 different syntaxes for 10 different subsets, why not just learn the one syntax for the general case? E.
On 19 February 2017 at 01:01, Erik <python@lucidity.plus.com> wrote:
That is very fair point and very interesting topic. There is even such classification of languages, how 'natural' are they, and Python is definitely a more natural language. At the same time it is sort of unique selling point of the language, for those who look at it or start to read the code for the first time. Right after that however, pure physics comes in play. So memorizing a visual pattern happens in some minutes of active reading, but further reading lasts "till final victory". Obviously proposing something like "amore" as a keyword would cause only laughter. Nevertherless, the language that uses more reading-effective patterns, in physical sense, will be superior to the language that uses "meaningful" words but which are optically bad,e.g. "all" or "through". And with all respect, "in" happens to be one.
I suppose you mean this pair: for i,e in enumerate(Seq): for e in Seq: and conditional if e in Seq: Certainly "over" will not suit in the last example, that is true. But probably swap "in" to "amore" :-) I will be totally ok with it, and it is a good visual pattern. Also it is international, so non-native speakers will learn easier, and +1 to the selling point. None of my words cancel the 'burden', and the 'burden' is tremendous I can imagine. So obviously it is not easy. However most of the burden is not in the word learning . Mikhail
On Sun, Feb 19, 2017 at 03:58:56AM +0100, Mikhail V wrote:
You think that learning to read is "pure physics". That's very ignorant of physiology, neuroscience and pedagogy. [...]
You think that "in" is "optically bad" and "over" is "optically good". Please tell us the optics formula used to determine the optical "goodness" and "badness" of a word. I want to see this physics formula that tells us how good or bad a word is "optically", and I want to know the names of at least a dozen widely available text books that teach about this theory of the optical goodness and badness of words. I want to know who discovered this formula, where it has been published for peer-review by other scientists, and what evidence exists that the formula is factually correct. Unless you do all that, don't bother responding. Your personal opinion about the optical properties of words is not a fact, and we aren't interested. Go start a blog and write about it there for people who care about your theories, and stop wasting our time here. The purpose of this mailing list is to improve the Python language, not to make it match your pseudo-scientific fantasies. There is absolutely no chance that the "in" keyword is going to be replaced by "over". Zero. None. абсолю́тный ноль. This is the last I have to say about this proposal. Don't bother responding to argue, I'm not listening, and I doubt anyone else is either. This proposal is dead in the water, its not going anywhere. -- Steve
On 19 February 2017 at 12:29, Steven D'Aprano <steve@pearwood.info> wrote:
I've understood already that ther is no interest in proposal and that is fine. If you want something about theories, the only way is that you PM me and I'll see what I can do for you free of charge. Mikhail
On 2/17/17, Mikhail V <mikhailwas@gmail.com> wrote:
Do you think that for i in steps * 10: for i in steps * 1-10: for i in steps * 1-10 ^ 2: are better than for i in range(10): for i in range(1, 10): for i in range(1, 10, 2): because brackets are gone? I am asking because you could simply implement it with current syntax. And I am not sure if removing bracket is really good enough. We could use though experiment: Is it good for you? Do you want to implement package and use "from my_package import steps" and "for in steps" in your (not performance critical) code? BTW proposing new keyword is often bad idea because it break backward compatibility. Sometimes existing keywords or operators could be used.
On 17 February 2017 at 04:59, Chris Angelico <rosuav@gmail.com> wrote:
This would be more compact, yet less readable, more error prone variant. I'd avoid it it all costs and even if I don't need the index further in loop body, (which happens rarely in my experience) I write e=L[i] in second line to make the code more verbose and keep the flow order. So your variant (and those proposed in PEP-212) could serve in list comprehensions for example, but for common 'expanded' code I find it decline of readability, and creating totally different variants for same iteration idea. But partially that could be simply matter of habit and love to contractions. Mikhail
On Sat, Feb 18, 2017 at 3:30 AM, Mikhail V <mikhailwas@gmail.com> wrote:
If you don't need the index, why not just iterate over the list directly? for e in L: That's the single most obvious way to step through a collection in Python. What do you need to count up to the length for? ChrisA
On 17 February 2017 at 17:37, Chris Angelico <rosuav@gmail.com> wrote:
I have said I need the index, probably you've misread my last comment. Further more I explained why I think iteration over index should be the preferred way, it help with readability a lot. All my learning years ended up with rewriting most code to "for i in range()" and I slap myself when I start to write "for e in L". It is exactly where TOOWTDI applies perfectly and it is integer iteration for me. Mikhail
On Sat, Feb 18, 2017 at 4:31 AM, Mikhail V <mikhailwas@gmail.com> wrote:
Further discussion probably should be redirected to python-list, but I'll elaborate here to explain why I do not support your proposal. You have a shelf of books. I ask you to go through the books and read their titles out. How do you do it? * Point your finger to the first book - probably the leftmost one, but you might use some other order. * Read out the title of that book. * Point your finger to the next book. * Read out that book's title. * Continue until you reach the end of the shelf. This corresponds to this code: for book in books: print(book.title) Your style of iteration would be more like this: * See how many books there are * Locate the first book on the shelf * Read out the title of book #1 * Locate the second book on the shelf * Read out book title #2 * Continue until you've read as many titles as you originally counted books. This is the code: for i in range(len(books)): print(books[i].title) Which of these real-world algorithms is more natural? The only reason the iteration counter feels more readable to you is that you're accustomed to it. It's not an objective measure, it's an entirely subjective one. That's not to say that it's unimportant for that reason, but your line of argument must be "this feels more comfortable TO ME", rather than "this is more readable". Further elaboration on python-list, as mentioned above. ChrisA
On 17 February 2017 at 18:40, Chris Angelico <rosuav@gmail.com> wrote:
Further discussion probably should be redirected to python-list, but I'll elaborate here to explain why I do not support your proposal.
I don't see why you want redirect me to python-list, and how exactly do you see it, start a related discussion there?
You have a shelf of books. I ask you to go through the books and read their titles out. How do you do it?
I think first I would suppose that probably I'll need not all of the books, but say 20, or want to count something. And that is life - if I want to batch process 100 movie files obviously I'll first try to process one file. And then, if all is ok, I'll uncomment the full loop line and comment out the partial loop line. It is not known how much percent of processing algorithms does not require index *at all*. For me it is probably 20% or so. I do math, all sorts of batch processings and even in unexpected cases "for in range()" comes in handy, e.g: D = {"a":5, "b":10, "c":15} keys = D.keys() d = len(D) for i in range(0, d) : key = keys[i] print "progress:", i So I'd say there is a big amount of cases where it is natural and the proposal should not contradict with current usage, but rather is a syntactic sugar for 'for in range()" which, IMO has some purpose due to frequent usage, hence there are some PEPs related to this. Mikhail
Further more I explained why I think iteration over index should be the preferred way, it help with readability a lot.
I think you'll find this statement at odds with most of the Python community, especially Guido. I find looping over objects in a collection is what you want to do 90% of the time so adding an extra step just adds noise. I find that most people who prefer looping over indexes do so because they are more familiar with languages like C, not because it is inherently more readable. Being more comfortable with a worse way of doing something isn't a good justification for changing the language. On Fri, Feb 17, 2017 at 11:31 AM, Mikhail V <mikhailwas@gmail.com> wrote:
I think fundamentally by special-casing a for-loop variant, you have a construct with limited/no generality that's simply an additional burden to learn. You're kind of doing the opposite of converting print from a statement into a function. I far prefer the print function because it's a function like every other and doesn't have it's own curious syntax (if only assert was also fixed..., assert(cond, reason) has bit me a few times) It's nice that you can put *anything* that supports the iterator protocol after "for x in" and Python will "iterate" over it, however that is defined for the object. The thing might not have a useful integer index at all (dictionaries, file systems...) and the loop doesn't care. If you *do* want that index, you can enumerate() or range(len()), which I sometimes do if modifying a list in-place, but it's kinda icky as David suggests. Nick On Fri, Feb 17, 2017 at 4:31 PM, David Mertz <mertz@gnosis.cx> wrote:
A short Meta-note: I see most people are bottom-replying and still many do top-reply, namely you Nick always do. I dont know if there is a rule, but it makes quite hard to manage/read post with mixed posting style. On 17 February 2017 at 23:51, Nick Timkovich <prometheus235@gmail.com> wrote:
I see it is almost a tradition to give negative comments, and that is ok in many cases. But I am slightly worried how *quick* you make judgements. In what sense iteration over integer is limited? It cannot write a program for you, no doubt. If you look through examples I made, including iterating over dictionary, you will see that you can do everything with simple iteration, including cases where you do not even have any sequence which you can put in, e.g. simple loop with constant parameters, which comes in extremely handy, e.g. in simple batch scripts. Probably you mean that it can come in play with Python's inner mechanics which will lead to performance loss - yes, can be, but I was not going to argue that. "burden to learn" - I hope you are not serious :)
On 18 February 2017 at 00:27, Mikhail V <mikhailwas@gmail.com> wrote:
This is not quick - it is based on 25+ years of Python history, with iterating over object collections. And still with you being able to do: r = range for i in r(20): pass if you really need. Now, if you haven't noticed, unlike some other proposes with extended threads, there is really no one that supports this idea here. Not a single point raised, or agreed by anyone else than you that would objectively improve the language. (Ok, half it, I thin k I saw someone commenting that such a syntax could have a use in comprehension one liners). On the other hand, yu have being pointed to this being a complete Python anti-pattern. Anyway, if you don't think it is time for you to concede this is not a good idea at all, maybe it is time to use common sense, and send one last e-mail asking for any support for this idea at all. If no one else steps up suppoting at least some aspect of your proposal , I don't see the point in continuing this thread.
You can still use range.
It is not a matter of performance: it leads to readability loss. And no gain at all.
"burden to learn" - I hope you are not serious :)
No, this is serious. You duplicate the syntax possibilities of one ot he most basics syntactic elements on the language - when most of us have agreed that "There should be one-- and preferably only one --obvious way to do it". One can start coding in Python if after a couple minutes of tutorial, he learns about "for", "if", "def" and a couple data primitives - and maybe "print" and "input" for some UI. So, out of 3 needed statements to start coding, you are doubling the syntax possibilities on one of them. There s no kidding about augmenting the "burden to learn" here. (By the way, one of your arguments is about the keyword "in" being too short and hard to read - I should point that certainly most Python code these days is read in a tool that does syntax highlighting, and "in" shows in a very distinct way of the variables and expressions needed to the "for" loop - and that includes even the interactive environment as provided by ipython).
On Sat, Feb 18, 2017 at 2:13 PM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
And if you want a point of comparison, look at JavaScript's for loop. What's the difference between "for (x in y)" and "for (x of y)"? When should you use each one? More ways to use a fundamental statement == more confusion. ChrisA
On 18 February 2017 at 04:13, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
You can still use range. Yes thats what I do, see my proposal
How do you count duplicate? And what is the sense to speak about 'burden to learn' before the new syntax get approved? If it will be the new syntax, then you will need to learn the new syntax only. You want throw iterables in it, do it: for e over Sequence : I see this probably could have some ambiguity problems but is it such an unsolvable problem? For integers write e.g. like this: for i over 0, N : or for i over *N : What is the problem?
it leads to readability loss What exactly are you talking about?
most Python code these days is read in a tool that does syntax highlighting
You suppose I don't know about it? Then you are extremely underestimating me. Mikhail
On Feb 18, 2017 02:30, "Mikhail V" <mikhailwas@gmail.com> wrote: On 18 February 2017 at 04:13, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
There is no point discussing an idea on this mailing list if there is no chance it is going to be implemented. You can talk about it on the general list, as has been suggested to you before. But once an idea has been largely rejected, as this one has, this mailing list is no longer the right place for it.
How do you count duplicate? And what is the sense to speak about 'burden to learn' before the new syntax get approved? If it will be the new syntax, then you will need to learn the new syntax only. The existing syntax will not be removed. It would break all python code ever written in the most fundamental way. That is never going to happen. You want throw iterables in it, do it: for e over Sequence : I see this probably could have some ambiguity problems but is it such an unsolvable problem? For integers write e.g. like this: for i over 0, N : or for i over *N : What is the problem? So anyone learning python would need to know both syntaxes to be able to work with other peoples' code. But we would end up with two syntaxes that do exactly the same thing except with either an integer or two or three integers separated by commas, in which case they behave completely differently. That will be confusing even to experienced developers.
On Sat, Feb 18, 2017 at 03:27:00AM +0100, Mikhail V wrote:
In what sense iteration over integer is limited?
It cannot iterate over something where the length is unknown in advance, or infinite, or not meaningfully indexed by integers. Here are four for-loops. How would you re-write this using indexing? Don't forget the list comprehension! for directory, subdirs, files in os.walk(top): files.sort() for f in files: print(os.path.join(top, directory, f)) # skip .git and .hg directories, and those ending with ~ for d in ('.git', '.hg'): try: subdirs.remove(d) except ValueError: pass subdirs[:] = [d for d in subdirs if not d.endswith('~')] subdirs.sort() -- Steve
On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote:
Your concept of readability is clearly radically different from that of the majority of the Python community.
All my learning years ended up with rewriting most code to "for i in range()"
How do you cope with generators and iterators that don't have a length? How do you cope with iterables which are infinite?
It sounds like Python is not a good match for the way you think. I don't say that as a put-down, but perhaps you would be happier if you found another language that works the way you would like, instead of trying to force Python to be something it isn't? -- Steve
On 18 February 2017 at 05:43, Steven D'Aprano <steve@pearwood.info> wrote:
You mean what my proposal would bring technically better than e.g.: for i,e in enumerate(Seq) Well, nothing, and I will simply use it, with only difference it could be: for i,e over enumerate(Seq) In this case only space holes will be smoothed out, so pure optical fix. As for my comment about indexing preference- something inside me would push me to write something like: for i index Seq: e = Seq[i] One could call the second line 'noise', but I can't explain why, it helps me to read, and I am not biased to C style or anything. Also it probably has to do with variables names, and here I see it on the second line, note that it is not always 'e' and they often make sense, e.g. 'files', 'dirs'. Mikhail
On 18/02/17 19:35, Mikhail V wrote:
But you also make the language's structure not make sense. For good or bad, English is the language that the keywords are written in so it makes sense for the Python language constructs to follow English constructs. An iterable in Python (something that can be the target of a 'for' loop) is a collection of objects (whether they represent a sequence of integers, a set of unique values, a list of random things, whatever). It is valid English to say "for each object in my collection, I will do the following:". It is not valid English to say "for each object over my collection, I will do the following:". In that respect, "in" is the correct keyword for Python to use. In the physical world, if the "collection" is some coins in your pocket, would you say "for each coin over my pocket, I will take it out and look at it"? Other than that, I also echo Stephen's comments that not all iterables' lengths can be known in advance, and not all iterables can be indexed, so looping using length and indexing is a subset of what the 'for' loop can do today. Why introduce new syntax for a restricted subset of what can already be done? Soon, someone else will propose another syntax for a different subset. This is why people are talking about the "burden" of learning these extra syntaxes. Rather than 10 different syntaxes for 10 different subsets, why not just learn the one syntax for the general case? E.
On 19 February 2017 at 01:01, Erik <python@lucidity.plus.com> wrote:
That is very fair point and very interesting topic. There is even such classification of languages, how 'natural' are they, and Python is definitely a more natural language. At the same time it is sort of unique selling point of the language, for those who look at it or start to read the code for the first time. Right after that however, pure physics comes in play. So memorizing a visual pattern happens in some minutes of active reading, but further reading lasts "till final victory". Obviously proposing something like "amore" as a keyword would cause only laughter. Nevertherless, the language that uses more reading-effective patterns, in physical sense, will be superior to the language that uses "meaningful" words but which are optically bad,e.g. "all" or "through". And with all respect, "in" happens to be one.
I suppose you mean this pair: for i,e in enumerate(Seq): for e in Seq: and conditional if e in Seq: Certainly "over" will not suit in the last example, that is true. But probably swap "in" to "amore" :-) I will be totally ok with it, and it is a good visual pattern. Also it is international, so non-native speakers will learn easier, and +1 to the selling point. None of my words cancel the 'burden', and the 'burden' is tremendous I can imagine. So obviously it is not easy. However most of the burden is not in the word learning . Mikhail
On Sun, Feb 19, 2017 at 03:58:56AM +0100, Mikhail V wrote:
You think that learning to read is "pure physics". That's very ignorant of physiology, neuroscience and pedagogy. [...]
You think that "in" is "optically bad" and "over" is "optically good". Please tell us the optics formula used to determine the optical "goodness" and "badness" of a word. I want to see this physics formula that tells us how good or bad a word is "optically", and I want to know the names of at least a dozen widely available text books that teach about this theory of the optical goodness and badness of words. I want to know who discovered this formula, where it has been published for peer-review by other scientists, and what evidence exists that the formula is factually correct. Unless you do all that, don't bother responding. Your personal opinion about the optical properties of words is not a fact, and we aren't interested. Go start a blog and write about it there for people who care about your theories, and stop wasting our time here. The purpose of this mailing list is to improve the Python language, not to make it match your pseudo-scientific fantasies. There is absolutely no chance that the "in" keyword is going to be replaced by "over". Zero. None. абсолю́тный ноль. This is the last I have to say about this proposal. Don't bother responding to argue, I'm not listening, and I doubt anyone else is either. This proposal is dead in the water, its not going anywhere. -- Steve
On 19 February 2017 at 12:29, Steven D'Aprano <steve@pearwood.info> wrote:
I've understood already that ther is no interest in proposal and that is fine. If you want something about theories, the only way is that you PM me and I'll see what I can do for you free of charge. Mikhail
On 2/17/17, Mikhail V <mikhailwas@gmail.com> wrote:
Do you think that for i in steps * 10: for i in steps * 1-10: for i in steps * 1-10 ^ 2: are better than for i in range(10): for i in range(1, 10): for i in range(1, 10, 2): because brackets are gone? I am asking because you could simply implement it with current syntax. And I am not sure if removing bracket is really good enough. We could use though experiment: Is it good for you? Do you want to implement package and use "from my_package import steps" and "for in steps" in your (not performance critical) code? BTW proposing new keyword is often bad idea because it break backward compatibility. Sometimes existing keywords or operators could be used.
participants (11)
-
Abe Dillon -
Chris Angelico -
David Mertz -
Erik -
Joao S. O. Bueno -
Mikhail V -
Nick Timkovich -
Pavol Lisy -
Steven D'Aprano -
Sven R. Kunze -
Todd