[Python-ideas] More general "for" loop handling

[Joseph Martinot-Lagarde]

Le 01/05/2015 18:56, Guido van Rossum a écrit :
> On Fri, May 1, 2015 at 8:52 AM, Joseph Martinot-Lagarde
> <joseph.martinot-lagarde at m4x.org
> <mailto:joseph.martinot-lagarde at m4x.org>> wrote:
>
>     Le 01/05/2015 02:35, Steven D'Aprano a écrit :
>
>
>         If you still wish to argue for this, one thing which may help
>         your case
>         is if you can identify other programming languages that have already
>         done something similar.
>
>
>     Cython has prange. It replaces range() in the for loop but runs the
>     loop body in parallel using openmp:
>
>     from cython.parallel import prange
>
>     cdef int func(Py_ssize_t n):
>          cdef Py_ssize_t i
>
>          for i in prange(n, nogil=True):
>              if i == 8:
>                  with gil:
>                      raise Exception()
>              elif i == 4:
>                  break
>              elif i == 2:
>                  return i
>
>     This is an example from the cython documentation:
>     http://docs.cython.org/src/userguide/parallelism.html
>
>
> Interesting. I'm trying to imagine how this could be implemented in
> CPython by turning the for-loop body into a coroutine. It would be a
> complicated transformation because of the interaction with local
> variables in the code surrounding the for-loop. Perhaps the compiler
> could mark all such variables as implicitly nonlocal. The Cython example
> also shows other interesting issues -- what should return or break do?

About return and break in cython, there is a section in the documentation:

"For prange() this means that the loop body is skipped after the first 
break, return or exception for any subsequent iteration in any thread. 
It is undefined which value shall be returned if multiple different 
values may be returned, as the iterations are in no particular order."

>
> In any case, I don't want this idea to distract the PEP 492 discussion
> -- it's a much thornier problem, and maybe coroutine concurrency isn't
> what we should be after here -- the use cases here seem to be true
> (GIL-free) parallelism. I'm imagining that pyparallel has already solved
> this (if it has solved anything :-).
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>