PyLint - 'from_dict' member (no-member)

[sdupere-git]

dataclasses-json does not seem to pass PyLint tests if using created methods.

In this example the method used is from_dict.

To get around it, brain tips must be added.

Example Implementation for dataclasses: https://github.com/PyCQA/astroid/blob/master/astroid/brain/brain_dataclasses.py

Note at the moment I did not look exactly the full logic of this, but if dataclasses-json can be added to the astroid git project, it would play nicely like dataclasses does.

For now we got around it by having a .pylintrc with:
[TYPECHECK]
generated-members=from_dict

[Spenhouet]

The same is true for other methods (e.g. from_json, to_json) and also for mypy.

Class 'X' has no 'from_json' member - pylint(no-member)

"Type[X]" has no attribute "from_json" - mypy(error)

Instance of 'X' has no 'to_json' member - pylint(no-member)

"X" has no attribute "to_json" - mypy(error)

[RunOrVeith]

You can also get around it by inheriting from DataClassJsonMixin instead of using the decorator.

[Spenhouet]

@RunOrVeith Thanks for the hint. Is it possible to also achieve that with the decorator i.e. is this fixable or is inheriting from DataClassJsonMixin the only solution?

With the inheritance I still get the following warnings:

Type of "to_dict" is unknown
Type of "to_dict" is "(encode_json=False) -> Dict[str, dict[_KT, _VT] | list[_T] | str | int | float | bool | None]" Pyright (reportUnknownMemberType)

Type of "from_dict" is unknown
Type of "from_dict" is "(kvs: dict[_KT, _VT] | list[_T] | str | int | float | bool | None, *, infer_missing=False) -> SimpleExample" Pyright (reportUnknownMemberType)

But I can't explain why that is since dataclasses_json does seem to have proper type annotations. Maybe this is a pyright issue and I need to raise it on their side?

I do also get the warning that the package does not have a stub file:

Stub file not found for "dataclasses_json" Pyright (reportMissingTypeStubs)

Since dataclasses_json does provide type annotations, I'm not sure how that correlates with the type stub file. Maybe one needs to an empty or basic stub file for static type checkers to be happy? I don't know what the best practice with respect to package development is.

[lidatong]

Hi, dataclasses-json currently does not have full support for typing. There are type annotations / hints added by some contributors, but to full-typing support would require following the guidelines here: https://www.python.org/dev/peps/pep-0484/#stub-files.

Regarding the errors around to_dict and from_dict: I find in general type checkers to be inadequate at inferring protocol-oriented Python, which we might call "typed duck-typing".

The decorator registers a given user class as a "virtual subclass" of DataClassJsonMixin. Last I looked into this the type checker couldn't determine that a virtual subclass is, in fact, a subclass. Hence why inheriting as a Mixin works.

[takeda]

You don't want to use stub files, it is a nightmare to keep them in sync with the code. They are better suited as an addon to existing packages that you can't modify.

[george-zubrienko]

This should be resolved in 0.5.8

[ramnes]

@george-zubrienko It seems that Mypy is still struggling to find to_dict with 0.5.9:

chainlit/server.py:272: error: "PaginatedResponse[ConversationDict]" has no attribute "to_dict"  [attr-defined]

You can see the code triggering this error here (PaginatedResponse being defined here).

Is this error related to this issue or should I open a new one?

[george-zubrienko]

@ramnes yeah it will be triggering for a while if you dont't subclass the Mixin, please take a look at #402 - we reverted the change as did more bad than good.
Please also take a look at #442 that should solve this eventually and cast your vote as well + share your opinion

[george-zubrienko]

Currently the only way to avoid this is to subclass DataClassJsonMixin - you can use annotation as well, but subclassing is mandatory to prevent pylint/mypy fuming black smoke

[george-zubrienko]

Also re-opening this one, as not solved yet - #442 is the way forward.