This is what makes me nervous: if in some other place the conversion to
false from 0 doesn't happen then the `== False` for will tolerate that
while the `== false` form will not. We currently have this problem with
checksol giving bad results because the assumption system doesn't sanitize
input from 1 to True, for example (which is the "some places" that you
reference). I guess you could say that it's more likely to be made right if
we do the right thing and test `== false` and let someone else puzzle over
the reason something is failing and eventually fix the offending place
where 0 was not being converted.



On Tue, Nov 5, 2013 at 1:34 PM, Aaron Meurer <notifications@github.com>wrote:

> In sympy/functions/elementary/piecewise.py:
>
> > @@ -97,14 +92,14 @@ def __new__(cls, *args, **options):
> >          for ec in args:
> >              pair = ExprCondPair(*ec)
> >              cond = pair.cond
> > -            if cond is False:
> > +            if cond == false:
>
> Yes, I think the difference should not matter if we do things correctly,
> because code that does this should be looking for boolean expressions,
> whereas 0 and 1 are not these. This is perhaps one argument against
> allowing judicious use of 0 and 1 (and other numbers) in place of
> booleans. But you are right regardless; even if we do allow it, they should
> be canonicalized by the time they get to places like this anyway (though in some
> places <https://code.google.com/p/sympy/issues/detail?id=3567> of the
> SymPy code-base, unrelated to this PR, they aren't...).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/sympy/sympy/pull/2560/files#r7442607>
> .
>