Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for **kwargs autocompletion when using Unpack[T] #2541

Closed
dgellow opened this issue Apr 6, 2022 · 12 comments
Closed

Support for **kwargs autocompletion when using Unpack[T] #2541

dgellow opened this issue Apr 6, 2022 · 12 comments

Comments

@dgellow
Copy link

dgellow commented Apr 6, 2022

Environment: Pylance version v2022.3.4, from vscode.

I'm not sure if it is a bug or would be considered a new feature. I understood from microsoft/pyright#3002 that typed **kwargs are now supported by pylance/pyright. Thank you for this!

Now when I try the example mentioned at microsoft/pyright#3002 (comment) I see that while type checking seem to work correctly, the autocompletion doesn't seem to work as I would expect.

Let's say I have this code in vscode, with Pylance enabled:

from typing_extensions import Unpack, TypedDict, Literal

class MyKwargs(TypedDict):
    foo: Literal["hello", "nopnop"]
    bar: int

def baz(**kwargs: Unpack[MyKwargs]) -> None:
    pass

baz(foo="hello", bar=3)
baz(|) # 👈 My caret is here

I would expect that when I trigger the autocompletion via ctrl+space I would get suggested foo= and bar=, but instead the only relevant suggestion is kwargs=.

image

When I trigger the autocompletion for MyKwargs() arguments I get something correct, the issue seem to only be when using Unpack[T]:
image

It would be nice to have the list of keys of the unpacked typed dict :)

@rattrayalex
Copy link

Related issue thread in mypy: python/mypy#4441

@erictraut
Copy link
Contributor

erictraut commented Apr 6, 2022

This feature (using a TypedDict to specify the value of **kwargs) is experimental and hasn't yet been ratified. It's supported only as a proof of concept to inform an eventual PEP. Until it becomes standard, I don't think it's likely to get much adoption, and it's probably not worth investing the time in adding completion suggestion support. But it may eventually make sense to do so if we get sufficient signal from users.

Since this is not a core type checking issue, I'm going to transfer this request to the pylance-release repo for consideration and tracking.

@erictraut erictraut transferred this issue from microsoft/pyright Apr 6, 2022
@github-actions github-actions bot added the triage label Apr 6, 2022
@dgellow
Copy link
Author

dgellow commented Apr 6, 2022

Sounds good, thanks for the quick response. Would you accept a pull request, or do you consider the feature too experimental and would prefer to first wait for the feature to become standard? (or at least for a PEP to be accepted)

@bschnurr
Copy link
Member

bschnurr commented Apr 6, 2022

We would prefer to wait for it to become standard. If that happens, please reopen if you would still like it.
Thank you.

@bschnurr bschnurr closed this as completed Apr 6, 2022
@nitedani
Copy link

nitedani commented Sep 30, 2022

In my opinion, this is a must have feature for the future of python. Typescript had this for 10 years and it's an essential feature of the language. I'm happy to see python making progress in supporting better typing.

@erictraut
Copy link
Contributor

The good news is that this proposal is one step closer to becoming standardized in Python. It is now a draft PEP, and if it's accepted, it will become part of Python 3.12.

@zanieb
Copy link

zanieb commented Feb 28, 2023

@bschnurr it looks like this PEP has now been accepted and is on track to be a standard in Python 3.12. See https://peps.python.org/pep-0692/

Would you be willing to open this issue again?

@rchiodo
Copy link
Contributor

rchiodo commented Feb 28, 2023

We actually implemented this. It should be working in our latest prerelease.

image

@zanieb
Copy link

zanieb commented Feb 28, 2023

@rchiodo Oh sweet! I had just tried this on VSCode but I'm not on any preview versions. Thanks for the quick response.

@alon-ba
Copy link

alon-ba commented Dec 4, 2024

It works really nice, thank you!
But - It produces 2 issues for me:

  1. In the case that my TypedDict is complex - meaning having another TypedDict nested inside my main TypedDict - it wouldn't auto-complete the fields of the inner TypedDict, if not all fields of OuterDict are given:
    Image
    Image

  2. Probably MyPy's fault, not yours: With MyPy, if I don't invoke my method with all the required args I get a constant error `Missing named argument "xyz" for "some_method" Mypy(call-arg) - as if it expects to receive all the fields of my TypedDict, even if I marked them as optional.
    Image

@erictraut
Copy link
Contributor

Mypy is correct to generate an error here. You'll see the same error if you enable type errors in pylance. If you want the fields in your TypedDict to not be required, they need to be marked as "NotRequired". Alternatively, you can specify total=False which will implicitly mark all of the fields as NotRequired. In your sample, field_1 is required and must be of type int | None.

class MyDict(TypedDict, total=False):
    field_1: int | None

or

class MyDict(TypedDict):
    field_1: NotRequired[int | None]

For future bug reports, please include your code in text form rather than (or in addition to) screen shots and open new issues rather than adding to issues that have been closed for a long time.

@alon-ba
Copy link

alon-ba commented Dec 4, 2024

@erictraut
Thank you very much! I'll try that tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants