Adding a Par construct to Python?

[Aaron Brady]

On May 17, 7:05 am, jer... at martinfamily.freeserve.co.uk wrote:
> From a user point of view I think that adding a 'par' construct to
> Python for parallel loops would add a lot of power and simplicity,
> e.g.
>
> par i in list:
>     updatePartition(i)
>
> There would be no locking and it would be the programmer's
> responsibility to ensure that the loop was truly parallel and correct.
>
> The intention of this would be to speed up Python execution on multi-
> core platforms. Within a few years we will see 100+ core processors as
> standard and we need to be ready for that.
>
> There could also be parallel versions of map, filter and reduce
> provided.
>
> BUT...none of this would be possible with the current implementation
> of Python with its Global Interpreter Lock, which effectively rules
> out true parallel processing.
>
> See:http://jessenoller.com/2009/02/01/python-threads-and-the-global-inter...
>
> What do others think?
>
> Jeremy Martin

Hi, joining late.

My first guess is that you haven't considered the existing syntactic
variants.

for i in list:
    fireandforget( updatePartition )( i )

for i in list:
    with fireandforget( ) as x:
        x.call( updatePartition )( i )

@fireandforget
def fun( i ):
    updatePartition( i )
for i in list:
    fun( i )

Are you suggesting only syntactic sugar, or a true semantic change to
make parallel programming easier?