Issues accessing `PurePath.parents` by index in Python 3.10

[merelcht]

Bug description

We're running pylint as part of our CircleCI builds, which we run on Python 3.7, 3.8, 3.9 and have now added 3.10.

We're using pylint version 2.12.2, and the checks succeed on all versions < python 3.10, but on 3.10 we see the following errors:

E1101: Instance of 'tuple' has no 'resolve' member (no-member)
for:

starter_path = Path(__file__).parents[3].resolve()

I0021: Useless suppression of 'abstract-class-instantiated' (useless-suppression)
for:

from filelock import FileLock

root_tmp_dir = tmp_path_factory.getbasetemp().parent
lock = root_tmp_dir / "semaphore.lock"
    with FileLock(lock):  # pylint: disable=abstract-class-instantiated
          spark = _setup_spark_session()

If the above failures are fixed for Python 3.10 the checks will then fail on all builds with version < Python 3.10.

Command used

pylint -j 4 --disable=missing-docstring,redefined-outer-name,no-self-use,invalid-name,protected-access,too-many-arguments,too-many-public-methods,use-implicit-booleaness-not-comparison tests

Pylint output

This is the output for the 3.10 build:

************* Module tests.framework.cli.conftest
tests/framework/cli/conftest.py:117:19: E1101: Instance of 'tuple' has no 'resolve' member (no-member)
************* Module tests.extras.datasets.spark.conftest
tests/extras/datasets/spark/conftest.py:38:0: I0021: Useless suppression of 'abstract-class-instantiated' (useless-suppression)

Expected behavior

I would expect pylint to give the same output for the various Python versions.

Pylint version

The versions used for the respective Python builds:

pylint 2.12.2
astroid 2.9.3
Python 3.7.11 (default, Jul 27 2021, 14:32:16) [GCC 7.5.0]

pylint 2.12.2
astroid 2.9.3
Python 3.8.12 (default, Oct 12 2021, 13:49:34) [GCC 7.5.0]

pylint 2.12.2
astroid 2.9.3
Python 3.9.7 (default, Sep 16 2021, 13:09:58) [GCC 7.5.0]

pylint 2.12.2
astroid 2.9.3
Python 3.10.0 (default, Dec 21 2021, 13:36:04) [GCC 7.5.0]

[Pierre-Sassoulas]

Thank you for opening the issue.

Some checks have voluntarily different output for different python version. For example typing with dict or list needs to import from __future__ in earlier python interpreter. In 2.12, we introduced a new option py-version that permits to analyze code for a python version that may differ from your current python interpreter. Could you try to set the py-version ?

It's possible that some checkers still do not take it into account properly (the tuple error seems fishy here).

[merelcht]

Hi @Pierre-Sassoulas, thanks for your quick response. Do you have any docs on how to use the py-version option? Is that just in the cli command?

[Pierre-Sassoulas]

This is a global option, (pylint --py-version=3.8)

If you think we can make it clearer there's an issue to make the doc better: #5038, do not hesitate to add a comment there :)

[merelcht]

Thanks, the doc explanation makes sense 🙂

Unfortunately, it doesn't make a difference for my checks..

[deepyaman]

We're running pylint as part of our CircleCI builds, which we run on Python 3.7, 3.8, 3.9 and have now added 3.10.

We're using pylint version 2.12.2, and the checks succeed on all versions < python 3.10, but on 3.10 we see the following errors:

E1101: Instance of 'tuple' has no 'resolve' member (no-member) for:

starter_path = Path(__file__).parents[3].resolve()

@MerelTheisenQB With regards to this example, the reason for different behavior in Python 3.10 is actually because .parents changed in 3.10 to accept a slice. I don't know how pylint works, but I assume it doesn't figure out that passing a non-slice index to .parents will necessarily yield a Path object, and never a tuple. @Pierre-Sassoulas Do you know whether the pylint parser should be able to distinguish something like this?

With regards to the solution, the simple thing to do is change it to:

starter_path = Path(__file__).resolve().parents[3]

as even the pathlib docs recommend calling resolve() before arbitrarily walking paths upwards.

Haven't looked into the second issue at all.

[Pierre-Sassoulas]

Thank you for the investigation @deepyaman, this indeed look like something that require an astroid update.