skip to navigation
skip to content

picoweb 0.5.1

A very lightweight, memory-efficient async web framework for and its asyncio_micro.

Latest Version: 1.0

picoweb is "micro" web micro-framework (thus, "pico-framework") for radically
unbloated web applications using radically unbloated Python implementation,
MicroPython, .


* Asynchronous from the start, using unbloated asyncio-like library
* Modest memory usage (I would say radically small memory usage, but
so far, trivial web app requires 64K (yes, kilobytes) of heap, which
is much more than I expected).
* Has API affinity with well-known Python web micro-framework(s),
thus it should be easy start if you have experience with that, and
existing applications can be potentially ported, instead of requiring
complete rewrite.

picoweb depends on:

* asyncio_micro for asynchronous networking
* utemplate, for templating
* uorm, for database access (optional, no direct dependency)

picoweb API is roughly based on APIs of other well-known Python web
frameworks. The strongest affinity is Flask,, as
arguably the most popular micro-framework. Some features are also based on
Bottle and Django. Note that this does not mean particular "compatibility"
with Flask, Bottle, or Django: most existing web frameworks are synchronous
(and threaded), while picoweb is async framework, so its architecture is
quite different. However, there an aim to save porting efforts from
repeatitive search & replace trials, in other words, when methods do similar
things, they are likely named the same (but they may take slightly different
parameters, return different values, and behave slightly differently).

The biggest difference is async, non-threaded nature of picoweb. That means
that the same code may handle multiple requests at the same time, but unlike
threaded environment, there's no external context (like thread and thread
local storage) to associate with each request. Thus, there're no "global"
(or thread-local "global") request and response objects, like Flask,
Bottle, Django have. Instead, all picoweb functions explicitly pass current
request and response around.

Also, picoweb, being unbloated framework, tries to avoid avoidable
abstractions. For example, HTTP at the lowest level has just read and write
endpoints of a socket. To dispatch request, picoweb needs to pre-parse
some request data from input stream, and it saves that partially (sic!)
parsed data as "request" object, and that's what passed to application
handlers. However, there's no unavoidable need to have "response"
abstraction - the most efficient/lightweight application may want to
just write raw HTTP status line, headers, and body to the socket. Thus,
raw write stream is passed to application handlers. (But high-level
convenience functions to create an HTTP response are provided).

Last point is questionable conveniences. For example, both Flask and Bottle
provide special objects to handle form/get parameters, with features
like "if request variable has only one value, the value is returned directly;
otherwise, list of values is returned". However, Python standard library
provides function parse_qs(), which always returns array of values (based
on the fact that any request variable may have more than one value). Given
2 choices, picoweb follows the interface of standard library, instead of
providing extra wrapper class on top of it.
File Type Py Version Uploaded on Size
picoweb-0.5.1.tar.gz (md5) Source 2014-07-20 4KB