On 11/5/2017 1:49 PM, Juancarlo Añez wrote:

I found this interesting: https://stackoverflow.com/a/46996392 <https://stackoverflow.com/a/46996392>

python-list is the place to post 'interesting' python-related items. If you are proposing a repeat(n) builtin, that was discussed on this list and rejected a year or two ago. It would be be a bit faster than even itertools.repeat(None, n) in a for loop. The speed argument for the proposal was countered then with the point made on the 3rd comment in the link: "But in practical code the body of the loop will be more complex, and dominate the over all timing. " An overhead of .23 microseconds per loop is small enough for real use cases. The better argument for repeat(n) was simplicity, not speed. The counter for that was and is that never needing the index for the lifetime of a particular loop, including learning, testing, debugging, and maintenance, is rare and not predictable. -- Terry Jan Reedy

On 11/5/2017 1:49 PM, Juancarlo Añez wrote:

I found this interesting: https://stackoverflow.com/a/46996392 <https://stackoverflow.com/a/46996392>

python-list is the place to post 'interesting' python-related items. If you are proposing a repeat(n) builtin, that was discussed on this list and rejected a year or two ago. It would be be a bit faster than even itertools.repeat(None, n) in a for loop. The speed argument for the proposal was countered then with the point made on the 3rd comment in the link: "But in practical code the body of the loop will be more complex, and dominate the over all timing. " An overhead of .23 microseconds per loop is small enough for real use cases. The better argument for repeat(n) was simplicity, not speed. The counter for that was and is that never needing the index for the lifetime of a particular loop, including learning, testing, debugging, and maintenance, is rare and not predictable. -- Terry Jan Reedy