Issue #103: util.state: Implement __await__ and .future#104
Merged
ChristianTremblay merged 12 commits intoFeb 26, 2021
Merged
Conversation
`.future` returns a `Future` object (either a native `asyncio` `Future`, or a Tornado `Future`), which can be `yield`-ed (Tornado on Python <3.4) or `await`-ed (Python 3.5+).
…hon. Python older than v3.3 does not understand `yield from`, and won't ignore it inspite of it being in a code path that won't be run for older releases. So instead, we have to put it in a completely separate file and convince Python to hopefully not import it when running on older Python releases.
Owner
|
@sjlongland it was tagged as "draft" , can we merge ? |
Collaborator
Author
|
On 1/12/20 11:28 am, Christian Tremblay wrote:
@sjlongland it was tagged as "draft" , can we merge ?
I'd like to try and get some unit tests in there first. Make sure it
works as it should.
|
There are some "extra" features, which are not required for `pyhaystack` to run, but may make its use more pleasant. - `pandas`: Installing this drags in a _lot_ of X11-related dependencies on Linux-based platforms, so it makes sense to make this "optional" for "embedded" use cases where advanced computation is not being performed. - `tornado`: Support for the Tornado IO loop. Mostly this only matters for Python 2.7 users who may still want to drive `pyhaystack` asynchronously.
Some of these branches are impossible to test since unless Shrödinger starts writing Python packages, we can't have a package simultaneously "installed" and "uninstalled" at the same time.
Collaborator
Author
|
Okay, let's see what Travis CI makes of this. Works fine on Gentoo with Python 2.7.18 and Python 3.8.6. |
…low copy. This allows for objects to be shallow-copied using `__copy__`, instead of relying on the object having a `.copy` method.
With wrapper to "hide" the tests from Python < 3.5.
`extras_require` should be a `dict` not a `list`, Duh!
sjlongland
force-pushed
the
feature/awaitable-operation
branch
from
36bd18a to
2beebcb
Compare
Owner
|
Keeping state.py for compatibility ? Not sure how this will be called (I don't get the assert...) |
Owner
|
Another question, just to be sure, if we want this to work, we'll need an async requests gizmo ? You set up the base, right ? |
Collaborator
Author
|
On 20/12/20 7:02 am, Christian Tremblay wrote:
Keeping state.py for compatibility ? Not sure how this will be called (I don't get the assert...)
Well, sort-of. I tried to do it all in `state.py`, but Python 2 threw a
hissy fit over the `await` and `async` keywords. This is primarily a
Python 3 feature, but I don't want to break Python 2 yet (even though
I've told my workplace I won't be writing Py2 code from 2020 onwards).
So I was forced to put it in a separate "module" to "hide" it. It
checks what version of Python is before importing. That said, just
realised I should try actually installing the package too.
Same deal with the tests, you'll see I did the same thing there.
All the `assert` does is keep `pyflakes` from complaining that a symbol
is imported but not used.
|
Collaborator
Author
|
On 20/12/20 7:04 am, Christian Tremblay wrote:
Another question, just to be sure, if we want this to work, we'll need an async requests gizmo ? You set up the base, right ?
Yeah, that's the other half of the equation, asynchronous HTTP client
glue logic. There's `aiohttp` on Python 3.4+. Tornado also has an
`async` client we could wrap.
Again, I'll put these in their own modules so that they're "hidden" from
Python installs that can't understand the syntax (`yield from`/`await`).
My primary aim in this PR was to make the operations in `ipython` shell
more "natural" by making its `async` support handle `pyhaystack`'s way
of doing async operations.
|
… hide from Python 2. At the moment, installing `pyhaystack` on Python 2 works, but it throws an error (which it then ignores) when it tries to "compile" the `.py` file to `.pyo`. Since these files have no use in a Python 2 install, let's move them into a sub-package which we can selectively import if and only if Python 3 is in use.
Collaborator
Author
|
Okay, so that last commit takes care of this: I've moved |
Owner
|
Going forward.... it is a tremendous improvement for what will happen next ! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
.futurereturns aFutureobject (either a nativeasyncioFuture,or a Tornado
Future), which can beyield-ed (Tornado on Python <3.4)or
await-ed (Python 3.5+).TODO: Some unit tests.