Hacker News Reader

Comment by matrix | Hacker News Reader

I've built a couple of reasonably complex Djamgo apps, and as much as I like Django, all the points author makes are very true. That said, by the time you have swapped out the template language and the ORM you are basically no longer using Django; I think it's fair to say that if find yourself needing to do those things, you're much better off with Pylons.It's a question of the right tool for the job.

I do agree heartily that Django apps are not an effective level of abstraction as on might hope. Personally I usually just stick to using various libraries and writing my own code to do the Django-specific parts.

View on HN

I just switched the other way - from Pylons to Django - for a work project, for pretty much exactly the same reasons that he describes - inflexibility. In my case, lots of boilerplate for admin screens plus SQLAlchemy felt like too much magic. Particularly when trying to run functionality tests against my app, there were a few too many weird errors, with no obvious way to fix them (the solution was normally to move the database commit around), when the application worked fine. Django tests on the other hand, Just Work(tm).

So far I haven't run into any lack of flexibility on Django's part, and I've been using it for fairly serious stuff (mainly as a general-purpose CMS, heavy admin screen work). From the look of the original author's sites, the things that he's doing aren't too different, so I'm not sure what the problem is. Perhaps he just prefers the way Pylons does things?

It sounds like you had issues with SQLAlchemy, not Pylons.*

If you take care to understand SQLAlchemy well, it won't get in your way either.

*(I concede that Pylons doesn't have a good automated admin feature.)

I think it was more that the automated web testing part of Pylons wasn't particularly well integrated with SQLAlchemy. So (eg.) it's basically impossible (AFAICT) to populate the database with preexisting data and then directly call the controllers, since when you commit the data in your controller, you can't access the database afterwards when you get back to your controller. Instead, you get lots of odd tracebacks - things like "Instance <Foo at 0x103779f90> is not bound to a Session". It also means that you can't do rollback type testing - you have to stick different data in, or blow it all away and recreate it manually.

Django on the other hand, has fixtures, which you can create from your existing database, and use rollbacks, so they're really fast. Combine that with the test client, and I can just write my test cases and forget about setting stuff up. People often go on about Django's admin interface, but I find that the rest of the framework is written to the same sort of standard, so there are lots of hidden gems (like fixtures) just waiting for you to find them.

Pylons is awesome because its purpose is to provide me with the magic that makes Python websites easier and that's it. After that, it leaves me alone to write Python. It doesn't impose a certain toolkit on me; though Pylons suggests a certain ORM and templating language, there is no obligation to use them, and everything will swim along just swimmingly if I want to use something else. These things are all replaceable and interchangeable.

In my mind, Pylons is what a framework should be. It gives you a handy set of conveniences, functions, and configurations designed to overcome and share much of the monotonous and repetitive solutions necessary to reach the specified end (in Pylons's case, developing web apps in Python) and then it gets out of your way.

When I write Pylons, I am mostly writing Python; it's just like any other Python application, except in the places where I want a shortcut specific to the web-based nature of my program, and then it's an elegant, unassuming function name or shortcut that doesn't get in the way or announce itself.

However, when I've used other frameworks, like Rails and CakePHP, I've felt more like I am writing programs in Rails or CakePHP than "real" Ruby or "real" PHP. They all seem to demand a way of doing things that's quite different from the usual flow of those languages, and the resulting apps don't feel like apps anyone who reads Ruby or PHP could follow. CakePHP particularly has its own implementation of almost everything and relatively few lines of pure PHP ended up in the codebase.

Worse, those frameworks were tightly coupled with their custom ORMs, templating languages, and other important affixes that really deserve their own projects. Pylons's assumed toolkits are full-fledged, external projects, and if I don't like their suggestions of Mako and SQLA, it's really easy to drop in whatever suits my fancy. It's done in the normal Python way. Pylons isn't going to give me any extra guff over it, and it doesn't care if I use SQLAlchemy or DB-API directly or whatever I want to use.

I really love Pylons for all of this. I hope more frameworks start adopting these philosophies.

This is exactly the reason I love Pylons as well, I think you summed it up quite well.

Simply the fact that it's a minimalistic framework (not another abstraction layer on top Python)

A) The template system rocks

B) Use PISTON for APIs: he could have had it working WAY easier

C) Use SOUTH with the ORM. The ORM wouldn't make much sense on its own unless you like wiping your database a lot during development.

http://ericholscher.com/tag/largeproblems/ "Large Problems in Django: Mostly Solved"

It is a shame the tutorial doesn't point out South and Piston, everyone should be using them.

The template system rocks if you like handcuffs on your templates - and for some projects that may be the case.

Otherwise it's crippled in comparison to Jinja or Mako - with large amounts of un-Pythonic boilerplate if you want to write template tags.

To an extent you can replace it but again you will have trouble with those "reusable" apps.

I think it's better to keep additional logic in your page view functions instead of letting it bloat the template html. Why use a two pass method to parse your custom template logic into python code when you can just write the python code in the view functions?

Reply on news.ycombinator.com