[akavlie]

One thing going for Pylons: Great documentation. If you're using TurboGears 2.0, you'll do far better going straight to Pylons docs than most of the stuff on turbogears.org.

Still though, it seems that most people tend to go for the full-stack frameworks. Anyone here using Pylons?

[auston]

I've used Pylons for reporting, here are my takeaways:

1. It's a little tougher to get working "out-of-the-box"

2. It's documentation is not as "centralized" - meaning because you can use whatever template engine you want (jinja, mako, etc) and whatever db backend you want (sqlalchemy, elixir - a nice overlay on top of sqlalchemy, django ORM, etc) the docs for a particular module may or may not be in pylons docs

3. It's waaayyyy more flexible - I can't praise SQLAlchemy enough, it's freaking amazing!

[rmanocha]

> 3. It's waaayyyy more flexible - I can't praise SQLAlchemy enough, it's freaking amazing!

I used SQLAlchemy breifly, but found myself drawn back to the Django ORM (even for non-web based projects) - can someone explain to me why they think SA is better than the Django ORM - I find the latter to be much better.

[stevenwei]

Mostly because it's a lot more powerful than Django's ORM. Just take a look at the documentation table of contents to get a vague idea: http://www.sqlalchemy.org/docs/

- The support for various class inheritance hierarchies is much more powerful than Django's inheritance.

- You can customize the default JOINs between object relationships very easily.

- You can map objects against arbitrary select statements.

- It has supported multiple databases for a long time now (which only just got added in Django 1.2)

- It supports composite primary keys.

- It implements the unit of work pattern, so you can save entire object graphs without having to explicitly save each individual node. This is a lot more intuitive, IMO.

- It uses an identity map to maintain object consistency. So if you query for the same object in two different queries, the same object is returned (at the Python level).

- The docs are excellent.

I think Django's ORM is fine for simple web apps where the model objects are just used to shuffle data in and out of the database. If you've got complex domain models, or specific database requirements, though, then you'll probably hit a wall where Django won't do what you need, whereas SQLAlchemy probably does.

[iainduncan]

I would add that the data mapper pattern gives you very fine grained control over what objects and attributes of the object are matched to which tables. So refactoring either your object layer or your table layer is easy to do independently.

[rmanocha]

Thanks for that list. I guess I haven't run into any of these more "complex" issues yet developing the relatively low scale sites I've been working on. Hopefully some day, the Django ORM would become too much of a time sink for me to consider SA, but in the meantime, I'm gonna be sticking with it just 'cause I find it easier/more intuitive to use :).

[MisterWebz]

Yes, i do. I'm still not quite sure why most people choose Django over Pylons. Maybe it's the complexity (Might not be complex for the experienced Pythonista, but i feel that it's definitely more complex than Django) that steers potential users away from Pylons?

[icey]

Historically Django's documentation has been significantly better than Pylons'.

That may have changed recently (I don't know, I'm not familiar with Pylons), but it gave Django a head-start with people who didn't want to have to dig through the source to figure out how to do things.

[GeneralMaximus]

I've dabbled a bit in both Django and Pylons, and I've found working with Pylons is much easier than working with Django. Django has more "magic", which freaks me out. Pylons, on the other hand, mostly consists of glue code to tie different modules together and the Pylons book goes to great lengths to explain how this glue code works.

Setting any one of them for development is easy: just install them in a virtualenv using pip. Can't say how they fare in production setups. I'm not there yet :p

[ubernostrum]

Seems to be a matter of personal preference. Some people prefer the Pylons style, some prefer the Django style. Nothing wrong with that, and it's why we have both (as well as other frameworks for the people who don't prefer either of Pylons/Django).

[weixiyen]

I'm using Pylons as well. It's the perfect balance between using something too basic like cherrypy / web.py and something way too spoonfed like "django".

It removes the need for writing my own MVC which I would have needed anyways, and doesn't force me to use anything I don't want to. It's just Python, but neatly separates the files in logical places.

Thus far, Pylons has met every single need so far outside of async I/O, for which I've turned to node.js.

Contrary to popular belief, Pylons is not for intermediate Python users. I've taught web development in Python to beginners using Pylons and it's not hard at all to pick up for them.

[nym]

I have, it's a great framework, but as someone who would rather spend time working on what makes my product unique, I'd likely write it in Django instead as so much heavy lifting in terms of auth is already taken care of completely. On the other hand, you get to use SQLAlchemy in Pylons, which is pretty tasty...

[shazow]

I do, I love it. Been using it for the past several years and it's one of the few package collections which is written so well that I can read the source from start to finish and actually understand what it does. It's very easy to adopt it to unexpected use cases. I highly recommend it.

[tjpick]

Yep. Pylons is fine. More flexible than many of the frameworks out there.

[iainduncan]

With the exception of repoze.bfg, I think repoze.bfg is even more flexible.