Generate stubs for implementing abstract methods from superclass

[idanarye]

PyCharm can generate stubs for implementing abstract methods in a subclass. If you have something like this:

from abc import ABCMeta, abstractmethod


class Superclass(metaclass=ABCMeta):
    @abstractmethod
    def method(self, foo, bar, baz):
        pass


class Subclass(Superclass):
    pass

PyCharm can transform it to this:

from abc import ABCMeta, abstractmethod


class Superclass(metaclass=ABCMeta):
    @abstractmethod
    def method(self, foo, bar, baz):
        pass


class Subclass(Superclass):
    def method(self, foo, bar, baz):
        pass

Could something similar be added to Jedi?

[davidhalter]

How are you using Jedi? With a language server or what?

[idanarye]

With jedi-language-server. But I figured Jedi needs to offer such a feature before any language server can offer it as a code action.

[bew]

In a similar way, the Rust language server has a similar feature, but integrates it at completion time (you start writing a function name and it completes the entire signature, almost ready to be implemented).
If jedi can expose the needed methods, the jedi-language-server could either implement it as a code action or a completion.

[davidhalter]

Jedi already does that in a way, because it completes def m<tab> in your example. So for completions it would probably be pretty easy to add. We could even think of making this the default instead of just completing the name.

@idanarye The problem I see then is that the language servers currently don't have a "normal" way of doing this like inline, extract, or rename. You could probably somehow work around that limitation, but that is off spec for a language server and most clients won't support it. So the first step is probably getting it into that spec. As @bew noted, completions are probably way easier to modify (and it will yield almost the same result).

[idanarye]

Language servers do this via code actions. At least - that's what rust-analyzer does. If Jedi offers the backend, the language server can use it to format a code action which any LSP client knows how to use.

Or maybe Jedi can also offer a code actions mechanism, and then every code action added to Jedi will automatically be available to all language servers that have interfaced to that mechanism?

[davidhalter]

But how would such a code action look like? What's the CodeActionKind? I know that that's what code actions are targeted at, but I'm not sure how editors work with such language specific actions that are not a CodeActionKind like rename/inline/etc.

[idanarye]

rust-analyzer sets the kind to "quickfix", but it hardly matters - CodeActionKind is only used for filtering the generated actions and maybe for IDEs to show an appropriate icon. Inline gets its own kind because it's so common, but rename is not even a code action - is an API of it's own.

The idea behind code actions is that you point the language server at a file, or at a code range within a file, and the server spits out suggestions of things that can be done there - inline code, add annotations, extract expression, fill missing parameters, implement missing methods, whatever. They are usually tied to the diagnostics the language server provided, so if the language server noticed a problem it can also offer a solution, but there can also be standalone code actions.

The IDE/editor, then, presents these suggested code actions to the user, and the user can pick a code action and tell the IDE to perform it. The code action can carry a list of text edits that the client can perform itself, or it can carry a command that the client can send back to the server to perform the action (it can have both, but I'm not sure what it's useful for)

[davidhalter]

I'm not against this, but I feel like we should do autocompletion first. I'm keeping it open for that.

The other thing is something you or somebody else could implement, but it would need to be very solid for it to be accepted. This means testing of all the different cases (staticmethod, property, etc).