#30941: hasattr(request, '_cached_user') check no longer works
---------------------------------+--------------------------------------
     Reporter:  Collin Anderson  |                    Owner:  nobody
         Type:  Bug              |                   Status:  new
    Component:  contrib.auth     |                  Version:  master
     Severity:  Normal           |               Resolution:
     Keywords:                   |             Triage Stage:  Unreviewed
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+--------------------------------------

Comment (by Nick Pope):

 > This is really helpful in middleware to be able to check whether the
 user has been evaluated, so you can access the user if it has already been
 accessed, but can avoid fetching user if it hasn't already been fetched.

 I can't understand the use case described here. Surely you either need to
 access it in the middleware, or you don't. Maybe you could explain why
 you'd need to only get it if it has already been accessed...

 > FWIW I'd much prefer we define a blessed way of looking this up then
 maintaining compatibility with this implementation specific `_cached_user`
 hack.

 Agreed. This always looked like a hack and it is an undocumented and
 private variable after all. That said, a way to determine whether
 `LazyObject` has been resolved would be good. The main challenge is
 conflicting attributes with the wrapped object, so I think `.loaded` is
 too problematic. I would suggest creating and documenting `_resolved` to
 go alongside `_wrapped`:

 {{{#!python
 class LazyObject:

     ...

     @property
     def _resolved(self):
         return self._wrapped is not empty

     ...
 }}}

 I also note that `LazyObject` and `SimpleLazyObject` are vaguely
 referenced in the documentation, but mainly in release notes where it
 occasionally says things like "if you use ... in your own code". There is
 no proper public documentation so these are sort of internals that are
 sometimes used in projects. Do we really want to make this officially
 public API?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30941#comment:5>
Django <https://code.djangoproject.com/>
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.2deccd0d3ec375170a84d6f51a5ee6b3%40djangoproject.com.

Reply via email to