Byron, I think Shai is suggesting that a user's form class may do extra processing in __init__ on the data and files fields. If someone starts using the new pattern in their views, it will break those classes because they expect the initializer to be called with valid data when there is any. Your new method will bypass their customizations.
Best, Alex Ogier On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth <[email protected]> wrote: > I don't understand your argument regarding overriding `__init__`. Nothing > has changed in __init__, the logic for setting `data` and `files` is simply > moved to a method. You _can_ still pass `request.POST` and `request.FILES` > into the constructor. If a user extends __init__ (I do it all the time), > you still need (are expected) to call `super` to _finish_ initialization. > > > On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote: >> >> On Thursday 31 January 2013, Byron Ruth wrote: >> > Here is the ticket: >> > https://code.djangoproject.**com/ticket/19668<https://code.djangoproject.com/ticket/19668>and >> > the >> > pull request >> > https://github.com/django/**django/pull/674<https://github.com/django/django/pull/674> >> > >> > One user commented on the ticket raising a concern that it could >> possibly >> > be misused if the data is set after it had been used. It is certainly a >> > valid concern, however it should be made clear in the docs when to use >> it >> > and/or raise an exception if `is_valid` has already been called. >> > >> > Thoughts? >> >> While this is backwards-compatible per se, using it in views is generally >> not >> backwards-compatible with user form classes (you can't tell what they do >> in >> their initializers); thus, generic views (and also some not-generic >> views) are >> forced to keep using the "old way" unless the (user) form code is >> altered. >> Which means, you'll have two ways to do the same thing (in views), >> without a >> clear preference between them. >> >> So if you want this judged as a backwards-compatible change, I'm -1. >> >> As a non-backwards-compatible change, I'd like it, but I don't think it's >> worth the disruption, so I'm -0. >> >> Either way, I'm not a core dev. >> >> Shai. >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
