On 18 February 2017 at 00:27, Mikhail V <mikhail...@gmail.com> 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 <prometheus...@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. > > 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
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. > 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. You can still use range. > 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. 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). > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/