IMHO programs don’t belong on pypi only libraries. Its a waste of namespace.

Explicit is better than implicit, read the zen of python(its short). Don’t be too magical. Don’t reach for a class if you have no state. Watch some jackdied talks from old pycons. You don’t need custom exceptions the stdlib has plenty. Also if its not documented don’t use it. Don’t use star imports.

Black just use it don’t fight it, don’t waste brain space with formatting rules. “You can have any formatter you want as long as its black”. Use default black settings. People who don’t are heretics :P

sys.path or PYTHONPATH is how imports are resolved. Much like shells looking for binaries. IMHO you should never adjust either. The current directory is always added to sys.path. but beyond that directories are packages. Use “init.py” when you want to provide a module for what happens when you import a package.

python3.11 -m venv .venv This is how you should create your venv. After that activate it and use pip. You should setup a requirements.txt for your project, then you can use pip -r to configure your env. Global install of third-party libraries is always a bad idea in practice. Version constraints make that almost impossible these days.

Can’t speak authoritatively on the other things, but I do know PEP8 is the most commonly used style guide, and people often use Black to lint their code.

Well I am only able to offer some lame answers. Mostly because quality answers would take a very long time to construct. But here you go

• This really depends on what your building. Maybe find a n established project that’s similar to yours and mimick its structure. There are many patterns available.
• Google it, try it, repeat. Python is loaded with “syntactic sugar”. That leaves you with lots of options for how to structure and format your code. Which leads to many varying opinions. This is extra noteworthy for larger dev teams because of varying experience levels. You might be able to write a short, clear but of code that some devs won’t understand. Lots of good options leads to a lack of clear choices. Opinions will vary.
• Again, lots of options. I like using the Black formatter because it gives you very few options and forces you into some style choices. Even the ones I don’t like 🙂
• Oh boy. Google it. Extensively. Google it for several hours and then read some source code. Do this every time you start a new project 😂.
• I don’t have a specific tutorial unfortunately. But the idea is that your “pyenv” directory will contain the packages your project depends on. Maybe the python installation too. And every one of these items will be a specific version. Because this is all installed in a single directory for each project, you can easily have different projects use and rely on different versions of the same dependency. This avoids all sorts of problems where you accidentally build and test locally using the wrong package version. I think a common practice is to create the “env” folder in the root of your git repo. And add “env/” to your gut ignore. Don’t trust that exact syntax btw 😅

python packaging authority and pytest have pretty good resources on standard repo structure; poetry is a new-kid-on-the-block tool to get started developing packages quickly (i.e., standard repo config, handles dependency environments / works as build tool)

re: formatting & style – others have mentioned black; I also recommend ruff to lint/standardize your code to many accepted best practices.

import is kind of a clusterf, because you can have absolute import packagename and relative from . import x.y.z imports, and importing a project-in-development can depend on the IDE you use (i.e., vscode and pycharm are generally smart enough to figure out that a src/ dir in the workspace should be importable, but not always). Using pip install -e can install your project-in-dev in “editable” mode and make it available for import. The modules docs may help here.

Package management/locking is a a (relatively) rapidly evolving part of the python ecosystem. Because Python can be so dependent on the packages installed in the environment, simply managing the python version (like you would with pyenv) is insufficient, and it is recommended to create pseudo-hermetic virtual environments per project (venv, virtualenv, poetry, or conda help with this). I can’t help with pyenv (I use conda); this might be helpful. I think you would use pyenv to manage the python version and then venv or virtualenv to manage the installed packages. Personally, I would first get used to managing virtual environments with venv and then deal with pyenv later if you decide you need multiple python versions