Personal tools
Skip to content. | Skip to navigation
These provide several pieces of "middleware" (or filters) that can be nested to build web applications. Each piece of middleware uses the WSGI (PEP 333) interface, and should be compatible with other middleware based on those interfaces.
This tool provides code to load WSGI applications and servers from URIs; these URIs can refer to Python Eggs for INI-style configuration files. PasteScript provides commands to serve applications based on this configuration file.
Paster is pluggable command-line frontend, including commands to setup package file layouts Built-in features: * Creating file layouts for packages. For instance a setuptools-ready file layout. * Serving up web applications, with configuration based on paste.deploy
Pattern matching and various utilities for file systems paths.
Paver is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake. What makes Paver unique is its integration with commonly used Python libraries. Common tasks that were easy before remain easy. More importantly, dealing with your applications specific needs and requirements is now much easier. * Build files are just Python * One file with one syntax, pavement.py, knows how to manage your project * File operations are unbelievably easy, thanks to the built-in version of Jason Orendorff’s path.py. * Need to do something that takes 5 lines of code? It’ll only take 5 lines of code.. * Completely encompasses distutils and setuptools so that you can customize behavior as you need to. * Wraps Sphinx for generating documentation, and adds utilities that make it easier to incorporate fully tested sample code. * Wraps Subversion for working with code that is checked out. * Wraps virtualenv to allow you to trivially create a bootstrap script that gets a virtual environment up and running. This is a great way to install packages into a contained environment. * Can use all of these other libraries, but requires none of them * Easily transition from setup.py without making your users learn about or even install Paver! (See the Getting Started Guide for an example).
PEAK-Rules is a highly-extensible framework for creating and using generic functions, from the very simple to the very complex. Out of the box, it supports multiple-dispatch on positional arguments using tuples of types, full predicate dispatch using strings containing Python expressions, and CLOS-like method combining. (But the framework allows you to mix and match dispatch engines and custom method combinations, if you need or want to.)
In any sufficiently-sized application or framework, it's common to end up lumping a lot of different concerns into the same class. For example, you may have business logic, persistence code, and UI all jammed into a single class. Attribute and method names for all sorts of different operations get shoved into a single namespace -- even when using mixin classes. Separating concerns into different objects, however, makes it easier to write reusable and separately-testable components. The AddOns package (``peak.util.addons``) lets you manage concerns using ``AddOn`` classes.
peak.util.assembler is a simple bytecode assembler module that handles most low-level bytecode generation details like jump offsets, stack size tracking, line number table generation, constant and variable name index tracking, etc. That way, you can focus your attention on the desired semantics of your bytecode instead of on these mechanical issues. In addition to a low-level opcode-oriented API for directly generating specific Python bytecodes, this module also offers an extensible mini-AST framework for generating code from high-level specifications. This framework does most of the work needed to transform tree-like structures into linear bytecode instructions, and includes the ability to do compile-time constant folding.
The peak.util.extremes module provides a production-quality implementation of the Min and Max objects from PEP 326. While PEP 326 was rejected for inclusion in the language or standard library, the objects described in it are useful in a variety of applications. In PEAK, they have been used to implement generic functions (in RuleDispatch and PEAK-Rules), as well as to handle scheduling and time operations in the Trellis. Because this has led to each project copying the same code, we've now split the module out so it can be used independently.
SymbolType gives you access to the peak.util.symbols module, previously available only by installing the full PEAK toolkit. peak.util.symbols provides a Symbol type and two built-in symbols that are used by PEAK: NOT_FOUND and NOT_GIVEN.