Hmm, this would add an __init__ tag for each class in the generated tags file only to satify this special logic for Python (and D).
True, but this is how the command-line ctags works. And it also works this way for user-written code. So for ``` MyClass( ``` you get calltip containing ``` __init__(...) ``` and not ``` MyClass(...) ``` Adding arguments to classes would make calltips look different for user-written code and global tags which I think is confusing.
Those additional ___init__ tags are of no other use for the user and just might cause confusion if you get suggestions and lots of additional calltips when writing own __init__ methods.
You get only the `__init__()` from the class whose constructor you call for the calltips, `__init__()` functions from other classes are not shown.
Apart from the generated tag file use case, I'd consider this change to make this special logic a bit less hard because now the normal calltip selection process will continue as for all other languages. Before, it roughly stopped trying find a matching calltip if no constructor tag was found.
Yes, but only for `class` and `struct` types which don't have arguments (at least the way `ctags` works) so the following code won't find any arguments. Again, this patch won't hurt anything and can be merged, I just think the script (if it's not a big problem) should detect this special case and make the output similar to `ctags` behavior.
It's actually the inspect library which does "smart" things. The script just asks inspect to get the signature for a class object. I would not call this "fake" :).
It's "smart" compared to `ctags` because the way `ctags` parses code, the moment it encounters `def MyClass:` it doesn't know the `__init__()` so it emits (and will always emit) `MyClass` without arguments.