Er, that looks pretty hideous to me.

I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand.

Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopped trying to figure out what was going on when I realised that

    headers = remember(request, login)

actually returns the raw headers as a list of strings, and you need to feed them manually back into the response.

Compare to Django's login, which is a lot clearer, even though it includes all of the things that the Pyramid version skips over: https://docs.djangoproject.com/en/dev/topics/auth/#django.co...

When I look at django apps they are often similarly hideous to me. (edit: such as - when hundreds of objects are pulled into memory, then filtered further, or processed one at a time, when the entire thing could be done in one query. They'll do this not only because the Django ORM isn't capable enough to do the work out on the query side, but also because the programmer isn't SQL-aware enough to know that's even how it should be done. Django's lack of capability is matched by the developers lack of awareness, and the conclusion for such a developer is "django works great!" This is why SQLAlchemy users get annoyed by Django and Django users get annoyed by SQLAlchemy. There are two totally different ways of looking at problems going on).

This whole thing is about where you're coming from and what software development traditions you subscribe to. We know full well django isn't going anywhere and you can rebut all you want, the alternatives aren't going away either.

Well, when I see code like that, I see lots of moving parts, all with their own weird API, interacting in odd ways. You just have to know that thing X takes a string, an object and a callback function, and there are twenty thing Xs, not five.

Complexity breeds bugs like rabbits; if you can't look at something and understand what's going on (potentially drilling down into an abstraction or two), then it's going to be a maintenance nightmare.

If you can come up with something that's easy to use and powerful, like the declarative_base stuff in SQLAlchemy over the top of the Mapper/Relationship, then I'm all ears - but if complexity is the price that I have to pay for that then it's not an easy tradeoff to make, and in a lot of cases you're better off with the easier, worser solution.

A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly? ie. so that all of the fancy Django manage commands work. I'm assuming a fair bit, but it might be a good way to get some sort of help as far as SQLAlchemy goes. Or you might be happy to continue forging ahead solo, I don't know. Just a thought ;)

> A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly?

There is a version of this I have in mind that would take at least 6-8 weeks of pretty solid developer time. A new layer would be built on top of SQLAlchemy ORM that would look just like Django mappings/QuerySet. The mappings wouldn't be too difficult, QuerySet maybe a little more.

The advantage to that approach would be that existing Django mappings and QuerySet code could be reused in the context of a SQLAlchemy session conversation, that is, the unit of work/identity map paradigms would be brought in. A lot of the "bolted-on/doesnt-really-work" code I see to approximate these features in a tool like JohnnyCache wouldn't be needed anymore.

I'm not sure that this really encompasses "manage" though, I'd have to increase my familiarity with that tool to know everything it does.

Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem

The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this case, we didn't."

So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.

Chris' perception of design errors aside, there is no reason a feasible auth system not tied to a specific persistence system can't be built. My usual way of proving this is by building one but I'm really at my max number of OSS projects to be maintaining.