PylonsHQ - Blog - Pylons 1.0 Released
pylonshq.com
PylonsHQ - Blog - Pylons 1.0 Released
1–10 of 25 posts
Re: PylonsHQ - Blog - Pylons 1.0 Released
#21080 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?
Re: PylonsHQ - Blog - Pylons 1.0 Released
#3One 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?
Re: PylonsHQ - Blog - Pylons 1.0 Released
#41080 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.
Re: PylonsHQ - Blog - Pylons 1.0 Released
#51080 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 th…
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. ;-)
Re: PylonsHQ - Blog - Pylons 1.0 Released
#6One 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?
Re: PylonsHQ - Blog - Pylons 1.0 Released
#7One 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.
Re: PylonsHQ - Blog - Pylons 1.0 Released
#8One 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?
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!
Re: PylonsHQ - Blog - Pylons 1.0 Released
#9[deleted]
Re: PylonsHQ - Blog - Pylons 1.0 Released
#10One 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?
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.