This is a great start on this topic. There arent actually a lot of youtube videos about this topic, and its hard to find information. Would appreciate a follow up that went more into detail, if you can. For instance: what exactly happens when you import things in the __init__.py file. What sort of start up logic do you need to do. What is the appropriate use of this file etc....
Thanks for this basic tutorial about imports, could it be possible to make a video about imports between modules in the same package ? cause this is always a pain in the a** to know how to do these correctly and everyone seems to use different tricks when searching for solutions on the net. That would be a really helpful video
I don't understand how it's difficult. If you have an __init__?py file in each folder, they become submodules, which you can import the same way as a file inside a package. If you need to import from one submodule to another, you use two dots instead of one.
@@ego-lay_atman-bay I'm not talking about imports outside a package (involving __init__.py), but more about imports between modules in the same package (same folder), as relative imports easily gives you a "attempted relative import but no parent package found" even with __init__.py everywhere, and direct import like "from module import func" without a dot it easily gives you a "no module named 'module' found"
When you have `__init__.py` file in your folder directory, your folder called as "package". When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
thank you very much! this also explains why some packages won't work when you just use import *... the __init__ flie in the package didn't explicitly declare the file that was needed! It is always a safer way to explicitly declaring the packages that one need then
It would have been interesting to see the behavior of __init__.py when importing the same package from multiple different modules within your project. If I'm not mistaken, the __init__.py will be called only once (the first time any import statement is used).
I use "__init__.py" also for importing all the libraries that I will import in the submodules. And then, in the submodules, I use "from . import ". I don't know if it's useful, I wanted to have organized imports.. Does it make sense?
I thought the __init__.py was no longer needed? I've never used it. Though I also have issues with pytest when my test files are in a sub directory, so that could be part of it
I think the interpreter has added some layer of inference to this… but it can still be buggy sometimes. I.e: i dont get import errors when trying mysql in django, but when including the module at init then the hug goes away
When you have `__init__.py` file in your folder directory, your folder called as "package". When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
If you are basically using everything in a package already it makes sense to use it. If you only need a couple then it might make sense not to so naming conflicts are less likely but personally once my import line gets past 3-4 things I switch.
@@michaelcummings7246 there are many issues with star imports. Honestly when I just discovered it I started to use it all over the place since it’s def easier But after a few days I changed all that 😀 it makes refactoring etc much harder and imagine solving circular import error with this approach 😀
Star imports are essential for some Python libraries, where you want to get a whole new "dialect" into your script (versus borrowing specific functionality). The best example I know is FastHTML, in which HTML tags are brought into Python to simplify server side rendering with HTMX.
Hey @Indently, If I have multiple modules (so many modules) in packages, & our init script has this __all__ dunder method, do I need to give each & every module name in __all__ = ['wifi', 'mobile', 'bluetooth', 'module4', 'module5'..... ] Is there a better way for us to include all modules in package initalizer? in order for * recognizes all modules?
you can compare with or wihout __init__.py in two scenarios 1. HAVING _init_.py, No INSERT of path in sys 2. NO _init_.py, INSERT path in PYTHONPATH, import module statement after inserting path import sys sys.path.append('/python/NoInitModule') from dir import module statement
When you have `__init__.py` file in your folder directory, your folder called as "package". When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
While learning a bit more on how star import works is useful and interesting, star import is really a bad practice. I hope this video doesn't encourage anyone to use it.
Sometimes it's useful, such as importing c_types. You're most likely going to just import everything instead of using ctypes.c_uint32(). However, they still are not very good most of the time.
Thanks for covering the role of __init__.py in the import of a module. Because a lot of video tutorials skip this information.
fr
This is a great start on this topic. There arent actually a lot of youtube videos about this topic, and its hard to find information. Would appreciate a follow up that went more into detail, if you can. For instance: what exactly happens when you import things in the __init__.py file. What sort of start up logic do you need to do. What is the appropriate use of this file etc....
Thanks for this basic tutorial about imports, could it be possible to make a video about imports between modules in the same package ? cause this is always a pain in the a** to know how to do these correctly and everyone seems to use different tricks when searching for solutions on the net. That would be a really helpful video
Same. Had to use sys.path to import packages from another folder yesterday. My brain exploded
I don't understand how it's difficult. If you have an __init__?py file in each folder, they become submodules, which you can import the same way as a file inside a package. If you need to import from one submodule to another, you use two dots instead of one.
@@ego-lay_atman-bay I'm not talking about imports outside a package (involving __init__.py), but more about imports between modules in the same package (same folder), as relative imports easily gives you a "attempted relative import but no parent package found" even with __init__.py everywhere, and direct import like "from module import func" without a dot it easily gives you a "no module named 'module' found"
@@dragweb7725 and what is the use case for such a project with that kind of folder structure?
you should mention the difference between having _init_.py and not having one in your module directory
He explained it's the _init_.py that makes the directory module a package and how to use that file to define the behaviour of the imports.
@@luisdominguesforprogramaca3221 NO _init_.py, INSERT path in PYTHONPATH, import module statement after inserting path will behave like a package too.
When you have `__init__.py` file in your folder directory, your folder called as "package".
When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
Rewatch the video
How about explaining the difference in your comment?
Crystal clear. Thank you for explaining it very simpel!
that one class I ignored, it was this one in 2021. i got it now 😂 thanks for this!
Good job! Pycharm was a nice touch since that’s the environment that many use.
This is so helpful and clearly explained! Thank you very much!
Thanks. Mind refresher, Life saver.
Great! Loved it, my hero 🎉
You're awesome.
This one has a lot of great tips
Wonderful explanation. Thanks 🙏
Thank you indeed... Extremely clear, concise... Thank you ...
Quick and accurate. Thanks.
thank you very much! this also explains why some packages won't work when you just use import *... the __init__ flie in the package didn't explicitly declare the file that was needed! It is always a safer way to explicitly declaring the packages that one need then
Clearly explained. Thank you!
I enjoy your videos a lot! Keep posting😊
Very useful 🙏🙏🙏
The __all__ dunder method is something i didnt know yet. Neat
FYI, from what I can tell, VS Code doesn't change the directory icon when you declare it to be a module (by adding dunder init . py).
very clear video. thanks
This is amazing. Im completely rebuilding an app Im working on based on this!!!
It would have been interesting to see the behavior of __init__.py when importing the same package from multiple different modules within your project. If I'm not mistaken, the __init__.py will be called only once (the first time any import statement is used).
❤ thank you 🎉
Veryw ell explained, Thank you!
Thanks a lot, very helpful.
I love you, great videos, and please keep going.😁😁😁
Super , thanks
I use "__init__.py" also for importing all the libraries that I will import in the submodules. And then, in the submodules, I use "from . import ". I don't know if it's useful, I wanted to have organized imports.. Does it make sense?
I do that too!
Great video. Congrats !
Excellent, thankyou!
so a package is a container that contains an __init__ in it! 😂
brilliant! 👏
❤❤❤❤❤ awesome
Very useful video
aveasome thank you, would like to learn more about it :D
Utterly usefull
Fantastic video. How do you feel about placing all imports needed for the files inside?
For example...
From enum import Enum
Could you please make a video on python garbage collection
very good tutorial 👍
You'r plane went well!
Thanks
Share your vscode setup
That's pycharm not vscode
🙏
i didnt even know i needed to know this
thx
I thought the __init__.py was no longer needed? I've never used it. Though I also have issues with pytest when my test files are in a sub directory, so that could be part of it
I think the interpreter has added some layer of inference to this… but it can still be buggy sometimes. I.e: i dont get import errors when trying mysql in django, but when including the module at init then the hug goes away
When you have `__init__.py` file in your folder directory, your folder called as "package".
When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
@murphygreen8484 could you please suggest if know any tutorials for pytest?
Star import is a really poor practice
If you are basically using everything in a package already it makes sense to use it. If you only need a couple then it might make sense not to so naming conflicts are less likely but personally once my import line gets past 3-4 things I switch.
@@michaelcummings7246 there are many issues with star imports. Honestly when I just discovered it I started to use it all over the place since it’s def easier
But after a few days I changed all that 😀 it makes refactoring etc much harder and imagine solving circular import error with this approach 😀
Star imports are essential for some Python libraries, where you want to get a whole new "dialect" into your script (versus borrowing specific functionality).
The best example I know is FastHTML, in which HTML tags are brought into Python to simplify server side rendering with HTMX.
Can you do blender python? plz
Learning python on the go apps?
Which code editor you use
PyCharm
How would you make the connections module accessible with different projects without copying it over to every new project?
I came I saw and i liked
Do the functions in the new package still need, the if name == main line?
If you want to execute code exclusively at the file, then yes… it applies for all files/imports/packages/modules
I guess it would be a poor practice or even dangerous to execute a code from __init__ file, right?
Hey @Indently, If I have multiple modules (so many modules) in packages, & our init script has this __all__ dunder method,
do I need to give each & every module name in __all__ = ['wifi', 'mobile', 'bluetooth', 'module4', 'module5'..... ]
Is there a better way for us to include all modules in package initalizer? in order for * recognizes all modules?
what's the code editor
My favourite Bankai Zanka No Tachi
👋👋👋
Does anybody knows what font he's using?
you can compare with or wihout __init__.py in two scenarios
1. HAVING _init_.py, No INSERT of path in sys
2. NO _init_.py, INSERT path in PYTHONPATH, import module statement after inserting path
import sys
sys.path.append('/python/NoInitModule')
from dir import module statement
its loading some libraries. Innit? :D
Dude holy I legit was thinking about this an hour ago LOL
i read the __init__ file is no longer necesary
Not its infered, but i would still recommend it since it can be buggy sometimes
When you have `__init__.py` file in your folder directory, your folder called as "package".
When you don't have `__init__.py` file in your folder directory, your folder still count as package but now your folder called as "Namespace Package" instead of "package".
When did python became British?
Since it was founded it was based on a British TV series
While learning a bit more on how star import works is useful and interesting, star import is really a bad practice. I hope this video doesn't encourage anyone to use it.
Sometimes it's useful, such as importing c_types. You're most likely going to just import everything instead of using ctypes.c_uint32(). However, they still are not very good most of the time.
For us blind guys you need to speak__or thunder
Also, what is this whole thing is a variable is it a list? What is it is a dictionary
thanks
Thanks