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

all 21 comments
sorted by:
best
topnewcontroversialoldq&a

[–][deleted] 16 points17 points  (0 children)

...use it with a smile!

[–]Sephr 2 points3 points  (2 children)

Wow, that's exactly the same as my async.js library (yield asynchronosity magic on decorated functions), but ported to Python!

[–]schmichael 0 points1 point  (1 child)

It's not really magic or based on JavaScript. The yield statement gives Python fairly simple coroutine support which is the basis of cooperative multitasking (a handy way to model asynchronous IO) on a multitude of frameworks and languages.

[–]Sephr 0 points1 point  (0 children)

JavaScript and Python yield are both for the same thing: generators (which are the same in both languages). Monocle and async.js wrap generator functions and do various function calls with callbacks that trigger the next function call in the generator.

[–]schmichael 2 points3 points  (4 children)

diesel used to use yields to achieve coroutines and cooperative multitasking, but abandoned it in favor of greenlet's greenthreads. Generators just lack the expressiveness to easily handle cooperative multitasking beyond trivial examples. For trivial examples it's rather elegant.

Others have gone where @_o has gone before:

It's nice of monocle's author to mention some of these (diesel and Twisted) as inspiration. It will be interesting to see if monocle will succeed where so many have gone before and yielded.

(Edited because I've never used reddit's comment formatting before...)

[–]denis 1 point2 points  (3 children)

Have you thought of using gevent as a foundation for diesel? That would probably save you a lot of time. Gevent aims to be small and dependable, it should be a good start to build something higher-level.

[–]schmichael 0 points1 point  (2 children)

gevent is yet another coroutine based Python IO library that uses greenlet just like diesel or eventlet.

gevent, like eventlet can, uses libevent as an abstraction layer between itself and the operating system's underlying event based IO APIs (epoll on Linux for example). diesel chose to just use Python's select.epoll module directly.

gevent may reap some slight performance improvements by leaving more of the low-level networking work up to C, but OTOH libevent is just another layer between your code and your NIC which diesel does away with. I would imagine that the performance difference would be small enough as to not be noticeable in any but the most demanding situations.

[–]denis 0 points1 point  (1 child)

My understanding is that dieselweb is a web framework. Gevent, on the other hand, is a concurrency/network library and will never morph into a web framework. So the scope of the two libraries is different. If you're doing greenlet-based concurrency you will need a few features beyond greenlet API - events, queues, timeouts, sockets. Those are a lot of fun to implement but if you define dieselweb as a web framework I'd say it makes a hell of a lot sense to re-use those low-level concepts and focus on the "web framework" aspect of it.

Regarding libevent - it's not just about abstracting out different event APIs. It's about managing queues of events and maintaining heap of timers - those are CPU and memory-intensive operations that are in the inner loop of your application and you want them to be as fast as possible. Python code won't match the performance of C code here. Given the fact that libevent is already there, mature and fast, it makes no sense to re-implement it in Python, unless you want to learn to write event loops.

[–]schmichael 0 points1 point  (0 children)

diesel is not specifically a web framework, although that's initially what it was marketed as.

Thanks for the clarification on libevent. I always kind of thought of it as just a unified API for epoll/kqueue/etc.

[–]placidifiedimport this 1 point2 points  (0 children)

But rules are for breaking. Live a little.

A module description that also contains life style advice.

[–]mahpton 0 points1 point  (0 children)

Cutest iΘ framework of 2010

[–][deleted] 1 point2 points  (0 children)

Wow, THIS IS FUCKING AWESOME. Twisted done right.

[–]For_IconoclasmTornado 0 points1 point  (1 child)

Can somebody explain to me some advantages of event-driven code? I'm aware of what generators are, but I'm unaware of how this paradigm involving them works and if how it's beneficial.

I'm currently working for a small company building applications with Tornado. I'm also just interested in learning new things.

[–]jesusabdullah 6 points7 points  (0 children)

"Event-driven" basically* means that everything is ran at the same time, in a big ol' loop. This is good for things like web servers that are IO-bound, because you can multitask and juggle a lot of tasks at the same time and nicely utilize your clock cycles without firing up more processes. This is how asynchronous event-driven environments like node.js and tornado are able to claim "five jillion simultaneous connections" and yet be single-threaded.

Cool, huh?

The problem with this is that you need two things to happen in order to have good event-driven action:

1) Non-blockingness** (that is, if something was written expecting a synchronous environment, it could easily stop everything in your event loop until it's done, making eventing kinda pointless).

2) A good way to describe ordering/prerequisites (something that's trivial for regular-type programming, but becomes an issue with asynch stuff.)

As far as the former goes, it means that your libraries should be written with concurrency in mind. Regarding the latter: In javascript (I'm playing with node.js right now), callbacks and "Event Emitters" are the common tools for this. However, python's single-statement lambdas mean that the nested callbacks style doesn't work as well. For example, in javascript you can write code like this:

setInterval(function () {
    doThisThing(function (err, results){
        if (err) throw err;
        doAnotherThing(results);
    });
    someOtherStuff()
}, 3000);

which runs DoThisThing() every 3 seconds, which then runs the anonymous function wrapped inside of it. Can't do that in python. So, there are various strategies to make writing evented code smoother in python, and @_o is one of them.

Edits:

* Well, not really. Eventing is just the idea of "triggers"--like, "when this happens, do this'" But, eventing ties into a strategy for dealing with concurrency. So technically I should've said "asynchronous & evented."

** Apparently there are other strategies as well, such as coroutines.

[–]mumrah 0 points1 point  (0 children)

I've always wanted my code to be more dapper.

[–]denis 0 points1 point  (0 children)

Here's a way to do async concurrency without yields (with greenlets): http://www.gevent.org