Hettinger is becoming a better and better speaker with experience.

@medthehatta

5 жыл бұрын

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.

i really enjoyed it. Great talk.

These videos are gold

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.

The man the legend

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'.

So dataclasses are Java Lombok Library @Data class annotation? Awesome, and super simple.

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?

@DeMurker

5 жыл бұрын

Yes, it is needed. If you would write def __init__(self, parameter=[]) then all instances of the class refer to the same list.

More questions would have been nice, they never give him enough time.

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

@aoeu256

5 жыл бұрын

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)

Both links to the slides are dead...

@Egzvorg

6 жыл бұрын

you can find slides on twitter @raymondh

@alexanderreynolds7638

6 жыл бұрын

This tweet specifically has the dropbox link to the slides for this talk: twitter.com/raymondh/status/995693882812915712

__dataclass_fields__ for lightness and saturation seem wrong. Shouldn't they say .type = float rather than .name = float?

@Zergosss

5 жыл бұрын

It seems to be corrected in the slides that I downloaded from his Twitter.

Would be even cooler if the dataclass support in-place replace() functionality like :: replace(c, hue+=10) Just sayin.

@calebgindelberger3046

5 жыл бұрын

Wasn't there a joke about collections authors always getting feature requests in there somewhere?

@drygordspellweaver8761

2 жыл бұрын

Errr... c.hue += 10 Attributes are already mutable

hello my name is "Erick Smith"? 0:33

@narnbrez

4 жыл бұрын

eric schmidt

@fiordnord

4 жыл бұрын

@@narnbrez and whats the punch in this line?

@yochem9294

3 жыл бұрын

@@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

Raymond, i'll take the 10 bitcoins /day job...

Why not just dict() and tuple() instead of asdict() and astuple()

@gnikgnak

6 жыл бұрын

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.

@j2kun

6 жыл бұрын

I meant, why not just reuse the builtins? Do they behave any differently?

@gnikgnak

6 жыл бұрын

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.

@juanarrivillaga2683

3 жыл бұрын

@@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.

@MikeSelik

3 жыл бұрын

@@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.

python is so big

Very low volume :(

> 0.033 seconds > "33 nanoseconds" how to speed up python with one simple trick :P

@psikoumaha

4 жыл бұрын

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.

@drygordspellweaver8761

2 жыл бұрын

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.