Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use import * #177

Open
jfpuget opened this issue May 16, 2022 · 9 comments
Open

Don't use import * #177

jfpuget opened this issue May 16, 2022 · 9 comments

Comments

@jfpuget
Copy link

jfpuget commented May 16, 2022

The startup code loaded by default for the SymPy shell has an import * statement. This is very very bad practice and should not be used

@oscarbenjamin
Copy link
Contributor

Why is it bad practice in the particular context of the sympy interactive shell to use a star import?

@certik
Copy link
Member

certik commented May 16, 2022

Right, I always thought the import * should not be used in Python source files, but it can be used in interactive shells (that is what is was meant for).

@asmeurer
Copy link
Member

import * is just fine for interactive use. What would you suggest we use instead? If we were to replace it with an explicit import the import would be huge. sympy contains over 900 names.

@oscarbenjamin
Copy link
Contributor

sympy contains over 900 names.

I guess you could argue that maybe it isn't necessary to import all 900 of them.

@jfpuget
Copy link
Author

jfpuget commented May 17, 2022

If import * is just fine in your shell then I can break it with one line. Just run this as first command

from math import * # import * is just fine

Then, this example from right pane no longer works:

sin(x).series(x, 0, 7) # one of the examples on the right pane

In general, import * is bad practice (I hope there is no disagreement here). If people see you use it, then they are likely to use it later on when writing python programs. And there it could be real bad.

@sylee957
Copy link
Member

sylee957 commented Jan 19, 2023

I think that it was design flaw that sympy made exceptions for CamelCase for sin, cos even if they were really classes. The choice that they made everything look like math library like some 'magic' before, rather starts to confuse the users, and make conflicts for contributors, and not sure if it is helpful for learning curve.

@oscarbenjamin
Copy link
Contributor

The real design flaw is the fact that there isn't a single sin function that can work with all types. Hence we have math.sin, 'cmath.sin', numpy.sin, sympy.sin etc. If there was a single dispatch sin function (like in Julia) then there would be no confusion about which to use.

@Anshika91
Copy link

hey i can solve it please assign this issue to me

@oscarbenjamin
Copy link
Contributor

I don't think that we want to change anything here. The online shell is designed for conveniently using sympy interactively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants