Yeah, but encapsulation (a well-written API) and dependencies are totally orthogonal.
One could write a dependency-less framework that provided sensible, minimal, yet functional components, and *still* provided a really clean API and way for developers to hook in external implementations. Lines like "Pyramid only depends on 84 lines of repoze" make me think: "Okay, just pull in those 84 lines and ditch the dependency". But, the story isn't actually that simple, of course. (because repoze is the recommended default for tons of other stuff like auth/auth). I think Pyramid misses the mark providing a functional framework out of the box. In particular, the specifics around sessions and auth/auth. As a developer, you can't make a "real site" without good versions of both of these, and Pyramid only provides options and suggestions, not a solution here. I agree that learning outside modules is good practice, and can help you with other projects, but what most developers want is "it works great out of the box, and I don't get stuck later on". I think Pyramid has the latter but not the former. Pyramid makes me feel shoe-horned into zope/repoze land. IUser, ISession, etc. Pyramid is missing the feel of a "Consistent approach to X." where X pretty much any existing pluggable feature. What I'd like to see from a framework is good, internally consistent implementations of core features, and a nice clean API to plug alternates in. I feel like Pyramid is bending to the whims of outside implementations (zope, repoze, WebOb, etc) and providing APIs to match those, instead of going down the route of "what's the right thing here". This development approach is clear from the design defense document. Steve "s(he)" Lacy On Thu, Mar 3, 2011 at 10:47 AM, Joe Dallago <jd.dall...@gmail.com> wrote: > Essentially what I am giving is a real world example of the concept of > encapsulation, which is something that every programmer should value.* > > On Thu, Mar 3, 2011 at 12:43 PM, Joe Dallago <jd.dall...@gmail.com> wrote: > > I just thought that I would chime in and say that the > > "dependency-heavy" model that Pyramid uses is not a new one. Look at > > Linux, arguably the largest open source project in existence right > > now, it is hard to find a package that doesn't have 10 dependencies. > > Linux does this b/c it is efficient, and it means that code doesn't > > have to be duplicated. It is also important to note that it is also > > the model that Python excels at(easy imports, packages and module > > organization is easy, etc.). > > > > The dependency-heavy model actually makes learning more efficient in > > the long term as well, b/c if one module fails, then you don't have to > > ditch the whole system. For example(this example is somewhat from my > > experience with the cakephp framework), lets say you reach a point in > > an application where the framework itself is limiting your progress. > > Let's say that you need row-level permissions and the default auth > > helper doesn't do this. If the entire framework is tied together, > > then you would have to deal with either having to manipulate some of > > the source code(which could possibly be changed in future updates) or > > scrap the whole thing. With Pyramid, a failure in a specific module > > simply means you ditch that ONE module and sub in another. It is also > > important to note that if Pyramid itself becomes obsolete in 5-10 > > years, as Pylons did, then at least you can carry over your knowledge > > of SQLAlchemy, paster, deform, etc. to the next framework. > > Essentially what I giving a world world example of the concept of > > encapsulation, that is something that every programmer should value. > > > > On Thu, Mar 3, 2011 at 12:24 PM, Chris McDonough <chr...@plope.com> > wrote: > >> On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: > >>> Okay, chiming in here. :) Yeah, this is my post. I've been pretty > >>> quiet here. > >>> > >>> Sorry for the somewhat negative tone, as you can imagine, the post was > >>> written after spending several hours digging through a very large > >>> amount of the Pyramid source code trying to figure out the answer to > >>> what seemed to be a very simple question. Yes, I could have asked > >>> here, or on #pylons, and maybe I should have. But, at the same time, > >>> I think that "read and understand the source" is an important aspect > >>> of a good framework, and that's what I was most frustrated about. > >> > >> We've all been there, no worries. > >> > >> - C > >> > >> > >> > >> -- > >> 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.
