Supplying argument list at decoration time is hardly ideal.
Typical call site would pass argument sequence at invocation time.
Thus you probably want to rewrite this decorator and allow application
without argument list:
@parallel
def foo(item)
return item ** 123
results = foo(range(9))
Perhaps OT:
My immediate reaction when I saw TransactionQueue in the docs was:
1. does add() have set semantics, that is, can I add() same item several times?
2. is queue synchronous or asynchronous, that is, can I do the following:
tq = TransactionQueue()
tq.start()
for item in some_expensive_stream():
tq.add(func, item)
tq.wait()
Or is item execution already implied during .add() before .run()?
Perhaps it's just something that needs to be clarified in the docs; or
it may influence your sugar.
On 24 July 2015 at 00:40, Antonio Cuni <anto.c...@gmail.com> wrote:
> hi Armin,
> following the discussion we had today, that TransactionQueue could be easier
> to understand for people if you explain it as "a for loop in which you don't
> know the order of the iteration", I figured out that we might even introduce
> some syntactic sugar for it; not sure if it makes things simpler or more
> complicated, though :).
> Anyway, I'm thinking of something like this:
>
> def parallel(iterable):
> def decorator(f):
> tr = TransactionQueue()
> for item in iterable:
> tr.add(f, item)
> tr.run()
> return decorator
>
>
> to be used in this way:
>
> mylist = [1, 2, 3]
>
> @parallel(mylist)
> def for_(item):
> # do something with item
> pass
>
>
> ciao,
> Anto
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev@python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
