asyncio event guarantees to notify all waiting?
Hello,
I'm wondering if set'ing an asyncio.Event guarantees to notify all tasks that
are waiting for the event ?
Thus even if I `set()` the event and directly `clear()` the event, considering
that both thus instructions are no co-routines and thus will not return control
to the event-loop, will the wait'ers be notified?
I guess so because if I add a 'clear()' directly after the `set` in following
example, the waiting task is still notified. However this guarantee is not in
the documentation:
```
async def waiter(event):
print('waiting for it ...')
await event.wait()
print('... got it!')
async def main():
# Create an Event object.
event = asyncio.Event()
# Spawn a Task to wait until 'event' is set.
waiter_task = asyncio.create_task(waiter(event))
# Sleep for 1 second and set the event.
await asyncio.sleep(1)
event.set()
event.clear() # event directly cleared after being set
# Wait until the waiter task is finished.
await waiter_task
asyncio.run(main())
```
--
https://mail.python.org/mailman/listinfo/python-list
launching python in parallel
Dear all, I'm looking into launching python in parallel using MPI. There are many projects already doing this but I would like to understand how this can be done in a portable way. For instance, is it possible to launch myscript.py (which calls MPI_Init through an extension module) like: mpirun -np 2 /path/to/python myscript.py Using mpichgm this works, using stock mpich-1.2.5.2 (ch_p4) however, this does not work. I have been looking into the implemenation of p4 and the behavious (as described above) is understandable. The reason is that p4 creates the remote processes _in_ the MPI_Init of the master. The MPI_Init performs and execlp specifying the name of the executable only. Once the 'slave' is launched and also calls the MPI_Init, the command-line arguments are passed on to the slave. But the slave will thus only launch python, not the myscript.py. Therefore it will never call MPI_Init. I would like to know how other parallel python projects handle this. Thanks in advance, Toon Knapen -- http://mail.python.org/mailman/listinfo/python-list
build now requires Python exist before the build starts
I'm trying to build the svn-trunk version of python on a Solaris box. However I do not have a python installed yet and apparantly the build of python requires a python to be accessible (as also annotated in the Makefile generated during the ./configure). How can I solve this situation? Thanks, toon -- http://mail.python.org/mailman/listinfo/python-list
Re: build now requires Python exist before the build starts
[EMAIL PROTECTED] wrote: > > It shouldn't actually be required. I'm assuming the problem is while > trying to run asdlgen.py. The generated files are checked in, but the > timestamps are wrong and the Makefile is trying to be helpful. > > Try: > touch Include/Python-ast.h Python/Python-ast.c > make > Thanks, indeed it is a timestamp problem. However I copied the error message 'build now requires Python exists before the build starts' directly from the Makefile. It might be instructive that the Makefile also mentions that this is not strictly necessary and documents that python is needed if one wants to regenerated Python-ast.[hc]. Thanks a lot, toon -- http://mail.python.org/mailman/listinfo/python-list
CFLAGS are not taken into account properly
To configure python on a Solaris 9 box with sunstudio11 installed and to compile it in 64bit, I execute following: export CC=cc export CFLAGS="-xarch=v9" export CXX=CC export CXXFLAGS="-xarch=v9" export F77=f77 export FFLAGS="-xarch=v9" export LDFLAGS="-xarch=v9" ./configure When doing 'make' afterwards, the '-xarch=v9' option is not on the command-line however? Should'nt the CFLAGS be propagated to the Makefile that is generated by configure? Or is there any other way to do this? Thanks in advance, toon -- http://mail.python.org/mailman/listinfo/python-list
Re: CFLAGS are not taken into account properly
[EMAIL PROTECTED] wrote: > I agree, the Python configure/Makefile combination doesn't conform very well > to current GNU style in this regard. Try setting EXTRA_CFLAGS instead of > CFLAGS. Thanks. But some other (but 'similar') functionality is broken. Now I succeeded in compiling python. But when using distutils (e.g. when installing numarray using the setup.py), python will compile the files using the '-xarch=v9' option but drops this option when linking dynamic libraries (although I defined LDFLAGS="-xarch=v9" before configuring python). Additionally python adds the option '-xcode=pic32' to the compile-command which will compile my numarray in 32bit instead of 64bit (while python itself is in 64bit) toon -- http://mail.python.org/mailman/listinfo/python-list
Re: CFLAGS are not taken into account properly
[EMAIL PROTECTED] wrote: > Toon> But some other (but 'similar') functionality is broken. Now I > Toon> succeeded in compiling python. But when using distutils (e.g. when > Toon> installing numarray using the setup.py), python will compile the > Toon> files using the '-xarch=v9' option but drops this option when > Toon> linking dynamic libraries (although I defined LDFLAGS="-xarch=v9" > Toon> before configuring python). Additionally python adds the option > Toon> '-xcode=pic32' to the compile-command which will compile my > Toon> numarray in 32bit instead of 64bit (while python itself is in > Toon> 64bit) > > That seems like a bug in distutils. Can you submit a help ticket? > > Skip Done -- http://mail.python.org/mailman/listinfo/python-list
