Formalize the concept of "soft deprecation" (don't schedule removal) in PEP 387 "Backwards Compatibility Policy"

DanielNoord · June 30, 2023, 9:15am

Speaking as pylint maintainer, but certainly not on behalf of all Python linters:

I think we would prefer a JSON file.
We currently implement this with the following code:

pylint-dev/pylint/blob/3a99820113cf4d449e7d7fcec53375b799c7b608/pylint/checkers/stdlib.py#L48


      
          LRU_CACHE = {
              "functools.lru_cache",  # Inferred for @lru_cache
              "functools._lru_cache_wrapper.wrapper",  # Inferred for @lru_cache() on >= Python 3.8
              "functools.lru_cache.decorating_function",  # Inferred for @lru_cache() on <= Python 3.7
          }
          NON_INSTANCE_METHODS = {"builtins.staticmethod", "builtins.classmethod"}
          
          
          # For modules, see ImportsChecker
          
          DEPRECATED_ARGUMENTS: dict[
              tuple[int, int, int], dict[str, tuple[tuple[int | None, str], ...]]
          ] = {
              (0, 0, 0): {
                  "int": ((None, "x"),),
                  "bool": ((None, "x"),),
                  "float": ((None, "x"),),
              },
              (3, 8, 0): {
                  "asyncio.tasks.sleep": ((None, "loop"),),
                  "asyncio.tasks.gather": ((None, "loop"),),

We would probably just parse the JSON file into this format whenever some user notifies us that it is outdated or we ourselves note this. (Or change our code to parse the JSON, but that is probably more effort. Perhaps a good first issue? )

The issue with the API is that we’re just too reliant on the Python interpreter the user is running. This will probably cause a lot of confusion for (newer) users and also makes it so that pylint behaves differently on different interpreters. That last point is unavoidable to some degree, but if we can avoid it (by just hardcoding data instead of relying on the interpreter) we tend to go that route.