3 ms·

This looks really nice, and Flask compatibility is great. One question, in the asyncio docs (really nice BTW, I hadn't tried that out yet and instantly grasped

by mcintyre1994 9y ago

This looks really nice, and Flask compatibility is great. One question, in the asyncio docs (really nice BTW, I hadn't tried that out yet and instantly grasped your example) you mention the common pitfall of `await awaitable.attribute` with missing brackets. In the Migration from Flask docs you give some examples where you need await like `await request.data` and `await request.get_json()` - do these need brackets in the same way or is `request` special? Same deal with `test_client` straight after that. BTW, do all routes have to be async here - even your quickstart that just returns 'hello'? One other thing - since you require Python 3.6 anyway it'd probably make sense to use `pipenv` instead of `venv` as your recommended install, it'd probably make your docs simpler.

orf 9y ago
For the common pitfall question, when you do `await expression` python will resolve `expression` and then await it. When you do `await request.json()`, python calls `request.json()` and then awaits the return value (which will return json, at some point). The same thing with `await request.data`. You can easily avoid this pitfall by writing this code: data = await resp.json() print(data['attribute']) instead of this: print((await resp.json())['attribute']) TBH I find that section of the docs more confusing than helpful, it's not an issue you'd generally run into IMO.
pgjones 9y ago
`request` itself isn't an awaitable, whereas the `data` property and `get_json` method both return awaitables (https://gitlab.com/pgjones/quart/blob/master/quart/wrappers/request.py#L142 https://gitlab.com/pgjones/quart/blob/master/quart/wrappers/...). I think these are probably things that become second nature through usage. The routes don't have to be async as Quart will wrap them in a coroutine anyway. However I'm not sure there is any advantage to not adding the async keyword. Thanks, I need to learn how pipenv works.
- bb88 9y ago
  Pipenv is not bad. I switched to it in about 30 minutes. To start a new project: pipenv --three To add packages: pipenv install <package> pipenv install -d <development packages> pipenv install -r requirements.txt Then check in your Pipfile and Pipfile.lock. When someone makes a fresh checkout, they cd to where the Pipfile and Pipfile.lock are and run: pipenv install When you're ready to update your dependencies do the following: rm Pipfile.lock pipenv update (-d to load development packages) To get a shell, cd to where the Pipfile of your project is: pipenv shell To run something in the virtualenv when the virtualenv is not activated: pipenv run <command>

orf 9y ago

For the common pitfall question, when you do `await expression` python will resolve `expression` and then await it. When you do `await request.json()`, python calls `request.json()` and then awaits the return value (which will return json, at some point). The same thing with `await request.data`. You can easily avoid this pitfall by writing this code: data = await resp.json() print(data['attribute']) instead of this: print((await resp.json())['attribute']) TBH I find that section of the docs more confusing than helpful, it's not an issue you'd generally run into IMO.

pgjones 9y ago

`request` itself isn't an awaitable, whereas the `data` property and `get_json` method both return awaitables (https://gitlab.com/pgjones/quart/blob/master/quart/wrappers/request.py#L142 https://gitlab.com/pgjones/quart/blob/master/quart/wrappers/...). I think these are probably things that become second nature through usage. The routes don't have to be async as Quart will wrap them in a coroutine anyway. However I'm not sure there is any advantage to not adding the async keyword. Thanks, I need to learn how pipenv works.

bb88 9y ago
Pipenv is not bad. I switched to it in about 30 minutes. To start a new project: pipenv --three To add packages: pipenv install <package> pipenv install -d <development packages> pipenv install -r requirements.txt Then check in your Pipfile and Pipfile.lock. When someone makes a fresh checkout, they cd to where the Pipfile and Pipfile.lock are and run: pipenv install When you're ready to update your dependencies do the following: rm Pipfile.lock pipenv update (-d to load development packages) To get a shell, cd to where the Pipfile of your project is: pipenv shell To run something in the virtualenv when the virtualenv is not activated: pipenv run <command>