Deprecation warnings when using is_real

[Amit Saha]

Hi,

As per https://github.com/sympy/sympy/issues/6212, is_real is
deprecated. I just found this:

>>> s = FiniteSet(FiniteSet(1, 2, 3))
>>> s
{{1, 2, 3}}
>>> len(s)
1
>>> s.powerset()
/usr/lib/python3.3/site-packages/sympy-0.7.5_git-py3.3.egg/sympy/functions/elementary/miscellaneous.py:334:
SymPyDeprecationWarning:

is_real has been deprecated since SymPy 0.7.6. Use is_subset(Reals)
instead. See https://github.com/sympy/sympy/issues/6212 for more info.

if (arg.is_real is False) or (arg is S.ComplexInfinity):
/usr/lib/python3.3/site-packages/sympy-0.7.5_git-py3.3.egg/sympy/core/basic.py:577:
SymPyDeprecationWarning:

is_real has been deprecated since SymPy 0.7.6. Use is_subset(Reals)
instead. See https://github.com/sympy/sympy/issues/6212 for more info.

is_real = self.is_real
{EmptySet(), {{1, 2, 3}}}

In my opinion, the deprecation warnings should be shown only when the
library user is invoking the deprecated method/property.

Hence, i think usage of is_real from SymPy's code base should be removed.

For what it's worth, the first is easy:

diff --git a/sympy/functions/elementary/miscellaneous.py
b/sympy/functions/elementary/miscellaneous.py
index 8adf46d..0935b03 100644
--- a/sympy/functions/elementary/miscellaneous.py
+++ b/sympy/functions/elementary/miscellaneous.py
@@ -331,7 +331,7 @@ def _new_args_filter(cls, arg_sequence):
for arg in arg_sequence:

# pre-filter, checking comparability of arguments
- if (arg.is_real is False) or (arg is S.ComplexInfinity):
+ if not arg.is_subset(S.Reals) or arg is S.ComplexInfinity:
raise ValueError("The argument '%s' is not comparable." % arg)

if arg == cls.zero:

What do folks think?

Best,
Amit.

[Chris Smith]

Yes, that would be a good change to make.

[Amit Saha]

I have submitted a PR for this one: https://github.com/sympy/sympy/pull/8269

I am not sure how to fix this one:

/usr/lib/python3.3/site-packages/sympy-0.7.5_git-py3.3.egg/sympy/core/basic.py:577:
>> SymPyDeprecationWarning:
>>
>> is_real has been deprecated since SymPy 0.7.6. Use is_subset(Reals)
>> instead. See https://github.com/sympy/sympy/issues/6212 for more info.

Since is_subset() is not defined for sympy.core.numbers.Infinity (for example).

Thanks,
Amit.

[Aaron Meurer]

Right, all deprecated function calls should be removed from the SymPy
codebase and test suite. Otherwise we ourselves are not even doing
what we say we should do.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CANODV3m%2Byy-1mWw7ZLq_jHSyK%3D7vexG%2BTgaPt9MWxTzoouVfGQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Aaron Meurer]

On Fri, Oct 17, 2014 at 11:51 PM, Amit Saha <amits...@gmail.com> wrote:

I don't understand. Infinity is not a set. Anyway, we shouldn't
deprecate something unless the replacement can completely replace it.

Aaron Meurer

[Joachim Durchholz]

Am 18.10.2014 um 07:57 schrieb Aaron Meurer:
> Right, all deprecated function calls should be removed from the SymPy
> codebase and test suite. Otherwise we ourselves are not even doing
> what we say we should do.

If you build your codebase in the expectation of users writing
subclasses, you need to keep the deprecated function and actually have
to point all code paths towards that deprecated one, so that people who
need to override the functionality both for old and new interface need
to do it only once.

I'm not sure whether SymPy is intended to support subclassing though. It
uses this liberally for its own uses, but that doesn't mean that it's
recommended usage for code that uses SymPy.

[Aaron Meurer]

It definitely should support subclassing. Sometimes there are
antipatterns used that prevent this (like using the class name
explicitly instead of self or checking type instead of isinstance),
but these should be fixed.

See also https://github.com/sympy/sympy/issues/6751.

Aaron Meurer

>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/5443592A.6050105%40durchholz.org.

[Joachim Durchholz]

Am 20.10.2014 um 00:48 schrieb Aaron Meurer:
> [SymPy] definitely should support subclassing.

In that case, the pattern should be that SymPy code should avoid calling
deprecated functions, except for the one function that replaces the
deprecated one, which *must* call the deprecated one so that code that
overrides the deprecated function will continue to work.

It's not always possible to do it that way, of course (e.g. if some
functionality is simply being removed).

However, "do not call deprecated stuff from SymPy at all" isn't a viable
guideline, you need to list the cases where it's actually okay to do so.
A short, potentially nonexhaustive list:
- Calls from deprecated to deprecated code.
- Old code is being superseded by new code, new code implements
its functionality by calling old code. Removal of deprecated
function usually means that you inline the deprecated function.
- If we wish to keep subclasses functional without forcing them to
override the new, non-deprecated functions as well.

HTH