python 3.5 support about quamash HOT 17 CLOSED

The initial exception doesn't quite look like it has anything to do with Quamash. Where does _DetachedRequestContextManager stem from?

from quamash.

Hm, google said, that it is from aiohttp. Line 32 in job is:

response = yield from asyncio.wait_for(
    aiohttp.get(task.url),
    10,
)

This code works fine on 3.4.3 with quamash. You think it is aiohttp issue?

from quamash.

It does look as if _DetachedRequestContextManager is passed to _format_coroutine as a coroutine for some reason, and _format_coroutine expects it to have a different interface.

from quamash.

What you can do to debug in the meantime is to see if self._coro is a _DetachedRequestContextManager line 102 of file "C:\Python35\lib\asyncio\tasks.py" (in _repr_info), with Python 3.4.

from quamash.

Forgot to specify at first, that I'd like you to compare to what happens in Python 3.4, since that works. If the coro is a _DetachedRequestContextManager then too, the problem should be that _DetachedRequestContextManager is incompatible.

from quamash.

I made test. The _coro is _DetachedRequestContextManager only with 3.5. Anyway, there is some PY35-only code in aiohttp, and I have installed alpha version.

from quamash.

I think I would try to debug why _DetachedRequestContextManager is passed as the coro with 3.5, sounds as if it shouldn't be.

from quamash.

There is duality for python versions: https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/client.py#L413-L417
which may cause some problems. But aiohttp master have commits almost every day, so I think it's better to wait until stable release. aiohttp issues search have not _DetachedRequestContextManager.

from quamash.

In that case, it looks as if _DetachedRequestContextManager has the wrong coro interface.

from quamash.

Hello,

I have the same problem. What are supposed to be contained in gi_code and cr_code ? The ContextManager doesn't look like a coroutine. I think there is a bug when passing the coroutine somewhere in the code...

from quamash.

I thought it looked like a problem with aiohttp and not quamash?

On Fri, Oct 23, 2015 at 9:16 AM, Insoleet [email protected] wrote:

Hello,

I have the same problem. What are supposed to be contained in gi_code and
cr_code ? The ContextManager doesn't look like a coroutine. I think there
is a bug when passing the coroutine somewhere in the code...

—
Reply to this email directly or view it on GitHub
#50 (comment).

from quamash.

@harvimt true. But it can't be tested well, since there is no pyqt for 3.5. I've tested it again (cause aiohttp 18.1 releazed), but nothing changes.

from quamash.

Oh, missed that traceback change:

Traceback (most recent call last):
  File "C:\Python35\lib\asyncio\coroutines.py", line 270, in _format_coroutine
    coro_code = coro.gi_code
AttributeError: '_RequestContextManager' object has no attribute 'gi_code'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "bazar-watcher.py", line 304, in Sender
    20
  File "C:\Python35\lib\asyncio\tasks.py", line 378, in wait_for
    return fut.result()
  File "C:\Python35\lib\asyncio\futures.py", line 274, in result
    raise self._exception
  File "C:\Python35\lib\asyncio\tasks.py", line 239, in _step
    result = coro.send(value)
  File "C:\pro\py\bazar-watcher\vk_sender.py", line 58, in send_message
    links.append((yield from self.upload_photo(file_like)))
  File "C:\pro\py\bazar-watcher\vk_sender.py", line 45, in upload_photo
    response = yield from self.vk.photos.getMessagesUploadServer()
  File "C:\pro\py\bazar-watcher\aiovk\api.py", line 75, in make_request
    response = yield from self.send_api_request(method_request)
  File "C:\pro\py\bazar-watcher\aiovk\api.py", line 127, in send_api_request
    response = yield from self.send_request(url, method_args, timeout)
  File "C:\pro\py\bazar-watcher\aiovk\api.py", line 137, in send_request
    timeout=timeout,
  File "C:\Python35\lib\asyncio\tasks.py", line 365, in wait_for
    fut = ensure_future(fut, loop=loop)
  File "C:\Python35\lib\asyncio\tasks.py", line 526, in ensure_future
    task = loop.create_task(coro_or_future)
  File "C:\Python35\lib\asyncio\base_events.py", line 216, in create_task
    task = tasks.Task(coro, loop=self)
  File "C:\Python35\lib\asyncio\tasks.py", line 77, in __init__
    self._loop.call_soon(self._step)
  File "C:\pro\py\bazar-watcher\quamash\__init__.py", line 373, in call_soon
    return self.call_later(0, callback, *args)
  File "C:\pro\py\bazar-watcher\quamash\__init__.py", line 348, in call_later
    .format(callback, args, delay))
  File "C:\Python35\lib\asyncio\futures.py", line 194, in __repr__
    info = self._repr_info()
  File "C:\Python35\lib\asyncio\tasks.py", line 102, in _repr_info
    coro = coroutines._format_coroutine(self._coro)
  File "C:\Python35\lib\asyncio\coroutines.py", line 272, in _format_coroutine
    coro_code = coro.cr_code
AttributeError: '_RequestContextManager' object has no attribute 'cr_code'

from quamash.

Without quamash I got:

aiohttp.errors.ClientOSError: [Errno 1] Cannot connect to host api.vk.com:443 ssl:True [Can not connect to api.vk.com:443 [[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:646)]]

But this is just cause Windows, I think. Same code with Ubuntu 3.4.3 and 3.5.0 works just fine (it have some OAuth2 exceptions, but it does not matter). What I have done is isolate aiohttp part and run it without qt and quamash.
So, probably, this is not just aiohttp, but this need some research.

from quamash.

I handled to reproduce the bug with aiohttp without quamash in aio-libs/aiohttp#590 .

from quamash.

@Insoleet brilliant! 👍

from quamash.

Please close the issue, fixed by aiohttp 0.18.3 release.

from quamash.