I'm up too
On Mar 3, 8:09 pm, Carlos de la Guardia <carlos.delaguar...@gmail.com>
wrote:
> 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
> >> > athttp://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
> > athttp://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.
