#30941: hasattr(request, '_cached_user') check no longer works
---------------------------------+------------------------------------
Reporter: Collin Anderson | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth | Version: master
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 Nick Pope):
I'd not really been following along, so just caught up on the comments
here.
If we revert, then I honestly think that this should be documented. Or at
least have a comment in the code to say that this is going to be supported
for third-parties and shouldn't be removed.
----
I've got to be honest and say if you're going to use code that is
**clearly** marked as private - ''that is the underscore prefix convention
in Python'' - you've got what's coming to you and you haven't got a leg to
stand on. Yes, it doesn't stop me either, but I would accept that I'm in
the wrong and will have to deal with the fallout. In addition, as
highlighted above, many of the cases are copy-paste from Django's own
code. That is just sloppy and if encouraged, or at least not discouraged,
no changes would ever be possible because "someone might have copied it
and used it" in a way that was never intended.
To quote the Python [https://docs.python.org/3/tutorial/classes.html
#private-variables documentation]:
> “Private” instance variables that cannot be accessed except from inside
an object don’t exist in Python. However, there is a convention that is
followed by most Python code: a name prefixed with an underscore (e.g.
`_spam`) should be treated as a non-public part of the API (whether it is
a function, a method or a data member). **It should be considered an
implementation detail and subject to change without notice.**
I also don't really understand why `hasattr()` checks are needed here in
other middlewares. My question wasn't answered. Surely you just need to
access `request.user` if you need the user object and if you don't, you
don't. If this is to check whether we've called this and thus assigned
`request.user` prior to using that elsewhere, then it sounds like a
middleware ordering problem. Or not subclassing a middleware properly.
> Grrr. I think it's
[https://github.com/search?l=Python&q=_cached_user&type=Code more than
sometimes...]. 😬
I find GitHub code search to be dreadful. It doesn't provide capability to
filter out partial paths. Yes that says 53K+ results, but the vast
majority seem to be vendored copies of Django and other projects that have
copied bits of Django and then been vendored themselves which will,
frankly, not be affected.
> The user has been cached on the request here for 13 years.
Just because something is old, that doesn't mean it shouldn't necessarily
change.
> Exactly this. Custom middleware's leveraging `_cached_user` but not
setting a `user` that has `_wrapped` property... (and so on).
I was merely suggesting an example to complement proposals in other
comments, but posited whether we actually wanted to do this as we'd have
to document `LazyObject` which is currently private. (That is another
private thing that unfortunately bleeds across public interfaces, notably
in lazy translations.)
----
Anyway, this is a relatively small change so it isn't something that is
the end of the world and I won't get in the way of it if the majority want
to revert. I just have a different view that progress shouldn't be stymied
just because something has always been that way, is old (and thus
venerated?), or because people broke convention and thus we need to
capitulate and accept all "bad" behaviour. Yes, there is not breaking
backward compatibility, but that is different to not breaking something
where backward compatibility was never guaranteed.
--
Ticket URL: <https://code.djangoproject.com/ticket/30941#comment:16>
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.3c4b0ff66750f1915579117110a5b2ca%40djangoproject.com.
