Reuven M. Lerner - Practical decorators - PyCon 2019
HTML-код
- Опубликовано: 16 июл 2024
- "Speaker: Reuven M. Lerner
Decorators are one of Python's most powerful features. But even if you understand what they do, it's not always obvious what you can do with them. Sure, from a practical perspective, they let you remove repeated code from your callables. And semantically, they let you think at a higher level of abstraction, applying the same treatment to functions and classes.
But what can you actually do with them? For many Python developers I've encountered, ecorators sometimes appear to be a solution looking for a problem.
In this talk, I'll show you some practical uses for decorators, and how you can use them to make your code more readable and maintainable, while also providing more semantic power. Moreover, you'll see examples of things would be hard to do without decorators. I hope that after this talk, you'll have a good sense of how to use decorators in your own Python projects.
Slides can be found at: speakerdeck.com/pycon2019 and github.com/PyCon/2019-slides"
So I have watched many (too many) talks about decorators over the years, and none of them stuck.
This marvelous talk was the first to actually explain them in a way that makes sense. Thank you so much!
I'm so happy to hear this -- thanks!
Brilliant presentation on decorators. This presentation highly recommended for everyone starting with decorators. My compliments.
That was an excellent lecture on Practical Decorators in Python. Awesome Presentation.
Thanks so much!
Caching using pickle'ing was a very nice! Great talk!
that joke about static variables was gold
protip: watch this at 0.75x speed
Ha! Guilty as charged; I tend to speak quickly, including when I'm lecturing.
Hahah, i watched on 1,75 :D
i watched on x2 lol
Ha! I didn't watch it at all, the comments did the trick.
protip: watch at 2x speed
Great talk! Will have to revisit many times
Learned something new. Sold ! Upvoted !
Thank you very much for the excellent presentation!
ראובן יא תותח על! הרצאה מצויינת על DECORATORS!
Great presentation!
Nailed it - perfect introduction, explanation and practical tips
Thanks!
- "Decorator" is a utility that accepts a callable as argument and returns a callable.
- "We love dictionaries and we use them wherever we can."
- Use pickle when args are not hashable.
- Decorator can be used to modify classes easily and conveniently.
Couldn't have said it better myself -- glad you enjoyed!
Great lecture, with nice examples!~
Thank you Reuven! :)
Very nice talk. The teaching style is very compelling and learned a lot!
Thanks so much!
Very good presenter, fun and informative :)
Great presentation.
Great talk! Thank you very much!
Great comment about using callable classes as a replacement of functools.partial in the q&a :)
Classes are always callable, remember that's what allows you create the objects. Functools.partial comes into picture only for parameterized decorators n writing parameterized decorators with classes is also pretty nested since you have a callable inside the __call__ of the class.
Great Talk!
Thanks! Learned a lot.
I'm delighted you enjoyed it!
that was pretty interesting
Great lecture! Very understandable 👍
So happy to hear it!
The questions were so smart and insightful that he couldn't answer most of them!
I couldn't even understand a couple of those questions, even when repeating the video, so no wonder why he didn't answer those :)
Beautiful lecture. Your lecture saves my ass at 01:30 AM .
fantastic! :D
Thanks!
Actually, the value returned from the decorator doesn't need to be a callable. It can be an arbitrary thing.
Parametrized decorators are easy to grasp, once you realize what '@' expects. @ expects a callable (a function) that receives a single argument (a function or whatever we are decorating, which might not be a callable in some cases if you contrive or chain decorators that do weird things). So "@mydeco(a=5)", the mydeco(a=5) is evaluated first. mydeco here is not a decorator. a full value mydeco(a=5) is a decorator. So it must be able to accept what we are decorating. so (mydeco(a=5))(originalfunc) must be valid and produce the end result. You can construct mydeco by nesting 3 functions, or using lambdas, but it can also be done using currying.
In fact the terminaology at 13:40 is wrong. the 'middle' is a decorator, the once_per_n return the middle, aka the decorator. once_per_n is just a function. it is not a decorator. You could call it a decorator generator / factory.
There is nothing magical or special in decorators, it is really just saying 'add = mydeco(add)' after the function. Nothing less, nothing more.
One of my recent use of decorator syntax was to create classes and instance of this class easier and in smaller amount of code. '@op('add3', latency=3) def Add3(X, Y, Z=Imm(0)): return lambda x,y,z:x+y+z, X, Y, Z'
then in the decorator don't just wrap the Add3, but actually call it to capture the default arguments and the implementation (the lambda), then create a new type of class derived from some base class (OP), automatically add various fields and methods based on the lambda, arguments, and defaults, as well the decorator paremters, register it globally, and return an instance of the class just created, with some extra stuff and keyword parameters. So user can do Add(3, 4, comment="xyz"), which doesn't actually call the original body of the Add3, but return a complex object, with some stuff populated and capturing the semantic of the op. The same could be done using classes, but it would be about 8 lines, instead of just 3. And with 100 ops it wasn't nice. The decorator itself was about 20 lines of dense code.
I always thought why would I use a decorator why not modify the original function, so I thought I suppose to use it only when I don't have access to function code directly. But now I know better
It makes it happy to know you enjoyed and learned from the talk!
Excellent lecture! very nice and interested topics
Question:
in case the inner function named "foo" and it can receive a named argument named "cache"
in time 16:12, don't you *have* to use nonlocal? since "cache" foo may shadow the local "cache" variable of "memoize " function
EDIT:
i checked the scenario, and the named variable "cache" of "foo" DON'T shadow the "cache" variable of memoize
Thanks again for the great video
Class methods can be surely be decorated but in that case the decorator class has to implement descriptor protocal, Non-Data descriptor to be specific.
Right -- you can, but it gets a bit messy. Not impossible, but a bit beyond the scope (and timing) of the talk.
I have to shower each time I run my code :D
20:05 c.__repr__ = fancy_repr this is just monkey patching
speed is bad.
Every time you use _time.time()_ to measure time, God kills a kitten.
Use _time.monotonic()_ to save them.
Have you ever considered that I dislike kittens? :-)
More seriously, I've been told that I should use time.monotonic or time.perf_counter... more recent versions of the talk now include those points.