Romain Picard

Thanks for raising this inconsistency. The difference comes from the fact that when the error is raised, *fromiterable* catches it and tries to re-notify the on_error handler. As a consequence,...

Hello @igordertigor, How is done the branch/merge at p1 and p3? your issue may come from that part of the pipeline

Glad that you found a solution. Let's keep this issue open for now. Personally, I would rather move the existing schedulers to dedicated packages/repos rather than adding new schedulers in...

The take operator consumes the whole generator, but emits only the number of items asked for. With the contextmanager decorator, you need to use a try/finally construct to clean-up the...

> This is not the desired output, because the generator should be released by the `take` operator, so the `release context` message should appear before the `completed` message. The fact...

> So each new subscription starts the iteration again. To me it's counter intuitive that the behavior should depend on the actual kind of Iterable. This seems to contradict the...

The role of the scheduler parameter is different depending on where it is provided. First, the scheduler parameter of *subscribe* is used to propagate a default scheduler that operators can...

Item 456 is not emitted because it is pushed on the subject before the subscription happened. You either need to delay the emission, or use a ReplaySubject so that the...

If you wait until the program completes, does the memory go down? It looks like the code generates the items faster than they are processed in the thread pool. There...

You need to handle backpressure in your application. Unfortunately, there is no built-in solution for this in RxPY. Depending on the structure of your application, you can use different techniques....