Packaging for python2/3 compatibility
Hello all, I'm a member of the RHEV integration team and for the past few weeks I've been working on packaging Ovirt for python3 compatibility for Fedora, and we have very clear guidelines for packaging python packages for Fedora: https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling and that is basically a package name starts with python2/3-*package-name*. But in RHEL or Centos, we have some packages named: python-*package-name*, *package-name*-python and so on, one example is libselinux, which in Fedora is: python2/3-libselinux and on Centos\RHEL is libselinux-python When I re-write the spec file I want to avoid (as much as possible) from if/else like if rhel require and if fedora require, I want to know if there is a correct way of doing so without using if/else everywhere in the spec file? BTW I thought of creating a macro function that gets the package name and an argument for the location of python for rhel and returns the correct python package name, and if that is the best way, I had trouble in finding examples of spec macro functions with conditions within them so I would love to get a good example of such macro function. Thanks, Gal -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio: Warning message when waiting for an Event set by AbstractLoop.add_reader
I found out what was the problem. The behavior of my "reader" (The callback passed to AbstractEventLoop.add_reader()) is to set an event. This event is awaited for in a coroutine which actually reads what is written on a pipe. The execution flow is the following: * NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * At some point, the file descriptor becomes read-ready, the selector queue the callback to set the event on the loop * The callback put on the queue is called and the event is set * NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * The file descriptor is read-ready, so the selector queue the callback to set the event on the loop * The corouting is resumed, because the event is now set, the corouting then reads what was written on the file descriptor, then clears the event and awaits again for it * The callback put on the queue is called and the event is set * NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * The corouting is resumed, because the event was set at the end of the last turn, so the coroutine attempts a read, but blocks on it, because the file descriptor is actually not read-ready Rince and repeat. This behavior actually depends on how the loop is implemented. So the best practice here is to actually do the read from the callback you gives to AbstractEventLoop.add_reader(). I think we should put a mention about it in the documentation. -- https://mail.python.org/mailman/listinfo/python-list
