Missing Type hints and VSCode autocompletion

[g0di]

• Faker version: 19.2.0
• OS: Windows 10 Enterprise
• Python: 3.8

Using Faker is a bit tedious to me at the moment because I have no type hints through my VSCode editor. I must regularly go to the documentation and check in all providers to find the function that would suit me the most compared to having function suggested directly by my editor when I type faker..

I saw a related issue from 2021 which was closed as completed but still I don't have any type hints

Steps to reproduce

1. Get VSCode installed and Python extension (from Microsoft)
2. Create a virtual environment and install faker in it
3. Create a new file with something like

from faker import Faker

fake = Faker()
fake.name()

Expected behavior

I expect that VSCode provides autocompletions for available providers functions (like .name())

Actual behavior

VSCode mark the fake.name() function as Any and does not provide any autocompletions

.name() function marked as Any even if the from faker import Faker is proprly resolved and typed

VSCode suggestions does not embed any providers function like .name() for this example

[stefan6419846]

This seems to be the same as in #1604.

[g0di]

I've red the issue you've linked and it might be related indeed. I'm just not sure if the "tab completion" in REPL is the same as for VSCode Python extension.

I think the former is using the dir method to list an object available functions when you press tab on REPL. This could not work if some providers are somehow generated dynamically I guess.

The later is more based (AFAIK) on type annotations on the code. The extension is doing a static analysis of an object based on his type to collect possible attributes or methods.

In any cases this is not working and it makes it tedious to use faker

[fcurella]

I think we've already done everything we could do, short of rewriting Faker from scratch.

But I'm open to ideas! If anybody knows how to help, please submit a Pull Request!

[g0di]

Thé issue is that Faker instances are mostly proxies around providers. This dynamic behavior cause static type checking tools to not be able to resolve types because they’re not aware of those proxied providers. The only solution I could see is that we generate type stubs from the providers and « attach them » to the faker object. Those stubs .pyi files can then be shipped next to faker package.

[g0di]

In the meanwhile, I found the following workaround. It is a bit of a hack to trick the type checker

from typing import cast

from faker import Faker, Generator
from faker.providers import address, date_time, python


class SmartFaker(
    date_time.Provider,
    address.Provider,
    python.Provider,
    Faker,
    Generator,
):
    unique: "SmartFaker"
    optional: "SmartFaker"

    def __init__(self, generator: Any) -> None:
        msg = "This class is meant to be used only as a type"
        raise RuntimeError(msg)

def create_faker() -> SmartFaker:
    return cast(SmartFaker, Faker())

The idea is to create a "fake" class inheriting all the providers you want plus Faker and Generator. Then you use this class just as a type by either casting, using a factory function or typing a "fake" object in a function arg to get full type checking + intelisense.

Note that this class is not meant to be instantiated

Well, this is a bit ugly but it actually saves me lot of time going back and forth the online documentation to check available providers and parameters.

[khusmann]

@g0di I like your workaround! For me, vscode is reporting a conflict with the Faker class and Generator class though, on the seed_instance method - do you get that on your end too? Removing Faker from the subclass list resolves it.

[g0di]

I don’t remember having such an issue. Maybe because I disabled pyright and I’m using mypy for type checking? I’ll have to check that on Monday.

Anyway as I mentioned, this is just a trick, feel free to edit to make it for your case ;)

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.