We’ve also had functional testing with the ability to introspect and verify all the template renders and session data that was done during the request. Django is just now adding this functionality.

Templatetags aren’t needed when you have the full power of Python behind you. Why learn a new language of template tags to do what you already know how to do in Python? In Django’s case it was because they were purposely limiting access to Python from the web designer. When you have Python available, if you need more functions… import them! It’s all just Python.

Many of these features don’t come from Pylons itself, but other excellent packages. This re-use means you get lots of powerful features that can be upgraded independently of Pylons. The WSGI spec and use within Pylons also means we can keep backwards compatibility much longer, and with less breakage in between releases.

For another example of re-use, consider this recent article covering implementing the Atom protocol in WSGI:
http://www.xml.com/pub/a/2006/07/19/implementing-atom-publishing-protocol-python-wsgi.html

You can copy the WSGI app shown there, as is, into a Pylons controller file, and its ready to go.

Consider that if you have a highly dynamic site that can’t be heavily cached, and you’re doing a ton with the database, the Django ORM’s limitations will quickly beat you. The lack of efficient eager loading, and other advanced database features such as an Identity Map to easily track updated objects will eventually force you to switch to something else. And once you switch, you lose generic views, automatic admin, and widget machinery; since they all rely on you using Django’s ORM.

That kind of situation doesn’t really happen with any of the high traffic sites I’ve seen that are Django powered. Since the content doesn’t change often, caching can be used aggressively to compensate for any possible ORM inefficiencies. This is what I mean when I say that Django is optimized for certain styles of web development. You could use Django for anything obviously, but you quickly lose its biggest selling points.

By the way, 99% of web apps are using any kind of data model, and normally content is managed by users. Only I see an scenario which Pylons wins over Django: in adding a web interface to non-webs applications that uses SQLObject, etc. or re-use these modules on an existing web. In general, Pylons offers users more posibilities in each component, and Django offers a more homogeneous components and philosiphy.

Django offers you any functionality you said for Pylons, and more:

- generic views
- automatic admin site
- templatetags (for building web components)
- widget machinery (for example there are tutorial for integrating RichTextFields with TinyMCE)

Automatic admin can be used like model of good web with a good CSS and usability. I used, in two projects, admin site for building entire web (for intranet), and looks incredible (and very very fast).

And in develop environment, provides an excelent productivity, for autoreload, precise error pages, excellent debug, etc. (Pylons maybe has good one).

Regards,
Lin

You’re right that FormEncode doesn’t generate forms. Neither does Django, though its manipulators can make the fields you’re still left laying out the form and the labels. It’s really quick to make those form widgets with the helper functions in WebHelpers though.

Cohesion is definitely important, I think Pylons excels in this aspect since it makes it very easy to use separate tools very easily. If you look at the large batch of import statements that can accrue in Django views, vs the basic one in a Pylons controller, as well as the fact that you can just use your session, or the request from anywhere; you could even consider Pylons more cohesive.

The most important thing I think, is that Pylons doesn’t overlap that much with Django when it comes to its intended audience. Django was derived from a project that was created to meet the needs of the newsroom. Many Django advantages are lost when you’re not using it in a staff content-driven manner, though it should be noted that a huge amount of the webapps people develop are content-driven by a group/staff.

This focus is clearly shown in the layout of a Django project and Apps, merely by how few files it creates for you. Pylons is geared more towards people that want maximum flexibility and customization.

Pretty much everything in Pylons can be customized, and therefore a lot of the configuration is also present in the project directory created for you. There’s a large batch of template languages supported, multiple ORM’s with ease, powerful caching of templates in any template language, easy re-use of WSGI apps and middleware, etc.

If you’re looking for a framework in the future, and your site deviates highly from the workflow that Django is optimized from, give Pylons a try. The new 0.9 which is almost out makes it even easier to use, and I think you’ll hard-pressed to find so many internals documented as highly: http://pylonshq.com/docs/0.9/module-index.html

Cheers,
Ben

Ok, it’s a fact that i don’t know Pylons as well as Django, but any case i’d like to anwser you in several points:

- I have used ZPT (and also kid) templates for three years (in fact I continue with ZPT with Plone). I have to acknowledge that mix logic and presentation can be useful for rapid deployment, but not for maintenance and legibility.

- My above code of mixture logic and presentation is in index.myt of pylonshq.com… It’s true that you can separate logic on controller, but at the end you take easy way (of mixing).

- FormEncode it’s ok but, if I don’t miss, You cannot build a form based on widgets of you model automatically. But sorry for do not talk about FormEncode (I forgot it).

- The cohesion is very important. You said that Pylons doesnt require SQLObject or SQLAlchemy or AuthKit or … This can produce a worse cohesion than Django.

- SQLAlchemy can have several times more capabilities, but in my case I have no oportunity for using that. I consider Django ORM very powerful and I don’t need (for now) features like mappers. I’d like simplicity and medium capabilities over complexity and strong capabilities. For that, I prefer Django to Zope 3.

In general, I think with Django I can get productive several times that with Turbo Gears (an example in a real project). Pylons is newer and I didn’t have oportunity for using in a real project.

===
Creo que más de unos cuantos comentarios aquí andan desencaminados. Desafortunadamente, el traductor de español a inglés no es muy bueno.

Primero, el esquema de herencia de Myghty es en realidad más sencillo que el de Django. Hay herencia automática, lo que significa que no necesitas poner ese trocito en absoluto, y la herencia de plantillas te proporciona la poderosa capacidad de actualizar los elementos en las plantillas de envoltorio.

Además tu ejemplo es muy engañoso, porque estás poniendo selects a una base de datos en una plantilla… ¿¿¿por qué querrías hacer eso??? Sólo porque no estés encerrado en una camisa de fuerza para mantener fuera de las plantillas los temas de la base de datos no significa que se algo malo. Myghty simplemente supone que el desarrollador es lo bastante inteligente para saber lo que es una buena y una mala idea.

Segundo, Pylons no trae ORM de bases de datos. Puedes usar SQLObject y escribir el código de la base de datos igual que en Django; de hecho, Django ha actualizado su ORM para que se parezca más todavía a SQLObject.

Si quieres tener capacidades SQL potentes, sugerimos usar SQLAlchemy. Es muy potente y se puede conectar con Oracle, MS SQL y más. No sólo eso, también puede hacer carga activa (eager loading) de datos, y le da varias vueltas al ORM de Django en cuanto a capacidades.

Para la validación de formularios sugerimos FormEncode. FormBuild todavía está en desarrollo, pero en general me gusta hacer los elementos de formularo por mi cuenta, o con las herramientas auxiliares de WebHelpers (que evitaste mencionar, junto con las características de AJAX). El SVN de Pylons también incluye un decorador @validate que facilita mucho la validación de formularios.

Hay muchas más inexactitudes aquí con respecto a Pylons; estas sólo son las obvias que destacan y que mejor conseguí traducir.

Saludos,
Ben
===

First, the Myghty inheritance scheme is actually simpler than Django’s. There’s automatic inheritance which means you don’t need the bit at all, and template inheritance gives you powerful abilities to update elements up and down the template wrapping.

Your example is also very misleading because you drop in database selects into a template…. why would you do that??? Just because you aren’t stuck in a straight-jacket forcing you to keep database stuff out of your template, doesn’t make something bad. Myghty just assumes the developer is intelligent enough to know what is and isn’t a good idea.

Second, Pylons comes with no database ORM. You can use SQLObject and write your database code just like in Django, in fact, Django has updated their ORM so that it looks even more similar to SQLObject.

If you want powerful SQL abilities, we suggest using SQLAlchemy. It’s very powerful, and can connect to Oracle, MS SQL, and more. Not only that, but it can do eager loading of data, and run circles around Django’s ORM when it comes to capabilities.

For form validation, we suggest FormEncode. FormBuild is still being worked on, but I generally like making form elements myself, or with the helpers in WebHelpers (which you failed to mention, along with the AJAX abilities provided). Pylons SVN also comes wiht a @validate decorator which makes validating forms really easy.

There’s many more inaccuracies listed here regarding Pylons, these are just the obvious ones that stand out which I was able to translate best.

Cheers,
Ben