7 ms·

PylonsHQ - Blog - Pylons 1.0 Released

80 points by brolewis 16y ago

phreeza 16y ago
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 16y ago
  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 16y ago
    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. ;-)
- shazow 16y ago
  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).
  - jokull 16y 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.
akavlie 16y ago
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 16y ago
  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 16y ago
    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 16y ago
    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 16y ago
    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).
- auston 16y ago
deleted 16y ago
[deleted]
stevenwei 16y ago
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 16y ago
  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.

80 points by brolewis 16y ago

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 16y ago
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 16y ago
  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. ;-)
shazow 16y ago
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).
- jokull 16y 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.

akavlie 16y ago

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 16y ago
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 16y ago
  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 16y ago
  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 16y ago
  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).
auston 16y ago

deleted 16y ago

[deleted]

stevenwei 16y ago

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 16y ago
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.