On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote:
> So the thing we can carry away from this discussion is that we should
> improve Pyramid's "new user" experience, with tutorials and perhaps
> some defaults for basic functionality.
"We hold these truths to be self evident..."
- C
>
> On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr <sluggos...@gmail.com> wrote:
> > On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com
> > <danjac...@gmail.com> wrote:
> >> I'm not sure the OP is trolling, it comes across as frustration.
> >
> > It's absolutely a legitimate point, and it's what I've been concerned
> > about for the past several months. It's why I'm writing the Pyramid
> > Migration Guide and Akhet (the successor to pyramid_sqla) -- both to
> > be released hopefully by PyCon.
> >
> > Stephan comes from a new user's perspective with a Django background.
> > As such, there will be more users like this, and if we can give them
> > specific documentation and examples addressing their concerns, it will
> > help the "works-out-of-the-box" issue. If we want to attract new
> > users, we must do this. That doesn't mean the Pyramid core developers
> > have to do all the work. It's a great opportunity for add-on products
> > made by others with more time on their hands.
> >
> > The Pyramid manual is essentially a reference guide, so it documents
> > all the alternatives in detail. That's necessary, but it's not the
> > same as a tutorial. And people have such different backgrounds that
> > several focused tutorials would be better than one. I'm writing a
> > migration guide for Pylons users.
> >
> > Stephan's post makes me think a migration guide for Django users would
> > be helpful. I don't know enough about Django to write this myself.
> > Obviously we can't write guides for every single framework, but
> > "Pylons" covers a variety of WSGI developers who know something about
> > Pylons, and "Django" covers another large set that's unique enough to
> > require its own guide. Zope/BFG people seem to find the Pyramid manual
> > sufficient, so that's covered.
> >
> > The answers to Stephan's concerns fall into roughly three categories:
> > - Intentional design decisions; i.e., goals for Pyramid.
> > - Tradeoffs we had to make given those decisions.
> > - The historical legacy of BFG, and the desire not to break backward
> > compatibility.
> >
> > Pyramid's design is heavily shaped by things that Pylons/TurboGears
> > didn't have and their developers wanted. BFG did have these so we took
> > them, and along came everything else BFG had. Things that Pylons
> > specifically wanted were: events, a complete reference manual,
> > eliminating the magic globals [1], better unit testing (which
> > views-returning-a-dict provides), interfaces, a larger developer-base,
> > and maybe other things I'm forgetting. Traversal, ZODB, and built-in
> > auth that's simpler than repoze.who/what were minor desires that
> > essentially came for free.
> >
> > [1] Pyramid threadlocals are similar to Pylons magic globals, but the
> > rest of the framework has been designed not to require them (the
> > threadlocals).
> >
> > The BFG developers make a compelling case that traversal and
> > interfaces are useful, especially for certain kinds of applications.
> > That having these available is a good thing, even for those who don't
> > use them, because it provides a migration path to use them later if
> > they become important someday.
> >
> > Traversal is particularly suited to CMS sites where editor-users can
> > attach a page to any URL, arbitrarily nested. Routes doesn't do this;
> > Routes depends on path variables being in fixed URL positions.
> >
> > Interfaces I only understand superficially, but I have a gut feeling
> > they will be more widely used as more people get comfortable with
> > them. Previously interfaces were available only in Zope and BFG. Zope
> > is a very specialized environment, BFG somewhat less so, but Pyramid
> > makes interfaces accessible to the masses (i.e., general Python-web
> > developers).
> >
> > Pyramid and WebHelpers have borrowed some features from Django, but
> > certain aspects of Django are decidedly non-features in
> > Pyramid/Pylons/TurboGears, and have been for five years. The Pylons
> > Project believes in using third-party packages whenever feasable, and
> > in spinning off packages that can be used outside the frameworks. Of
> > course there are disadvantages to this as well as advantages. If a
> > third-party library becomes unmaintained or has version skew (i.e.,
> > its latest version has incompatible changes), it adversely affects the
> > framework until we reconcile the two or switch to another library.
> > Likewise, sometimes the framework needs to switch to a better library,
> > and users have to adjust their applications. But overall we're glad
> > that users and framework developers can switch libraries as they see
> > fit, and that we can use the latest gee-whiz library as soon as it's
> > available.
> >
> > The other main non-feature of Django is the tight binding between the
> > ORM and the rest of the framework. That may work well for some Django
> > applications, but it's just not something the Pylons Project believes
> > in.
> >
> > The complexity of the Pyramid source is another issue. You're right
> > that interfaces make the source more complex, and it's especially
> > difficult for those who aren't accustomed to Python interfaces. ("I
> > can't keep track of Session vs ISession, or Settings vs
> > ISomethingWithACompletelyDifferentName.") But that's a tradeoff we had
> > to accept. One thing I remember fondly about Quixote is that I could
> > read the entire printed source in half an hour and understand it. But
> > eventually I realized that Quixote just didn't have certain features I
> > needed, and I switched to Pylons.
> >
> > Re auth, there is some ambiguity because some people are recommending
> > the built-in auth while others are using repoze.who/what. Generally,
> > the built-in auth is simpler, and not being middleware makes it more
> > straightforward. But repoze.who has more authentication mechanisms
> > out of the box. Eventually there will be patterns for combining the
> > two, or a simpler successor to repoze.who that's aware of the built-in
> > auth will emerge.
> >
> > The Pyramid manual and the migration guide are necessarily geared
> > toward the majority users who come from a BFG or Pylons background.
> > Those users are comfortable with Paste and have been using it for five
> > years, so that's what the standard application templates recommend.
> > There have been calls over the years to replace Paster, but no clear
> > idea on what to replace it with, or assurance that anything else would
> > be sufficiently better. Paste's creator, Ian Bicking, has been
> > spinning off packages out of Paste (WebOb, WebError), and expects that
> > eventually all of Paste will be spun off or left to die. But there has
> > been little effort to replace PasteDeploy or PasteScript because they
> > basically work.
> >
> > --
> > 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.
> >
> >
>
--
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.
