On Nov 1, 4:47 pm, Alice Bevan-McGregor <[email protected]> wrote: > Chris convinced me at last year’s ConFoo that I should re-join the TurboGears > community, voice my opinions, and try to help out. Unfortunately I no longer > feel comfortable camping here, as my role as direct competitor (aka “The > Enemy™”) gives me a not-so-minor conflict of interest. Additionally, the > pervasive belief in the “not invented here” mentality blinds people to the > reasoning behind some of my decisions and ensures I get very little respect. > > There has been some great discussion in the last few days about perceived > issues, future possibilities, re-inventing the wheel, community, and joining > forces. Unfortunately what I’m seeing so far is a repetition of the 1.x → > 2.x migration. A significant problem with “best of breed” is the criteria. > Too often in the past I have seen things jumped on too hastily and three > months later seen the regret. > > > One package (pyramid) will fill the base-microframework role > > 30KLoC in 149 modules a microframework does not make. Especially when it > re-implements template engine adaptors (alacarte), session handling (Beaker), > configuration file parsing (PasteDeploy), thread locals (Paste), has a large > amount of authentication/authorization code to adapt repoze.{who,what} (a > package I recall people saying was a mistake to make required for TG2.0), > object dispatch (crank), regex-based routing (Routes), static file serving > (Paste), etc. The majority of these are modules contained within one package > and thoroughly blended.
Let's try to get some perspective on that whirlwind. I'm not writing this to convince anyone that TG should use Pyramid (that's a decision best left to y'all), but I do have to respond to the above because almost all of it is just not true. I had really hoped to not have to do this, it's a huge time sink. With respect to "30KLoC": [chr...@thinko pyramid]$ pwd /home/chrism/projects/pyramid [chr...@thinko pyramid]$ cd pyramid [chr...@thinko pyramid]$ sloccount . ... output snipped ... SLOC Directory SLOC-by-Language (Sorted) 13830 tests python=13830 5096 top_dir python=5096 170 fixers python=170 156 paster_templates python=156 40 compat python=40 20 personality python=20 0 includes (none) Totals grouped by language (dominant language first): python: 19312 (100.00%) Total Physical Source Lines of Code (SLOC) = 19,312 Development Effort Estimate, Person-Years (Person-Months) = 4.48 (53.74) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.95 (11.36) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 4.73 Total Estimated Cost to Develop = $ 605,007 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as "generated using David A. Wheeler's 'SLOCCount'." The output line to pay attention to is: 5096 top_dir python=5096 That's 5000 lines of code that has a chance to be executed at runtime. The *rest* of the code is: - Tests. - Paster templates. - Tutorial code in documentation. Note another thing, please. There are *13KLoC* of tests. That's 2.6 lines of test code for each line of code that has a chance of running when your application is running. I hope to not be punished for this. See also http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-is-too-big "Reimplements template engine adapters"... alacarte.. first time I've ever heard of it. It appears to have been created in September of 2009. The template abstraction code in Pyramid has been around since August of 2008. It's also reasonably well documented: http://docs.pylonshq.com/pyramid/dev/narr/views.html#adding-a-new-renderer "Reinvents thread locals"... have you ever *seen* the Paste StackedObjectProxy code? This is what replaces it in Pyramid: http://github.com/Pylons/pyramid/blob/master/pyramid/threadlocal.py Not rocket science. Not that there *should* be any thread locals to start with, but that's a different thing. Certainly, at least, the idea that you don't *import* a thread local has merit. Session handling... we dont replace Beaker, we allow people to *use* it: http://github.com/Pylons/pyramid_beaker .. we also have a very basic implementation that doesn't require Beaker, and we allow alternate implementations: http://docs.pylonshq.com/pyramid/dev/narr/sessions.html#creating-your-own-session-factory Configuration file parsing.. gotta leave this one to http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-uses-zcml-zcml-is-xml-and-i-don-t-like-xml Large amount of code to adapt r.who/r.what.. no.. it doesn't require r.who or r.what at all. See the red "Warning" box near the top of http://docs.repoze.org/bfg/1.3/narr/security.html (which i actually removed from the Pyramid docs because I couldn't imagine someone seriously making this assertion anymore). Pyramid has its own authorization policy and authentication policy plugpoints: see http://docs.pylonshq.com/pyramid/dev/narr/security.html for an overview. Object dispatch.. Crank wasn't released until early 2010. Pyramid's dispatch (written first in 2008) is based on Zope's, which has been around since 1998. The traversal is pluggable, though. I've actually even helped try to make TG-style dispatch work on top of BFG (Pyramid's predecessor): http://svn.repoze.org/repoze.bfg.metatg/trunk/README.txt Replacing Routes: Ben Bangert, the author of Routes, has signed on to Pyramid's implementation. BFG actually *used* Routes for some time, but didn't need most of its functionality. The routes code was very large, and it was replaced by less than 4K of code in BFG (now Pyramid). Static file serving.. Pyramid actually *does* use the Paste static file application. > All of this needs testing and documentation, all of which would be more > useful as reusable, and more importantly, optional components. Most are > already available as reusable components. From the standpoint of a template > engine developer I have to write adapters for two widget systems, at least > one framework (probably more), and still have my own API to deal with. As a > framework user, if I want to use a templating engine that’s new -I- have to > write the adapters. The duplication of work is horrendous. As far as documentation, I know http://docs.pylonshq.com/pyramid/dev/index.html isn't perfect, but good lord, it's 600+ pages printed in PDF format. *Nothing* is undocumented. Even the add-ons have similar docs. I'm unclear as to what more could be done. As far as templating system add ons: - http://github.com/Pylons/pyramid_jinja2 (see also http://docs.pylonshq.com/pyramid_jinja2/dev/index.html) That's an example of what it takes to add new templating system bindings. Seems pretty straightforward to me. Pyramid supports Mako and Chameleon ZPT/text templates out of the box, Jinja2 with the extension above, and I plan to write at least one more for Genshi. > > It’s one thing to decide that a Django-inspired framework design (everything > and the kitchen sink available with no dependancies) is the way to go, in > which case rigid structure and organization is necessary, another to want a > microframework base, and a third to have a modular best-of-breed framework. > Pyramid seems to me to be none of these, and has quite the intimidating > codebase. Lots of sweeping generalizations there. > > TurboGears 3, or the future project with no name yet, doesn’t need Pyramid > from a technical standpoint. It didn’t need Pylons. WebCore showed that > utilizing the same components as TurboGears (PasteScript, PasteDeploy, > Genshi/Mako, ToscaWidgets, Beaker, SQLAlchemy, etc.) without a parent > framework can be trivially easy, modular, light-weight, and fast. Relying on > another ‘base’ framework seems to me to be a repeat of past mistakes, with > more pitfalls than benefits. No argument here, you guys can decide what to do about TG, this post was just required to defend Pyramid. -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
