
PylonsHQ - Blog - Pylons 1.0 Released - brolewis
http://pylonshq.com/articles/archives/2010/5/pylons_10_released
======
stevenwei
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.

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

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

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

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

------
phreeza
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?

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

~~~
iainduncan
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.
;-)

