Here's some additional important details about @datacalsses that a viewer called out (thank you @FrederikSchumacher): 1. Type annotations are not validated or enforced - they can act as a nice guide for you, but be aware that Python won't throw and error or warn you if you use a different type in runtime. 2. Frozen (constant) lists can have items appended/removed (similar to a constant array in Typescript). If you want the list operations itself to be immutable too, try using tuples instead. 3. **kwargs initialisation works on the initial instance of the dataclass, but not on nested dataclasses or fields (there you might want to look at Pydantic instead, which I believe does do that).
Dude your level of detail and pace is just PERFECT! I have easily seen hundreds if not thousands of videos on RUclips regarding CS. You're one of the best on that aspect! And I love how you leave further details for documentation, which is necessary anyways!
Really solid video. I'm really glad the options frozen and order where presented. I wish you had mentioned something potentially confusing about the type annotations: although the type annotations are required for the fields declaration, they're not validated or enforced. Meaning it's possible to declare a field "name: str" but then assign some other type of value. Another gotcha is even when using frozen, this only applies to assignment to the fields, not the values. So something like "tags: list = field(default_factory=list)" still allows modification of the list (eg. using append or extend). And one more gotcha about the **kwargs initialization: this only applies to the initial instance, not any nested fields using dataclasses - that's related to the aforementioned field types not being "used" internally. This can become potentially confusing and lead to bugs, if one isn't aware of that. So, while dataclasses.asdict works recursive, there's not really an equivalent fromdict and using **kwargs can introduce bugs.
Thanks for your detailed comments and elaboration on the dataclasses :) I've added a pinned comment to the video with those details so everyone can read them too. You're absolutely right, good points to be aware of for anyone using dataclasses.
Great introduction to dataclasses! I especially appreciated the tip about making dataclasses immutable, something I will definitely use on my future projects. Thank you!
For Java developers, it's just like records or in kotlin: dataclasses. The difference in Python is that it does not have validation and instances aren't "strictly" typed, so you can add or remove properties at will.
The dataclass decorator provides useful features, but it is often used even when it doesn't fit the name dataclass, which can decrease code readability. In fact, it is confusing to see the dataclass decorator attached to classes that are only used once. The simplification of __init__ and __repr__ should be separated and implemented under different names.
Here's some additional important details about @datacalsses that a viewer called out (thank you @FrederikSchumacher):
1. Type annotations are not validated or enforced - they can act as a nice guide for you, but be aware that Python won't throw and error or warn you if you use a different type in runtime.
2. Frozen (constant) lists can have items appended/removed (similar to a constant array in Typescript). If you want the list operations itself to be immutable too, try using tuples instead.
3. **kwargs initialisation works on the initial instance of the dataclass, but not on nested dataclasses or fields (there you might want to look at Pydantic instead, which I believe does do that).
Dude your level of detail and pace is just PERFECT! I have easily seen hundreds if not thousands of videos on RUclips regarding CS. You're one of the best on that aspect! And I love how you leave further details for documentation, which is necessary anyways!
Thank you so much :) I spend a lot of effort editing the script/pacing, so I really appreciate your comment.
Really solid video. I'm really glad the options frozen and order where presented. I wish you had mentioned something potentially confusing about the type annotations: although the type annotations are required for the fields declaration, they're not validated or enforced. Meaning it's possible to declare a field "name: str" but then assign some other type of value. Another gotcha is even when using frozen, this only applies to assignment to the fields, not the values. So something like "tags: list = field(default_factory=list)" still allows modification of the list (eg. using append or extend).
And one more gotcha about the **kwargs initialization: this only applies to the initial instance, not any nested fields using dataclasses - that's related to the aforementioned field types not being "used" internally. This can become potentially confusing and lead to bugs, if one isn't aware of that. So, while dataclasses.asdict works recursive, there's not really an equivalent fromdict and using **kwargs can introduce bugs.
Thanks for your detailed comments and elaboration on the dataclasses :) I've added a pinned comment to the video with those details so everyone can read them too. You're absolutely right, good points to be aware of for anyone using dataclasses.
Great introduction to dataclasses! I especially appreciated the tip about making dataclasses immutable, something I will definitely use on my future projects. Thank you!
Thank you! So glad you found it helpful :)
Man, I love it when I find a youtuber who is clear and thorough. You rock!!
Thank you! Great overview.
Thanks for watching!
Nice introduction to dataclasses, Thanks
Thank you!
Nice video, +1 for Pydantic!
Thanks!
Nice guide to dataclasses!
Thank you!
For Java developers, it's just like records or in kotlin: dataclasses.
The difference in Python is that it does not have validation and instances aren't "strictly" typed, so you can add or remove properties at will.
Thank you very much 🤓
You’re welcome!
The dataclass decorator provides useful features, but it is often used even when it doesn't fit the name dataclass, which can decrease code readability. In fact, it is confusing to see the dataclass decorator attached to classes that are only used once. The simplification of __init__ and __repr__ should be separated and implemented under different names.
I have a question I would like to email it to you, I don't want to look bad in the comment section😗
I didnt know that