-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python3.7 support #437
python3.7 support #437
Conversation
Problem with python3.7 |
Codecov Report
@@ Coverage Diff @@
## master #437 +/- ##
==========================================
+ Coverage 93.57% 93.59% +0.02%
==========================================
Files 25 25
Lines 3672 3684 +12
Branches 194 195 +1
==========================================
+ Hits 3436 3448 +12
Misses 198 198
Partials 38 38
Continue to review full report at Codecov.
|
@asvetlov: fixes for python3.7 done |
@smagafurov you lowered the coverage, could you raise it or leave it as before |
@vir-mir: Sorry but I can't understand how to do this. |
I'll try to look at this week |
@vir-mir: now code coverage is ok !!! but there is some back incompatibility in python 3.7 This code works in python 3.6 async for value in conn.execute(sql): But in python 3.7 it throws:
I fix this for python 3.7 as: async for value in await conn.execute(sql): See my changes in May be this solution is wrong and we must do something to support python3.7 without this incompatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests/pep492/test_async_await.py
Outdated
@@ -275,7 +278,10 @@ | |||
result = [] | |||
async with aiopg.sa.create_engine(loop=loop, **pg_params) as engine: | |||
async with engine.acquire() as conn: | |||
async for value in conn.execute(sql): | |||
rows = conn.execute(sql) | |||
if PY_37: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bad decision. We are here solving the consequences and not the cause. you need to rethink it, you probably need to do this in conn.execute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can anyone else refactor this hack so we can move forward? I don't know what you mean by "doing this in conn.execute
", @vir-mir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fun one. The examples and documentation show that aiopg.sa.SAConnection.execute
is both await
-able and can be asynchronously iterated BUT the current implementation should only work by awaiting result before iterating. It just happens to be working without awaiting the result in CPython < 3.7 because it thinks we were supplying an old-style async iterable and that it should await the iterable first like it did pre-3.5.2.
Now that CPython doesn't revert to awaiting when __aiter__
returns an awaitable, we have a couple choices:
- Change the documentation, examples, tests to emphasize that execute is not async-for-able but its result is, like
async for row in await conn.execute(tbl.select())
or
- Leave docs, tests, examples as-is, but make our
_SAConnectionContextManager
s behave like they should, with their__aiter__
providing something other than a coroutine. This could be the_SAConnectionContextManager
instance itself, with some__anext__
implemented, or some other wrapper around the coroutine the manager encapsulates.- This might be the best option given folks have probably already been using
for row in conn.execute()
in their code.
- This might be the best option given folks have probably already been using
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smagafurov I've created a possible fix PR to your PR in smagafurov#1.
any update on this? |
Please postpone the merge. |
@@ -106,7 +106,8 @@ class Connection: | |||
|
|||
def __init__(self, dsn, loop, timeout, waiter, echo, **kwargs): | |||
self._loop = loop | |||
self._conn = psycopg2.connect(dsn, async=True, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we can use async_
keyword: http://initd.org/psycopg/docs/connection.html#connection.async_
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
Hi, any updates and estimates on this? Thanks |
…ecute. Supplements pull request aio-libs#437 for aio-libs#436.
The behavior of iteration has changed to where a StopIteration exception should not be raised inside a generator except by something unexpected.
@smagafurov I have two pull requests pending against your PR's branch for fixing some of the remaining issues. |
Fix for RuntimeError in Python 3.7+ from unexpected StopIteration raises
Await result before first async iteration in 3.5.2+ in SQL alchemy execute
Resolves Python 3.4 flake8 continuous integration failure.
This last one should address the failing CI checks for 3.4. |
This reverts commit 8d82522.
…stopasynciteration Allow QA of StopAsyncIteration lines, give flake8 built-ins hint in Python <3.5
except StopAsyncIteration: | ||
self._obj.close() | ||
self._obj = None | ||
raise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, we would just make __aiter__
an async generator so we don't have to supply this __anext__
proxying code, but this would break for the small handful of CPython releases >=3.5.2 and <3.6
@@ -9,8 +9,10 @@ python: | |||
- "3.4" | |||
- "3.5" | |||
- "3.6" | |||
- "nightly" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to replace "nightly" -> "3.7" but there is issue about Travis and python 3.7: travis-ci/travis-ci#9815
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add a job with specific settings for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind. I did this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@webknjaz nice. Did you mean to leave in the nightly build? Not opposed to it either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nightly points to 3.8-dev now.
LGTM, but I'd rather wait for @asvetlov to share his thoughts on this |
I have run our battery of integration tests against this branch and has worked good. I see there are a couple of comments open, do they require any further action? We need into 3.7 in my project and right now this is the one dependency keeping us in 3.6, is there anything I can do to push this forward? |
@asvetlov @popravich @jettify if there are no objections, I will wait a few days and salt it. |
Please... merge it.. I can't connect using latest psycopg2 :( |
No description provided.