Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Marc Tamlyn ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"be733bf672eebb7d03061a293a2b0b03c727ab44"]:
 {{{
 #!CommitTicketReference repository=""
 revision="be733bf672eebb7d03061a293a2b0b03c727ab44"
 [1.7.x] Fixed #22510 -- Harden field removal to only None.

 Refs #8620.

 If we allow any value to remove form fields then we get name clashes
 with method names, media classes etc. There was a backwards
 incompatibility introduced meaning ModelForm subclasses with declared
 fields called media or clean would lose those fields.

 Field removal is now only permitted by using the sentinel value None.
 The docs have been slightly reworded to refer to removal of fields
 rather than shadowing.

 Thanks to gcbirzan for the report and initial patch, and several of the
 core team for opinions.

 Backport of 9fb0f5dddc4cf7f2d294af1bcde2c359cffd90a5 from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.d424914811afe90e7f9a6e03affaf7fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mjtamlyn):

 Pull request for the `None` approach:
 https://github.com/django/django/pull/2706

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.ff040e7a0edbe2c970e20ad578ba7f26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 I guess my preference for 3 comes down to `ignored_fields` being an API
 vs. `None` as a sentinel value being a trick.

 Regarding the documentation-only fix, I suspect it'll be an issue to quite
 a few people. I can imagine it's pretty common to have a model field
 called `media` or `clean`, and since DTL gives more precedence to `dict`
 lookups than it does to attribute lookups I suspect most never noticed
 that they were shadowing form attributes in their templates.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.7df66575154abfb87e98b6b148924a94%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by aaugustin):

 With reference to the list in comment 6, my order of preference is 1, 3,
 2.

 - It seems quite natural that clashes between field names and form method
 names cause errors. +0 to just documenting that.
 - Adding `ignored_fields` isn't too bad, but it's one more API that our
 users may encounter. +0 to adding this API.
 - Requiring that shadowing only works with a `None` is seriously
 idiosyncratic. -0 to that solution.

 I hope this helps!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.4b2a42a4e8914d813d2bef3de46aad67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timo):

 * component:  Documentation => Forms


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b52ff9994813fc04f0e2c481d465d22f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mjtamlyn):

 Ugh, so much for getting things done at sprints, sorry. I discussed with
 Russ and although part of his argument was "just use del" he decided he
 was happy enough with `None` as a sentinel, and preferred it to
 `ignore_fields`. This is still on my list, but if anyone else gets time
 then feel free.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.862a7251014ecda07638ef257f5b9f51%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 My preference still goes to `ignore_fields` but I wouldn't stand in the
 way of using `None` as a sentinel value since it's a decent solution that
 would indeed fix the regression on `Form.media`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.3403904002ebb1698a9618f6e687e535%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mjtamlyn):

 Ok fair point I now see why `MyForm.foo !== MyForm['foo']`.

 Having reviewed the available options, I'm happy to make a design decision
 to harden the current recommendation to use `None` into a requirement to
 use `None` assuming that solves this ticket (which I believe it does). If
 there are no objections, I can commit this at the sprints on Friday.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.4968919cf3e8bd06fc5372fb7268f90b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 Allowing `MyForm().foo == MyForm['foo']` would require additional magic.
 Fields defined declaratively are stored in `Form.declared_fields`, those
 fields should be considered immutable, they are then cloned into
 `Form.fields` in `Form.__init__` where they can be freely modified by form
 instances. If we just stuck to python inheritance and didn't remove
 fields, we'd expose a big footgun where altering `self.fieldname` would
 alter the form globally. We could mitigate the problem by shadowing
 declared fields by their clone in `__init__`, but that's just additional
 magic, and it doesn't offer much benefit over `Form.fields`. All in all,
 I'm -0 on this option.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.2018bc8812f1d1367773764e116efd27%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by anonymous):

 Replying to [comment:9 mjtamlyn]:
 > I am strongly in favour of loic's option number 1 - change no code and
 document the problems with naming fields after things which would be on
 the form anyway. In the spirit of the fix for #8620 (making forms behave
 more like "normal" python objects), this makes sense anyway.

 This is, in no way similar to how normal python objects behave. In
 particular, normal Python objects do not silently discard attributes you
 put on the class definition. Also, normal objects, as you mention, do not
 magic attributes into `__getitem__()` stuff.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.8b90ab4845fedadcfef637adf3c456e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by mjtamlyn):

 * component:  Forms => Documentation


Comment:

 I am strongly in favour of loic's option number 1 - change no code and
 document the problems with naming fields after things which would be on
 the form anyway. In the spirit of the fix for #8620 (making forms behave
 more like "normal" python objects), this makes sense anyway.

 As a side note, it would be much more incompatible (but imo better) to not
 remove the field definitions from the form object at all - i.e.
 `MyForm().foo == MyForm['foo']`. This may have serious implications for
 the use of forms in DTL though. However, it would potentially give us the
 option of using the metaclass simply to define fields after the class is
 resolved normally by python. This is likely a step too far.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.fce9162b44ff2cc925d1b19d385fb593%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by loic84):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 I've renamed `shadow_fields` to `ignore_fields` on the premise that
 "overloading" (which forms support) is also a form of shadowing, whereas
 this feature is only about opting out from previously declared fields.

 @apollo13 commented on the PR "Shadow_fields should at least be on meta to
 not clutter the form namespace any more". The issue is that normal `Form`
 don't support `Meta`, and I'm not convinced we should start introducing
 it. We already have a bunch of fields related attributes, namely `fields`,
 `base_fields`, `declared_fields`, IMO `ignore_fields` fits nicely.

 I like this implementation better because there is now an obvious parallel
 between the handling of `declared_fields` and `ignore_fields`, it also
 does away with fiddling with `__dict__`.

 To move this ticket forward we need to make a design decision, but if this
 solution is retained the patch on the PR is ready for review.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b9fa6d783f746fd9a3467d38841161c8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by loic84):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1


Comment:

 POC for the `shadow_fields` option:
 https://github.com/django/django/pull/2615/.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.4e18a57806848db51d7d4c18128c3023%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 I've discussed this with @gcbirzan on IRC, there is indeed a regression on
 attributes called `media`.

 Since `MediaDefiningClass` monkeypatches each subclass with a `media`
 attribute, it effectively shadows any field called `media`.

 Moving the shadowing before the parent's fields discovery as suggested
 above would allow a single Form to have a `media` field, but that wouldn't
 work when inheritance is involved anyway.

 The problem could also manifest itself with overridden methods that would
 clash with a field name:

 {{{
 Form(forms.Form):
 clean = forms.BooleanField()

 Form2(Form):
 def clean(self):
 pass
 }}}

 Options I can think of:
 - Backward incompatible change, care must be taken when subclassing a form
 not to accidentally shadow a field with a method, and a special mention
 for `media`.
 - Change the shadowing logic to use a sentinel value (e.g. `None`, or a
 `ShadowField` object).
 - A declarative class attribute to list the fields to shadow:
 {{{
 Form(forms.Form):
 something = forms.CharField()

 Form2(Form):
 shadow_fields = ['something']
  }}}

 For reference the ticket for field shadowing is #8620.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.6910b6039ea6af7d950b0d9d2f0ec4a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timo):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.bb82c83d4e44a0e9e1ca15a10c12aaab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 @gcbirzan, I don't really understand, could you provide a set of examples
 (in documentation format rather than test)?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.1b9ab59addfd504e9b9f1f9c9ba94cfd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by gcbirzan):

 Replying to [comment:2 loic84]:
 > At the time I suggested we only allowed shadowing with `None`, @mjtamlyn
 convinced me that we should follow normal Python inheritance/shadowing and
 I think that was a good decision.

 True, but the problem is that the builtin Form fields also have this
 property. It's made worse by, for example, media being set by magic via
 the previous meta class, so it's set on each of the classes that inherit
 from Form.

 > I see value in matching as closely as possible the MRO behavior, other
 than the fact that `Field` magically remove themselves from the class
 (whether shadowed or not), we are pretty good on that front.
 >
 > Inheritance makes this kind of clash possible, but a single form
 couldn't define both a `Field` and an attribute anyway.
 >
 > To expose a `media=42` attribute like in the test of the proposed patch,
 one can set `self.media` in `__init__()`, or ensure that it appears first
 in the MRO. By ensuring it appears first in the MRO it won't shadow any
 field, and it will not be shadowed itself because fields are removed from
 the class.

 To be honest, I don't remember why media = 42 is in there, it doesn't
 really matter, it happens either way.

 As for the proposed solution, with `__init__()` is ugly and, at the very
 least, needs documentation explaining that things you don't manually set
 might have this effect.

 > We document:
 >
 > {{{
 > It's possible to opt-out from a ``Field`` inherited from a parent class
 by
 > shadowing it. While any non-``Field`` value works for this purpose, it's
 > recommended to use ``None`` to make it explicit that a field is being
 > nullified.
 > }}}
 >
 > Which is exactly the case described in the test of the proposed patch.

 True. But even so, there's another bug that's fixed by my patch.
 Reordering the shadowing and collecting means that, if nothing else,
 defining media as a field on a form will work, if there's no other
 inheritance.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.65f2e3a823f8f38ba5e9643f646ccd9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 At the time I suggested we only allowed shadowing with `None`, @mjtamlyn
 convinced me that we should follow normal Python inheritance/shadowing and
 I think that was a good decision.

 I see value in matching as closely as possible the MRO behavior, other
 than the fact that `Field` magically remove themselves from the class
 (whether shadowed or not), we are pretty good on that front.

 Inheritance makes this kind of clash possible, but a single form couldn't
 define both a `Field` and an attribute anyway.

 To expose a `media=42` attribute like in the test of the proposed patch,
 one can set `self.media` in `__init__()`, or ensure that it appears first
 in the MRO. By ensuring it appears first in the MRO it won't shadow any
 field, and it will not be shadowed itself because fields are removed from
 the class.

 We document:

 {{{
 It's possible to opt-out from a ``Field`` inherited from a parent class by
 shadowing it. While any non-``Field`` value works for this purpose, it's
 recommended to use ``None`` to make it explicit that a field is being
 nullified.
 }}}

 Which is exactly the case describe in the tests.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.e396a3eabd07dc0d6cde54ed5e9d5ff2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timo):

 * cc: loic84 (added)
 * needs_better_patch:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Loic, could you take a look at this?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.f5ab72862f95d5e841ec930f93780669%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.