Djng - a Django powered microframework | Hacker News Reader

Djng - a Django powered microframework

simonwillison.net

56 pointssimonw19 comments

So many web frameworks slowly evolve features that Pylons has had for years. I think it's by far the most under appreciated framework out there.

Which feature(s) are you referring to?

StackedObjectProxy (which I have mixed feelings about), data mapper pattern (basically SQLAlchemy kicking ass), and the kicker: an integrated debugger.

There are others I've noticed, but that's off the top of my head. Of course, Pylons falls short in some other areas.

To be fair, StackedObjectProxy comes from Paste, not Pylons.

Almost all of pylons' nice features come from it being built on some of the best python projects out there. Pylons itself isn't much more than glue, but as a packaged deal, it can't be beat.

That's my two cents anyway.

And Pylons isn't much more than a thin layer on top of Paste anyway.

I'd be interested to hear your thoughts on StackedObjectProxy. What is it that makes you uncomfortable about it?

Well, it's been a while, but I'll see what I can recall. I fought with them a lot during one project, though it may have been due to a lack of understanding. You can view a bit of that struggle here: http://groups.google.com/group/pylons-discuss/browse_thread/...

The main issue is that they're poorly documented and don't seem that pythonic to me. They are not standard python objects, and as such they are difficult to debug. Hopefully the situation has improved in the past year or so.

I see what you're saying here about how Pylons makes heavy use of WSGI chaining, but I really just cannot fathom that Django is "approaching" Pylons. Perhaps things have improved since I last used Pylons, but there were so many issues with it that drove me absolutely crazy and eventually drove me away from the framework all together.

Off the top of my head:

- Poorly written, half written, scattered, or plain old missing documentation all over the place.

- Poor release coordination and communication.

- Version incompatibility hell between different releases of its components/dependencies.

- Incomplete solutions for basic things like form generation. At the time that I was using Pylons they seemed to jump between a quite a few different libraries, none of which really worked well.

- Tons of magic that both offended my sensibilities and made debugging a nightmare.

To be honest, I don't think any Python web framework was quite "there" at that time, but I think today Django has far exceeded Pylons.

Also, I'm not sure I'd consider Pylons a micro-framework.

I never said that Django was becoming Pylons or that Pylons was a micro framework. All I'm saying is that features Pylons (and included projects) has had forever keep being reinvented in other frameworks when people suddenly realize what a good idea they are.

Pylons' documentation is a nightmare, I'll agree with you there. It's a shame too, if it was better documented, I feel it could really compete.

Guilty as charged - I'm always up for borrowing good ideas from other projects. That's what open source is about. Most of my favourite ideas in Django were inspired by other frameworks (template inheritance came from Cheetah, the request/response objects were inspired by a combination of Java servlets and PHP).

I should probably set aside some time to build a project using modern Pylons and find out about all the other good ideas I've been missing!

Nice work, Simon. Thanks, and thanks for all the hard work on django as well. Keep it up. :)

Less time on frameworks, more time on useful applications/services.

Frameworks are often byproducts of useful applications/services.

If you want more useful applications and services then go write them, don't complain that other people are spending their time writing open source software that you don't think they should be writing, it's really not your place.

I don't think this can be fairly considered a "microframework" when it depends on Django itself...I will give it a try and look at the source because I think that the author's motiviations for removing urls.py and settings.py are valid (in cases) and would be better fulfilled with a few surgical patches than "turtles all the way down."

At EuroDjangoCon I joked that djng is a "micro macro framework" due to the Django dependency. If you look at the source it basically IS a few surgical patches, some of which are implemented as monkey patches.

Wonder if this would work on App Engine.

I haven't tried running it on App Engine yet, but I think it will eventually be a really good fit there (and in fact it should work right now).

Reply on news.ycombinator.com