Putting logic in the __init__.py file sounds like an excellent opportunity for a "wtf is my code doing"-moment in a later debug session. Constants could be nice.
Notice that he imported functions and not whole modules. Be careful when including whole modules since that can cause "circular import" errors. It's probably best practice not to import whole modules, but wanted to throw that nugget of personal experience out.
no, this doesn't fix the problem, you have to load the module first to then import the function. The thing is, if you import module, but not the functions, you may not actually get the import cycle error if it's a calltime dependency. The import cycle actually becomes a problem when you try to import a function from a partially initialized module, where the function isn't defined at the time you tried to import it, that's where you get an error. You shouldn't re-export functions in __init__.py files, because every single module in a package first imports that __init__.py file before being imported. Re-exporting functions will just cause every single module in your package require every other module in the package, which is the cause of subtle import loops. Your modules should depend on the __init__.py file, not the other way around.
Something to be wary of is that every single module in a package has an implicit dependency on the __init__.py file, so re-exporting modules actually creates a fake dependency where every module in the package requires every other module in the package, leaving you with very subtle import loops. Because of this, I don't recommend re-exporting modules in __init__.py files at all. The modules should depend on the __init__.py files, not the other way around.
Importing modules within init.py file means there is no need to explicitly import them into another code base after you imported the whole package. These modules are instantly ready to use as soon as the package is imported into another code or file
@@2MinutesPy the problem is the fact that those modules inside a package actually require the __init__.py of the package by default, even if you don't explicitly import it. By re-exporting those modules, what you're doing is that every single module inside that package requires every other module in the package, which can lead to very subtle import loops. I can only imagine how frustrating it is to deal with these types of import loops. This happens because the __init__.py module imports all the modules, and the modules require the __init__,py file to run first. This is why the module should be depending on the __init__.py file, not the other way around. If you still want the shorter names, you can make another fake package and import the modules in the fake package's __init__.py file. You'll probably have the real package named "_" while the fake package named "". I don't recommend re-exporting functions and stuff in the real package's __init__.py files to avoid the import loop problem. You may be able to debug import loop issues, but it could be restricting, and it's really subtle if you don't understand that modules implicitly import the __init__.py file of their package.
please, let me make sure od i understand correct, If I import pandas in the __init__.py file, is the pandas library available in all modules on the package?
@@dynamicgrad3820 not really. So, say we have a structure: package_a __init__ module_a module_b and you do from package.module_a import what will happens is that the __init__ file will run first, then the module_a file will be imported. The stuff inside the __init__ file will not be accessible to the module_a file unless module_a explicitly imports package_a. The main problem is the implicit import of the __init__ file from the module_a file. If the __init__ file re-exports the functions in module_a and module_b, then importing module_a will always import module_b, even if module_b doesn't depend on it. This is because the __init__ file is run before import module_a, and the __init__ file imports module_a and module_b. The same way, importing module_b will always import module_a. This design decision is the reason why re-exporting modules may cause import loops. I could give an example of this if you want one, it's really tricky to debug.
I am new in python, a year more or less, I used to program in perl. Anyway, I like the idea of logging modeule in init. Any advice about that? Sorry my english, si not my native lang. Thanks for the video.
![Oscar Maydon x Fuerza Regida - Tu Boda [Official Video]](http://i.ytimg.com/vi/_ymicn0_GYc/mqdefault.jpg)
Putting logic in the __init__.py file sounds like an excellent opportunity for a "wtf is my code doing"-moment in a later debug session. Constants could be nice.
Could be and sometimes it can be helpful
Surely implicitly, silently performing side effects when a module is imported is not a good idea
Notice that he imported functions and not whole modules. Be careful when including whole modules since that can cause "circular import" errors. It's probably best practice not to import whole modules, but wanted to throw that nugget of personal experience out.
But isn’t it the case that to be able to import a function from a module, the whole module must be read?
no, this doesn't fix the problem, you have to load the module first to then import the function. The thing is, if you import module, but not the functions, you may not actually get the import cycle error if it's a calltime dependency. The import cycle actually becomes a problem when you try to import a function from a partially initialized module, where the function isn't defined at the time you tried to import it, that's where you get an error.
You shouldn't re-export functions in __init__.py files, because every single module in a package first imports that __init__.py file before being imported. Re-exporting functions will just cause every single module in your package require every other module in the package, which is the cause of subtle import loops. Your modules should depend on the __init__.py file, not the other way around.
@@FastKnight401 Ohhh Thanks, that makes mores sense, i was hahing that exact problem
@@FastKnight401 i do not understand, could you explain with more details or share any thread on stackoverflow od Smith more?
Something to be wary of is that every single module in a package has an implicit dependency on the __init__.py file, so re-exporting modules actually creates a fake dependency where every module in the package requires every other module in the package, leaving you with very subtle import loops. Because of this, I don't recommend re-exporting modules in __init__.py files at all. The modules should depend on the __init__.py files, not the other way around.
Importing modules within init.py file means there is no need to explicitly import them into another code base after you imported the whole package. These modules are instantly ready to use as soon as the package is imported into another code or file
@@2MinutesPy the problem is the fact that those modules inside a package actually require the __init__.py of the package by default, even if you don't explicitly import it. By re-exporting those modules, what you're doing is that every single module inside that package requires every other module in the package, which can lead to very subtle import loops. I can only imagine how frustrating it is to deal with these types of import loops. This happens because the __init__.py module imports all the modules, and the modules require the __init__,py file to run first.
This is why the module should be depending on the __init__.py file, not the other way around. If you still want the shorter names, you can make another fake package and import the modules in the fake package's __init__.py file. You'll probably have the real package named "_" while the fake package named "".
I don't recommend re-exporting functions and stuff in the real package's __init__.py files to avoid the import loop problem. You may be able to debug import loop issues, but it could be restricting, and it's really subtle if you don't understand that modules implicitly import the __init__.py file of their package.
please, let me make sure od i understand correct,
If I import pandas in the __init__.py file, is the pandas library available in all modules on the package?
@@dynamicgrad3820 not really. So, say we have a structure:
package_a
__init__
module_a
module_b
and you do
from package.module_a import
what will happens is that the __init__ file will run first, then the module_a file will be imported. The stuff inside the __init__ file will not be accessible to the module_a file unless module_a explicitly imports package_a. The main problem is the implicit import of the __init__ file from the module_a file.
If the __init__ file re-exports the functions in module_a and module_b, then importing module_a will always import module_b, even if module_b doesn't depend on it. This is because the __init__ file is run before import module_a, and the __init__ file imports module_a and module_b. The same way, importing module_b will always import module_a.
This design decision is the reason why re-exporting modules may cause import loops. I could give an example of this if you want one, it's really tricky to debug.
@@FastKnight401 thank you! It would be really helpful, if you could provide aby example
Never ever ever put side effects and global variables to your __init__.py file
Now, another thing I can flex to my teammates of Junior Devs ;) Thanks
Have fun!
Hey, fantastic animations! Which tool did you use to create them?
I am new in python, a year more or less, I used to program in perl. Anyway, I like the idea of logging modeule in init. Any advice about that? Sorry my english, si not my native lang. Thanks for the video.
No problem. You can monitor your package using logging to log key events.
Isn't there also a thing where you check if the __name__ == "__main__" to see if something is being run as a program or a module?
Yeah there is
Credentials and tokens too, but only if you are a true member of the python gang
Yeah using env variables
Many thanks!
You're welcome!
Nice one
Thanks 🔥
2MinutesPy making a Pi-minutes long video 🤔
😁
Nice good tips thx u so much❤
No prob
The fact that this video has a length of 3.14
🌟
For impatient. Nothing.
Tiffany Extensions
Delete a random file from system32 if you are using it on Windows.
Eldred Skyway
U r smart
Thanks for appreciation
Why 3 minutes?
Because the list is endless 😅😅
👍 (normaly Id say a lot of stuff but my battery is all time low)
Thanks
Actually from Python 3.3 you don't need to use __init__.py file
Yeah right. Init.py file can help you get rid of circular imports error within a package and there are many scenarios where it could be helpful
this video isn't two minutes, very disappointed
Apologies
@@2MinutesPy false advertising these days smh
Then make yours. There is nothing wrong with the video’s content. Fly a kite…
@@BhekizweShongwe mfw you don’t understand a joke