Asynchronously Prototyping

There are plenty of predefined Python executables, symlinks, and aliases that come bundled with your operating system. These commands come in very handy because it saves you from typing out long commands or chain of scripts. However the downfall of operating system aliases is that they don’t always play nice with virtualenv (or venv if you’re on Python 3). Most predefined aliases use the system’s default Python as the interpreter, which is next to useless when your application runs in a virtual environment. Over the years, I’ve come up with my own Python aliases that play nice with virtual environments. For this post, I tried to stay as generic as possible such that any alias here can be used by every Pythonista. In other words, there will be no aliases for specific frameworks such as running a Django server or starting a Scrappy spider. The following is one of my bash scripts I source: .py-aliases #----- Pip -----# alias pip-list="pip freeze | less" alias pip-search

Expanding Your App Subroutes Let’s start with a simple way to combine routes that share a common endpoint. For example, lets say we need routes for /base/first , /base/second , /base/third . The crude way of achieving this would be to explicitly write out each route with the /base route, like so: app . route( '/base/first' ) def first (request): # ... app . route( '/base/second' ) def second (request): # ... app . route( '/base/third' ) def third (request): # ... This is valid code, but there’s simpler syntax that can help reduce some common human errors like misspellings. The subroute function helps make the code more legible as well as simpler. with app . subroute( '/base' ) as sub: @sub.route ( '/first' ) def first (request): return 'first' @sub.route ( '/second' ) def second (request): return 'second' @sub.route ( '/t

Request Parameter: What is it and why is it passed in? You may have noticed the request argument which gets passed into every route function.  This variable is a Request object and serves a very important purpose of holding valuable request information.  Request objects have an abundance of functionality in them, which would be tedious to convey in such a short tutorial.  Some concepts, such as usage of Deferred and callbacks, are formally introduced in other posts. Write to the Frontend Content can slowly be added to the frontend using the Request.write() function.  Please note that the parameter must be a bytes type, Python 2.7 users don't have to worry as strings are bytes, however in Python 3, a string is NOT a bytes object. @app.route ( '/write' ) def gradualWrite (request): request . write(b '<h1>Header</h1>' ) request . write(b '<h2>Header</h2>' ) request . write(b '<h3>Header<

Non-Blocking Recipes Do you like expressjs , but don’t want to switch to Node.js? Want non-blocking execution in Python? Then look no further! Asynchronous execution is the very essence of what makes Klein a contender in todays web framework landscape. It’s also the most difficult concept to grasp since most Pythonistas are not accustomed to asynchronous programming. Hopefully with the addition asyncio to Python’s standard library, this will change. Klein is built atop Twisted and developers can expose Deferred objects for asynchronous behavior. A very brief overview will be given on Twisted Deferred , afterwards aspiring developers are encouraged to read the Twisted documents on the subject (provided in the links near the bottom). Deferred Overview To demonstrate how Deferred objects work, we will create a chain of callback functions that execute after a result is available. Don’t worry if this confuses you right now, the code will clear things up. from __future_

twisted.enterprise.adbapi Twisted, and subsequently Klein, allows asynchronous interaction with databases using blocking/sequential interfaces using adbapi . The only caveat is that the database interface must be DBAPI 2.0 compliant. For instance, if a PostgreSQL database needs to be accessed, then a typical interaction would be something like: import psycopg2 connection = psycopg2 . connect(database = 'Tutorial' , user = 'admin' , host = '10.10.10.10' ) cursor = connection . cursor() cursor . execute( "CREATE TABLE test (id serial PRIMARY KEY, num integer, data varchar);" ) cursor . execute( "INSERT INTO test (num, data) VALUES (%s, %s)" , ( 100 , "mydata" )) cursor . execute( "SELECT * FROM test;" ) connection . commit() cursor . close() connection . close() Depending on environment settings, connecting to the database server, inserting data, or even querying for records can take an unpr

Basics: Routes, Methods, Variables This section contains many similarities with Flask .  So if you know how to perform basic Flask-style routing, this section can be skipped.  Just keep in mind that a request parameter must be passed in all route functions.  Example::       app. route('/')    def example( request ):        #... Web frameworks have come a long way, especially in Python.  A major contributing factor is the dead simple routing syntax from Flask , Bottle , Hug , etc.  Klein shares syntactical similarities with those frameworks for the most part.  The only key difference is the request parameter that gets passed into the functions after specifying the route.  However we won't worry about that for now.  Let’s dive into Klein with a simple Hello World application. Routes *aka* Hello World helloworld.py from klein import Klein app = Klein() @app.route ( '/' ) def root (request): return 'Welcome' @app.route ( &