core: make _sympify reject Basic subclasses #20128
Conversation
Previously a Basic subclass could pass through _sympify e.g.: >>> _sympify(sin) is sin True This was problemantic because _sympify is used to validate and prepare args for many Basic subclasses which should only have Basic args. With this change using _sympify with a Basic subclass will now raise an error: >>> _sympify(sin) ... SympifyError: SympifyError: sin This should mean that the output of _sympify is guaranteed to be of type Basic.
|
✅ Hi, I am the SymPy bot (v160). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.
Note: This comment will be updated with the latest check if you edit the pull request. You need to reload the page to see it. Click here to see the pull request description that was parsed. |
Codecov Report
@@ Coverage Diff @@
## master #20128 +/- ##
==============================================
+ Coverage 44.463% 75.822% +31.359%
==============================================
Files 671 671
Lines 173608 173708 +100
Branches 41001 41020 +19
==============================================
+ Hits 77192 131710 +54518
+ Misses 90531 36245 -54286
+ Partials 5885 5753 -132 |
sympy/core/basic.py
Outdated
| if not (isinstance(pattern, type) and issubclass(pattern, Basic)): | ||
| pattern = _sympify(pattern) | ||
| if isinstance(pattern, BasicMeta): |
There was a problem hiding this comment.
This first if is essentially mutually exclusive with the second, isn't it? So perhaps it should be changed to an else
There was a problem hiding this comment.
Oh, good point. Actually I should have just swapped the order of these.
There was a problem hiding this comment.
I've just moved the call to _sympify after the check for BasicMeta.
Simplify check for Basic subclasses in Basic.has
|
I was expecting more failures from across the codebase due to this. Maybe there are few errors because the code that is buggy is more likely to be using If tests pass on this run I might push a temporary commit to test a stronger verification that |
80aead9 to
319b4b0
Compare
|
So it looks like sympify with string input can return anything as it doesn't sympify the result of In [1]: type(sympify('True'))
Out[1]: bool
In [2]: type(sympify(True))
Out[2]: sympy.logic.boolalg.BooleanTrue
In [3]: type(sympify('Matrix([[1]])'))
Out[3]: sympy.matrices.dense.MutableDenseMatrix
In [4]: type(sympify(Matrix([[1]])))
Out[4]: sympy.matrices.immutable.ImmutableDenseMatrixI'm not sure if that should be considered a bug or not. It seems that |
The behaviour of sympify was changed in sympy#20128 so that sympifying a Basic subclass would be an error when strict=True. That change made the codepath for calling e.g. _sympify(Basic) slower as more checks would be done before returning. This commit adds an early raise for the case of calling _sympify(a) where a is a Basic subclass.
The behaviour of sympify was changed in sympy#20128 so that sympifying a Basic subclass would be an error when strict=True. That change made the codepath for calling e.g. _sympify(Basic) slower as more checks would be done before returning. This commit adds an early raise for the case of calling _sympify(a) where a is a Basic subclass.
Previously a Basic subclass could pass through _sympify e.g.:
This was problemantic because _sympify is used to validate and prepare
args for many Basic subclasses which should only have Basic args. With
this change using _sympify with a Basic subclass will now raise an
error:
This should mean that the output of _sympify is guaranteed to be of type
Basic.
References to other Issues or PRs
Fixes #20124
Release Notes
NO ENTRY