I think it's important to mention that @property is perfectly usable in other kinds of classes. This is not a feature unique to dataclasses. Otherwise nice video
Yep. For any class it's the first step towards having 'setters' and 'getters'. @property -> named property becomes read-only through the getter with whatever code you want to manipulate the return value; @.setter -> setter with whatever sanity checking or whatever to manipulate the stored value.
When I read about dataclasses in the docs I didn't really see the point to using them but after watching this video I can see how they are more useful than I thought. I would like to see another video on some of the more advanced features for sure.
As an extra point it's common (at least where I'm from) to put the emphasis on the second syllable, which sounds almost like the word rim - so peRIMeter instead of PErimeter
Really well described :) might have been useful to discuss slots and also show more on how the default_factory etc work (and the caveats of having attributes that aren't set initially where they don't show in the repr) - maybe those for a follow up vid? :)
these are very cool features as your worst features video was beneficial for me I was stuck at some point in one project implicit str concatenation was making my project difficult but your video was beneficial for me
Pydantic is far superior eg built in data validation, supports deep structures, validation, serialisation, etc. If you use already use Pydantic, not much point, dataclasses are a step backwards.
It is an attribute that is computed from other attributed. There are many things that need to be recomputed once an attribute changes. Property makes it so that it is always computed properly
1. The usage method cannot prevent users from misuse and overwriting it, such as ary.len = 10. 2. Using property, you can customize its setter (@.setter) and deleter (@.deleter), so you can accept more flexible syntax while retaining the setter method to check the input, such as: circle.c, circle.r = (0, 0), 10 3. The method cannot be used in special cases where the expression cannot be used, such as: match circle: case Circle(r=0): print(f'This is a dot.')
Minor note: I'm pretty sure I read in PEP that __init__ shouldn't have a return type. I too had started to put -> None there, until I read the "don't bother". More pertinent: one thing I'd really like to see, as someone who works with REST APIs day in, day out, is better "native" support for JSON. Serialisation, schema-to-dataclass, etc. There's various support packages that do this more or less well, but as so often they're bolted on and of varying level of support.
I think it's important to mention that @property is perfectly usable in other kinds of classes. This is not a feature unique to dataclasses. Otherwise nice video
Yep. For any class it's the first step towards having 'setters' and 'getters'. @property -> named property becomes read-only through the getter with whatever code you want to manipulate the return value; @.setter -> setter with whatever sanity checking or whatever to manipulate the stored value.
Next... advanced dataclasses video please
When I read about dataclasses in the docs I didn't really see the point to using them but after watching this video I can see how they are more useful than I thought. I would like to see another video on some of the more advanced features for sure.
Echo the same thought
Me too
You had it almost right! Perimeter is pronounced the same as parameter, but "ih" instead of "ah" for the second a
As an extra point it's common (at least where I'm from) to put the emphasis on the second syllable, which sounds almost like the word rim - so peRIMeter instead of PErimeter
@@STIUTK but in "parameter" you already put emphasis on the second syllable so it's enough to say "same as parameter but..."
Really well described :) might have been useful to discuss slots and also show more on how the default_factory etc work (and the caveats of having attributes that aren't set initially where they don't show in the repr) - maybe those for a follow up vid? :)
these are very cool features as your worst features video was beneficial for me
I was stuck at some point in one project implicit str concatenation was making my project difficult but your video was beneficial for me
Nice. Perhaps a video on cool pydantic features would be a good complement.
Thank you for sharing your Python knowledge. You make learning it easy and interesting :)
__post_init__ is useful, list attributes should be initialized by a list factory because it is mutable
0:43 that was personal
super knowledge
Question: if we do `friends: list[str] = []`, is the list gonna be shared by all instances?
What is the difference between pydantic BaseModel and dataclasses?
Pydantic is far superior eg built in data validation, supports deep structures, validation, serialisation, etc. If you use already use Pydantic, not much point, dataclasses are a step backwards.
Would make more videos about data classes please
More data class
Bob is not just more than James, Bob is more than all of us.
possible to you make `friends` a list[Person]?
Okay, but what if you want the address of an object created by the @dataclass decorator?
id() like you use with any other object in python
I don't understand what the @property accomplishes? Could you not just create the same method but without the decorator?
Using @property is considered more pythonic way of doing it.
it should be more of an attribute than a method
from the video it is implied that the with @property we don't have to explicitly call the method when the attribute changes right?
It is an attribute that is computed from other attributed. There are many things that need to be recomputed once an attribute changes. Property makes it so that it is always computed properly
1. The usage method cannot prevent users from misuse and overwriting it, such as ary.len = 10.
2. Using property, you can customize its setter (@.setter) and deleter (@.deleter), so you can accept more flexible syntax while retaining the setter method to check the input, such as: circle.c, circle.r = (0, 0), 10
3. The method cannot be used in special cases where the expression cannot be used, such as: match circle: case Circle(r=0): print(f'This is a dot.')
Thank you 😊
Is Luigi a friend of yours? You use him almost everywhere. And where is his brother, Mario?
Minor note: I'm pretty sure I read in PEP that __init__ shouldn't have a return type. I too had started to put -> None there, until I read the "don't bother".
More pertinent: one thing I'd really like to see, as someone who works with REST APIs day in, day out, is better "native" support for JSON. Serialisation, schema-to-dataclass, etc. There's various support packages that do this more or less well, but as so often they're bolted on and of varying level of support.
Type hinting dunder init is so very unpythonic….on both ends. Y’all might get guido out of retirement.