PylonsHQ - Blog - Pylons 1.0 Released | Hacker News Reader

PylonsHQ - Blog - Pylons 1.0 Released

pylonshq.com

80 pointsbrolewis23 comments

Open articleView on HN

Congrats, it has been quite a while since their last release.

A short comparison to Django:

- SQLAlchemy is badass.

- Jinja2 (or whatever templating language you like) is also badass.

- Passing data to your templates using a global 'c' object is weird and seems rather hack-ish to me.

- None of the third party form libraries are as good as Django's forms, especially when it comes to ModelForms (FormAlchemy's API is rather lacking, IMO). WTForms is the best I've seen so far, but it's lacking model integration.

- Both of the major user auth systems (AuthKit and repoze.who/repoze.what) are lacking compared to Django's contrib.auth. I found them convoluted, somewhat overengineered, and difficult to set up. Doing authentication in the middleware layer is the wrong approach, IMO. You shouldn't have to shuffle user data and login state around using redirects, query strings, and environment variables. If you search around on this topic, a lot of people end up recommending rolling your own. Blargh.

- Pylons puts a lot of cruft in your project when you create an new project. I'm not convinced how much of this stuff is actually necessary, especially at the beginning of a project.

- The docs have tended to lag behind the actual releases. For example, at one point url_for() was deprecated in favor of url(), but a lot of the docs still referenced it and it was not obvious where to find the documentation for url(). In fact, it's still not obvious. Sometimes you see TODOs in the documentation itself that make you wonder how up to date the docs actually are. Hopefully this has improved since I last used it.

My biggest issue with Pylons is when you run into needing a third party library like forms or user auth, you have to spend time researching 2342 different libraries, only to discover that many of them have fallen into disuse, or are poorly documented. On the other hand, it's great when it lets you choose well written components like SQLAlchemy and Jinja2.

Django and Pylons both have their pluses and minuses, but I think there is still a lot of room for improvement in the Python web world. Armin Ronacher seems to be making lots of progress with Flask, maybe we'll see that grow into a bigger project.

I agree with that assessment with the exception of the repoze.who comment. Repoze.who is bad ass. It takes a while to get your head around it, but at the end, it is far and away the best engineered and extensible auth system for python apps. I would encourage you to take a closer look.

The main thing I didn't like about it was the way it uses environment variables and query strings to pass around information. E.g. take a look at this: http://code.gustavonarea.net/repoze.who-friendlyform/

The way you identify a user is to pull the 'repoze.who.identity' out of environment variables. The way you detect a failed login is to check whether the login count, passed as a query string in a specially named __logins variable, is greater than zero. This especially seems like an ugly hack to me.

Oh, and I really didn't like the fact that the latest release of repoze.who (2.0a1) has a ton of undocumented, backwards incompatible API changes. It was amusing trying to get it working, only to realize that the docs only referenced a much earlier release.

I understand the goals of repoze.who and think they've written a very impressive set of plugins, and I understand how it would be useful if your app happened to have multiple types of authentication that made sense to handle at the middleware level: HTTP Basic or LDAP or whatever.

But they've done that at the expense of keeping the base case simple: having a user model with a username and password that authenticates at the application level with a login form. 99% of websites use this approach so I was surprised that it wasn't simpler to do, especially coming from Django where this feature ships by default.

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?

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?

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.

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

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).

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!

> 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.

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.

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 :).

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.

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.

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

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

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...

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.

1080 lines sounds quite sleek, but then I suspect it just sources almost everything out to other packages.

Could someone who has used it comment on how it compares to Django?

I've use Django, Pylongs, TG, and repoze.bfg. It's quite different. A vastly oversimplified metaphor would be unix to OSX. Django is a monolithic all in one environment where everything 'just works' together but is not useful outside of Django, and no part really really excels at its own job, while being good enough for Django. Pylons expects you to write a lot more glue, and works better if you anticipate hitting the wall with a Django component ( ie Django's ORM is not even close to SQLAlchemy ). Pylons tends to attract people who will be writing a complex app that they will run with for a long time, or be extending in their own way. If you think there is a good chance you might need to rip out own component to replace it with a tweaked one, or different version, it's a lot easier with Pylons. Pylons is also written from the ground up around WSGI, so if building app stacks out of WSGI is your thing, that is still easier in Pylons ( though possible in Django. It still feels a bit bolted on though ).

That said, I personally prefer repoze.bfg over all of them now. Also minimal, built on wsgi, but also built on the Zope Component Architecture ( just the ZCA, does not depend on the ZODB or Zope server). For really being able to reuse and extend your code, that ZCA infrastructure is the killer feature.

To be fair, I should point out that it's much easier to get new developers going on Django, and that the monolithic approach gives people a much better out-of-box experience. Just not my thing, I like Vim better than Eclipse too. ;-)

I think of it this way: Django was built by a bunch of people with some specific goal in mind (make building a CMS super easy). For the most part, the same developers who built the ORM also built the templating language and the glue and the admin generator, and the auth system, etc.

Pylons was built by a bunch of people with different goals in mind. One was to make an awesome ORM. Another was to make a kickass templating language[1]. The purpose of Pylons is to make it easy to integrate your choice of optimal components into a web framework with reasonable ease.

Yes, if you're going to deviate from the defaults things may not work "out of the box" like Django, and you might not get a default auth system and an admin panel (could use something like repoze). While it'll take you longer to build the initial prototype in the first week, you wont hit that wall of "why do I have to put code in 4 places to add a template tag?" or "why am I getting weird PYTHONPATH-related side effects from using settings.py?" or "oh well, I guess I just wont use joins."

The ramp-up time/results curve of Pylons is steeper than Django's, but it stays relatively steady throughout your project, whereas a monolithic framework will get more and more in your way over time until you realize you've slowly dismantled the entire framework and reinvented Pylons.

[1] Incidentally, both SQLAlchemy and Mako Templates are founded by the same person, but historically Pylons has defaulted to whatever "the best" package was (SQLObject and Kid, a few years ago).

That's a good point about the Django honeymoon period before you hit all those little things like a proper multi environment settings.py schema. Once you're over those and start reading the Django code it becomes even more productive.

Reply on news.ycombinator.com