On Thu, 2011-03-03 at 10:59 -0800, Stephen Lacy wrote: > 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.
That's fine, but the support and maintenance requirements become pretty massive. It's a great benefit, for example, to have someone-other-than-us maintaining Chameleon, Mako, and WebOb. If I personally had to maintain those things, they (and their users) would be a lot poorer for it. > Lines like "Pyramid only depends on 84 lines of repoze" make me think: > "Okay, just pull in those 84 lines and ditch the dependency". The LRU code was indeed part of Pyramid at one point. But other packages also depend upon an LRU cache implementation, so pulling it out and sharing this code made sense. > But, the story isn't actually that simple, of course. (because > repoze is the recommended default for tons of other stuff like > auth/auth). Actually it's not. Do you have a link to some documentation that makes this claim? I'd love to remove it if so. > 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. More specifics would be helpful. Do you mean docs-wise? It actually provides very concrete implementations (multiple ones) of each of these things. > 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. I'm going to suggest that learning how to create a Pyramid application by reading the Pyramid source code instead of reading its docs is a bit like learning how to drive by reassembling an engine. Knowing how to reassemble an engine is useful, but on a different level than just driving somewhere. > 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. It sounds like you have very concrete opinions, and that you want to use a framework that provides these and only these opinions. That's fine, and you certainly have your choice of web frameworks, but please know that other folks actually use the features that fall outside of that set of opinions. For example, traversal: I would have exactly zero consulting income (at least if I wanted to use Pyramid) if I didn't have traversal, because most of our actual consulting engagements involve very hierarchical systems with very granular security constraints. Traversal makes this pattern very easy. I hope we've made it possible to ignore traversal, because it certainly doesn't make sense for every (or even most) applications, but its existence isn't for nothing. - C > > > 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. -- 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.
