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/
