No cyclic-import messages with jobs=0

[udifuchs]

Running pylint -jobs=0 does not report about cyclic-import. This can be reproduced with a trivial example.
a.py:

import b

b.py:

import a

This issue is not new to pylint 2.7. It is more noticeable only because running jobs in parallel became more useful in this version.

pylint --version
pylint 2.7.1
astroid 2.5
Python 3.8.6 (default, Sep 25 2020, 09:36:53) 
[GCC 10.2.0]

[doublethefish]

This is issue is mentioned in #374 .

[udifuchs]

Sorry, I missed this bug report.
I will close this issue.

[doublethefish]

It might be good to keep this open as it is a simpler repro and the other bug contains a lot of stuff.

[hippo91]

@udifuchs thanks for the report.

[praiskup]

The problem with this trivial example is that it actually detects a non-issue. It seems completely fine to cross-include the modules, as long as the "use" (accessing objects from the module) happens on runtime (not import time).

[doublethefish]

The problem with this trivial example is that it actually detects a non-issue. It seems completely fine to cross-include the modules, as long as the "use" (accessing objects from the module) happens on runtime (not import time).

Whilst I agree that, in practical terms, the trivial example should "work", I would state that any form of cyclic import is either problematic or will become problematic. That said, if it were possible to detect use-at-import that would be a better, more complete check - but, I suspect that is almost impossible to do thoroughly because of aliasing.

Simpler and more useful approaches (vs use-at-import detection) would be to either:

1. scope the import:

def run_time_use():
   """Safer but uglier.

   Still suffers from the potential aliasing problem, but is explicit and scoped, so the problem is contained."""
   import A
   a.do_something()

2. explicitly disable the warning

"""Dangerous as use-at-import can be introduced later, and deployed to prod"""
import A  # pylint: disable=cyclic-import

[Pierre-Sassoulas]

Closing as duplicate of #374, I added the example in a comment there.

[jacobtylerwalls]

It might be good to keep this open as it is a simpler repro and the other bug contains a lot of stuff.

Indeed! Reopening because I'm about to mark #374 closed by a separate PR.