With all respect, this seems like a bad idea; there would be little, if any,
gain from having this method.
--
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
The problem is that if you use your idiom, data and files are None when the
class is instantiated. This is currently a sign that the form has no data
attached. Currently, if you want to massage input data before cleaning, you
do it using either form of of overriding __init__ as you describe. But if
I don't want to belabor our difference in understanding/opinion, but there are
two ways to extend __init__. Processing before super is called, and processing
after super is called:
# Common pre-processing..
class MyForm(forms.Form):
def __init__(self, request, *args, **kwargs):
# Use
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 n
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)
Interestingly enough, it reminds me of the pattern proposed by Daniel
Greenfeld and Miguel Araujo, who used a pattern:
form = MyForm(request.POST or None)
http://blip.tv/djangocon/advanced-django-form-usage-5573287
Wim
On Thursday, 31 January 2013 07:08:52 UTC+1, Shai Berger wrote:
>
> On Thur
On Thursday 31 January 2013, Byron Ruth wrote:
> Here is the ticket: https://code.djangoproject.com/ticket/19668 and the
> pull request 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 h
Here is the ticket: https://code.djangoproject.com/ticket/19668 and the
pull request 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
