Why is __main__ is considered first-party rather than stdlib ?

[Avasam]

Edit: I got confused with #8750 and #8805 , for some reasons I though it was the other way around. Although neither the issue nor PR offers a reasoning as to why __main__ is considered first-party rather than stdlib by default.

Here's a handful of example usage from pywin32: https://github.com/search?q=repo%3Amhammond%2Fpywin32+"import+main"&type=code

---

import __main__ gets moved all the way down with first-party imports

The config:

target-version = "py37"

[lint]
select = ["I"]

[lint.isort]
combine-as-imports = true
detect-same-package = false
# This forces distutils imports to always be after setuptools
extra-standard-library = ["setuptools"]
known-third-party = ["distutils"]

[zanieb]

I don't know the context from those, but import __main__ can an import an arbitrary third-party module — the Python __main__ documentation covers this. It seems like it may be sensible to treat it as a third-party import. In the Python import documentation they describe it as a non-builtin module which might be a good reason to exclude it from the standard imports.

Including it as a first-party import seems like a misunderstanding, but maybe it's with the idea that you should only be doing this for your own application?

cc @charliermarsh @AlexWaygood

[charliermarsh]

It seems like it could make sense to treat it as stdlib, since __main__ itself is part of the standard library. Even though it can resolve to an arbitrary file, that file can actually be different across runs, right? So there's no way to know statically what file it refers to.

[zanieb]

Yeah standard library might make sense... I actually don't understand the use-case for importing __main__, I'd be curious to hear about that as it might help with a decision.

[Avasam]

[...] I actually don't understand the use-case for importing __main__, I'd be curious to hear about that as it might help with a decision.

I haven't looked into it in details, and whether there's a better way to achieve what it's trying to do, but I added a reference to Pythonwin IDE (in pywin32) examples in my original description.

[AlexWaygood]

Hmmm https://github.com/mhammond/pywin32/blob/7cac4eb311db157a72edff1968706d92740937ff/Pythonwin/pywin/idle/CallTips.py#L94

[charliermarsh]

It looks like isort treats it as third-party, so lets just do that.

[charliermarsh]

Oh, we originally did mark it as third-party, huh. Just seeing https://github.com/astral-sh/ruff/issues/8750 which is linked up-top.

[charliermarsh]

I would propose that we change it back to third-party.

[Avasam]

Either way I can configure it to appear where I'd like in the import groups. This is more of a question since I misunderstood past issue. I don't mind too much whatever the resolution is here, as long as there's a rationale with it.

[charliermarsh]

I'm gonna close this for now -- I think it's fine to leave as-is unless we hear more reports, just to avoid churn in the absence of a clear right answer. The rationale I'd give is something like: __main__ refers to the executed module, and so that likely (but not always) refers to first-party code. But, again, I don't think there's a right answer.