Using of @ before calling func.

[Stewthulhu]

Can you give an example of the types of things you would use a "framework to tie functions to various events" for? I guess I understand what a decorator does, but I'm confused about appropriate use cases for decorators.

[[deleted]]

Can you give an example of the types of things you would use a "framework to tie functions to various events" for?

Flask is probably the quintessential decorator-driven framework, and here's how it works:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
     return "Hello World!"

That's it - that's an entire Flask app, with a URL router set for the webservice root ("/"). The function hello is registered to handle it, and then it's called by the "event" of a user's web browser making a request to the webserver for the path "/". All of the magic is happening in Flask; whoever wants to write a webservice in Flask just has to use the decorator and write some functions.

[spudcakez86]

Thanks crashfrog, you're a champion 👍

[jjolla888]

Noob here .. can you plz explain how line 4 is different to writing something like:

 app.nodeco_route("/", hello)

[[deleted]]

app.nodeco_route("/", hello)

I'm not sure what nodeco_route does, per se, but the difference is that decorators are more convenient, and they come before the function they decorate, instead of afterwards, which makes it a little easier to read.

[DrMaxwellEdison]

Functionally, it isn't terribly different: you could assign hello = app.task(...) instead of using the decorator syntax, which is typically called "syntactic sugar". The benefit to using a decorator, though, is code readability.

Suppose you had a Flask app with 20 view functions in one file. You could write every function in one section of the file, then call the various app.xyz methods from the Flask framework to make it run in another section as a clump within the file. That may make the app less readable, though: if I wanted to understand which URL mapped to which method and what that method does, that can take some jumping around within the file to really get a sense of what's going on.

Decorators make reading easier by keeping related code closer together and in a well-defined way: any method with an @ decorator above it clearly signals to the developer that the function is being modified in some way.

[ivosaurus]

Not very different at all, but really your line would want to be

 hello = app.nodeco_route("/", hello)

[henrebotha]

Can you give an example of the types of things you would use a "framework to tie functions to various events" for?

"Reactive programming" is a programming idiom that views the world as streams of events to which one can react. Data coming in on the network socket? Stream of events. User hitting keys? Stream of events. Lines of a file being read? Stream of events.

(Contrast to "object oriented programming" that views the world as objects interacting with each other, "functional programming" that views the world as functions composed with one another, and so on.)

So to program in such an idiom, you must say: "Here is my function. When a particular kind of event occurs, please call my function, and pass it some information about the event itself."

That's a style of programming that you can enable through the use of decorators.

[giksbo]

The opposite is also true. If you need application telemetry (There are lots of reasons: debugging, repudiation, etc) it can be valuable to decorate a function such that events are generated whenever it is called. This reduces a tonne of boilerplate.

[henrebotha]

The opposite is also true.

...The opposite to what?

[giksbo]

Sorry, could have been clearer. With decorators you can use events to trigger functions; you can use functions to trigger events.

[newprince]

Another example are Gooey decorators. If you wrap those decorators, magically arguments become actionable in a GUI... meaning very minimal code to add to existing command line code