On 11/07/2010 02:33 PM, Mike Orr wrote:
> On Sun, Nov 7, 2010 at 9:28 AM, Ev Kontsevoy <[email protected]> wrote:
>> I wanted Pylons to
>> follow Rails, i.e. be more opinionated, offer more powerful routes,
>> require eve less code for typical CRUD, have powerful default RESTful
>> routes and controller/view defaults, etc...
> After years of requests for alternate APIs by users, and a few users
> subclassing PylonsApp, and our own discovered needs as we built apps,
> we generally came to the conclusion that Pylons was a bit too rigid.
> Just a bit, mind you. We can still keep the opinionated vision in the
> docs, while providing more hooks in Pylons for alternatives. Pyramid
> adds those hooks. Those mandatory dependencies (FormEncode,
> WebHelpers) are a nuisance if you're not using them, and a practical
> problem in space-challenged deployments (Google App Engine).
>
> The framework you want can be built on top of Pyramid. Maybe
> TurboGears 3 will be it , or maybe a new framework. If Pyramid has
> inefficiencies (excess overhead), this may be a problem. But first we
> have to identify what the overhead is and whether it actually exists.
> Unused ZCML parsers and threadlocal modules are insignificant in this
> regard. If they are always active and draining CPU cycles and
> burgeoning call-stack levels, then we can address those problems
> directly.
>
> (Note: the BFG/Zope dependencies are of course numerous compared to
> Pylons, and that will be an intrinsic issue for space-challenged
> deployments. But most users are not running on platforms where it
> matters. I also mentioned Pylons' unexpectedly-high memory usage, and
> how it does best on 1 GB servers. I don't know how Pyramid compares in
> this regard, whether it's more frugal or prodigal. That's another
> issue to focus on someday.)
>
> BTW, there is an ambiguity between Pyramid the meta-framework, and
> Pyramid the top-level framework (Pylons style or BFG style). I wish
> these had remained distinct in the branding, with the meta-framework
> under one name and in a separate package, and the top-level framework
> with its own name. But others felt differently about this, that
> Pyramid should simultaneously be a complete Pylons-style framework,
> and a meta-framework (like Paste). That it would be easier to market a
> single framework than a dichotomy.
Since this discussion seems to be presupposing the general collaboration
plan Pylons and TurboGears had a while back where Pylons would be the
"lower-level" or basic framework and TurboGears would be the "Full
Stack" framework with sensible/opinionated defaults, this whole
discussion is making me think it might be a good idea to make the front
page of the final website for Pyramids present something like this:
3 buttons:
1. Get "Bare Metal" Pyramids ( => Pylons) | 2. Get "Full Stack"
Pyramids ( => TurboGears)
3. Or get other Pyramids mixes/distributions ( =>
third-party/community frameworks based on Pyramids)
Or make the Pyramids site say:
Get Pyramids | Need more? Get TurboGears
And make the TurboGears site say:
Get TurboGears | Need less? Get Pyramids
It seems to me this sort of clear set of recommended options for which
framework to choose would help answer concerns like Ev's above from the
outset.
Tim
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
