Exploring the possibility of adding support for mypy and static analysis tools

[lucemia]

Exploring the possibility of adding support for mypy and static analysis tools – While I don’t yet have a concrete implementation plan, I’ll investigate how we can integrate custom mypy, pyright, or pylint rules to guide users away from deprecated methods like .filter(), suggesting alternatives such as .vfilter() or .afilter(). If feasible, this would improve both IDE and CI/CD feedback, making the migration process even smoother.

[lucemia]

from GPT

Yes, it’s possible to define custom rules for pyright, mypy, and pylint in a Python package to catch deprecated or removed method calls like .filter(). Here’s how you can approach it:

1. For mypy (Type Checking)
   • You can use type stubs (.pyi files) or plugin hooks to enforce such checks.
   • Example: Define a typed-ffmpeg.pyi file with .filter() marked as deprecated or removed.
   • You can also create a mypy plugin that hooks into method resolution and raises a custom error when .filter() is used.

Example mypy plugin snippet:

from mypy.plugin import FunctionContext, Plugin
from mypy.types import AnyType, TypeOfAny

class TypedFFmpegPlugin(Plugin):
    def get_function_hook(self, fullname: str):
        if fullname == "typed_ffmpeg.filter":
            return self.deprecate_filter
        return None

    def deprecate_filter(self, ctx: FunctionContext):
        ctx.api.fail("'.filter()' has been removed in typed-ffmpeg, use '.vfilter()' or '.afilter()' instead.", ctx.context)
        return AnyType(TypeOfAny.from_error)

def plugin(version: str):
    return TypedFFmpegPlugin

• This will make mypy emit an error when .filter() is used.

2. For pyright (Static Analysis)
   • You can use a pyrightconfig.json to mark .filter() as an error.
   • Another approach is using stub files (.pyi) to specify that .filter() doesn’t exist.
   • If deeper customization is needed, a VS Code extension with Pyright rules could be created.

Example stub file (typed_ffmpeg.pyi)

class FFmpeg:
    def vfilter(self, *args: str) -> "FFmpeg": ...
    def afilter(self, *args: str) -> "FFmpeg": ...

• This prevents .filter() from being recognized as a valid method.

3. For pylint (Linting)
   • You can write a pylint plugin that detects .filter() usage and suggests alternatives.

Example pylint plugin:

from pylint.checkers import BaseChecker
from pylint.interfaces import IAstroidChecker

class FilterMethodChecker(BaseChecker):
    __implements__ = IAstroidChecker
    name = "filter-method-checker"
    msgs = {
        "E9001": (
            "'.filter()' has been removed in typed-ffmpeg, use '.vfilter()' or '.afilter()' instead.",
            "filter-deprecated",
            "Use .vfilter() or .afilter() instead of .filter()"
        ),
    }

    def visit_call(self, node):
        if node.func.as_string() == "typed_ffmpeg.filter":
            self.add_message("E9001", node=node)

def register(linter):
    linter.register_checker(FilterMethodChecker(linter))

• This can be installed as a custom pylint rule.

Conclusion

Yes, it is absolutely possible to define package-specific rules for pyright, mypy, and pylint. You can enforce .filter() deprecation using:
• Mypy: Plugins or .pyi type stubs
• Pyright: Stub files or a custom rule extension
• Pylint: A custom linting rule

Would you like help implementing a specific one of these? 🚀