Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff
On 4 November 2017 at 09:52, Jelle Zijlstra jelle.zijlstra@gmail.com wrote:
2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno jsbueno@python.org.br:
This just popped up in Brython's issue tracker discussion:
""" Pierre Quentel notifications@github.com
04:57 (16 hours ago) to brython-dev/br., Subscribed
I think it's better to rename all occurences of async now, although it's strange that :
there is currently no deprecation warning in CPython with code that uses it as a variable name, PEP492 said that "async and await names will be softly deprecated in CPython 3.5 and 3.6" there is no mention of async and await becoming keywords in What's new in Python 3.7
Maybe the idea was finally given up, but I can't find a reference.
"""
So, what is the status of promoting async and await to full keyword for 3.7?
This was implemented, and it's in NEWS: https://github.com/python/cpython/pull/1669.
That's a big enough change that it should be in What's New as well (at least in the porting section, and probably more prominent than that).
The current lack of DeprecationWarnings in 3.6 is a fairly major oversight/bug, though:
Python 3.6.2 (default, Oct 2 2017, 16:51:32)
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> await = 1
>>> async = 1
>>> print(async, await)
1 1So if we're going to go ahead with making them real keywords in 3.7 (as specified in PEP 492), then the missing DeprecationWarning problem in 3.6 needs to be fixed.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 4 November 2017 at 09:52, Jelle Zijlstra jelle.zijlstra@gmail.com wrote:
2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno jsbueno@python.org.br:
This just popped up in Brython's issue tracker discussion:
""" Pierre Quentel notifications@github.com
04:57 (16 hours ago) to brython-dev/br., Subscribed
I think it's better to rename all occurences of async now, although it's strange that :
there is currently no deprecation warning in CPython with code that uses it as a variable name, PEP492 said that "async and await names will be softly deprecated in CPython 3.5 and 3.6" there is no mention of async and await becoming keywords in What's new in Python 3.7
Maybe the idea was finally given up, but I can't find a reference.
"""
So, what is the status of promoting async and await to full keyword for 3.7?
This was implemented, and it's in NEWS: https://github.com/python/cpython/pull/1669.
That's a big enough change that it should be in What's New as well (at least in the porting section, and probably more prominent than that).
The current lack of DeprecationWarnings in 3.6 is a fairly major oversight/bug, though:
There's no oversight. We had PendingDeprecationWarning for async/await names in 3.5, and DeprecationWarning in 3.6. You just need to enable warnings to see them:
~ » python3 -Wall Python 3.6.2 (default, Aug 2 2017, 22:29:27) [GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)] on darwin Type "help", "copyright", "credits" or "license" for more information.
async = 1 <stdin>:1: DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 3.7
So if we're going to go ahead with making them real keywords in 3.7 (as specified in PEP 492), then the missing DeprecationWarning problem in 3.6 needs to be fixed.
They are already keywords in 3.7, I've committed that change a month ago.
Yury
On 6 November 2017 at 02:02, Yury Selivanov yselivanov.ml@gmail.com wrote:
On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan ncoghlan@gmail.com wrote:
The current lack of DeprecationWarnings in 3.6 is a fairly major oversight/bug, though:
There's no oversight. We had PendingDeprecationWarning for async/await names in 3.5, and DeprecationWarning in 3.6. You just need to enable warnings to see them:
Gah, seven years on from Python 2.7's release, I still get caught by that. I'm tempted to propose we reverse that decision and go back to enabling them by default :P
If app devs don't want their users seeing deprecation warnings, they can silence them globally during app startup, and end users can do the same in PYTHONSTARTUP for their interactive sessions.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, 06 Nov 2017 11:46:48 +1000, Nick Coghlan ncoghlan@gmail.com wrote:
On 6 November 2017 at 02:02, Yury Selivanov yselivanov.ml@gmail.com wrote:
On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan ncoghlan@gmail.com wrote:
The current lack of DeprecationWarnings in 3.6 is a fairly major oversight/bug, though:
There's no oversight. We had PendingDeprecationWarning for async/await names in 3.5, and DeprecationWarning in 3.6. You just need to enable warnings to see them:
Gah, seven years on from Python 2.7's release, I still get caught by that. I'm tempted to propose we reverse that decision and go back to enabling them by default :P
If app devs don't want their users seeing deprecation warnings, they can silence them globally during app startup, and end users can do the same in PYTHONSTARTUP for their interactive sessions.
I'm glad you are only tempted and have not actually proposed it :)
--David
On 2017-11-06, Nick Coghlan wrote:
Gah, seven years on from Python 2.7's release, I still get caught by that. I'm tempted to propose we reverse that decision and go back to enabling them by default :P
Either enable them by default or make them really easy to enable for development evironments. I think some setting of the PYTHONWARNINGS evironment variable should do it. It is not obvious to me how to do it though. Maybe there should be an environment variable that does it more directly. E.g.
PYTHONWARNDEPRECATED=1Another idea is to have venv to turn them on by default or, based on a command-line option, do it. Or, maybe the unit testing frameworks should turn on the warnings when they run.
The current "disabled by default" behavior is obviously not working very well. I had them turned on for a while and found quite a number of warnings in what are otherwise high-quality Python packages. Obviously the vast majority of developers don't have them turned on.
Regards,
Neil
I also feel this decision was a mistake. If there's a consensus to revert, I'm happy to draft a PEP.
Alex
On Nov 6, 2017 1:58 PM, "Neil Schemenauer" nas-python@arctrix.com wrote:
On 2017-11-06, Nick Coghlan wrote:
Gah, seven years on from Python 2.7's release, I still get caught by that. I'm tempted to propose we reverse that decision and go back to enabling them by default :P
Either enable them by default or make them really easy to enable for development evironments. I think some setting of the PYTHONWARNINGS evironment variable should do it. It is not obvious to me how to do it though. Maybe there should be an environment variable that does it more directly. E.g.
PYTHONWARNDEPRECATED=1Another idea is to have venv to turn them on by default or, based on a command-line option, do it. Or, maybe the unit testing frameworks should turn on the warnings when they run.
The current "disabled by default" behavior is obviously not working very well. I had them turned on for a while and found quite a number of warnings in what are otherwise high-quality Python packages. Obviously the vast majority of developers don't have them turned on.
Regards,
Neil
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Mon, 06 Nov 2017 12:51:45 -0600, Neil Schemenauer nas-python@arctrix.com wrote:
Another idea is to have venv to turn them on by default or, based on a command-line option, do it. Or, maybe the unit testing frameworks should turn on the warnings when they run.
Unit test frameworks, including at least unittest, do.
The current "disabled by default" behavior is obviously not working very well. I had them turned on for a while and found quite a number of warnings in what are otherwise high-quality Python packages. Obviously the vast majority of developers don't have them turned on.
It's working great for me. I've only run into warnings in one package, and I wouldn't call that one high quality. And we use a lot of packages in our current project.
I'm curious which ones you are seeing it in? It could be we are operating in different problem spaces :)
--David
On 2017-11-06, R. David Murray wrote:
I'm curious which ones you are seeing it in? It could be we are operating in different problem spaces :)
In the last few months: Pillow, docutils, dateutil. Some of them could have been PendingDeprecationWarning, I'm not sure. I had that enabled as well. So, maybe the warnings would have been fixed once they became DeprecationWarning. The fact that unittest enables the warnings should help a lot.
Regards,
Neil
Perhaps this discussion can go back to python-dev?
Le 06/11/2017 à 20:25, Neil Schemenauer a écrit :
On 2017-11-06, R. David Murray wrote:
I'm curious which ones you are seeing it in? It could be we are operating in different problem spaces :)
In the last few months: Pillow, docutils, dateutil. Some of them could have been PendingDeprecationWarning, I'm not sure. I had that enabled as well. So, maybe the warnings would have been fixed once they became DeprecationWarning. The fact that unittest enables the warnings should help a lot.
Regards,
Neil
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Mon, 06 Nov 2017 13:25:09 -0600, Neil Schemenauer nas-python@arctrix.com wrote:
On 2017-11-06, R. David Murray wrote:
I'm curious which ones you are seeing it in? It could be we are operating in different problem spaces :)
In the last few months: Pillow, docutils, dateutil. Some of them could have been PendingDeprecationWarning, I'm not sure. I had that enabled as well. So, maybe the warnings would have been fixed once they became DeprecationWarning. The fact that unittest enables the warnings should help a lot.
We're using at Pillow and dateutil without seeing any warnings (without Pending on), so I suspect your speculation is correct.
--David
participants (6)
-
Alex Gaynor -
Antoine Pitrou -
Neil Schemenauer -
Nick Coghlan -
R. David Murray -
Yury Selivanov