the latest episode was 3y ago?

example of using uv to install a python tool:

uv tool install harlequin

nice! It just works (harlequin.sh is a python program that allows to interact with databases using SQL qury langues, you can also load csv and json data)

I was just trying to make sure that this is ok and won’t tangle up my code later on.

I guess the main issue there is Python doesn't like circular dependencies? Like if you try to import dep2 from dep1 and dep1 from dep2, you're going to have a problem. You'd essentially have to refactor your code to have a dep3 that both can import to use the common functionality I guess.

Sorry, that was just a joke that came off wrong. I understand you were just trying to help.

Yeah, that's the solution I asked about (last line of my question). I was just trying to make sure that this is ok and won't tangle up my code later on.

I'm not sure why you're using as to make the module name longer? Usually, if I use it at all, I use it make things shorter. Anyway, once you've imported dep2, you can call dep2.some_fn().

That was just for the example (clarifying order of import). The actual code has imports such as from src.formatter import Formatter as fmt; always making the name shorter.

Thanks for the suggestions

I was pointing out a part of the documentation that you may have overlooked. In good faith, I might add, because the documentation is comprehensive but horribly signposted. Everything I wrote in my first comment is there, but in a less human, more technical phrasing.

As others have mentioned, I would add a src/__init__.py file to turn src into a package.

Then, inside dep1.py, you can do a relative import with:

from . import dep2  

I'm not sure why you're using as to make the module name longer? Usually, if I use it at all, I use it make things shorter. Anyway, once you've imported dep2, you can call dep2.some_fn(). You could also go:

from .dep2 import some_fn  
some_fn()  

Are you accusing me of not reading tfm? because I did, but was expecting this specific situation to be clarified on stackOverFlow, geeksForGeeks or somewhere similar. Since it seemed like this import pattern should be common.

https://docs.python.org/3/tutorial/modules.html#packages

The __init__.py files are required to make Python treat directories containing the file as packages (unless using a namespace package, a relatively advanced feature). This prevents directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path. In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package or set the __all__ variable, described later.

ofc. It's weird how no one asked this before with how little help articles mention __init__.py.

Items that you define in __init__.py or import into it will be available to import from the module: from .submodule import some_fn

That will be very useful. Thanks for your quick reply!

Quick template: https://files.catbox.moe/g5tcy5.tar

Also, don't delete this post. Others might need this information too.

If you have to import a directory structure, you should make each directory a module by creating an __init__.py file in them, and use relative import statements. I usually have one main.py as the entry point, which imports a lib module that contains all of the program logic.

├── lib
│   ├── __init__.py
│   ├── module_content.py
│   └── submodule
│       ├── __init__.py
│       └── submodule_content.py
└── main.py

You can import the lib directory as a module:

main.py:

from lib import some_fn

Within any module, though, you should use relative import statements to import from files and submodules, and regular import statements to import packages from the system or the venv:

lib/__init__.py:

from .module_content import some_fn # import from a file
from .submodule import some_other_fn # import from a submodule directory
from os.path import join # import from an installed package

Items that you define in __init__.py or import into it will be available to import from the module: from .submodule import some_fn. Otherwise, you can import an item from a file by specifying the full path: from .submodule.submodule_content import some_fn.

You can also import an item from a parent package using the .. prefix: from ..some_other_submodule import some_fn.

This is the kinda news want to wake up in the morning and be presented with.

I don't think the env vars were dumped. Unexec only dumped out the memory region where the loaded modules were. It was very OS dependent and got harder to maintain as the number of OS variations grew, and eventually had to be replaced with something a little less efficient. But, it think it might be doable again using something like CRIU. I've been wanting to look into it. Another idea might be extending the marshal format to dump all the loaded modules and their data into one file for fast reloading.

What do you mean by "image"? As in, everything currently loaded into Python? Wouldn't that just be execing the current architecture[0] again with the same ENV vars and args?

And that's actually what I want much of the time, since I'd rather pay that cost on startup than throughout a running program's life, esp. for heavy dependencies.

So a keyword is great here, since I can balance startup time and hitching during operation.

Before reading it: why not make it the default?

Because it breaks a lot of things. Whether it's good practice or not, running module code at import time may be expected to initialize some code, setup listeners, build classes etc.

Before reading it: why not make it the default?

I read the PEP and couldn't find why it's a proposal for an explicit keyword only. Probably backwards compatibility, but maybe it'll become the norm.

It wouldn't surprise me if it became a keyword for module local things too like functions. Then it would make declaring a class that uses other classes in read order i.e class A uses class B which uses class C >>> declaration order is A, B, C instead of the current C, B, A.

Very cool - wonder how this might impact micropython...

wrong direction, we needed something like unexec to dump an image file with any currently loaded modules.

This is great news, I've never sat down and benchmarked the importing times (I believe theres a python -X switch or similar) but the more options the merrier!

YEEEEEEES

wreck can. It's venv aware. Takes full advantage of hierarchical requirement files. Is intuitive. The learning curve is minimal. Written in Python.

[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
    'requirements/pip',
    'requirements/pip-tools',
    'requirements/prod',
    'requirements/dev',
    'requirements/manage',
    'requirements/kit',
    'requirements/mypy',
    'requirements/tox',
]
[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
    'docs/requirements',
    'docs/pip-tools',
]

[tool.setuptools.dynamic]
dependencies = { file = ['requirements/prod.unlock'] }
optional-dependencies.pip = { file = ['requirements/pip.lock'] }
optional-dependencies.pip_tools = { file = ['requirements/pip-tools.lock'] }
optional-dependencies.dev = { file = ['requirements/dev.lock'] }
optional-dependencies.manage = { file = ['requirements/manage.lock'] }
optional-dependencies.docs = { file = ['docs/requirements.lock'] }

reqs fix --venv-relpath='.venv'

reqs fix --venv-relpath='.doc/.venv'

From *.in requirements files would produce *.unlock and *.lock files for venv .venv. Package versions are sync'ed within all requirements files within that venv.

spoiler alert: Python isn't written in fortran, cobol, pascal, assembly, VBA, Java, javascript, or Rust (ignoring clunky pypy). uv is written in Rust.

spoiler alert: Don't have to be a C coder to use Python