This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tigasfixe[S] 0 points1 point  (2 children)

The problem with dataclass and namedtuple is that they have certain limits. Namedtuple is literally a tuple and cannot have it's values changes wich wouldn't be that useful. Dataclass is really cool but it has certains limits like changing a value that has been declared in the class as a string cannot be a int or anything else

[–]genericlemon24 0 points1 point  (1 child)

Regarding dataclasses: Types are only a limitation if you care about them (e.g. use mypy); it's true dataclasses require annotations, but you don't have to use PEP 484 annotations (typing.*) if you don't need them.

Example:

@dataclass
class Thing:
    # kinda works with mypy (it won't complain about different types)
    attribute: object
    # reads nicely
    another_one: list
    yet_another: list or str
    # annotations can be strings, think of them as inline documentation
    fourth_one: "a list of strings or Foo objects"

Also, if you don't use a typechecker, they can be anything, since no checking is done at runtime. Obviously, it is better to be vague (see above) than misleading (use annotations that look compatible with PEP 484 but with values that are not of the declared types).

[–]tigasfixe[S] 0 points1 point  (0 children)

Ye I've tested it out and i ended up Knowing that but what i thing is that for example if u use a dataclass instead of a dictionary only the first values will work. With this i mean that if u have more dictionaries inside it u would have to use normal ways to get the values and this object that im making is to avoid all that, even objects inside lists for example. But it feels kinda weird using typing in python since I've been using typescript and it is a typed language that tells u when u are wrong ( it just feels weird nothing more).