Greg ewing writes:
That sounds like exactly what Class.method(self) does today. Why do we need another way to do it?
Because that's a completely different syntax from the commonly used super, it's likely enough that some people wouldn't think of it to be a problem. Again, if you disagree with this statement, fine, argue with it, but come on now, stop ignoring my answer to your question and act like i didn't answer.
That's not the kind of knowledge I'm talking about. You need to know a lot about how those particular classes behave -- what their methods do, whether they would conflict with each other in any way, what the consequences would be of calling them in various orders, etc. First of all, LOL who is even doing that? I get that you need to know a minimum about anything before using it, but diving in depths in any library you use is not the norm, to say the least. Second of all, how would you go about that? running instances of those classes, and watching their behavior? reading the docs (that would talk about their independant behavior, and never care to explain if any method calls super)? something else?
You would still get the surprise when inheriting from 2 classes that sometimes, one's behavior would be overriden by the other, or that one's behavior is 'interrupted' by the other. Sometimes that's what you want, as in cases where you only want one commit to a database, for exemple. But not in all cases. And you have no way to tell before actually running the code.
You seem to think that removing the MRO and making super work the way you imagine it should would make it easy to grab any bunch of arbitrary classes and inherit from them and everything would be fine and dandy. Well, it would make for an easier experience in those hard MI cases, and an equivalent experience in the simple cases.
I still don't understand how you expect a particular super call in a particular method to somehow be able to jump sideways when you want it to and not other times. Simple. I never want it to jump sideways.
You'll have to provide a detailed example, not just vague waffling about mixins and proxying. Okay, but waffles are good tho.
again, read it : https://github.com/malmiteria/super-alternative-to-super/tree/master/convers... It's been up for a long time now. I'll just repeat it here, so you can't complain about having to click once (and you tell me people read the docs huh?): assume you're making a web framework, you'll have a lot of View classes, based on different needs: ``` class GenericView: def render(self): # does something generic class ModelView: def render(self): # does something related to models class DetailView: def render(self): # does something for one instance of a model class ListView: def render(self): # does something for all instance of a model ``` Now, you also wanna allow for some of those view to require users to be logged in, or have the permission to access it. You could create a PermissionGenericView, a PermissionDetailView, and so on, but that's not DRY at all, so you kinda have to do it like that: ``` class Permission: def render(self): if not self.user.has_perm(): raise PermissionError return super().render() class LoginRequired: def render(self): if not self.user.is_logged_in(): raise LoginError return super().render() ``` Then, your frameworks users would have to integrate those view and mixins like that: ``` class MyView(Permission, DetailView): pass ``` Turns out, this : ``` class MyView(DetailView, Permission): pass ``` Is not equivalent at all, since it completely mutes Permission render. In this case, what you really want is Permission to inherit from DetailView as it is meant to extend it's render behavior. My adoption proposal is to allow for this syntax: ``` class MyView(Permission(DetailView)): pass ``` Which makes it so that MyView inherits from Permission, which itself inherits from DetailView. I'd argue it's also quite intuitive as you can see here it was the first reaction of Stephen J. Turnbull to this syntax: Stephen J. Turnbull writes
malmiteria writes:
That's why my proposal for those cases is to allow inheritance to be postponed after definition time, and set by the final child class that inherits from those.
class Sphynx(Hairless(Cat)): pass That doesn't "look like" a mixin, though. That looks like a simple inheritance chain
And that despite the fact that Stephen and I 's experiences with mixins seems very different. I've mostly been confronted with mixin that do extend their non mixin class behavior. Hence the reason of me presenting adoption as an alternative to mixins. However, if mixins are used like in Stephen's experiences, meaning, essentially gluing together a bunch of attributes / method that are meant not to override, then MI would work the exact same before and after my proposal for those mixins. With the added bonus that you would get an error when two attributes that have the same name would now raise an error, alerting the user of an overriding. In this scenarios, this is a bug from the mixin's author, that needs addressing. Today debugging it is extremely awkward, since you would only observe unexpected behavior, with possible no errors, or unrelated errors if this overrides leads to error down the line.