On 05/22/2014 11:13 AM, Shai Berger wrote:
Any thoughts on this idea?
Instinctively -- isn't it possible to achieve the same things today by
overriding __new__ ?
My understanding is that achieving all the same things isn't possible.
The problem is that inside __new__ it is impossible to know if the call
to __new__ was made from database loading or from user code. It also
seems that it is impossible to alter the args and kwargs passed to
__init__(). In addition if one wants for some reason (speed, or not
invoking __setattr__) to assign values directly to the __dict__ of the
new class, then __new__() doesn't seem to offer any way to do that.
It is true that STI is likely possible with usage of __new__() as long
as you don't want to change the arguments to the __init__ call of the
created object.
As a side note I think direct assignment to __dict__ on model loading
would be a better design than the current __init__ call. For example
Django needs to do some pretty crazy stuff in __init__() to support
deferred field loading. With direct __dict__ assignment deferred model
creation is trivial. Also, loading from the database is a form of
deserialization, and when deserializing you want to load the model as it
were saved. The way to do this is to avoid __init__, __setattr__ and
descriptor __set__ calls. To avoid those the values should be assigned
directly to the __dict__ of the object. This is also used by Python's
deserialization. Of course, thinking about this is mostly academic.
Changing the way model loading from database is done has severe
backwards compatibility issues. Even django-core relies on descriptor
calls in some case. As an example to_python() method of custom fields is
called through a descriptor.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/537DBD38.4080604%40thl.fi.
For more options, visit https://groups.google.com/d/optout.
