Better flexibility of pandas warnings

[darindillon]

From #1893 (scroll down a long way to the bottom) -- pandas is throwing a warning that we want to disable; but the same conceptual warning is being thrown from many different lines of code, with slightly different messages each time, so there's no way to filter them all out at once.
The python standard warning.filterwarning() method is fragile, cause you have to either

1. specify line number (which will break in the next release when line numbers change)
2. specify regex for the error message (which will break when the error message text changes, plus it's not safe for internationalization)
3. specify the module (which will filter out the warning you want to disable, but also filters out all the OTHER warnings which you want to keep).

So why not give pandas a more robust way of disabling warnings, maybe something like the C++ #pragma warning macro ( http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.80%29.aspx ) Something like:

pandas.warnings.disable("InPlaceReturnsObjectIsBeingDeprecated")
pandas.warnings.disable("SomeOtherSpecificWarning")

Or alternatively, instead of a name, maybe that takes a number specifying the warning. Gives maximum flexibility, robustness, and safety when upgrading to the next version.

[ghost]

I'm curious about the internationalization issue you mention, not sure
I follow. Could you give an example of what you mean?

[darindillon]

Some warnings and errors are only relevant for the programmer, but sometimes the warnings/errors will be shown to the end user. So if your software is used by people with different languages (like french and spanish), it's common to have the code throw "this is an error" for english users, but spanish users would see "esto es un error" instead, and french users would see it translated into french, etc. Obviously, you can't have a reg ex expression match all the different languages; so you need a system where each error/warning has a unique name/id.

Granted, most python programmers would never bother to handle multiple languages in their strings -- that's more common in "big, professional" software written in C++/Java/C#. So I'm not saying internationalization is the major reason we should implement my proposal above. Getting internationalization is just a bonus. The real reason we need this feature isn't for internationalization; it's for the issue described on #1893 (way at the bottom of the thread)

[ghost]

ok then. since pandas is not internationalized, that's not an issue.

Note that what you're asking can be made without new code, just by prefixing each warning
message with a unique number and using the existing regex filter support in warnings,
or something along those lines.

that scheme would work for i18n as well, if it was implemented.

As mentioned in #1893, that specific warning will go away permanently in the upcoming 0.11.0,
and that's the only case I'm aware of where the user can't get rid of the warning by
making the suggested change.

[darindillon]

Yes, prefixing each warning with a unique number would be sufficient (as long as the different warnings that are really the same warning have the same number -- for instance, on #1893, the set_index warning on line 2762 should have the same number as the sort warning on 3192 and the fillna error on line 2479, since they're really the exact same warning just appearing in different places). I'd be OK with that solution as long as its followed consistently.

I understand you that the specific warnings I cite will be going away in the next release. I just want to find a way to handle warnings better for the next time.

[jorisvandenbossche]

Closing as a won't fix for now given the low activity. If people are interested to actually discuss this / work on this, we can certainly re-open the issue.