Upgrade SymPy

[FrederikSchnack]

Summary

Update SymPDE to support the maintained SymPy release range:

SymPy >= 1.12, < 1.15

This PR addresses compatibility problems caused by stricter symbolic construction, traversal, reconstruction, hashing, and sympification behavior
in recent SymPy versions.

Closes #106.

Compatibility issues and fixes

1. Incorrect construction of custom Symbol subclasses

ScalarFunction, VectorFunction, and DifferentialForm were constructed through Expr.__new__ or Basic.__new__ instead of SymPy’s Symbol constructor.

Recent SymPy versions expect symbol subclasses to initialize Symbol-specific state, including assumptions, commutativity, and free-symbol behavior. Without this initialization:

• free_symbols could be incorrect;
• assumptions were not initialized consistently;
• scalar and vector functions could have incorrect commutativity;
• equality and hashing did not follow SymPy’s symbol semantics.

The affected objects are now constructed through Symbol.__xnew__.

SymPDE-specific metadata, such as the function space or differential-form degree and dimension, is included through _hashable_content rather than being passed as invalid raw symbol arguments.

Regression tests verify:

• correct scalar and vector commutativity;
• correct free_symbols;
• stable equality and hashing;
• distinct differential forms for different degree or dimension values.

2. Non-SymPy values stored in Basic.args

Several SymPDE expression classes stored ordinary Python objects directly in their structural arguments, including:

• strings;
• integers;
• None;
• lists and tuples;
• dictionaries.

Modern SymPy traverses, hashes, prints, sympifies, and reconstructs every object exposed through Basic.args. Raw Python metadata could therefore cause failures during operations such as:

expr.func(*expr.args)
expr.xreplace(...)
preorder_traversal(expr)

A common structural-argument normalization layer was introduced:

• strings are stored as SymPy Str objects;
• integers are sympified as Integer;
• tuples and lists are stored as SymPy Tuple objects;
• dictionaries are stored as SymPy Dict objects;
• optional None values use a private SymPy-compatible sentinel.

Matching restoration helpers convert these values back to their historical Python representation when accessed through public properties. This preserves the existing SymPDE API while keeping expression trees valid for SymPy.

The normalization is applied to objects including domains, boundaries, interfaces, equations, matrix elements, traces, one-dimensional forms, differential forms, and multipatch mappings.

3. Expressions could not be reconstructed from func and args

SymPy assumes that symbolic expressions can generally be rebuilt using:

expr.func(*expr.args)

This mechanism is used internally by substitution, xreplace, simplification, and other tree transformations.

A number of SymPDE constructors did not satisfy this contract because:

• structural metadata was omitted from args;
• constructors expected keyword-only arguments;
• reconstructed arguments were SymPy containers instead of Python containers;
• subclass constructors interpreted structural arguments as user-facing arguments;
• optional arguments were not converted back from their symbolic representation.

Constructors were updated to accept and restore normalized structural arguments. Reconstruction now retains information such as:

• domain interiors and boundaries;
• mappings and logical domains;
• interface orientations;
• domain connectivity;
• line, square, and cube bounds;
• equation boundary conditions and constraints;
• tensor-form names, axes, and weights;
• multipatch mapping dictionaries.

Regression tests now exercise both reconstruction and substitution:

rebuilt = expr.func(*expr.args)
replaced = expr.xreplace({...})

4. Multipatch mappings used raw dictionaries as symbolic arguments

MultiPatchMapping previously placed a Python dictionary directly in Basic.args and implemented a custom __hash__.

Recent SymPy operations expect structural arguments themselves to be symbolic and reconstructible. This caused problems during hashing, replacement, and rebuilding.

The mapping dictionary is now stored structurally as a SymPy Dict, while the public mappings property continues to return a regular Python dictionary. Hashing is derived from the normalized structural arguments instead of a separate custom implementation.

Tests verify that multipatch mappings survive both reconstruction and xreplace.

5. Function symbols with the same name collapsed across spaces

Function symbols were primarily identified by their printed name. As a result, functions with the same name but belonging to different function spaces could compare as equal and collapse during SymPy simplification.

For example, an expression conceptually equivalent to:

u_from_V + u_from_W

could be simplified as though both functions were the same symbol.

Function spaces now define structural equality from their name, domain, shape, and kind. Scalar and vector function symbols include their function space in _hashable_content.

This ensures that:

• equivalent spaces compare and hash equally;
• different spaces remain distinct;
• functions with the same name in different spaces remain distinct symbols;
• additions do not incorrectly combine functions from different spaces;
• mapped and logical test functions retain the correct domain identity.

6. Constructor postprocessing returned a Python list

The integral multiplication postprocessor wrapped a transformed IntAdd expression in a Python list before passing it back to Mul.

Recent SymPy versions strictly sympify constructor-postprocessor results and reject this list during form-linearity checks.

The postprocessor now returns the transformed IntAdd expression directly:

IntAdd(...)

instead of:

[IntAdd(...)]

7. Legacy SymPy compatibility helpers were outdated

SymPDE carried local copies of compatibility utilities for:

• is_sequence;
• Python 2-style metaclass construction.

These helpers were replaced with maintained functionality:

• use sympy.utilities.iterables.is_sequence;
• use native Python 3 metaclass declarations.

VectorFunction handling remains explicit where its indexed behavior differs from ordinary Python sequences.

The compatibility module itself remains temporarily available because it is still exported by the legacy package namespace. It is removed by the subsequent public-API PR.

8. Domain subclasses were not printed correctly in LaTeX

The custom LaTeX printer only implemented _print_Domain. Some reconstructed domain-related objects are subclasses of BasicDomain rather than Domain, causing modern SymPy’s printer dispatch to miss the custom representation.

A _print_BasicDomain implementation was added so domain interiors and interfaces consistently render using their symbolic names.

Regression tests cover multipatch interiors and interfaces.

Dependency and CI changes

• Raise the minimum supported SymPy version from 1.5 to 1.12.
• Support SymPy releases below 1.15.
• Keep the normal CI matrix on the newest version allowed by the dependency range.
• Add a dedicated Python 3.11 job pinned to SymPy 1.12.
• Run the complete test suite in both minimum- and maximum-supported dependency configurations.

The upper bound remains intentionally below SymPy 1.15 until that release range receives a separate compatibility review.

Validation

The test suite passes with the upgraded symbolic implementation:

170 passed, 2 skipped

New regression coverage includes:

• symbol assumptions and commutativity;
• free_symbols behavior;
• structural equality and hashing;
• functions with identical names in different spaces;
• SymPy-compatible expression arguments;
• func(*args) reconstruction;
• xreplace substitutions;
• multipatch mapping reconstruction;
• domain and interface LaTeX output;
• integral multiplication postprocessing.