+1 for encouraging `import sympy as sp`, when every things are not
simple enough for `from sympy import *`.
Jonathan
On 6/29/20 11:16 AM, Oscar Benjamin wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Mon, 29 Jun 2020 at 15:54, Javier Arantegui
<[email protected]> wrote:
Hi!
Hi Javier,
Most probably, this is a silly question...
I don't think it's a silly question
What is the best way to import Sympy?
I usually use:
from sympy import *
I know that using a wild import should be avoided. Is this a better way:
import sympy as sp
This is more of a general Python question than a sympy-specific
question. My answer is that it really depends on the context but my
rules of thumb is that star-imports are fine if you're writing a
single script that uses a single star-import.
Are you writing a small script to do a short calculation or are you
editing a large codebase with many different modules and internal and
external imports?
In any significant codebase star-import is a bad idea. It makes it
hard to trace the origin of an imported name when looking at the code.
If I'm looking at the code and I see sp.cos then I expect that sp will
be defined or imported somewhere at the top of the file and I can just
go to the first occurrence of it in the file to see where it comes
from. Likewise if you use "from sympy import cos" and I see cos(2) I
expect that cos will be imported at the top and I can search for that.
There have been issues in sympy where __init__.py files used
star-imports making some objects importable by accident. The
conclusion from those examples is that it is bad to use star-imports
when writing modules that other code will import from. Within the
sympy codebase itself most imports are more explicit like
from sympy.polys.polymatrix import PolyMatrix
That's a good practice for internal imports in a large codebase. There
are a few places around the sympy code base where names are imported
from top level sympy like
from sympy import cos
Those are not fine *within* sympy because they lead to circular import
problems. For users of sympy though I think that this would be
considered good practice.
The above is all about large codebases though (e.g. sympy has 750000
lines of code). If you are writing a short script that just uses sympy
to compute something then I don't see anything wrong with using a
star-import for brevity. Of course there's a big range between a
10-line calculation and a 750K-LOC library and you'll have to decide
where your code fits in that range...
Also are you combining sympy with other libraries such as numpy and
are you star-importing from all of them?
Many problems of star-import come from things like multiple star
imports. Both numpy and sympy have a cos function so if you
star-import both modules which one will you get? The two cos functions
are deliberately different so it does matter. Because of that even in
a short script that mixes numpy and sympy I would go with
import sympy as sp
import numpy as np
or perhaps
from sympy import *
import numpy as np
but never
from sympy import *
from numpy import *
Both sympy and numpy have hundreds of names at top-level and many of
them are the same names.
For simple interactive calculations I use isympy which does this when it starts:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)
>>> init_printing()
That saves a bunch of boiler-plate so you can quickly get started.
It's also convenient for pasting examples: I often paste code snippets
to show someone something with the implication that it works in isympy
with the above import and symbols. This is the original purpose of
star-import: to be convenient in an interactive context.
I see lots of examples around where people do different variants like
import sympy; sympy.cos(2)
import sympy as sp; sp.cos(2)
import sympy as sy; sy.cos(2)
and other less common examples. I wonder if it would be worthwhile for
sympy to endorse one of these explicitly in the way that numpy does
with np.
--
Oscar
--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fsympy%2FCAHVvXxRu1Y3CzHJOWJbATOsDvTnY7vZRUb5yYowZvqjQHJqVfw%2540mail.gmail.com&data=02%7C01%7Cgutow%40uwosh.edu%7C49e15f2f542e455d3b3308d81c47a5e9%7C16b8b9f2f7bd431ab739d49428e26316%7C0%7C0%7C637290441336920658&sdata=fXignxLFKK8ek9FnXpEOz%2FJDVjBtsOqDjEB1ymLpsaw%3D&reserved=0.
--
Dr. Jonathan Gutow
Chemistry Department
UW Oshkosh
web: https://uwosh.edu/facstaff/gutow
e-mail: [email protected]
Ph: 920-424-1326
--
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/cc227f60-7e26-c920-df9b-78e84b0c0af6%40uwosh.edu.
