How to handle variable names in expressions clashing with variables in sympy name space.

[MoAly98]

The issue in #117 points out an failure to parse an expression as the parser tries to sum an Integer() with a FunctionClass when the expresion is 1+beta. This was traced in #118 to be because beta exists in the sympy namespace as sp.beta and the current expression parser (parse_expr) imports this whole namespace unless restricted by the global_dict argument passed form parse_expression. The rough fix in #118 restricts the functions imported from the sympy namespace. This is too restrictive, since users may want to use one of these functions (e.g. sp.min) in their expressions. One solution is enforcing a heirarchy where local variable names are prioritised over using the sympy variables with the same name, and another is to restrict users from using variable names that are in the sympy namespace.

A few examples that fail parsing for the above reason:

config = {
      "type": "generic_function",
      "name": "myfunc",
      "expression": "min + 1"
}
func = GenericFunction(**config)

config = {
      "type": "generic_function",
      "name": "myfunc",
      "expression": "beta + 1"
}
func = GenericFunction(**config)

config = {
      "type": "generic_function",
      "name": "myfunc",
      "expression": "gamma + 1"
}
func = GenericFunction(**config)

[kratsg]

Just to put what ChatGPT responded with (along with typical hallucinations): https://chatgpt.com/share/68f854e8-be88-8011-b574-f4f77a7de629 . In general, It's not clear if we want to support something chaotic like beta + beta(x, y) or if we assume that the use of beta is either as a function or as a symbol.

This is a classic Sympy parser namespace collision problem — parse_expr() imports the full sympy namespace by default, so symbols like beta, gamma, or min get shadowed by built-in Sympy functions (sp.beta, sp.gamma, sp.Min), leading to type errors when users meant them as plain variables.

Here’s how other projects (and maintainers in similar situations) have typically approached and resolved this issue, with a brief rationale for each approach.

---

1. Prioritize local variable names over Sympy’s

When constructing the global_dict or local_dict passed to parse_expr(), ensure user-defined names take precedence:

from sympy.parsing.sympy_parser import parse_expr
from sympy import __dict__ as sympy_namespace

def parse_expression(expr_str, variables=None):
    # User-defined names (variables, functions, etc.)
    local_dict = {v: sympy.Symbol(v) for v in (variables or [])}
    # Merge: user-defined first, sympy second
    global_dict = {**sympy_namespace, **local_dict}
    return parse_expr(expr_str, global_dict=global_dict)

✅ Pros

• Transparent for users ("beta + 1" works as expected)
• Doesn’t restrict use of sympy.min, etc. if fully qualified (sympy.Min(...))
• Aligns with Sympy’s recommended parser customization pattern

⚠️ Cons

• Slightly tricky if user intentionally reuses a Sympy name (beta = sp.beta), but that’s rare.

---

2. Explicitly whitelist or blacklist Sympy names

Define a minimal global dictionary — only import safe symbols or a curated subset:

import sympy as sp

SAFE_FUNCS = {
    "sin": sp.sin, "cos": sp.cos, "exp": sp.exp, "sqrt": sp.sqrt,
}
def parse_expression(expr_str, variables=None):
    local_dict = {v: sp.Symbol(v) for v in (variables or [])}
    return parse_expr(expr_str, local_dict=local_dict, global_dict=SAFE_FUNCS)

✅ Pros

• Fully deterministic
• Prevents name collisions and user confusion

⚠️ Cons

• Overly restrictive — users lose access to sp.Min, sp.Max, etc.
• Requires maintaining a whitelist (annoying long-term)

---

3. Validate and warn users about conflicting names

At validation time, detect overlap with the Sympy namespace and raise/warn:

def validate_variables(vars):
    conflicts = [v for v in vars if v in sympy.__dict__]
    if conflicts:
        raise ValueError(
            f"Variable names conflict with Sympy builtins: {conflicts}. "
            "Please rename them (e.g. 'beta_' instead of 'beta')."
        )

✅ Pros

• Keeps parser simple
• Makes collisions explicit
• Helps educate users

⚠️ Cons

• Slightly annoying for users who expect "beta" to “just work”

This approach is used in some symfit, lmfit, and tensorwaves-style projects.

---

4. Use Symbol injection before parsing

Before parsing, scan the expression for unknown tokens and pre-inject them as symbols:

import re, sympy as sp

def extract_vars(expr):
    return re.findall(r"[A-Za-z_]\w*", expr)

def parse_expression(expr_str):
    tokens = extract_vars(expr_str)
    # Filter out known sympy names
    known = set(sp.__dict__)
    symbols = {t: sp.Symbol(t) for t in tokens if t not in known}
    return parse_expr(expr_str, local_dict=symbols)

✅ Pros

• Auto-resolves most user issues
• Doesn’t require maintaining whitelists

⚠️ Cons

• Regex-based token extraction can misfire for complex expressions