Silent DeprecationWarnings under Python 2.7 onwards
Hi all,
NumPy currently makes extensive use of the DeprecationWarning class to alert users when some feature is going to be withdrawn. However, as of Python 2.7, the DeprecationWarning is silent by default, see:
http://docs.python.org/library/warnings.html#updating-code-for-new-versions-...
This makes sense to me for deprecation warnings from Python itself or the standard library - after all, Python 2.7 is the last of the Python 2.x series.
However, I believe that a silent DeprecationWarning is bad news for third party libraries like NumPy where many end users are coders and we want them to see these warnings by default. Is anyone else concerned about this? A typical NumPy user (on Python 2.7+ or Python 3.2+) may never see the warnings (because they have to deliberately turn them on), the first they'll know about it is when they upgrade to a new release and their code suddenly stops working.
Potentially NumPy would have to introduce its own NumPy specific DeprecationWarning warning class, and use that.
Peter
On Fri, Sep 10, 2010 at 12:05 AM, Peter < numpy-discussion@maubp.freeserve.co.uk> wrote:
Hi all,
NumPy currently makes extensive use of the DeprecationWarning class to alert users when some feature is going to be withdrawn. However, as of Python 2.7, the DeprecationWarning is silent by default, see:
http://docs.python.org/library/warnings.html#updating-code-for-new-versions-...
This makes sense to me for deprecation warnings from Python itself or the standard library - after all, Python 2.7 is the last of the Python 2.x series.
The reason for the change is explained in the paragraph you link to, 2.7 being the final minor release in the 2.x series isn't it.
There are many other packages/programs built on numpy, the user/developer distinction can be made in the same way as for Python itself. I fail to see a reason not to follow the lead of the Python core developers here.
Cheers, Ralf
However, I believe that a silent DeprecationWarning is bad news for third party libraries like NumPy where many end users are coders and we want them to see these warnings by default. Is anyone else concerned about this? A typical NumPy user (on Python 2.7+ or Python 3.2+) may never see the warnings (because they have to deliberately turn them on), the first they'll know about it is when they upgrade to a new release and their code suddenly stops working.
Potentially NumPy would have to introduce its own NumPy specific DeprecationWarning warning class, and use that.
Peter _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Sep 15, 2010 at 8:28 AM, Ralf Gommers ralf.gommers@googlemail.comwrote:
On Fri, Sep 10, 2010 at 12:05 AM, Peter < numpy-discussion@maubp.freeserve.co.uk> wrote:
Hi all,
NumPy currently makes extensive use of the DeprecationWarning class to alert users when some feature is going to be withdrawn. However, as of Python 2.7, the DeprecationWarning is silent by default, see:
http://docs.python.org/library/warnings.html#updating-code-for-new-versions-...
This makes sense to me for deprecation warnings from Python itself or the standard library - after all, Python 2.7 is the last of the Python 2.x series.
The reason for the change is explained in the paragraph you link to, 2.7 being the final minor release in the 2.x series isn't it.
There are many other packages/programs built on numpy, the user/developer distinction can be made in the same way as for Python itself. I fail to see a reason not to follow the lead of the Python core developers here.
Cheers, Ralf
I have to agree a bit with Peter. I do understand the rationale of Python's position, however, I have to wonder what is the point of DeprecationWarning if it doesn't get displayed? The warning is supposed to give a heads-up to the developer to modify their code.
Now, the argument can be made that a python developer should know to run python with those warnings unmuted. And I would agree for "true", career programmers. However, numpy/scipy/matplotlib have become environments unto themselves, catered to converts from Matlab, R, S+ and other such languages. I would argue that many of the "developers" are not typical programmers with proper development habits/skills. Many (myself included) are graduate students in scientific fields unrelated to computer science. I have to wonder how many of them would even be aware of the differences between python versions (or even which version they are using!).
Anyway, my point is that the deprecation warnings are very valuable to display and that we need to keep in mind the audience that SciPy has. Maybe we don't necessarily turn them on by default (somehow), but maybe the documentation should highly recommend that they get turned on, thereby raising awareness on the part of the user.
There is a side-benefit to mentioning the muted warnings issue in the documentation. If a developer later complains that a feature was removed without any deprecation notices, we could simply point to the documentation and say that we recommended turning the warnings on.
My 2 cents, Ben Root
On Wed, Sep 15, 2010 at 10:34 PM, Benjamin Root ben.root@ou.edu wrote:
On Wed, Sep 15, 2010 at 8:28 AM, Ralf Gommers <ralf.gommers@googlemail.com
wrote:
On Fri, Sep 10, 2010 at 12:05 AM, Peter < numpy-discussion@maubp.freeserve.co.uk> wrote:
Hi all,
NumPy currently makes extensive use of the DeprecationWarning class to alert users when some feature is going to be withdrawn. However, as of Python 2.7, the DeprecationWarning is silent by default, see:
http://docs.python.org/library/warnings.html#updating-code-for-new-versions-...
This makes sense to me for deprecation warnings from Python itself or the standard library - after all, Python 2.7 is the last of the Python 2.x series.
The reason for the change is explained in the paragraph you link to, 2.7 being the final minor release in the 2.x series isn't it.
There are many other packages/programs built on numpy, the user/developer distinction can be made in the same way as for Python itself. I fail to see a reason not to follow the lead of the Python core developers here.
Cheers, Ralf
I have to agree a bit with Peter. I do understand the rationale of Python's position, however, I have to wonder what is the point of DeprecationWarning if it doesn't get displayed? The warning is supposed to give a heads-up to the developer to modify their code.
Now, the argument can be made that a python developer should know to run python with those warnings unmuted. And I would agree for "true", career programmers. However, numpy/scipy/matplotlib have become environments unto themselves, catered to converts from Matlab, R, S+ and other such languages. I would argue that many of the "developers" are not typical programmers with proper development habits/skills. Many (myself included) are graduate students in scientific fields unrelated to computer science. I have to wonder how many of them would even be aware of the differences between python versions (or even which version they are using!).
Anyway, my point is that the deprecation warnings are very valuable to display and that we need to keep in mind the audience that SciPy has. Maybe we don't necessarily turn them on by default (somehow), but maybe the documentation should highly recommend that they get turned on, thereby raising awareness on the part of the user.
Sure, documenting this well and recommending to turn on the warnings for example once after installation and once before upgrading makes a lot of sense.
Places to document it: http://www.scipy.org/FAQ http://projects.scipy.org/numpy/wiki/TestingGuidelines Any others?
Ralf
There is a side-benefit to mentioning the muted warnings issue in the documentation. If a developer later complains that a feature was removed without any deprecation notices, we could simply point to the documentation and say that we recommended turning the warnings on.
My 2 cents, Ben Root
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Sep 15, 2010 at 3:34 PM, Benjamin Root ben.root@ou.edu wrote:
On Wed, Sep 15, 2010 at 8:28 AM, Ralf Gommers ralf.gommers@googlemail.com wrote:
On Fri, Sep 10, 2010 at 12:05 AM, Peter
http://docs.python.org/library/warnings.html#updating-code-for-new-versions-...
This makes sense to me for deprecation warnings from Python itself or the standard library - after all, Python 2.7 is the last of the Python 2.x series.
The reason for the change is explained in the paragraph you link to, 2.7 being the final minor release in the 2.x series isn't it.
I didn't intend to suggest it was the official reason, rather this is my opinion: Given Python 2.7 is the last Python 2.x release, deprecation warnings from Python itself and the stdlib are only relevant to porting to Python 3, so having them silent makes sense for end users.
There are many other packages/programs built on numpy, the user/developer distinction can be made in the same way as for Python itself. I fail to see a reason not to follow the lead of the Python core developers here.
Cheers, Ralf
I have to agree a bit with Peter. I do understand the rationale of Python's position, however, I have to wonder what is the point of DeprecationWarning if it doesn't get displayed? The warning is supposed to give a heads-up to the developer to modify their code.
Now, the argument can be made that a python developer should know to run python with those warnings unmuted. And I would agree for "true", career programmers. However, numpy/scipy/matplotlib have become environments unto themselves, catered to converts from Matlab, R, S+ and other such languages. I would argue that many of the "developers" are not typical programmers with proper development habits/skills. Many (myself included) are graduate students in scientific fields unrelated to computer science. I have to wonder how many of them would even be aware of the differences between python versions (or even which version they are using!).
Anyway, my point is that the deprecation warnings are very valuable to display and that we need to keep in mind the audience that SciPy has. Maybe we don't necessarily turn them on by default (somehow), but maybe the documentation should highly recommend that they get turned on, thereby raising awareness on the part of the user.
We can make the warnings noisy by introducing a NumPyDeprecationWarning (which must not subclass DreprecationWarning as that would make it silent). This isn't very elegant though, and would mean existing scripts already using the warnings module to silence DreprecationWarning may need updating.
At very least, I agree the NumPy/SciPy documentation should mention this issue of silent DeprecationWarnings on Python 2.7 (and whichever of the Python 3 series do this).
There is a side-benefit to mentioning the muted warnings issue in the documentation. If a developer later complains that a feature was removed without any deprecation notices, we could simply point to the documentation and say that we recommended turning the warnings on.
It is an excuse, but at least documentation would have warned people.
Peter
participants (3)
-
Benjamin Root -
Peter -
Ralf Gommers