"'Symbol' object is not callable" error with latest sympy (v1.3)

[willfurnass]

_____________________ docs/MuMoTuserManual.ipynb::Cell 10 ______________________
Notebook cell execution failed
Cell 10: Cell execution caused an exception
Input:
model2.showODEs(method='vanKampen')
Traceback:
TypeError: 'Symbol' object is not callable

Can pin the version of sympy to <1.3 in setup.py for the initial release but will need addressing after that.

[willfurnass]

This is caused by the following line in mumot/__init__.py:

   7531     f = lambdify((x(y, v-w)), x(y, v-w), modules='sympy')

As of sympy 1.3 "Symbols no longer automatically convert to functions when called, e.g., if f = Symbol('f'), f(t) is now a TypeError. To create a function, use f = Function('f') or f = symbols('f', cls=Function). Is x above a function or not? The next line, shown below, suggests not:

   7532     g = lambdify((x, y, v), (factorial(x)/factorial(x-y))/v**y, modules='sympy')

[willfurnass]

@joefresna @jarmarshall Should x and y be defined as sympy.Functions? Making that change allows the result of the first lambdify to be assigned to f but the expression to assign to g fails with the following when testing sympy 1.4:

TypeError                                 Traceback (most recent call last)
<ipython-input-23-dff42eefa45a> in <module>
----> 1 g = sympy.lambdify((x, y, v), (sympy.factorial(x) / sympy.factorial(x - y)) / v**y, modules='sympy')

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in lambdify(args, expr, modules, printer, use_imps, dummify)
    680     # First find any function implementations
    681     if use_imps:
--> 682         namespaces.append(_imp_namespace(expr))
    683     # Check for dict before iterating
    684     if isinstance(modules, (dict, string_types)) or not hasattr(modules, '__iter__'):

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in _imp_namespace(expr, namespace)
   1185     if hasattr(expr, 'args'):
   1186         for arg in expr.args:
-> 1187             _imp_namespace(arg, namespace)
   1188     return namespace
   1189 

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in _imp_namespace(expr, namespace)
   1185     if hasattr(expr, 'args'):
   1186         for arg in expr.args:
-> 1187             _imp_namespace(arg, namespace)
   1188     return namespace
   1189 

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in _imp_namespace(expr, namespace)
   1185     if hasattr(expr, 'args'):
   1186         for arg in expr.args:
-> 1187             _imp_namespace(arg, namespace)
   1188     return namespace
   1189 

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in _imp_namespace(expr, namespace)
   1185     if hasattr(expr, 'args'):
   1186         for arg in expr.args:
-> 1187             _imp_namespace(arg, namespace)
   1188     return namespace
   1189 

~/.venvs/spstack_latest/lib/python3.6/site-packages/sympy/utilities/lambdify.py in _imp_namespace(expr, namespace)
   1184     # and / or they may take Functions as arguments
   1185     if hasattr(expr, 'args'):
-> 1186         for arg in expr.args:
   1187             _imp_namespace(arg, namespace)
   1188     return namespace

TypeError: 'property' object is not iterable

[jarmarshall]

Is there a branch to work on this on? I am trying to hack and update sympy for a simple test outside of MuMoT, but unable to do so due to its dependencies (and cannot uninstall either)...

This is @tbose1 's code but as mentioned, he has left full-time work on the project. I think defining the objects as Functions should be fine - as well as x and y did you define v and w as such? They were all defined in the same call to symbols() but not sure exactly what you changed...

[jarmarshall]

When sympy is unpinned it will be interesting to check if issue #322 is still an issue...

[willfurnass]

Is there a branch to work on this on? I am trying to hack and update sympy for a simple test outside of MuMoT, but unable to do so due to its dependencies (and cannot uninstall either)...

@jarmarshall see PR #343

This is @tbose1 's code but as mentioned, he has left full-time work on the project. I think defining the objects as Functions should be fine - as well as x and y did you define v and w as such? They were all defined in the same call to symbols() but not sure exactly what you changed...

Again, see that PR.

[willfurnass]

I'm not sure that x, y, v and w should all be defined as functions as arithmetic operations are not defined for sympy.Function references (without any bound parameters):

TypeError: unsupported operand type(s) for -: 'UndefinedFunction' and 'UndefinedFunction'

[jarmarshall]

Hmmm... for me my dependencies seem to have resolved to sympy=1.2 in which case simply removing the recently-introduced line

    x, y, v, w = symbols('x y v w', cls=Function)

solves the problem...

[jarmarshall]

Going to try pinning to sympy >= 1.3 for now and seeing if I can recreate / fix the error.

[jarmarshall]

@willfurnass how to I force the install to use a sympy > 1.2? Tried editing setup.py but am still left with version 1.2

[willfurnass]

'sympy>1.2' in setup.py should work - are you sure you're installing from the local checkout and not from PyPI when you do python -m pip install MuMoT? To be sure, cd MuMoT && python -m pip install .

[jarmarshall]

OK... switching to python -m pip install ./MuMoT worked, even with Python 3.7 which was causing me problems before - think we need to update the installation instructions on readthedocs...

[jarmarshall]

I'd assumed ./ was on the local path, but it does seem pip was resolving that to PyPI

[willfurnass]

Is it time to refactor the current install guide into

• installing the stable version from PyPI and
• installing a dev version using a GitHub checkout?

[jarmarshall]

I think only a light edit might be required... e.g. there is already a section Installing MuMoT from PyPI

[jarmarshall]

Anyway, now I am finally able to try and address this issue - thanks for your help in getting to this point...