Auto-complete does not pick up strings

[DonJayamanne]

Raised on behalf of @nchammas against Python extension using Jedi library.
Original issue raised here DonJayamanne/pythonVSCode/issues/223#issuecomment-234818601

When I enable this plugin, auto-complete stops picking up strings.
For example:

code = "DFF26"
another_code = "D

Right after hitting D, VS Code normally would auto-complete DFF26. However, with this plugin installed that doesn't happen.

User-defined named tuples are another area where you'd want auto-completion to pick up strings:

from collections import namedtuple

Person = namedtuple('Person', ['first_name', 'last_name'])
person1 = Person(fir  # <== auto-completion should kick in right there

[davidhalter]

Jedi version?

[DonJayamanne]

@davidhalter , version 0.9.0

[davidhalter]

I can see the use case for namedtuple, but at least for now I disagree about strings. I think that in strings autocompletion is something that is left to editors.

[DonJayamanne]

I agree, string completion would generally fall into the responsibility of the editor. Just quite difficult to determine whether the user is in the middle of a raw string or not. Thanks

[davidhalter]

Definitely related to #253.

[davidhalter]

I will close this issue for now, because I disagree with the string autocompletion and namedtuple is using the new method, which Jedi currently doesn't support. Maybe we will one day, but it doesn't have any priority (it's not just about namedtuples, it's just one of quite a few magic methods that Jedi ignores).

[nchammas]

@davidhalter - There are a few other use cases mentioned in the original issue. Do you find them all invalid and/or low priority?

[DonJayamanne]

@davidhalter, agreed

[davidhalter]

@nchammas Well, next time just use this tracker, it's pretty hard to discuss things from different issues ;)

1. Dictionary lookups

Your example touches a very special case that I think will not be cared for in the next few years. It's just too much work for very tiny results. I would rather have way better dictionary type inference where you can actually tell what's in a dict when it's modified. But that's also for another day (on my list, though).

2. Magic strings

This is something I definitely will not support at the moment. It doesn't fit the API and it's something that an IDE can do quite easily.

3. Object attributes that double as items

That's IMO unclean Python. I would recommend against even writing such an API. However it might one day be implemented if we decide to make it possible to follow __getitem__ in the completion API. But as long as dict support is nowhere in Jedi, why would we even care?

[nchammas]

OK, thanks for elaborating. Just from a user perspective, it's helpful to understand more of the rationale behind feature decisions.

Well, next time just use this tracker, it's pretty hard to discuss things from different issues ;)

Sorry about that. I didn't know about Jedi until @DonJayamanne opened this issue here as a copy of an issue I opened upstream against his project. (I'm just a dumb VS Code end-user. 😅)

The issue here only mentioned 2 of the 4 use-cases from the upstream issue, so I just wanted to make sure none of the remaining use cases would have changed your position.

[davidhalter]

Well, it's also totally fine if you open a new issue if you have a feature request. (Even if it's 4, doesn't make the work much bigger).

While there's a lot of possible small enhancements for completion, I've never really thought about those. They are not what interests me. I want to be able to do refactoring and linting and just have a set of awesome tools, like REPL completion. So I have to find a general balance between all of those new features and maintaining the project. Your requests are not wrong. There's just almost always the technology missing that is needed to implement them properly. What does better dict.update() completion help you if the dictionary support is just marginal? Nothing.

I'm continuously trying to improve the technology behind Jedi to make such things possible. Therefore I have a very slow release schedule. But it has enabled things that seemed impossible with the old code base. It enabled me to add like 5 features in the last week (but I haven't added features for like half a year before that).

So be very patient, help out and ask again in 2-3 years. The next improvement might be just around the corner and the feature request trivial.

[nchammas]

Yup, totally understood. Thank you again for elaborating on your rationale.