On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
<al...@gothcandy.com> wrote:
> 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.
I'll add it to the list. Although I'm hoping to move away from
namespace packages, as Paste as done. They have already caused
practical problems in that you can't install part of a namespace
package as OS packages and part as virtualenv packages. We can't get
away from Zope's namespace package but I think we can avoid it where
it's unnecessary. Nevertheless I'll add Marrow to the list in case it
turns out to be the best meta-framework otherwise.
> * marrow.wsgi.objects (WebOb) request/response/exceptions
These are fully WebOb compatible? WebOb has become essentially the
only multi-framework Request/Response, so I dont' want to interfere
with it becoming a standard. It's easier to program in WebOb than raw
WSGI.
>> - 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.
Does it require an entry point for each templage engine as Buffet
does? That's what we ultimately removed from Pylons because it was a
level of indirection and complexity that wasn't really necessary.
--
Mike Orr <sluggos...@gmail.com>
--
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.
