Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

django core here, some feedback on -annoying:

It'd be nice if you were clear about what versions of django and python are supported.

From django-annoying's feature list:

    * render_to - seems to be roughly equivalent to django.shortcuts.render
    * signals decorator - now in core[1] (since 1.3)
    * ajax_response - seems useful, though might make sense to check request.is_ajax[2]
    * autostrip - hmm, seems oddly edge case-y, I definitely wouldn't apply it to all my forms
    * get_object_or_None - nifty 
    * AutoOneToOneField - assumes the related model is valid with only the FK filled in, which seems fairly unlikely in many OneToOne cases.  I'm not sure if this was proposed to core, but I'd think it would need some sort of default= fillin feature to be more generally useful.
    * JSONField - soo many competing and variously featureful implementations. This has been discussed a few times; it seems fairly easy to implement and hard to gain consensus. I wish we could get it in core, but the juice doesn't seem worth the squeeze.
    * get_config - I don't think I understand the purpose of this, unless you're just trying to be more intention-revealing than getattr(settings, ...)
    * HttpResponseReload - nifty
    * StaticServer - I don't think I understand why you wouldn't want to config urls.py instead.
[1] https://docs.djangoproject.com/en/dev/topics/signals/#connec...

[2] https://docs.djangoproject.com/en/dev/ref/request-response/#...



Thanks for your feedback, let me reply to it:

As JshWright said, the appeal of render_to is that it's a decorator, it does clean up views by a lot.

The signals decorator is now obsolete, I also find ajax_response very handy (when I'm not using CBVs), autostrip is a bit edge-casey, I agree.

get_object_or_None is pretty much 1.6's .first(), but there was no alternative until 1.6. AutOneToOne/JSON fields are there because of convenience, get_config I have no idea about (I didn't write these), StaticServer, also no idea.

The thing is that this library has been out for years, and most of these things didn't exist in core when it came out, so it was really handy in its time. I've been using it for quite a few years, and that's also why I took up maintenance of it.

In the long run, I'd like to see the things that make sense in it integrated into core, especially the @render decorator.


I really like the fact that render_to is a decorator. That cleans up a bit of boilerplate that would normally be in the view (even with django.shortcuts.render).




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: