21–25 of 25 posts
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?
Yep. Pylons is fine. More flexible than many of the frameworks out there.
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 ra…
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 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.
Earlier quoted context omitted.
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. I…
> 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.
- 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.
Earlier quoted context omitted.
> 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…
Earlier quoted context omitted.
> 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…