Import inside function is probably the most efficient way to solve the circular imports especially when superclass needs to reference children However since there are different Builders here I’m not sure that’s the case 🙃
Putting imports in a certain scope of code makes sense if that scope is "throwaway code", e.g. it only gets executed once in a separate thread or something and if you do not want to shadow/clash identifiers. But only these two make it a valid thing to do imho, besides maybe some fun hacking stuff. In the old Python days this was done mainly to reduce module import cost, think "lazily importing modules", only when necessary. But ever since Python 3 computers (and Python itself) are fast enough and that doesn't pose any issues any more, gerally speaking of course. In the case of the Poetry Core builder module though... not sure. First guess is I would put all imports on top and only import the build module itself when needed. But maybe there's a perfectly valid reason I don't see.
There are several reasons to control when imports happen in the code. Sometimes it is required to NOT put the import at the top of the file. Think life cycle management in terms of dependency injection - even though "import" is more like the service locator pattern. 3 use cases off the top of my head are: * usages of importlib to import module(s) based on information only available at runtime (e.g., from env specific config or the command line) * imports for __main__ that should not be in the library itself - avoids namespace pollution / minimizes resource utilization * pythonnet - need to define the .NET assembly metadata objects before "import"-ing them
On the same topic of Poetry, it would be great if you could cover versioning management on a future video/stream. Been looking at the poetry-dynamic-versioning module which seems interesting. Cheers!
Hello @ArjanCodes, could you do a couple of "Under the Hood" sessions on a few of the core parts of Django Rest Framework and the Django ORM?
I miss my man. This is great!
Import inside function is probably the most efficient way to solve the circular imports especially when superclass needs to reference children
However since there are different Builders here I’m not sure that’s the case 🙃
Putting imports in a certain scope of code makes sense if that scope is "throwaway code", e.g. it only gets executed once in a separate thread or something and if you do not want to shadow/clash identifiers. But only these two make it a valid thing to do imho, besides maybe some fun hacking stuff. In the old Python days this was done mainly to reduce module import cost, think "lazily importing modules", only when necessary. But ever since Python 3 computers (and Python itself) are fast enough and that doesn't pose any issues any more, gerally speaking of course.
In the case of the Poetry Core builder module though... not sure. First guess is I would put all imports on top and only import the build module itself when needed. But maybe there's a perfectly valid reason I don't see.
I prefer to import into the classes so that they only take up memory when used.
There are several reasons to control when imports happen in the code. Sometimes it is required to NOT put the import at the top of the file.
Think life cycle management in terms of dependency injection - even though "import" is more like the service locator pattern.
3 use cases off the top of my head are:
* usages of importlib to import module(s) based on information only available at runtime (e.g., from env specific config or the command line)
* imports for __main__ that should not be in the library itself - avoids namespace pollution / minimizes resource utilization
* pythonnet - need to define the .NET assembly metadata objects before "import"-ing them
On the same topic of Poetry, it would be great if you could cover versioning management on a future video/stream. Been looking at the poetry-dynamic-versioning module which seems interesting. Cheers!