Re: Allowing Reverse, Single Inlines in Admin

On Friday, March 30, 2012 1:58:08 PM UTC-7, Tyler Kocheran wrote: > > > The real point is that I shouldn't be getting errors if I want to have a > OneToOneField inline of an Address on a Person. No matter what side the > relation is declared on, inlines should just work™. Maybe it's not the

Re: Dropping django.utils.simplejson

Standard python 2.6 json is a bundled and cleaned up simplejson without C extension and pre-26 compatibility - even if json serialization is not a common bottleneck why make things worse? Simplejson and python 2.6 json are arguably the same libraries, I think this is like choosing between

Re: Dropping django.utils.simplejson

I did some timing tests. https://code.djangoproject.com/ticket/18023#comment:5 An order of magnitude difference in JSON serialization time corresponds to an 8% change in total serialization time for a complex model, and 5 deeply nested model instances can be serialized in < 2 ms. It might be a

Re: Allowing Reverse, Single Inlines in Admin

I mean "multiple types of objects." Basically, in the db, it looks a bit like this: create table address(id int primary key auto increment, name text, address text); create table person(id int primary key auto increment, first_name varchar(30), last_name varchar(30), address_id int

Re: Allowing Reverse, Single Inlines in Admin

On Friday, March 30, 2012 11:44:29 AM UTC-7, Tyler Kocheran wrote: There's really no reason for an `Address` to know of itself what it is > owned by, it could be owned by multiple different objects. > Not if you are using a OneToOneField... I think you are just looking for a FK to an

Allowing Reverse, Single Inlines in Admin

Presently, there's not a way without altering models to be able to have inline models if dependencies are declared on the "owning" class. Allow me to explain with code: class Person(models.Model): address = models.OneToOneField("Address") class Monument(models.Model): address =

Re: Dropping django.utils.simplejson

On 30 March 2012 13:04, Alex Ogier wrote: > At the same time, I want to reiterate my support for option #1: not > deprecating the > module and leaving the shim in for the foreseeable future. If simplejson is > available on the system, and particularly if it has been

Re: [GSoC 2012] Enhanced contrib.auth

On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans wrote: On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros wrote: You can read the proposal nicely formatted here: https://gist.github.com/8dd9fb27127b44d4e789 Hi Stratos It's a long proposal, so

Re: [GSoC 2012] Enhanced contrib.auth

On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros wrote: > You can read the proposal nicely formatted here: > https://gist.github.com/8dd9fb27127b44d4e789 Hi Stratos It's a long proposal, so this is a brain dump of bits that I find interesting/worrisome. I'm sure you've

Re: Dropping django.utils.simplejson

It seems like everyone besides me agrees on option #2 so I implemented it in #18023 ( https://github.com/ogier/django/compare/remove-simplejson ). At the same time, I want to reiterate my support for option #1: not deprecating the module and leaving

[GSoC 2012] Enhanced contrib.auth

You can read the proposal nicely formatted here: https://gist.github.com/8dd9fb27127b44d4e789 GSoC 2012 Proposal - enhanced contirb.auth == Hello, my name is Stratos Moros and I am a Computer Science student in the University of Piraeus in Greece. I

Re: Dropping django.utils.simplejson

Hi, I am for number 2 too, but don't forget that's deprecation in 1.5 and 1.6 and removal in 1.7 Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit