On Wed, Sep 15, 2010 at 8:28 AM, Ralf Gommers 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. 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 3:34 PM, Benjamin Root wrote:

On Wed, Sep 15, 2010 at 8:28 AM, Ralf Gommers 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