Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff
On Mon, 06 Nov 2017 11:46:48 +1000, Nick Coghlan wrote: > On 6 November 2017 at 02:02, Yury Selivanov wrote: > > On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan 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 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Enabling depreciation warnings feature code cutoff
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=1 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. 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 [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
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" 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=1 > > 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. > > 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
On Mon, 06 Nov 2017 12:51:45 -0600, Neil Schemenauer 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 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
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 [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
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 > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
On Mon, 06 Nov 2017 13:25:09 -0600, Neil Schemenauer 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 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
