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".
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"
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?
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
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 😀
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".
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?
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.
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".
Thanks for covering the role of __init__.py in the import of a module. Because a lot of video tutorials skip this information.
fr
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?
that one class I ignored, it was this one in 2021. i got it now 😂 thanks for this!
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?
Crystal clear. Thank you for explaining it very simpel!
Wonderful explanation. Thanks 🙏
This is amazing. Im completely rebuilding an app Im working on based on this!!!
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
You're awesome.
This one has a lot of great tips
Great! Loved it, my hero 🎉
Thanks. Mind refresher, Life saver.
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).
The __all__ dunder method is something i didnt know yet. Neat
Thank you indeed... Extremely clear, concise... Thank you ...
Good job! Pycharm was a nice touch since that’s the environment that many use.
Clearly explained. Thank you!
Very useful 🙏🙏🙏
Quick and accurate. Thanks.
I enjoy your videos a lot! Keep posting😊
very clear video. thanks
Veryw ell explained, Thank you!
Great video. Congrats !
I love you, great videos, and please keep going.😁😁😁
Fantastic video. How do you feel about placing all imports needed for the files inside?
For example...
From enum import Enum
Very useful video
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!
aveasome thank you, would like to learn more about it :D
You'r plane went well!
Excellent, thankyou!
very good tutorial 👍
Thanks a lot, very helpful.
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
brilliant! 👏
Utterly usefull
❤❤❤❤❤ awesome
❤ thank you 🎉
i didnt even know i needed to know this
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 😀
Could you please make a video on python garbage collection
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?
How would you make the connections module accessible with different projects without copying it over to every new project?
Share your vscode setup
so a package is a container that contains an __init__ in it! 😂
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?
Thanks
I guess it would be a poor practice or even dangerous to execute a code from __init__ file, right?
Which code editor you use
PyCharm
Can you do blender python? plz
thx
Learning python on the go apps?
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
what's the code editor
🙏
Does anybody knows what font he's using?
👋👋👋
Dude holy I legit was thinking about this an hour ago LOL
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.
its loading some libraries. Innit? :D
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
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