Guys,
I'll be at PyCon and would like to sprint on this. Maybe a tutorial
with code. Anyone?
Carlos de la Guardia
On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough <chr...@plope.com> wrote:
> 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.
>
>
--
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.
