You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecation warnings for the future async and await keywords in Python 3.6 #70370
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/1st1'closed_at=<Date2016-09-15.16:51:13.036>created_at=<Date2016-01-22.19:06:06.579>labels= ['interpreter-core', 'type-feature', 'release-blocker', 'expert-asyncio']
title='Deprecation warnings for the future async and await keywords in Python 3.6'updated_at=<Date2017-11-08.19:58:50.497>user='https://github.com/marco-buttu'
I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I noticed that assigning to async or await does not issue any deprecation warning:
If someone wants to try and fix this, I would look at how the warning for the 'with' statement was handled (it will either be in the compiler while generating bytecode or somewhere in the parser, but I'm fairly certain it's the compiler).
marco-buttu commented on Feb 2, 2016
marco-buttumannequin
MannequinAuthor
More actions
The check for the 'with' statement was handled in the parser (parsetok.c), and in Python 2.5 the warnings were enabled by default.
I do not know how to check if the deprecation warning are enabled, otherwise I would have tried to fix the problem.
I'm not quite sure what you mean by "do not know how to check if the deprecation warning are enabled". Do you mean how do you make sure you don't emit a DeprecationWarning if someone hasn't turned warnings on? If that's the case then if you look at some example code and read https://docs.python.org/3/c-api/exceptions.html#issuing-warnings you will notice that when you call the warning-related functions, all you have to do is check if the return value is < 0, then return like there is an exception raised. Otherwise the warnings module handles whether something will be shown.
AnishShah commented on Feb 2, 2016
AnishShahmannequin
Mannequin
More actions
I would like to work on this, if it is okay with Marco?
I look at the history of parsetok.c file and I think I can solve this issue.
Also, I have a doubt - PEP-492 says that "async and await names will be softly deprecated in CPython 3.5 and 3.6".
What exactly does "softly deprecate" mean? is it just same as throwing a warning?
I don't know what "softly deprecate" means. Hopefully someone involved with the PEP can answer that question.
I actually thought about emitting DeprecationWarnings in 3.6 for async/await NAME tokens. I think it's a reasonable thing to do to prepare for 3.7, where they will become proper keywords.
marco-buttu commented on Feb 4, 2016
marco-buttumannequin
MannequinAuthor
More actions
Thank you Brett, your explanation (msg259409) and the c-api doc are really straightforward. I think I can fix it in a few days, just the time to read the devguide and be confident about the workflow.
changed the title [-]Deprecation warnings for the future async and await keywords[/-][+]Deprecation warnings for the future async and await keywords in Python 3.6[/+]on Feb 8, 2016
Do notice I used exec() as otherwise the warning will be triggered at import instead of when the test runs.
marco-buttu commented on Feb 12, 2016
marco-buttumannequin
MannequinAuthor
More actions
Thank you Brett, the problem was the missed exec(). With the patch in attachment the tests pass, but it does not seem to me a good solution. Infact, changing the filter at runtime has no effect:
$ cat foo.py
import warnings
warnings.simplefilter("always")
async=33await=33
$ ./python foo.py
$
Does this happen because, putting the PyErr_WarnEx() in Python/ast.c, the warning is issued before the runtime?
Furthermore, if I set the filter from the CL, then the warning is properly triggered, but the file name and line number are wrong:
$ ./python -Wd foo.py
sys:1: DeprecationWarning: 'async' will become a reserved keyword in Python 3.7
sys:1: DeprecationWarning: 'await' will become a reserved keyword in Python 3.7
Because parsing is done before execution you can't flip on warnings during runtime in the file you to be affected.
As for the line number, that's because it's raise in C code that doesn't have a trigger in Python code. Try importing the code and you should get the line number of the import. Otherwise you will have to check if there is some function to specify a syntax warning that lets you set the line number explicitly (I don't think there is).
Ned, would it be OK to commit this patch after b1?
async/await are scheduled to become real keywords in 3.7. Right now they are only keywords in 'async def' blocks, meaning that it's OK to have a class with 'async' or 'await' attributes.
So this will be a backwards compatibility breaking change in 3.7. This patch makes Python to emit a warning each time you use async or await as an attribute/variable/etc.
I'm fine with it being in b2 because IMO the warning really should make it in 3.6 and for stuff like this it's more critical to hit the RC for people's testing than the beta to work out semantic changes.
Activity
marco-buttu commentedon Jan 22, 2016
I saw that async and await will become keywords in Python 3.7 :
https://www.python.org/dev/peps/pep-0492/#deprecation-plans
I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I noticed that assigning to async or await does not issue any deprecation warning:
brettcannon commentedon Jan 27, 2016
If someone wants to try and fix this, I would look at how the warning for the 'with' statement was handled (it will either be in the compiler while generating bytecode or somewhere in the parser, but I'm fairly certain it's the compiler).
marco-buttu commentedon Feb 2, 2016
The check for the 'with' statement was handled in the parser (parsetok.c), and in Python 2.5 the warnings were enabled by default.
I do not know how to check if the deprecation warning are enabled, otherwise I would have tried to fix the problem.
brettcannon commentedon Feb 2, 2016
I'm not quite sure what you mean by "do not know how to check if the deprecation warning are enabled". Do you mean how do you make sure you don't emit a DeprecationWarning if someone hasn't turned warnings on? If that's the case then if you look at some example code and read https://docs.python.org/3/c-api/exceptions.html#issuing-warnings you will notice that when you call the warning-related functions, all you have to do is check if the return value is < 0, then return like there is an exception raised. Otherwise the warnings module handles whether something will be shown.
AnishShah commentedon Feb 2, 2016
I would like to work on this, if it is okay with Marco?
I look at the history of parsetok.c file and I think I can solve this issue.
Also, I have a doubt - PEP-492 says that "async and await names will be softly deprecated in CPython 3.5 and 3.6".
What exactly does "softly deprecate" mean? is it just same as throwing a warning?
brettcannon commentedon Feb 2, 2016
I don't know what "softly deprecate" means. Hopefully someone involved with the PEP can answer that question.
1st1 commentedon Feb 2, 2016
I actually thought about emitting DeprecationWarnings in 3.6 for async/await NAME tokens. I think it's a reasonable thing to do to prepare for 3.7, where they will become proper keywords.
marco-buttu commentedon Feb 4, 2016
Thank you Brett, your explanation (msg259409) and the c-api doc are really straightforward. I think I can fix it in a few days, just the time to read the devguide and be confident about the workflow.
1st1 commentedon Feb 8, 2016
Assigning the issue to myself to make sure it won't be forgotten before it's too late. Anish or Marco, feel free to propose a patch.
vstinner commentedon Feb 8, 2016
Can you please mention the python version in the title?
[-]Deprecation warnings for the future async and await keywords[/-][+]Deprecation warnings for the future async and await keywords in Python 3.6[/+]2 remaining items
brettcannon commentedon Feb 11, 2016
You need to temporarily turn on warnings for it to work. For example:
Do notice I used exec() as otherwise the warning will be triggered at import instead of when the test runs.
marco-buttu commentedon Feb 12, 2016
Thank you Brett, the problem was the missed exec(). With the patch in attachment the tests pass, but it does not seem to me a good solution. Infact, changing the filter at runtime has no effect:
Does this happen because, putting the PyErr_WarnEx() in Python/ast.c, the warning is issued before the runtime?
Furthermore, if I set the filter from the CL, then the warning is properly triggered, but the file name and line number are wrong:
brettcannon commentedon Feb 13, 2016
Because parsing is done before execution you can't flip on warnings during runtime in the file you to be affected.
As for the line number, that's because it's raise in C code that doesn't have a trigger in Python code. Try importing the code and you should get the line number of the import. Otherwise you will have to check if there is some function to specify a syntax warning that lets you set the line number explicitly (I don't think there is).
1st1 commentedon Sep 12, 2016
Ned, would it be OK to commit this patch after b1?
async/await are scheduled to become real keywords in 3.7. Right now they are only keywords in 'async def' blocks, meaning that it's OK to have a class with 'async' or 'await' attributes.
So this will be a backwards compatibility breaking change in 3.7. This patch makes Python to emit a warning each time you use async or await as an attribute/variable/etc.
ned-deily commentedon Sep 12, 2016
As long as Brett is also OK with it, it can go in for 360b2.
brettcannon commentedon Sep 12, 2016
I'm fine with it being in b2 because IMO the warning really should make it in 3.6 and for stuff like this it's more critical to hit the RC for people's testing than the beta to work out semantic changes.
1st1 commentedon Sep 14, 2016
I had to rewrite the patch to make sure it reports correct position and covers all cases where using async/await should trigger a warning.
Brett, could you please take a look at the patch?
1st1 commentedon Sep 15, 2016
I'm going to commit the patch now (I'm going on vacation tomorrow, and I want to watch the buildbots).
python-dev commentedon Sep 15, 2016
New changeset 82e6017dc841 by Yury Selivanov in branch '3.6':
Issue bpo-26182: Raise DeprecationWarning for improper use of async/await keywords
https://hg.python.org/cpython/rev/82e6017dc841
New changeset 3f8b75173543 by Yury Selivanov in branch 'default':
Merge 3.6 (issue bpo-26182)
https://hg.python.org/cpython/rev/3f8b75173543
1st1 commentedon Sep 15, 2016
Merged.
brettcannon commentedon Sep 15, 2016
Sorry I didn't get around to reviewing; I'm sick.
On Thu, Sep 15, 2016, 09:51 Yury Selivanov <[email protected]> wrote:
python-dev commentedon Nov 8, 2016
New changeset 7a996e826f83 by Yury Selivanov in branch '3.6':
Issue bpo-26182: Fix ia refleak in code that raises DeprecationWarning.
https://hg.python.org/cpython/rev/7a996e826f83
New changeset 7b0e79e7f567 by Yury Selivanov in branch 'default':
Merge 3.6 (issue bpo-26182)
https://hg.python.org/cpython/rev/7b0e79e7f567