Front page highlights:

...

"Must be usable and practical" is the key design principle for Pythomnic. It is what the actual developer does which is important, and life's too short to fight the language or development platform. Pythomnic provides the environment and hides tedious details, but does not get in the developer's way. No paradigms to learn, no need to shape your code in any unusual way. "This is where you write your stuff" is all the developer needs to know.

Putting objects to stable storage is easy, you don't need a separate database or an ORM to do that. Pythomnic has a simple storage facility to store any Python object so that it survives between separate requests or service restart. This "safe" facility uses BerkeleyDB embedded database which is fast and reliable.

Pythomnic supports PostgreSQL, MSSQL, MySQL and Oracle. But then they are but one class of external systems which Pythomnic can utilize. In the course of request processing your application will typically access several different systems, which could also be messaging servers such as JMS, SMPP or SMTP or application servers such as LDAP. Access to all external systems is provided in a uniform way.

If you need a single server to process a hundred simultaneous requests or few hundred requests per second, look somewhere else. To simplify things, Pythomnic uses threads and allocates a thread per request for the entire duration of its processing. Although Pythomnic tries to compensate by pooling worker threads and network service are frequently I/O bound, Python is still not a thread-friendly language. In practice this is rarely a limitation, because the typical request rate is not so high, the external systems saturate before, and you can always resort to horizontal scalability.