For the type decorator, I suggest accessing the __annotations__ property of the function and use the hints as the determinate instead of inputing the types in the decorator per function. This makes the decorator more reusable and less coupled.
Sorry it took so long to get back on this one. Been busy putting some of this to use. Thank you for once again taking the nightmare jungle of 'I don't have a clue' to 'Wow. that is So easy!'. I rewrote the type checker slightly so that it checks the arguments against the list of acceptable types (also checking for subclasses as well) so that the accepted_args acts more like a white list of ok arg types, rather than a strict 1 to 1 correlation. I've been paying more attention to type checking (and documentation, and error messaging) as my projects get bigger. It's time well spent not pulling out what little remains of my hair at some later point. Another thanks for including the informative error messages. It's so simple, and yet so effective at future stress reduction. Even after the years I've been here, you are STILL a freight-train of knowledge in it's simplest forms. 🖖😎👍
Thanks for the nice presentation of the idiomatic use of python decorators. Hint to all: If you want your original function name to appear in stacktraces instead of the name of the wrapper, just add a line with @wraps(func) before the definition of the wrapper function. For this you also need an import statement like: from functools import wraps
Such a good video and a perfect explanation of decorations 👍 I just have a not about the type checking decorator, it's not really practical to defin expected types in the decorator itself, instead use the pythonic type hinting and python typing and parsing for matching types.
it's probably better to capture exceptions at the function call, not at the definition. It's a runtime thing, so should stay with the runtime. But it makes sense for scripting and API calls. I.e. it is indeed a part of the interface then: a network interface that needs retries.
It depends on whether you want to supply arguments or not. The language reference states "the result [of the decorator expression] must be a callable, which is invoked with the function object". So when you write @foo (note: no parentheses) then foo is just the name of the decorator function which needs to return the wrapper when called. But when you write @foo(bar=5, baz="hello") then foo(bar=5, baz="hello") will be called and must return something which in turn returns the wrapper when called. So in this case you need two nested functions. (This also explains why @foo() is not the same as @foo. Just in case you ever fell into that trap)
How to Create a simple tool with UI that leverages AI to analyze logs of a Windows 10/11 computer to identify warnings, log off, and login time of users, the tool should automatically email a summary to a particular email ID.
Is old school synchronous code still being widely used outside of the learning sector and data science / AI? I have been seeing / writing async for over 5 years and seldom see benefit in pseudo threaded code.. Maybe when python and the GIL are removed things will change.. This video seems to be your learning journey in python from newb to intermediate.
Start (00:00:17)
@time_logger - simple decorator (00:02:52)
@retry - parameterised decorator (00:07:39)
@type_check - type enforcing decorator (00:13:29)
@debug - simple decorator (00:17:39)
@rate_limiter (00:20:02)
ehehehe
from neuralnine import decorators
Not just useful, really helps make sense of what decorators are and how they work. Thanks!
For the type decorator, I suggest accessing the __annotations__ property of the function and use the hints as the determinate instead of inputing the types in the decorator per function. This makes the decorator more reusable and less coupled.
thisl is wild, I never thought decorators were so easy
Sorry it took so long to get back on this one. Been busy putting some of this to use. Thank you for once again taking the nightmare jungle of 'I don't have a clue' to 'Wow. that is So easy!'.
I rewrote the type checker slightly so that it checks the arguments against the list of acceptable types (also checking for subclasses as well) so that the accepted_args acts more like a white list of ok arg types, rather than a strict 1 to 1 correlation.
I've been paying more attention to type checking (and documentation, and error messaging) as my projects get bigger. It's time well spent not pulling out what little remains of my hair at some later point.
Another thanks for including the informative error messages. It's so simple, and yet so effective at future stress reduction.
Even after the years I've been here, you are STILL a freight-train of knowledge in it's simplest forms.
🖖😎👍
This is gold! 🎉 Thanks for your great effort.
Broo you are too OP 🔥
Keep churning out more Python content...
*PYTHON FOREVAAAAAA !!!*
Thanks for explaining decorators.
Very useful and well explained. Thank you 👋
Thanks again for another quality content
Thanks for the nice presentation of the idiomatic use of python decorators. Hint to all: If you want your original function name to appear in stacktraces instead of the name of the wrapper, just add a line with @wraps(func) before the definition of the wrapper function. For this you also need an import statement like: from functools import wraps
two comments on my side:
1. consider usage of wraps (from functools)
2. 16:14 consider checking kwargs, too.
Such a good video and a perfect explanation of decorations 👍
I just have a not about the type checking decorator, it's not really practical to defin expected types in the decorator itself, instead use the pythonic type hinting and python typing and parsing for matching types.
Very usefull video. Thank you!
Thank you for something really useful!
Really useful
Awesome, thank you.
Great,thanks neurol nine. I've already find a solution to some minor bugs
it's probably better to capture exceptions at the function call, not at the definition. It's a runtime thing, so should stay with the runtime. But it makes sense for scripting and API calls. I.e. it is indeed a part of the interface then: a network interface that needs retries.
pretty advanced stuff
Should the rate limiter clean up old calls.. otherwise does the calls list keep growing?
oh nevermind. I see how it gets re-assigned with only the calls within the interval. that's nice.
what plugin to vim are you using?
Thanks a lot!
Can you explain when you need to use "def decorator(func)" & "return decorator" and when you do not?
It depends on whether you want to supply arguments or not. The language reference states "the result [of the decorator expression] must be a callable, which is invoked with the function object".
So when you write
@foo
(note: no parentheses) then foo is just the name of the decorator function which needs to return the wrapper when called.
But when you write
@foo(bar=5, baz="hello")
then foo(bar=5, baz="hello") will be called and must return something which in turn returns the wrapper when called. So in this case you need two nested functions.
(This also explains why @foo() is not the same as @foo. Just in case you ever fell into that trap)
What will happen if I change value when I use, "@cache" decorator like print(process_input(6)) in any step of calling the method process_input() ?
it's for you to decide, because you will have to implement that derorator and there you specify what is going to happen
awesom!
How to Create a simple tool with UI that leverages
AI to analyze logs of a Windows 10/11 computer to identify warnings, log off, and login time of users, the tool should automatically email a summary to
a particular email ID.
Is there an easy way to globally turn decorators on and off?
Add an if statement to every decorators code to a veriable.
Nah this is wild.
cool
Is old school synchronous code still being widely used outside of the learning sector and data science / AI? I have been seeing / writing async for over 5 years and seldom see benefit in pseudo threaded code.. Maybe when python and the GIL are removed things will change.. This video seems to be your learning journey in python from newb to intermediate.
Yeah it is used, especially when Python is used inside other softwares where there is a main thread and you can't go out of it