So we're really writing

if __name__ == "__main__"

?

I'm lost for words.

This is obsolete practice. If one wants to run main module of package, it should have file name "__main__.py".

Did you ask on UnderscoreOverflow?

What I really don't like about Python right now is that I cannot just bash `python .` in project's root directory to run main module. Instead, I deal with subdirectory.

@vintprox yeah nice, quick suggestion:

def main()

or like any other scripting language: just fucken code, no mains.

I'm always bashing python because i think it's stupid. The language itself seems to be alright but what the fuck is up with pip, why do i need to use exact minor versions for some things and why this ridiculous main declaration.

@nitwhiz ah, the quirks of pip. I recommend Pipenv because it:
+ handles approximate versioning;
+ works along with native virtualenv;
+ loads environment variables from .env file for you (pipenv shell/run);
+ Pipfile is source of truth for custom `pipenv run ...` aliases, separating application dependencies from ones for development, registries.
+ Pipfile.lock with exact versions and hashes for validating dependencies in production;
+ as slight bonus, `pipenv shell` is faster to type than `source env/bin/activate`.

I recommend Ruby 🤷🏻‍♀️

@vintprox it isn't obsolete, it is a different use case.

Using a package means you have a directory with the `__main__.py` in as you say. That doesn't make sense for single script projects (such as the Black code formatter).

`if __name__ == "__main__"` is for detecting running a single script directly (e.g. `python myscript.py`, whereas the package based solution would run `package/__main__.py` with `python -m package` :-)

The usecase for both is to differentiate between simply importing the script or module from another package or module as opposed to opening it directly.

@nekokatt thatta good reminder, thanks. Apparently, it's all nice for embedding as library and providing CLI with it at the same time.

@vintprox yeah. A nice use case is making a small flask microservice. Define a blueprint and attach routes to it. Then define your Flask object itself in a `__main__` check and boot the werkzeug dev server.

This way you have a module for a flask app that can be integrated into an ESB or WSGI server directly, or run standalone for development :)

Classic python.

@vintprox I didn't know about the __main__ file, that's pretty cool

@hubiruchi there is also __init__.py convention, by which you can import classes from according modules, and therefore line them up to the package level. It's used primarily to advance namespaces, while __main__.py is less suitable for that.

Lmfao 😂😂😂

@vintprox yeah I am familiar with __init__.py . Not sure why you hear about __init__.py then about __main__.py . Maybe because init is required for a package?

@hubiruchi it isn't required at all.

@vintprox really? I thought that it was required because this is what's written in the docs "The __init__.py files are required to make Python treat directories containing the file as packages."

@hubiruchi without __init__.py, you still get "namespace package", which acts as usual package.

@vintprox cool, I'll try it out

worth noting namespace packages can have weird semantics with tools like Pytest when nesting them from experience.

I generally always just add an init.py, even if it just contains a license header and module level docstring, there is no real downside to doing it.