10
nitwhiz
3y

So we're really writing

if __name__ == "__main__"

?

I'm lost for words.

Comments
  • 5
    This is obsolete practice. If one wants to run main module of package, it should have file name "__main__.py".
  • 4
    Did you ask on UnderscoreOverflow?
  • 0
    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.
  • 3
    @vintprox yeah nice, quick suggestion:

    def main()

    or like any other scripting language: just fucken code, no mains.
  • 2
    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.
  • 0
    @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`.
  • 3
    I recommend Ruby 🤷🏻‍♀️
  • 5
    @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.
  • 0
    @nekokatt thatta good reminder, thanks. Apparently, it's all nice for embedding as library and providing CLI with it at the same time.
  • 0
    @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 :)
  • 2
    Classic python.
  • 1
    @vintprox I didn't know about the __main__ file, that's pretty cool
  • 0
    @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.
  • 0
    Lmfao 😂😂😂
  • 0
    @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?
  • 1
    @hubiruchi it isn't required at all.
  • 0
    @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."
  • 0
    @hubiruchi without __init__.py, you still get "namespace package", which acts as usual package.
  • 1
    @vintprox cool, I'll try it out
  • 0
    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.
Add Comment