Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: SVN
Component: Core (Other) | Resolution: needsinfo
Severity: Normal | Triage Stage: Design
Keywords: | decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* status: new => closed
* ui_ux: => 0
* resolution: => needsinfo
* easy: => 0
Comment:
Malcolm explained why the code is written in this way, and his question
stays unanswered after years.
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: closed
Component: Core (Other) | Resolution: needsinfo
Severity: Normal | Triage Stage: Design
Keywords: | decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by nickname123):
Just came across this looking for the exception with Google search.
My use case is that I have a model form with extra fields on the form than
what the model defines. I use these extra fields to auto populate some of
the model fields.
I am iterating through the form fields to add HTML5 attrs during __init__.
I need to catch FieldDoesNotExist when I try to check if the model field
has blank=True to determine if the formfield is required or not.
{{{
from django.db.models.fields import FieldDoesNotExist
def __init__(self, *args, **kwargs):
super(FooModel, self).__init__(*args, **kwargs)
for key in self.fields:
try:
mfield = self.instance._meta.get_field_by_name(key)[0]
except FieldDoesNotExist:
pass
else:
self.fields[key].widget.attrs["required"] = mfield.blank
}}}
This isn't too important, so I am just leaving the comment in case Google
brings me back here again before I grep.
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Cleanup/optimization | Version: master
Component: Core (Other) | Resolution:
Keywords: | decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: needsinfo =>
Comment:
I'd like to reopen this just to hopefully have this oddity resolved.
One of the comments was talking about use cases, and I wanted to give the
use case that I'm using for it to hopefully sway opinion a bit on making
this simple change.
I'm working on a template tag that will allow me to iterate over a list of
a model's fields / attributes and output it as a table. I want to grab the
verbose_name of the field, given the field's name, and to do so, I get
obj._meta.get_field(field_name). However, I also want the option to
reference class attributes and functions, and obviously if I reference a
function or attribute, there is no matching field. Thus, I need to call
get_field, and catch FieldDoesNotExist to handle it as a function /
attribute and get a separate label.
There doesn't seem to be a more "obvious" way to do this, and I ran into
the issue of trying to find this oddly placed exception. I understand that
moving the exception would be a serious change, but hopefully making it
importable via django.core.exceptions will resolve this inconvenience.
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Core (Other) | Resolution:
Severity: Normal | Triage Stage: Design
Keywords: | decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by tomchristie):
I believe that the correct resolution of this should be whatever decision
is made in the official 'meta' API update.
Given that we don't yet document `get_fields` or `FieldDoesNotExist`
anywhere, the new public API is the correct way to resolve this one way or
the other.
https://github.com/django/django/pull/3114
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by freakboy3742):
This has been resolved as part of the Meta-refactor work, which is part of
[https://github.com/django/django/pull/3114 PR3114] - see commit
[https://github.com/PirosB3/django/commit/f96990ff71d30a7397b07367e93404d816ad085b
f96990ff].
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by claudep):
Even if it is not documented, searching for `FieldDoesNotExist` on github
for example reveals many usages of this import location in the wild, hence
I think we should provide some deprecation path.
It should be possible for example to create a
`django/db/models/fields/FieldDoesNotExist.py` module to trigger the
deprecation warning on old import location (don't know if there is a
cleaner way to deprecate import locations).
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by claudep):
Of course, my "trick" about a `FieldDoesNotExist.py` file only works if we
want to loudly fail with an explicit message. Still looking for a way to
raise a warning without ever calling the symbol (might be impossible...).
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: telenieko | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Design
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"8958170755b37ce346ae5257c1000bd936faa3b0"]:
{{{
#!CommitTicketReference repository=""
revision="8958170755b37ce346ae5257c1000bd936faa3b0"
Fixed #9104 -- Moved FieldDoesNotExist to core.exceptions
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/9104#comment:12>