Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 Reporter:  telenieko|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"8958170755b37ce346ae5257c1000bd936faa3b0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8958170755b37ce346ae5257c1000bd936faa3b0"
 Fixed #9104 -- Moved FieldDoesNotExist to core.exceptions
 }}}

--
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/067.b611afbdaa25d105509291bc4b923225%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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: 
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/067.bc429f935d26c0b0ba59facc2e445b48%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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: 
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/067.d4911ca39cca965b0133fcc6cab0156d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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 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: 
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/067.04e4ed3edc3d700fb386099b266347b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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: 
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/067.6fa3be1a7393686633afef5e6c9dbbae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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
-+-
Changes (by wraus):

 * 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: 
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/067.67a1f98e18bc8a0ea6de793626635eb3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 Reporter:  telenieko|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
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: 
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/067.60ebecf45eee45bd0721fe355f6d9bbd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 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: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+--
  Reporter:  telenieko   | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by mtredinnick):

 We can't move it (backwards compatibility is important), but we could add
 an alias in the other place, maybe.

 However, the reason for its current location is that this is not an
 exception that correct user code will ever see. You will see something
 like `ObjectDoesExist` because that can happen naturally. But your code
 should never be catching `FieldDoesNotExist`, since that would just mean
 you had made an error in your code 99% of the time (there are some
 introspection cases where it might not. I guess that is why the admin
 interface is using it). So declaring the exception where it is actually
 used and then only using it internally isn't a bad thing.

 What's the use-case where you actually need to ever import this exception?

-- 
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 post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
-+--
  Reporter:  telenieko   | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by telenieko):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
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 post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9104: FieldDoesNotExist is defined in "confusing" place.

[Django]

#9104: FieldDoesNotExist is defined in "confusing" place.
+---
 Reporter:  telenieko   |   Owner:  nobody
   Status:  new |   Milestone:  post-1.0  
Component:  Core framework  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Django has "django.core.exceptions" package/module where most exceptions
 are defined, including DB related ones (i.e: ObjectDoesNotExist). Lame
 users like me would expect FieldDoesNotExist to be defined on the same
 module but it's in django.db.fields

 Maybe we could move the exception?

-- 
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 post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---