On 3/3/11 10:59 AM, 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.
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).
This is confusing to me. There is no single "repoze" thing. "repoze"
is basically a brand name; it's a namespace package used for a
collection of useful things developed mostly by Agendaless Consulting.
Pyramid itself used to be "repoze.bfg". There's no monolithic "repoze"
thing that is being depended on.
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.
Pyramid is explicitly NOT making these decisions for you. That's what
is meant when it's said that Pyramid is trying to be a relatively
"unopinionated" framework. This is much less beginner-friendly than
Django, nobody is denying that. But for some of us who are not
beginners, we prefer being given choices, and choosing from available
packages, rather than dealing w/ choices that the framework made that
might not actually match what we really want.
Eventually the hope is that there will be a more opinionated framework
on top of Pyramid. This is one that would potentially compete with
Django, one that would try to make the "out-of-the-box" experience much
more complete. Pyramid is not that framework, and never intends to be.
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.
As I said, Pyramid is explicitly not trying to create an "it works great
out of the box" experience. Not in the same way that Django and Rails
are, anyway. It DOES work great out of the box for what it's trying to
do, which is give developers a great deal of efficiency and flexibility
in routing HTTP requests to callable code. If you want more "rails" to
help you, Pyramid is not the best choice.
As for feeling shoe-horned into zope/repoze land... I'm at a loss. Use
of "zope" technologies is fairly minimal, and is entirely an
implementation detail internal to Pyramid. You don't have to know
anything about "zope" in order to use Pyramid. You're definitely not
forced to use (or even understand) these idioms in order to build web
apps w/ Pyramid.
Pyramid is missing the feel of a "Consistent approach to X." where X
pretty much any existing pluggable feature.
Again, this is explicitly the opposite of Pyramid's intent.
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.
These desires are at cross-purposes, IMO. The more "internally
consistent" your core features are, the less flexibly will you be able
to plug alternates in. Alternate implementations of core technology
often end up working very differently from each other, and what
originally looked like internal consistency ends up looking like "I
can't do what I want to."
In Django, for instance, it's technically possible to use an alternate
ORM. When you do, you lose a lot of the other things that make Django
valuable, though, and most Django users aren't willing to give up the
other features. Pyramid goes the other route; there are clean APIs for
plugging in alternate (template engine, persistence engine, security
policy, etc. etc. etc.), but there is no pretense of a complete stack
that is the default.
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.
I'd say that Pyramid is *using* (rather than "bending to the whims of")
lots of battle-hardened, pre-existing technology so it wouldn't have to
reinvent the wheel a million times. And the answer to the question
"what's the right thing here?" is an opinion. Once again, Pyramid is
explicitly trying to not be opinionated. It doesn't always succeed...
Pyramid definitely does have a few opinions, but it has many fewer than
Django or Rails. If you want opinions, and you want choices to be made
for you, Pyramid is probably the wrong framework to use.
-r
Steve "s(he)" Lacy
On Thu, Mar 3, 2011 at 10:47 AM, Joe Dallago <jd.dall...@gmail.com
<mailto: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
<mailto: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 <mailto: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 <mailto:pylons-devel@googlegroups.com>.
>> To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com
<mailto:pylons-devel%2bunsubscr...@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
<mailto:pylons-devel@googlegroups.com>.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com
<mailto:pylons-devel%2bunsubscr...@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.
