Django example using ujson

[codygman]

This isn't the standard way of doing things with Django AFAIK. I use ujson myself, but I'd think it'd be more in the spirit of this competition to use the built-in serializers, at least for the non-stripped version:

https://docs.djangoproject.com/en/dev/topics/serialization/

I suspect going through these examples I'll see a lot of C level libraries used that aren't quite idiomatic, and from what I've been reading on hackernews that isn't in the spirit of this competition.

EDIT: It seems that bottle is also using ujson, but I cannot comment on whether or not that is the standard way of doing things.

The wsgi benchmark is also using ujson. I'd argue that the standard way of doing things is to use the json library built into python and using anything else qualifies this as a "stripped" version.

[bhauer]

@codygman You raise some good points. We have accepted changes that moved away from the built-in serializer to ujson without considering if that is idiomatic. Admittedly, we have a fairly loose definition of idiomatic. Put succinctly, we're looking for code that complies with the community's agreed-to best practices. That may or may not actually align with the example code in the framework's documentation.

If nearly everyone who builds production-grade Django applications uses ujson, we'd be comfortable with it being used (even in a "non-stripped" test) because of that consensus. On the other hand, where there is debate and no firm consensus, it seems like a safe bet to use the built-in functionality.

Bottom-line: I don't have a strong opinion on this one. I'd like to hear more opinions from the community.

[knappador]

As long as the API between two libraries is consistent, using drop-in replacements for isn't exactly straying from what a developer will likely do when performance becomes a concern. In Python, when performance becomes critical, using a C or C++ extension are the norm. Just look at numpy.

Django documentation is about getting up to speed, not rebuilding it to become flask-like or as a fully-featured CMS. It can do either. That's one of the strengths of the framework. In general use, C extensions like psycopg2 are indeed the norm. It's not a requirement to go with any particular DB driver, and it's expected that users will interchange components to suit the needs of the application.

[LadyMozzarella]

Closing this issue due to inactivity. Please reopen if this should remain as an issue.