Why aren't all simplification functions also methods? about sympy

[sylee957]

I think methods are particularly nice for method chaining, which I find very convenient.

I have different and general opinion that having duplicate methods and functions everywhere, are not a good idea.
It duplicates the code, makes the code more longer, and also causes the documentation to be duplicated and outdated.

Because of the reasons above, I think that they have obvious cons than some pros of method chaining,
so I'm not conclusive that we should have code standards that enforces that.

The reason expand and Expr.expand was there, for instance, was some code style of some authors written SymPy even before I started maintaining, so it was not a code standard now anyway. We don't necessarily reject someone to introduce more things like that, however, we don't necessarily reject someone not to add expand_... and not Expr.expand_....

However, we have to to keep such mirroring of expand and Expr.expand, (or simplify and Expr.simplify) that were done before as is at least for maintaninance and backward compatiblity.

expand_power_exp() is only a function?

expand_power_exp, implemented, is just a expand with some options pre configured.

sympy/sympy/core/function.py

Lines 3062 to 3086 in 9d13061

	def expand_power_exp(expr, deep=True):
	"""
	Wrapper around expand that only uses the power_exp hint.
	See the expand docstring for more information.
	Examples
	========
	>>> from sympy import expand_power_exp, Symbol
	>>> from sympy.abc import x, y
	>>> expand_power_exp(3**(y + 2))
	9*3**y
	>>> expand_power_exp(x**(y + 2))
	x**(y + 2)
	If ``x = 0`` the value of the expression depends on the
	value of ``y``; if the expression were expanded the result
	would be 0. So expansion is only done if ``x != 0``:
	>>> expand_power_exp(Symbol('x', zero=False)**(y + 2))
	x**2*x**y
	"""
	return sympify(expr).expand(deep=deep, complex=False, basic=False,
	log=False, mul=False, power_exp=True, power_base=False, multinomial=False)

So I don't think that it is very difficult for you to configure Expr.expand like that in your application.
I am not sure if we need to add more things like expand_power_exp in the future because they are just expand with some trivial options anyway.

[ricopicone]

I will note that expand_power_exp() is perhaps not considered a simplification function. Perhaps I should have titled this "Why aren't all manipulation functions also methods?"

[ricopicone]

Thank you for your response @sylee957. I appreciate your points about duplication. I suppose I would be happiest with everything being a method instead of a function due to my preference for method chaining. This preference is a result of my Mathematica past, in which I wrote nearly everything in a pipe-like paradigm (expr -> func -> func -> ... -> func -> output), which I think is very natural for symbolic manipulation.

I wonder if there is a clean way to have a function mirror a method (or vice versa), such as in the following example:

class Expr:
    def __repr__(self):
        return "Expression"

    def action(self):
        print("action method on self")

def action(expr):
    print(f"action function on {expr} just calls action method:")
    return expr.action()

expr = Expr()
expr.action()
action(expr)

Perhaps this type of paradigm could be used to clean up the existing code and maintain legacy functions or methods if you want to go with just one or the other for future routines. I think it would be helpful to know which direction future development will head, so when I'm using SymPy I can "trust" that the function or the method will be there instead of guessing (as I often do now). I believe that, for now, most routines are at least functions, sometimes methods. Although I prefer the opposite, I can get on board if that's the vision you have for the project. Thanks!