I dunno, I feel that he spoke less clearly here than usual, and the webpage slides are kinda lazy, especially considering he has done live demos in the past.
13:15 Yes! I developed a library for building, validating and serialise/deserialising data structures. There is always a stream of "small" requests or huge changes in behaviour.
Why can't we just use parameter: list instead of this factory thingy? I understand the purpose of factories for non-standard objects, but is it needed for an empty list?
Say i have a data class and instead of using setattr i want to have a function that sets the key ... How can i know which attr is a a data class field? And how can i define custom fields
For the first one dataClsObj.__class__.__dataclass_fields__, for the second one try inheritance? @dataclass class newdataclass (olddataclass): pass If not try: from copy import deepcopy, Newdataclass = olddataclass.deepcopy() Newdataclass.hue : int = 5 Newdataclass = dataclass(Newdataclass)
@@fiordnord erick wrote the dataclasses, he explains he nornally talks about thing he wrote for python. But not this time, raymond did not write the dataclasses module. So he introduces himself with the name of the author of the data classes
When defining the methods, they exist in the local scope of the class definition. If you define a method called "dict" it will shadow the builtin dict inside that local scope. You'll find that Python experts are averse to naming things the same as builtins, even if it doesn't cause a problem in the current implementation. They have a healthy paranoia that future changes, made hastily, will cause a problem. The unofficial standard for conversion methods is to name them "as_type". You'll see that pattern in the standard library and many popular packages. When designing an API, it's best to follow the standard even if you have a better idea. Folks familiar with the standard don't want to learn new names for concepts they already know.
Yes, they are different. I'm not really sure what you mean by "(re)use the builtins," but I'm taking a wild guess that you are suggesting using the dict or tuple constructors. The tuple constructor might work if the dataclass were iterable. There was a discussion about this idea ( github.com/ericvsmith/dataclasses/issues/21 ) which you might be interested in. The dict constructor would only work if the dataclass instance was itself a dict or an iterable of pairs, which in either case would prevent the tuple constructor from working.
@@gnikgnak No, this is absolutely not true at all. A method called `dict` will *never* shadow the built-in `dict`. First, the method *exists in the classes namespace*, which is not the local namespace.
@@juanarrivillaga2683 Check out the `locals()` output during class creation. Here's an example of shadowing the builtins: In [1]: class Foo: ...: dict = lambda: print("Gotcha!") ...: bar = dict() Gotcha!
Python is a god awful language, only slightly better than javascript. I will only mention java and php because some fool will come along and accuse me of being a lover of those awful langauges. Python does everything it can to disempower the programmer despite all evidence that suggests that it 'empowers programmers', rather than doing everything in a properly programmatic structured way python forces the programmer to do everything 'pythonically' which is painfully tedious. The saving social grace of python is that its participants arent rabid boy fans like in other languages, the females are a different matter, I would have actually expected better from the women considering how the feminist movement loves to insinuate how anything that is not imbued with estrogen it is bad.
Python is what finally helped me push through the barrier of learning a language and now my comprehension of other languages is so much stronger than before. You’re wrong about it depriving programmers of learning about “programmatic structure”. An engineering difficulty is an engineering difficulty regardless of the language. Most algorithms have been solved already. You don’t have to reinvent the wheel.
Hettinger is becoming a better and better speaker with experience.
I dunno, I feel that he spoke less clearly here than usual, and the webpage slides are kinda lazy, especially considering he has done live demos in the past.
13:15 Yes! I developed a library for building, validating and serialise/deserialising data structures. There is always a stream of "small" requests or huge changes in behaviour.
i really enjoyed it. Great talk.
These videos are gold
The man the legend
So dataclasses are Java Lombok Library @Data class annotation? Awesome, and super simple.
Not a single time did he say "there must be a better way". It's like a Steve Jobs keynote without the 'one more thing'.
Why can't we just use
parameter: list
instead of this factory thingy? I understand the purpose of factories for non-standard objects, but is it needed for an empty list?
Yes, it is needed. If you would write def __init__(self, parameter=[]) then all instances of the class refer to the same list.
Both links to the slides are dead...
you can find slides on twitter @raymondh
This tweet specifically has the dropbox link to the slides for this talk: twitter.com/raymondh/status/995693882812915712
Say i have a data class and instead of using setattr i want to have a function that sets the key ... How can i know which attr is a a data class field?
And how can i define custom fields
For the first one dataClsObj.__class__.__dataclass_fields__,
for the second one try inheritance? @dataclass class newdataclass (olddataclass): pass If not try:
from copy import deepcopy,
Newdataclass = olddataclass.deepcopy()
Newdataclass.hue : int = 5
Newdataclass = dataclass(Newdataclass)
__dataclass_fields__ for lightness and saturation seem wrong. Shouldn't they say .type = float rather than .name = float?
It seems to be corrected in the slides that I downloaded from his Twitter.
More questions would have been nice, they never give him enough time.
hello my name is "Erick Smith"? 0:33
eric schmidt
@@narnbrez and whats the punch in this line?
@@fiordnord erick wrote the dataclasses, he explains he nornally talks about thing he wrote for python. But not this time, raymond did not write the dataclasses module. So he introduces himself with the name of the author of the data classes
Would be even cooler if the dataclass support in-place replace() functionality like :: replace(c, hue+=10) Just sayin.
Wasn't there a joke about collections authors always getting feature requests in there somewhere?
Errr... c.hue += 10
Attributes are already mutable
Why not just dict() and tuple() instead of asdict() and astuple()
When defining the methods, they exist in the local scope of the class definition. If you define a method called "dict" it will shadow the builtin dict inside that local scope. You'll find that Python experts are averse to naming things the same as builtins, even if it doesn't cause a problem in the current implementation. They have a healthy paranoia that future changes, made hastily, will cause a problem.
The unofficial standard for conversion methods is to name them "as_type". You'll see that pattern in the standard library and many popular packages. When designing an API, it's best to follow the standard even if you have a better idea. Folks familiar with the standard don't want to learn new names for concepts they already know.
I meant, why not just reuse the builtins? Do they behave any differently?
Yes, they are different. I'm not really sure what you mean by "(re)use the builtins," but I'm taking a wild guess that you are suggesting using the dict or tuple constructors. The tuple constructor might work if the dataclass were iterable. There was a discussion about this idea ( github.com/ericvsmith/dataclasses/issues/21 ) which you might be interested in. The dict constructor would only work if the dataclass instance was itself a dict or an iterable of pairs, which in either case would prevent the tuple constructor from working.
@@gnikgnak No, this is absolutely not true at all. A method called `dict` will *never* shadow the built-in `dict`. First, the method *exists in the classes namespace*, which is not the local namespace.
@@juanarrivillaga2683 Check out the `locals()` output during class creation. Here's an example of shadowing the builtins:
In [1]: class Foo:
...: dict = lambda: print("Gotcha!")
...: bar = dict()
Gotcha!
The quality of the screens is absolutely terrible - no matter what the resolution.
Very low volume :(
python is so big
> 0.033 seconds
> "33 nanoseconds"
how to speed up python with one simple trick :P
He divided the result by 1 million because timeit runs it 1 million times, so you get the value for one sample
Python is a god awful language, only slightly better than javascript.
I will only mention java and php because some fool will come along and accuse me of being a lover of those awful langauges.
Python does everything it can to disempower the programmer despite all evidence that suggests that it 'empowers programmers', rather than doing everything in a properly programmatic structured way python forces the programmer to do everything 'pythonically' which is painfully tedious.
The saving social grace of python is that its participants arent rabid boy fans like in other languages, the females are a different matter, I would have actually expected better from the women considering how the feminist movement loves to insinuate how anything that is not imbued with estrogen it is bad.
Python is what finally helped me push through the barrier of learning a language and now my comprehension of other languages is so much stronger than before.
You’re wrong about it depriving programmers of learning about “programmatic structure”. An engineering difficulty is an engineering difficulty regardless of the language.
Most algorithms have been solved already. You don’t have to reinvent the wheel.
Sorry, what's your rationale to come on a random video on Python-dedicated channel to voice your opinion on an unrelated video? Genuinely baffled.