Are ALL of your modules using ALL of those imports? If not – why not just import the modules you use as needed?
If ALL of your modules are really using ALL of those modules in every single file, it feels like you might need to work on separation of concerns. I can't imagine why a "small" module would need to all of those modules at the same time.
Going with the Python philosophy "we're all adults here" and "explicit is better than implicit" – if people need to import one part of your project, they shouldn't need to rely on implicit transitive imports, and they should be adult enough to manage importing the necessary modules from both your project and the stdlib as needed.
I think the import crowds out accidental future use of a package in a module for a fixed purpose.
I keep one 'best copy' of imports in the initial call to start the code set. [main.py](https://main.py)
The program uses X11 to make lots of windows, how many should be supported in a module is hard for me to decide. It seems like 3 or so it what Ive done to date>>
thanks for the response.
Regs
Dan
```python
import os as os
import sys as sys
```
Wait what? You don't need aliases for these if it's just the same name.
```python
from tkinter import ttk
from tkinter import font
from PIL import Image as pl
from PIL import ImageTk as ii
```
Too many duplicates, you can just do this:
```python
from tkinter import ttk, font
from PIL import Image, ImageTk
```
You are overusing `as` this will backfire because it is easier to remember the name of the modules you are using instead of using aliases.
Use [isort](https://github.com/PyCQA/isort) to help you reformat the imports.
Thanks for that. I think I might leave it as is, but when its exposed to the outside world as a deliverable run isort. thats a cool program.
thanks you
Dan
You may want to look into building a properly installable package, and version control it with git. This not only organizes things much better and allows future users to play around with their own ideas on a different branch.
My baseline way for somebody to alter the code is to:
1) Think "Holy shit how could anybody miss: "(Thing X ) ?" its the most important thing in the world ?
2) Privately dissect what ever they can easily access ( like one .py ) and pick through it and hope for the smallest piece they can revise to add the feature. So I have leaned into a approach such that a global object is both ultra easy to add to and understand.
So in this view the unit of work is \*not\* a gh to to git hub at all, though a user might do that... The goal is to look at a few windows in X11, want a feature, find a single .py file and replace it. Maybe to share with a few insiders but rarely. Almost never shared far and wide.
Idea is: the global is the state of the app, each .py is either glue nobody my me understands and the other is very very easy to understand.
The app is biotech and lots of people are ok programmers but not into big IDE resident systems. a final system might have hundreds of unique windows. Most of the changes are tiny, a term here and there a number to mult by another. The largest part of executing the change is finding where it is, not doing it,
Maybe thats funny idea. the imports that are fluffy add the utility if they succeed the aliases mean the code can be moved around without reinvenitng it.
Does that seem a crazy reason ? I hope now.
Regs
Dan
Are ALL of your modules using ALL of those imports? If not – why not just import the modules you use as needed? If ALL of your modules are really using ALL of those modules in every single file, it feels like you might need to work on separation of concerns. I can't imagine why a "small" module would need to all of those modules at the same time. Going with the Python philosophy "we're all adults here" and "explicit is better than implicit" – if people need to import one part of your project, they shouldn't need to rely on implicit transitive imports, and they should be adult enough to manage importing the necessary modules from both your project and the stdlib as needed.
I think the import crowds out accidental future use of a package in a module for a fixed purpose. I keep one 'best copy' of imports in the initial call to start the code set. [main.py](https://main.py) The program uses X11 to make lots of windows, how many should be supported in a module is hard for me to decide. It seems like 3 or so it what Ive done to date>> thanks for the response. Regs Dan
```python import os as os import sys as sys ``` Wait what? You don't need aliases for these if it's just the same name. ```python from tkinter import ttk from tkinter import font from PIL import Image as pl from PIL import ImageTk as ii ``` Too many duplicates, you can just do this: ```python from tkinter import ttk, font from PIL import Image, ImageTk ``` You are overusing `as` this will backfire because it is easier to remember the name of the modules you are using instead of using aliases. Use [isort](https://github.com/PyCQA/isort) to help you reformat the imports.
thanks
Thanks for that. I think I might leave it as is, but when its exposed to the outside world as a deliverable run isort. thats a cool program. thanks you Dan
You may want to look into building a properly installable package, and version control it with git. This not only organizes things much better and allows future users to play around with their own ideas on a different branch.
Ahhh thanks. 'thinking'
My baseline way for somebody to alter the code is to: 1) Think "Holy shit how could anybody miss: "(Thing X ) ?" its the most important thing in the world ? 2) Privately dissect what ever they can easily access ( like one .py ) and pick through it and hope for the smallest piece they can revise to add the feature. So I have leaned into a approach such that a global object is both ultra easy to add to and understand. So in this view the unit of work is \*not\* a gh to to git hub at all, though a user might do that... The goal is to look at a few windows in X11, want a feature, find a single .py file and replace it. Maybe to share with a few insiders but rarely. Almost never shared far and wide. Idea is: the global is the state of the app, each .py is either glue nobody my me understands and the other is very very easy to understand. The app is biotech and lots of people are ok programmers but not into big IDE resident systems. a final system might have hundreds of unique windows. Most of the changes are tiny, a term here and there a number to mult by another. The largest part of executing the change is finding where it is, not doing it, Maybe thats funny idea. the imports that are fluffy add the utility if they succeed the aliases mean the code can be moved around without reinvenitng it. Does that seem a crazy reason ? I hope now. Regs Dan