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.
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.
