strange bug with start_subscribe

[tumb1er]

Hello!
Just got some strange bug with PUB/SUB code:
In coroutine I have:

pubsub = yield from redis.start_subscribe()
yield from pubsub.subscribe([channel])

In my case all stops after yielding from redis.start_subscribe() - reactor just don't return pubsub object. But! It only happens on second script launch (after __pycache__ dir filled with compiled code). And if I remove this directory, all works fine again until next launch.

As a workaround, I replaced first yield with:

try:
    redis.start_subscribe().__next__()
except StopIteration as e:
    pubsub = e.value

and all works without magic.

So, my proposal is to remove unnecessary @asyncio.coroutine decorator from start_subscribe and propose to use it like a synchronous method.

Sergey.

[tumb1er]

May be not a bug. It's just random on my project and I don't know what to do. It just doesn't receive messages from redis-cli, or receives it with incorrect order of message and channel :-/

[jonathanslenders]

Hi tumb1er. Can you somehow send me your code by mail? I can't reproduce it here...

Normally, the coroutine decorator shouldn't hurt. If so, it's definitely a bug in asyncio and in that case it would be really nice if we know the reason before the release of Python 3.4.

[tumb1er]

Fixed it.

It was asyncio==0.3.1.
In it 'asyncio.gather' flips the sequence of coro from it's args, so your redis client received

1 channelname subscribe

instead of

subscribe channelname 1

Very strange bug...

Sergey

[jonathanslenders]

It should be a bug that's recently introduced into asyncio...

[jonathanslenders]

It's this commit: https://code.google.com/p/tulip/source/detail?r=463313bafa7579c8ed67258cf436accfa7db00d2

[jonathanslenders]

Fixed in ab03a5a

Can you try again?