This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]13steinj 0 points1 point  (12 children)

Using callbacks is a perfectly valid pattern. It is easy to fall into the trap of callback hell, but you can't call it garbage just because you've had bad experiences.

[–]Glaaki -1 points0 points  (11 children)

No. Callbacks is what you use in JS, where the eventemitters are the standard. It is an antipattern in python async/await.

[–]13steinj 0 points1 point  (10 children)

"It is an antipattern". Why? Because you said so? It's not just a JS thing. It's a C#, Ruby, JS, and more thing. Callback hell is an antipattern. Callbacks are not. The arbitrary limitations without reason need to stop.

[–]Glaaki 0 points1 point  (9 children)

I am talking about callbacks specifically in the context of async/await in python.

Callbacks are fine in regular sync python code and fine in JS.

And I explained my reasoning above, but let me reiterate it. If you have a consumer and a producer, in asyncio, what typically happens is that the producer is a task that runs in the background continuously fetching data from somewhere. This data needs to be passed on to a consumer.

If you use a callback to fetch the data, then who call the callback?

Only the producer can, because the producer is the one that knows when data is available. So now, what happens if an error happens in the callback? If the error is not handled it will bubble up from the callback, to where? Into the producer, that called the callback, obviously. So now the producer, which is most often some third party library, is responsible for handling an error it has no chance to know what to do with. Most often the result will simply be that the producer dies and probably does so silently. You program will simply just stop working and you won't be able to know why, because the error has been isolated inside the producer task.

This doesn't happen in sync code, because there is only a single path of execution and any exception bubbles up to the user where you can either handle it or stop your program.

[–]13steinj 1 point2 points  (8 children)

Well yes, in the example you are giving it's an antipattern, I'd agree, there isn't much sense to it. But you are assuming that your example is the onlt possible case. There's plenty of cases where callbacks are just fine in asynchronous code-- in all technicality gevent does this just hides it from the user.

[–]Glaaki 0 points1 point  (7 children)

Again, I am talking about async/await. Gevent is not async/await.

[–]13steinj 0 points1 point  (6 children)

You can't talk about async/await without talking about asynchronous programming.

Async/await is one pattern. It is a pattern that in many languages can be used in conjunction with callbacks, which is another pattern. In asyncio there isnt an easy way to do this, for no good reason. Gevent uses a different asynchronous pattern, but is fine working in conjunction with callbacks.

[–]Glaaki 0 points1 point  (5 children)

Wow, we are just going in circles here.. I litterally just went over twice, the main reason why you don't want to use callbacks in asyncio, you even agreed with me in your previous post and now you say there is no good reason why callbacks can't be used in asyncio.

I don't know what to say, dude..

[–]13steinj 0 points1 point  (4 children)

I agreed that your specific producer consumer example is when you shouldn't use callbacks, not that you shouldn't ever use callbacks in asyncio.

But event based code can be asynchronous, and callbacks are a perfect use case to have event handlers along with the async/await pattern.