On Tue, Jun 30, 2020 at 3:53 PM David Bailey <[email protected]> wrote:
>
> Aaron, thanks for responding to my question in detail.
>
> On 30/06/2020 20:00, Aaron Meurer wrote:
>
>
> The printer doesn't take into account your namespace. It is
> copy-pastable from the point of view of having all the SymPy names
> imported. We could add a string printer mode that prefixes all SymPy
> names.
>
> Thanks, I wasn't aware that print() works that way.
>
> The problem seems to remain that if you integrate sin(x) you get cos(x), yo
> get a symbol cos that you didn't anticipate. Maybe integrating sin(x**3)
> would be a better example, where hypergeometrics and gamma functions suddenly
> appear in the answer - I mean these will appear without regard to the
> selective importing of SymPy. Thus if you copy/paste these into an input,
> these will generate an undefined name error because they are not prefixed.
>
> If you don't like using sym.cos and so on everywhere, you can just
> import things directly, like
>
> from sympy import cos
>
> Precisely - as explained above.
>
> I mean, is copy/paste an unusual thing to use - I would have thought it was
> completely normal.
>
> I don't know Python anywhere near well enough to figure out if it is possible
> for print() or something else, like fullprint() to add appropriate prefixes
> (like sp.) to things (not just every possible prefix) as it outputs them -
> can it extract enough information to actually do this?
I mean we could make something like
>>> sstr(sin(x), prefix='sym')
'sym.sin(x)'
work. I am not suggesting the printer would automatically deduce the
prefix from your environment.
>
> My suggestion to use "from sympy import *" within modules was meant to apply
> in a situation where you used a collection of modules for various purposes
> which all imported just SymPy. I can't quite see what the problem is in that
> case, unless you use Python tools.
>
> Even without using *, it is still possible to accidentally import something
> from more than one module:
>
> from sympy import sin
>
> from numpy import sin
The difference is that cases like this can easily be spotted by tools
like pyflakes, or even by hand. On the other hand if you have
from sympy import *
from numpy import *
it is not obvious that those overwrite names from each other, unless
you happen to know that numpy and sympy include some of the same
names. "from sympy import *' imports over 900 names and "from numpy
import *" imports over 500. No one should be expected to know what is
happening there. And automated tools like pyflakes won't help you here
either since they basically stop working in the presence of "import
*".
The 'import sin' example will also *only* affect 'sin'. The 'import *'
version will clash names that you might not even be using yet, causing
bugs not just in your current code but in future code as well.
>
> Indeed if you are going to use numpy in conjunction with sympy, this sort of
> clash seems quite inevitable unless you make all the numpy symbols work using
> the np. prefix.
You have two options. The correct thing to do depends on what your
code looks like, to what degree you are using numpy vs. sympy, etc.
- Prefix at least one of the names, or both, like np.sin or sym.sin
- Make use of namespaces. Each function can have its own imports
inside of it, which won't affect other functions, like
def sympy_code():
from sympy import sin, ...
def numpy_code():
from numpy import sin, ...
However, this second option only really works if your code happens to
be organized in a specific way that SymPy and NumPy are completely
separated. The prefixed approach always works, which is why it is
recommended.
>
> BTW, I really do not wish to be a nuisance, because I do realise what a
> magnificent facility SymPy represents, and the work that must have gone into
> it.
It's not a nuisance. I think it's important for people to understand
why 'import *' is a code smell, and is only really good for
convenience in interactive situations, where code is typically only
executed once and you see the output immediately, so "reusability"
doesn't matter.
Aaron Meurer
>
> David
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/ff6db073-aefc-6298-cfb3-aa0d14e8a63c%40dbailey.co.uk.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2Be%3DDyF%2BzC4h-JyAYY4HnUKnDZ-2gmHAkvZ8nJWh_MC0g%40mail.gmail.com.
