malmiteria writes:
> to give you exemples of problems :
> 1) let's start with a django problem :
> ```
> class MyView(ModelView, PermissionMixin): pass
> ```
>
> Since it's mostly made out of django stuff, it's likely there
> wouldn't be automated testing to check if the permissions are
> indeed required when attempting to visit whatever resource MyView
> serves. After all, automated testing should test your code, not the
> library you're importing's code.
PermissionsMixin is documented to be *abstract* -- there are *no*
default permissions in it. It either does nothing or errors when you
try to use the methods it declares.[1]
The permission-checking is (and must be) your code. For one thing,
that's what "abstract" means, and in any case *permissions will be
defined by your application*, and permissions violations are an
application problem that the app devs should be testing for, if only
because ransomware is a billion-dollar industry. Upstream is not
going to pay your ransom if some hacker walks in a door *you* left
wide-open and steals all your data.
I wish you'd stop making up non-problems and show us either working
code where you had to do something horrible (like use _as_parent)
because of the MRO, or non-working code where you have to restart from
scratch because of the MRO. By "working" I mean it has some use other
than making the point that Python's use of the MRO sucks.
> If O1 and O2 are refactored into N1(GP) and N2(GP)
> the MRO as it was before refactoring was essentially N1, GP, N2, GP,
> as what was O1 before refactoring is equivalent to N1, GP after
> refactoring.
> After refactoring, the MRO is now N1, N2, GP. Which do behave
> differently, in general.
Nobody denies that.
[...]
> And no, class.method doesn't work in this case either.
I don't understand what you mean by that. Here's a concrete
implementation of the case, where O1.a and O2.a don't even share any
code, and only N2 overrides a after refactoring a into a parent class
GP.
% python3.10
Python 3.10.4 (main, Mar 25 2022, 04:37:13) [Clang 13.0.0 (clang-1300.0.29.3)]
on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class GP:
... def a(s):
... print('This is GP')
...
>>> class N1(GP):
... pass
...
>>> class N2(GP):
... def a(s):
... print('This is N2')
...
>>> class C(N1, N2):
... def b(s):
... print('super: ', super().a(s))
... print('N1: ', N1.a(s))
... print('N2: ', N2.a(s))
... print('GP: ', GP.a(s), " # for completeness, the N1 case is the important
one')
...
>>> c = C()
>>> c.b()
super: This is N2
N1: This is GP
N2: This is N2
GP: This is GP # for completeness, the N1 case is the important one
>>>
That's what I would want. I don't have to go farther down the
hierarchy than the class I explicitly declared to get the result I
want. What do you mean by "work"? Or do you mean a different case?
If so, what is it?
Steve
Footnotes:
[1] It could be "abstract" in the sense that there is a standard way
to express permissions defined by the methods, but none are loaded.
Then it does nothing when its methods are invoked. Or it could be
abstract in the sense of providing unimplemented methods, in which
case they will error.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/URP3XQ3566R5YJ7S5VIZQ5HSNKNNQ43P/
Code of Conduct: http://python.org/psf/codeofconduct/
