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

[BUG] from_json of class with attribute of list of types which inherit basic types results in wrong result #485

Open
nirh-cye opened this issue Sep 18, 2023 · 3 comments · May be fixed by #494
Assignees
Labels

Comments

@nirh-cye
Copy link

Description

I have a dataclass that holds an attribute of list (if names was type of name and not list of Name, issue would not reproduce) of a class that inherits the basic type: string.
When creating an instance of this class, converting it into json, writing said json to a file and later reading it and re-creating the object from it, the object structure is not identical to the previous object structure.
The attribute of list that contains objects which inherit the basic type creates the list objects as the basic type instead of their expected type.

Code snippet that reproduces the issue

import json

from dataclasses import dataclass
from dataclasses_json import DataClassJsonMixin


class Name(str):
    ...


@dataclass
class Person(DataClassJsonMixin):
    names: list[Name]


if __name__ == '__main__':
    johnny = Person(names=[Name('John Doe')])
    with open('storage.json', 'w') as f:
        json.dump(johnny.to_json(), f)

    ...

    with open('storage.json', 'r') as f:
        johnny_again = Person.from_json(json.load(f))

    print(isinstance(johnny_again.names[0], Name))  # prints: False

Describe the results you expected

As the original type was indeed Name (before being written into the file) I expected the object after reading the json to also be Name

Python version you are using

3.10

Environment description

Standard clean env. only used pip install dataclasses-json

@nirh-cye nirh-cye added the bug Something isn't working label Sep 18, 2023
@george-zubrienko
Copy link
Collaborator

I am not sure what is happening here:

with open('storage.json', 'w') as f:
        json.dump(johnny.to_json(), f)

johnny.to_json already returns a string. If you do f.write(johnny.to_json()), do you still have an issue?

@george-zubrienko george-zubrienko added question Further information is requested and removed bug Something isn't working labels Sep 18, 2023
@george-zubrienko george-zubrienko self-assigned this Sep 18, 2023
@nirh-cye
Copy link
Author

johnny.to_json already returns a string. If you do f.write(johnny.to_json()), do you still have an issue?

Yes, the reason I am writing to a file in this example is that Person.from_json(johnny.to_json()) would indeed work as expected, the reason being that johnny.to_json would not change the names inner elements to string, it would leave them as they are and therefore would not convert them back in the from_json function.

When this is written to a file, the text: '{"names": ["John Doe"]}' is dumped into it. when attempting to convert that into Person via the Person.from_json function, the type of the names elements will indeed be incorrect.

In short, the writing into a file is not required and the following will also reproduce this bug:

from dataclasses import dataclass
from dataclasses_json import DataClassJsonMixin


class Name(str):
    ...


@dataclass
class Person(DataClassJsonMixin):
    names: list[Name]


if __name__ == '__main__':
    js = '{"names": ["John Doe"]}'
    print(isinstance(Person.from_json(js).names[0], Name))  # prints: False

@george-zubrienko george-zubrienko added triage api/v0 and removed question Further information is requested labels Oct 4, 2023
@george-zubrienko
Copy link
Collaborator

I'll retest this on latest commit tomorrow to see if this is some similar issue with 3.10 as with self-types

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

Successfully merging a pull request may close this issue.

2 participants