Howdy!
- Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
This is not just a good idea, it's the slaw; with the ratification of
PEP 3333 there finally exists a standard protocol for Python 3 support.
- Replace Paste, PasteDeploy, and PasteScript with "something".
- "paster create" can be extracted to a new utility, either a
top-level script or a subcommand.
The code could do with some modernization.
- Rename "application templates" to "application skeletons" to avoid
confusion with file templates.
- Possible new names for Paster and its components: glue ("Glue is the
new Paste!"), Create, Serve, karnak.
- Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
code and give better names.
- Replace the INI file with an YAML file?
Marrow is my namespaced meta-framework rewrite of Paste, WebOb, and
other utilities. It includes:
* marrow.blueprint (paster create) agnostic to underlying template
lingua via alacarte, advanced interactive and command-line
interrogation including secure password entry.
* marrow.script (paste script) using Python's powerful introspection features.
* marrow.wsgi.objects (WebOb) request/response/exceptions
* marrow.util (a lot of stuff including 2.6->3.1 forward compatibility)
* marrow.tags (12K page generations per second pure Python templating)
* marrow.server.http (C10K capable fully HTTP/1.1 compliant server)
* marrow.config (paste deploy) YAML-based configuration
The HTTP server would need a little bit of work to get it to speak PEP
3333 and not 444, but the amount of work would be minimal.
A few of these already have released versions, though marrow.config is
mostly just sketched p-code so far.
The requirements for release are:
* Complete documentation.
* Multiple examples.
* 100% unit test coverage.
Only marrow.util doesn't abide by this, though the package is far older
than the others and will be brought up to the above standard within a
few releases.
At PyCon Atlanta 2011 I'll be running a sprint to port TurboMail to
Py3K and work on Marrow — search for Marrow on
http://us.pycon.org/2011/sprints/projects/.
It would likely be worthwhile to cohabitate with the Pyramid sprint as
Marrow doesn't compete, it just offers the underlying portable support
libraries.
- Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
Pyramid. Some of these are more properly dependencies of the specific
applications which are using them.
There exists a package called alacarte which offers a back-end agnostic
templating interface. It already supports Mako, Jinja2, and a handful
of others, including serialization formats like JSON, Bencode, and
YAML. It was built to replace the ancient (and crufty) TurboGears 1
"buffet" API.
— Alice.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
