Currently, all the links in this mail are dead.
Am 19.04.2016 um 00:17 schrieb Alice Bevan–McGregor:
Best Practices Morpheus says: "What if I told you things can get
simpler, more independent, and more testable, with a separation of
concerns in a glorious holy land?"
WebCore is a WSGI nanoframework, a fraction of the size of competing
“microframeworks”, and culmination of more than ten years of web
development experience. It provides a clean API for standard points of
extension while strongly encouraging model, view, controller
separation. Being less than 400 source lines of code (SLoC of
`web.core`; excludes comments and documentation) and containing more
comments and lines of documentation than lines of code, WebCore is
built to be insanely easy to test, adapt, and use, allowing any
developer familiar with programming (not just Python programming) to
be able to read and understand the entirety of the framework in an
* Pypi Package: http://s.webcore.io/fjYp
* Annotated Source Documentation: http://s.webcore.io/fja7
* Source Repository: http://s.webcore.io/fjVF
* Compatible with: Python 2.7+, Python 3.2+, Pypy, Pypy3
* Dependencies: WebOb, marrow.package
* 100% test coverage.
* Digitally signed release artifacts and commits.
WebCore adds a light-weight dependency-graphed extension layer to
WSGI, offering points of extension which replace WSGI middleware, as
well as callbacks difficult to implement in bare WSGI, while also
supporting standard WSGI middleware both as an application and when
treating WebCore as middleware itself. As the #1 thing a typical
framework is responsible for is to resolve a URL to a controller to
handle the request, this process has been standardized under a
"dispatch protocol" (http://s.webcore.io/fjRy) which WebCore speaks.
The Marrow Open Source Collective provide several framework-agnostic
reference implementations covering regular expression-based routes,
object dispatch (attribute descent), and traversal (mapping descent),
as well as more abstract "meta-dispatchers" and "dispatch middleware".
from web.core import Application
The rest is up to you, the developer. WebCore is as opinionated as a
A request comes in, hits the WebCore WSGI Application or outermost
WSGI middleware layer, dispatch resolves an "endpoint", the endpoint
is executed if callable, and the return value (or endpoint if not
callable) is used to find a view which populates the response. The
example above relies on the fact that there is a default view to
Namespaces, virtual dependencies (extras_require) and standard Python
entry_points plugin registration are extensively utilized by the
framework. You may place your own packages within the `web`,
`web.app`, `web.ext`, `web.server`, etc. namespaces if desired.
WebCore is also "optimization aware" and will eliminate several
expensive validation tests and all debug-level logging from production
environments when run with -O or with PYTHONOPTIMIZE set. WebCore was
designed to make use of under-utilized WSGI features such as chunked
streaming responses and thus pairs naturally with the template engine
"cinje" (http://s.webcore.io/fjUx) allowing for the ultimate in
responsiveness. Where Django gets 2 generations per second on a 1000
row table test, cinje gets nearly 40,000; see the cinje wiki.
Eliminate boilerplate and enjoy a snappier app today!
Please give WebCore (and cinje!) a try on your next project or
experiment; see the README, many examples, and extensively documented
source code to learn more. You may be pleasantly surprised to discover
you won't miss those monolithic framework features you weren't using.
Join us in #webcore on Freenode IRC if you have any questions or
comments; we'd love to hear from you and will gladly assist users
getting started using the framework or evaluating and integrating
Proudly developed in Montréal with the support of Illico Hodes
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig