Hacker News Reader

Comment by anthonyb | Hacker News Reader

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?

View on HN

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)

Reply on news.ycombinator.com