> Ev, you're being ideological and presumptive. You're placing stylistic
> concerns (XML, Zope) above practicality.
Mike, my background is very heavy on Rails and what I love about
Pylons is that it has been the closest to "Rails in Python" thing we
had. You can call me "too pragmatic" perhaps, but I really wanted to
have an opinionated framework, with "one right way to do it" applied
to everything, including URL-to-code mapping. Rails-3 has brought an
amazing routing mechanism and I simply wanted for Pylons to follow the
lead. I believe that having many options are bad: XML? YAML? Why? Just
make one component (Routes) awesome enough to scratch an itch of 80%
projects with __minimal__ learning/coding effort.
> No previous framework has provided built-in primitives for all the
> programming styles that have emerged among the various post-2005 frameworks
> (traversal vs URL dispatch, "return render" vs decorators, class-based
> controllers vs a tiny function-based app that can fit in one module, etc).
> That was the original goal of Pypes. Pyramid's multiple modes allow almost
> any Python-WSGI framework to be built on top of it, which could provide a new
> level of unification among frameworks.
I understand. The issue is that soon we'll need a "Bible of Pyramid"
to get started using it. If that was the original goal of Pypes/Marco/
Pipefitters it should have been called Pypes or something else, I am
just sad that this thing has eaten my favorite framework :))
> The component architecture allows applications and the framework to be
> extensible in ways that weren't previously possible. Can you at least accept
> the possibility that *maybe* all these developers know something you don't
That possibility is pretty much certainty, no doubt Pyramid is full of
smart designs and the code is neat. It is a certainty, however, that
it's not what I need for my projects hence I can't call it "Pylons 2".
With the release of Rails-3 it has fallen behind in terms of speed of
development and ease of use. Pyramid is substantially lower level, and
seems like its done on purpose because you're suggesting other
frameworks to be built on top of it. But again, I wanted Pylons to
follow Rails, i.e. be more opinionated, offer more powerful routes,
require eve less code for typical CRUD, have powerful default RESTful
routes and controller/view defaults, etc...
> Can you attend PyCon next March in Atlanta? Then we can discuss the
> advantages and disadvantages of Pyramid in person with all the developers
> together. There will surely be Pyramid open spaces and a sprint, and we can
> even have some kind of "Is Pyramid good or bad for Pylons?" open space if
> there's enough interest. Again, your concerns are the same ones the Pylons
> developers raised with ChrisM two years ago. "Ewww, XML! Zope = bloat."
I would love to! Perhaps "Pylons-2" (well, the one I imagine) should/
can be built on top of Pyramid.
> XML is a tool. It's ugly but it can do some things better than other
tools. I'm sure it's possible to create a YAML-based or Python-based
alternative to ZCML, because it all has to be converted to Python
objects in the end. But somebody would have to take that on as a
project.
Perhaps you know something I don't, but XML is a tool for data
exchange between systems written by different vendors. That's pretty
much the only use case I can think of (or ever could). Having the
option of ZCML is really just a dead weight because Python itself is a
much, much better tool to create "Python objects in the end". :)
> The only area where Pylons needed help... FOR YOU. Other people have
> different needs, such as making Pylons apps more nestable, getting away from
> the magic globals, making apps more plugin-friendly.
Let me disagree. I simply observed the fact that dealing with forms
has been the most popular topic to bitch about (in my opinion) on
pylons-discuss, while nobody ever complained about magic globals or
plugins. Also, just to make a dent, I want to vote *for* magic globals
one more time! :) pylons.config and others have been awesome for us,
we learned when not to use it and love it when we can.
> Routes already has this: ``map.resource("cars", "car")``. Ben is currently
> adding all Routes features to Pyramid. He says that this gives the chance to
> greatly simplify (shrink) the code, and to refactor its internal structure
> based on the long-planned "Routes 2" branch. So there will probably be some
> kind of ``config.add_resource_hander`` method for this.
That's great news! Thanks. While Pyramid doesn't seem to be "Rails3
for Python" it is clear to me now that its authors never had such goal
in mind. With that said, I want to thank all of you guys for putting
your brains in time into these projects, there's so many quality
Python components out there, that it's not hard to assemble a very
Rails-like custom setup by hand.
Also, Mike, thanks for spending so much time answering my questions
and addressing my frustrations. This wasn't the first time this group
blows my mind with the quality of posts from regular contributors.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
