Reuven M. Lerner - Practical decorators - PyCon 2019

[@pamdemonia]

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!

[@ReuvenLerner]

I'm so happy to hear this -- thanks!

[@eversilver99]

That was an excellent lecture on Practical Decorators in Python. Awesome Presentation.

[@ReuvenLerner]

Thanks so much!

[@yomajo]

Caching using pickle'ing was a very nice! Great talk!

[@twanvanderschoot9667]

Brilliant presentation on decorators. This presentation highly recommended for everyone starting with decorators. My compliments.

[@EranMoshe-y9h]

ראובן יא תותח על! הרצאה מצויינת על DECORATORS!

[@computersciencetutorials2931]

Great talk! Will have to revisit many times

[@JackQuark]

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

[@ReuvenLerner]

Couldn't have said it better myself -- glad you enjoyed!

[@shneor.e]

Great presentation!

[@worldboy9684]

Nailed it - perfect introduction, explanation and practical tips

[@ReuvenLerner]

Thanks!

[@madhanganesh1]

Very nice talk. The teaching style is very compelling and learned a lot!

[@ReuvenLerner]

Thanks so much!

[@4rph3n]

Great comment about using callable classes as a replacement of functools.partial in the q&a :)

[@rohitbhanot7809]

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.

[@MrMartingale1]

protip: watch this at 0.75x speed

[@ReuvenLerner]

Ha! Guilty as charged; I tend to speak quickly, including when I'm lecturing.

[@mudskippy3903]

Hahah, i watched on 1,75 :D

[@moo_goo]

i watched on x2 lol

[@berryk.4174]

Ha! I didn't watch it at all, the comments did the trick.

[@VinceKully]

protip: watch at 2x speed

[@fjolublar]

that joke about static variables was gold

[@JohnMatthew1]

Very good presenter, fun and informative :)

[@SarfarazAhmad89]

Learned something new. Sold ! Upvoted !

[@irrationalpi]

Thank you very much for the excellent presentation!

[@rodelias9378]

Great talk! Thank you very much!

[@unperrier]

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 :)

[@edchelstephens]

Thank you Reuven! :)

[@jc_777]

Beautiful lecture. Your lecture saves my ass at 01:30 AM .

[@luckiertwin2]

Great presentation.

[@narutouzumaki2648]

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

[@movax20h]

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.

[@sanketg10]

Great lecture, with nice examples!~

[@stas.kudriashev]

Great lecture! Very understandable 👍

[@ReuvenLerner]

So happy to hear it!

[@danshtr]

Thanks! Learned a lot.

[@ReuvenLerner]

I'm delighted you enjoyed it!

[@JanOetting]

Great Talk!

[@dswonderchild]

that was pretty interesting

[@catface]

fantastic! :D

[@ReuvenLerner]

Thanks!

[@rohitbhanot7809]

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.

[@ReuvenLerner]

Right -- you can, but it gets a bit messy. Not impossible, but a bit beyond the scope (and timing) of the talk.

[@thinkingaloud1833]

I have to shower each time I run my code :D

[@abir95571]

20:05 c.__repr__ = fancy_repr this is just monkey patching

[@premavansmuuf]

Every time you use _time.time()_ to measure time, God kills a kitten. Use _time.monotonic()_ to save them.

[@ReuvenLerner]

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.

[@nngogol244]

speed is bad.

[@coreprogramming]

import time def fancy_repr(self): return f"I'm a {type(self)}, with vars {vars(self)}" def better_repr_and_birthday(c): c.__repr__ = fancy_repr def wrapper(*args, **kwargs): o = c(*args, **kwargs) o._created_at = time.time() return o return wrapper @better_repr_and_birthday class A: pass a = A() print(a._created_at) print(a)