On Fri, Nov 5, 2010 at 8:05 AM, Graham Higgins <gjhigg...@googlemail.com> wrote: > Kevin J Smith wrote: >> From >> the page on pyramids it seems to suggest that pylons post 1.0 will be using >> pyramids? If so, statements like "no controllers" kind of frighten me ... >> and quite frankly most things that are Zope related frighten me. >> >> Anybody care to clarify? > > Steady the Buffs, Kevin --- and any other Pylons users who might currently > be going "Whoa?! WTF?".
Chris McDonough wrote: > The word "Zope" is meaningless without qualification. What *part* of Zope do > you hate? > It's pretty hard to defend Pyramid against charges that won't be disclosed. Less confrontation, Chris, please. Pylons users are legitimately concerned about any sudden changes in the API, abandonment of previously-supported versions, and over-Zopeification. Also, Pyramid is being introduced to them in a haphazard way, rather than an announcement and discussion before the fact as TurboGears had [1] and presumably BFG had. So people are rightly concerned about where Pylons is headed, and asking for more details. [1]: http://groups.google.com/group/turbogears/browse_thread/thread/47779d8587721037?pli=1 The merger/rebanding is very recent -- like a week ago. Graham and I first heard about it four days ago. That's why not all of the pieces are in place yet. The reason for concerns like Kevin's is historical. I (and several WSGI developers) left Zope in 2000 because it was a huge monolith, and the documentation was geared toward content creators rather than Python developers. Zope has since fixed many of these shortcomings: improving the developer documentation, splitting the code into multiple packages, and spawning Repoze and BFG and Grok. But ZCML, component architecture, and interfaces still strike fear into many hearts. And Zope's greatest accomplishment -- Plone -- is still tied to Zope 2, and is still more monolithic than many here would like. The fears about Pylons are legitimate and need to be addressed. We just need to have a dialog about what exactly is coming from Zope, why it won't destroy Pylons, and what its benefits are. The other concern is abandonment of previous versions. Many people were not happy with the move from TurboGears 1 to TurboGears 2. They complained that the TG book was published right when its developers were starting to move away from that paradigm, and that the window between TG1 and TG2 was unusually short by framework standards. This forced people to invest in TG1 and then immediately rewrite their apps for TG2, or stick with TG1 which was now less-supported than they had been expecting. So people are rightly concerned that Pylons mustn't do that. Still, the state of the art evolves quickly, so some change is inevitable. My message to Pylons users is: the developers share your concerns. We asked the same questions of Chris when we were first considering BFG and a component architecture. We hate XML just as much as you do. We asked, "What would a component architecture gain us? Are there any alternative non-Zope implementations? Are these pieces separable from the rest of Zope? How much Zope is enough and how much is too much?" It turns out that that the Zope developers were smart to see the benefits of components/interfaces early on, and they were willing to split that out for the rest of us, just as they had earlier split out ZODB. There is no alternative Python package for this that has been as well tested over several years, especially in a web-framework environment. When Chris first explained the XML-based configurator, our first comment was, "That will be unacceptable to Pylons users." So he made a flexible configuration backend, envisioning multiple configuration styles (XML, Python, INI, etc). Only the XML and Python styles have been pursued. (The Paste INI file is not directly related to this. The upshot for Pylons users is a Python module equivalent to environment/middleware/routing.py .) > FACT: Pylons 1.0 is not being killed off in any way, shape or form. Your > apps will continue to work and Pylons 1.0 will continue to be supported for > the foreseeable future, And anyone is free to help with maintenance or take on feature enhancements -- with Ben's approval. But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies. "@validate" needs a replacement; that's the only thing I can think of. > Ben recently discovered an > architectural design flaw in Pylons [1]. The problem orients around the > chosen strategy of implementing individual app extensibility by allowing > subclassing of the WSGIController. > > Ben says that Bob Brewer (of CherryPy fame) warned him about it at the start > of Pylons but back four years ago Ben was young, carefree and thought little > of it --- I'm paraphrasing, you understand :-) What is the flaw? The footnote seems to have been omitted. > Architecturally, BFG is conceptually > very similar to Pylons. Chris looked very carefully at Pylons when he > created BFG and if you read through his blog posts, you'll find a posting > titled "Tips for greenlighting a framework" in which you'll find: "Requiring > that a user subclass a framework-defined class is almost always the wrong > answer" [2]. Another missing footnote. > Demonstrating a total lack of Zopish dogmatism, Chris has been Well put. :) > There's /explicitly-planned/ space in Pyramid to support the TG community's > "full-stack" style too, should the community fancy jumping on board. There has also been a dialog with the Django developers the past two years, mostly covering basic WSGI issues and a potential common request/response object (WebOb). The door is always open if they'd like greater collaboration, or to port Django to Pyramid the way TG was ported to Pylons. It hasn't gone very far because Django famously prefers homegrown code, but we aim to keep the code "Django-ready" by anticipating what hooks they'd likely need for their features. And the same goes for any other type of Python web framework. If it needs new plugin hooks to integrate with Pyramid, we're willing to consider them. But that work seems to be done because most of the full-stack frameworks we've seen fall into a few main categories: CherryPy-like (TG), Pylons-like, Zope-like (only Zope), Twisted-like (only Twisted), Django-like (only Django), and servlet-like (none since WebWare nine years ago). Zope and Twisted are too big and unique to be integrated, and servlet-like has long been abandoned, but we've tried to accommodate the other major API styles -- to give application developers the maximum flexibility and mix-and-match ability that was Pylons' original vision. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
