On 8/2/2016 7:05 AM, BartC wrote:
On 31/07/2016 19:58, Terry Reedy wrote:
On 7/31/2016 6:18 AM, BartC wrote:
repeat N:
The benefit is not so much performance, but being able to express
something very easily and quickly.
The cost of the 'repeat' contraction is that one cannot use the loop
variable, either as part of a modified computation or for monitoring or
debugging purposes.
print(i, for_body_result)
Beginners are often atrocious at debugging, and it seems not to be
taught hardly at all. 'repeat n' erects a barrier to debugging.
Debugging: probing a computation to see what actually happens, as
opposed to what one wanted and expected to happen. (Me, just now ;-)
One major way of debugging is printing values as they are computed.
Naming values (objects) allows them to be printed without recomputing
the value. In the 'repeat n' context, recomputing would mean adding 3
lines of debugging code instead of 1.
i = 0
repeat n:
a = f(a)
print(i, a)
n += 1
Your objection to a feature such as 'repeat N' doesn't really stack up.
My objection is that there is a real cost that MUST be stacked up
against the benefit.
...
Anyway, if that was a valid objection, it would apply throughout the
language. In list-comps for example (there is an index, but where do you
stick the print?).
In the expression. Given 'f(i) for i in range(n)', a careful debug
version might be '(f(i), print(i))[0] for i in range(n)'. If the loop
does not finish, the extra None component does not matter. and the
subscripting could be omitted.
Or in a for-loop iterating over values:
a=[10,20,30,40,50]
for x in a:
print (x)
This will print the element, but what's the index?
Irrelevant. The end of the sequence of prints says where the loop stopped.
> According to you,
every such for-loop needs to be written in a form that provides the
index of a loop
Don't pretend that I said that. It is not nice.
I get that people here don't want such a feature, but I don't think this
is the reason.
I think the real reason is not willing to admit that the language lacks
something that could actually be useful,
I think it is you who is unwilling to admit that nearly everything that
would be useful also has a cost, and that the ultimate cost of adding
every useful feature, especially syntax features, would be to make
python less unusable.
Some time around last August to October, I think, someone posted to
python-ideas that he had produced a children's Python environment that
accepted 'repeat n' statements and translated them to equivalent for
loops before running. His idea was that 'repeat n' should be added to
python itself so translation would not be needed. The main use of the
statement in this context is for logo/turtle code with many
side-effect-only calls.
I though the idea plausible, at first, and noted that one could add an
extension to IDLE to experiment further with the idea. An extension
could add a menu ited such as 'de-repeat'. One could also, with about
the same effort, *patch* IDLE to do the translation just before it calls
compile(code, ...).
Leaving IDLE aside, one could write a pyre.whatever script to translate
a .pyre file to a .py file and run the latter. Any of these methods
could be applied to experimenting with other 'improvement' ideas.
Anyway, *after thinking about the idea for at least a week*, I became
less enthusiastic about hiding the loop counter.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
