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.