view pyproject.toml @ 51884:f79f98733a5b

vfs: use @abstractmethod instead of homebrewing abstract methods

The latter confuses PyCharm after adding more type annotations when, for
example, `abstractvfs.rename()` calls `_auditpath()`- the latter unconditionally
raised an error, so PyCharm thought the code that came after is unreachable.  It
also tricked pytype into marking the return type as `Never`, which isn't
available until Python 3.11 (outside of `typing_extensions`).

This also avoid PyCharm warnings that the call to the superclass constructor was
missed (it couldn't be called because it raised an error to prevent
instantiation).

The statichttprepo module needed to be given an override for one of the abstract
methods, so that it can be instantiated.  In `abstractvfs`, this method is only
called by `rename()`, so I think we can leave this empty.  We raise an error in
case somebody accidentally calls it in the future- it would have raised this
same error prior to this change.

I couldn't wrangle `import-checker.py` into accepting importing `ABC` and
`abstractmethod`- for each subsequent import, it reports something like:

    stdlib import "contextlib" follows local import: abc

I suspect the problem is that near the `if fullname != '__future__'` check, if
the module doesn't fall into the error case, `seenlocal` gets set to the module
name.  That causes it to be treated like a local module on the next iteration,
even though it is in `stdlib_modules`.

[build-system]
requires = ["setuptools", "wheel"]

[tool.black]
line-length = 80
exclude = '''
build/
| wheelhouse/
| dist/
| packages/
| \.hg/
| \.mypy_cache/
| \.venv/
| mercurial/thirdparty/
'''
skip-string-normalization = true
quiet = true