✅

Hi, I am the SymPy bot. I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

• physics.biomechanics

  • Symengine backend support removed. (#25617 by @moorepants)

• physics.mechanics

  • Symengine backend support removed. (#25617 by @moorepants)

• physics.vector

  • Symengine backend support removed. (#25617 by @moorepants)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->

Fixes #25401


#### Brief description of what is fixed or changed

Symengine was added as a backend for sympy.physics.mechanics and related packages and modules to improve performance. Instead it created a maintenance burden because the developers of these SymPy packages do not develop Symengine and many additions improvements to the SymPy packages require duplicating functionality in Symengine. This PR removes support for the Symengine backend in a backwards compatible fashion. If a user was using this, results will not change but their code execution may become slower.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers. Formerly, `log(-x)` incorrectly gave `-log(x)`.

* physics.units
  * Corrected a semantical error in the conversion between volt and statvolt which
    reported the volt as being larger than the statvolt.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->

* physics.vector
  * Symengine backend support removed.
* physics.mechanics
  * Symengine backend support removed.
* physics.biomechanics
  * Symengine backend support removed.

<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

The changes look good, but two comments:

The imports should be using the full imports and not just import from sympy.
There is one import which renames Expr: from sympy.core.expr import Expr as ExprType, I suspect this rename might no longer be needed (but was before because of the symengine backend) but I'm not certain.

Let's make sure this gets flagged as backwards incompatible in the release notes.

As far as I can tell from the discussion in gh-25401 we are agreed that this should be merged so merging.

CC @certik @isuruf

The changes look good, but two comments:

Sorry I just missed this comment when merging.

The imports should be using the full imports and not just import from sympy.

I think that because mechanics is a "leaf node" in the import graph then it is okay to just import things in the way that users would.

The situation where it is important to use fully qualified imports is really for anything that would be imported during the process of import sympy because then it causes circularity problems etc. Otherwise the intended way to import things is always from sympy import X which is what users should do. Also in test code things should be imported in the way that users are expected to import thing (not fully qualified imports).

There is one import which renames Expr: from sympy.core.expr import Expr as ExprType, I suspect this rename might no longer be needed (but was before because of the symengine backend) but I'm not certain.

Yes, probably that is not needed...

Fully qualified imports in library code is something that could be enforced with a linter. Although I've never really been that convinced that it's that important. There's a misconception that from sympy.core.symbol import Symbol is faster than from sympy import Symbol, but that isn't true at all.

Although I've never really been that convinced that it's that important.

It wouldn't be important if SymPy was not full of circular imports.

I agree, and that's my point. It's cargo culted everywhere in the codebase. For instance, most test files use this style. But circular imports are impossible in a test file. Nothing does (or should) import something from a test file, even another test file.

I guess you could argue it's more readable, especially when a large number of the imports aren't in sympy/__init__.py and have to use this style anyway. But I'm not so sure I find that all that convincing.