Re: Extending JSONField serialization

It should be configurable and I like the kwargs idea. I've also had to monkey patch JSONField in this way for datetimes. Regards, Michael Manfre On Tue, Jan 5, 2016 at 12:48 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > > On 5 janv. 2016, at 18:37, Tom Christie

Re: Extending JSONField serialization

> On 5 janv. 2016, at 18:37, Tom Christie wrote: > >> Should JSONField accept additional kwargs to customize the encoder and the >> decoder? > > Quick take here: > > That sounds like a bit too much "cleverness" to me. The most obvious issue > it'd cause is putting

Extending JSONField serialization

> Should JSONField accept additional kwargs to customize the encoder and the > decoder? Quick take here: That sounds like a bit too much "cleverness" to me. The most obvious issue it'd cause is putting values of one type into the field, but getting objects of a different type back. (eg

Re: got glossarium?

I agree the glossary is abandoned and I propose removing it. I don't know that there's much value in expanding it. The idea is that you can use :term:`model` and have "model" linked to the glossary definition. In my opinion, the Django docs are comprehensible without this. A better solution in

got glossarium?

This thread is aimed at the specific issue pertaining to the Django Glossary. But first, after noticing, by accident, a huge spike of views on my G+ profile I think I should explain. I don't use G+ much because it seems kind-of goofey to me -- that's just me. If you want to see the real

Re: Extending JSONField serialization

This came up in a ticket a couple days ago: https://code.djangoproject.com/ticket/25995 On Tuesday, January 5, 2016 at 11:18:01 AM UTC-5, Aymeric Augustin wrote: > > Hello, > > I’m using the JSONField provided by django.contrib.postgres for logging > arbitrary data to PostgreSQL. > > For this

Extending JSONField serialization

Hello, I’m using the JSONField provided by django.contrib.postgres for logging arbitrary data to PostgreSQL. For this use case, I’d like my data to be JSON serialized with as little fuss as possible. Unfortunately lots of things (dates, datetimes, decimals, etc.) aren’t natively

Re: structural & functional review of django documentation

Scot, you've summarized what I've run into as well beautifully. My problem has never been with the documentation once I find it - it has been the path to finding it. Another frustration is trying to find a part of the documentation I know I've seen before a second time. I seem to go round and

Re: Request for Input: WSGI 2.0

One more thing — while this isn’t a use case I have myself, some people rely on the ability to run an application at a sub-part e.g. under https://example.com/appname/. WSGI should normalize the headers involved in that case so that applications don’t have custom code for various servers.

Re: Request for Input: WSGI 2.0

On Tuesday, January 5, 2016 at 10:37:32 AM UTC, Aymeric Augustin wrote: > > Hi Cory, > > I’m not subscribed to web-sig but I read the discussion there. Feel free > to forward my answer to the group if you think it’s useful. > > Thanks Aymeric, this feedback was extremely valuable. I've forwarded

Re: Request for Input: WSGI 2.0

Hi Cory, I’m not subscribed to web-sig but I read the discussion there. Feel free to forward my answer to the group if you think it’s useful. I have roughly the same convictions as Graham Dumpleton. If you want to support HTTP/2 and WebSockets, don’t start with design decisions anchored in