Stephen J. Turnbull writes:
> It's usually helpful to assume that if you parse someone's statement
> as nonsense, then probably you parsed it wrong.
Sorry, s/wrong/inconsistent with the statement's intended meaning/.
Obviously the statement was parsed correctly as English. It's "wrong"
only
Steven D'Aprano writes:
> On Sat, Apr 23, 2022 at 10:18:05PM +0900, Stephen J. Turnbull wrote:
> > malmiteria writes:
>
> > > 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
Stephen J. Turnbull writes:
> 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
On Sat, Apr 23, 2022 at 10:18:05PM +0900, Stephen J. Turnbull wrote:
> malmiteria writes:
> > 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
> >
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
Thanks for your comments!
On Fri, 22 Apr 2022 at 23:27, Steven D'Aprano wrote:
>
> On Fri, Apr 22, 2022 at 08:46:38PM +1100, Matsuoka Takuo wrote:
> >
> > So I may not have been told a refactoring like that shouldn't involve
> > a new instance of overriding, but may I have essentially been told
On Fri, Apr 22, 2022 at 08:46:38PM +1100, Matsuoka Takuo wrote:
> On Fri, 22 Apr 2022 at 15:47, Christopher Barker wrote:
> >
> > Sure -- but there's nothing special or difficult here -- refactoring
> > can create breaking changes. I believe it was part of Hettinger's
> > thesis in "Super
On Wed, Apr 20, 2022 at 03:43:44PM -, malmiteria wrote:
> to give you exemples of problems :
> 1) let's start with a django problem :
> ```
> class MyView(ModelView, PermissionMixin): pass
> ```
> doesn't apply any of the PermissionMixin logic to the view.
> It doesn't raise a single error
On Fri, 22 Apr 2022 at 15:47, Christopher Barker wrote:
>
> Sure -- but there's nothing special or difficult here -- refactoring can
> create breaking changes. I believe it was part of Hettinger's thesis in
> "Super Considered Super" that the use of super() is part of the API of a
> class
>
> On Thu, 21 Apr 2022 at 02:45, malmiteria wrote:
> > 4) Lib refactoring are breaking changes
> > A Lib author refactoring his code by extracting a class as a parent
> class of multiple of the class provided is introducing a breaking change.
>
> > After refactoring, the MRO is now N1, N2, GP.
On Thu, 21 Apr 2022 at 02:45, malmiteria wrote:
>
> 4) Lib refactoring are breaking changes
> A Lib author refactoring his code by extracting a class as a parent class of
> multiple of the class provided is introducing a breaking change.
> Because any user's code inheriting from at least 2 of
Greg Ewing writes:
> Even if you do, it's still an arbitrary choice to prefer the leftmost
> method, which might be what you want or might not.
Yep, i 100% agree with you, and that's (one of) my problems with current MI in
python, and the reason i named that thread MRO and super don't feel so
malmiteria writes:
> Stephen J. Turnbull writes
> > Every feature means making an arbitrary choice that may or may
> > not be what the programmers wanted.
>
> I don't think that's what greg meant.
I don't either. That's a separate comment that I made about the
nature of developing a
On 18/04/22 7:29 pm, malmiteria wrote:
It's an arbitrary choice that the C3 feature itself makes, and the programmer
is left guessing what that choice was, unless they can take the time to learn
C3 in depth.
Even if you do, it's still an arbitrary choice to prefer the leftmost
method, which
Stephen J. Turnbull writes
> Every feature means making an arbitrary choice that may or may not be
> what the programmers wanted.
I don't think that's what greg meant.
It's not an arbitrary choice between multiple possible features that would
cover the same need.
It's an arbitrary choice that
Greg Ewing writes:
> On 16/04/22 10:46 pm, Steven D'Aprano wrote:
> > There is no *guessing* in the C3 linearization algorithm.
>
> "Guessing" in the context of that Zen line means making an arbitrary
> choice that may or may not be what the programmer wants. It doesn't
> mean choosing at
I'm a bit late to this conversation, but here i go:
Steven d'Aprano writes:
> But given the assumptions that:
>
> - the inheritance model automatically resolves conflicts;
>
> - the MRO is entirely dependendent on the shape of the inheritance
> graph, and not on incidental properties like
On 16/04/22 10:46 pm, Steven D'Aprano wrote:
On Sat, Apr 16, 2022 at 05:56:13PM +1200, Greg Ewing wrote:
There's nothing incoherent or inconsistent about the way C++
and Eiffel do MI.
Good thing I never said that they were incoherent or inconsistent.
You seemed to be implying that,
On 16/04/22 11:13 pm, Steven D'Aprano wrote:
So we might say that all inheritance is delegation, but not all
delegation is inheritance. We might even go further and say that any
delegation to a superclass (not just the direct parent) is a form of
manual inheritance.
To my way of thinking,
On Sat, Apr 16, 2022 at 05:27:57PM +1200, Greg Ewing wrote:
> On 15/04/22 10:37 pm, Steven D'Aprano wrote:
> >If you look at languages that implement MI, and pick the implementations
> >which allow it with the fewest restrictions, then that is "full MI".
>
> >I believe that Python (and other
On Sat, Apr 16, 2022 at 05:56:13PM +1200, Greg Ewing wrote:
> On 16/04/22 12:56 pm, Steven D'Aprano wrote:
> >If you exclude models of MI which are logically incoherent and
> >inconsistent, (such as Python's prior to version 2.3), then Python's
> >model of MI is objectively as complete as you can
On 16/04/22 12:56 pm, Steven D'Aprano wrote:
If you exclude models of MI which are logically incoherent and
inconsistent, (such as Python's prior to version 2.3), then Python's
model of MI is objectively as complete as you can get.
You seem to be assuming that "full MI" has to include a fully
On 15/04/22 10:37 pm, Steven D'Aprano wrote:
If you look at languages that implement MI, and pick the implementations
which allow it with the fewest restrictions, then that is "full MI".
I believe that Python (and other languages) allow MI with
the smallest set of restrictions, namely that
On Fri, Apr 15, 2022 at 05:41:55PM -, malmiteria wrote:
> Sticking to the way its done "just" because it's the way it's done
> helps stabilising the language, but it makes it possible to miss
> improvements.
>
> Overall, if there's only valid reasons to implement a change, this
> change
On Sat, 16 Apr 2022 at 11:00, Steven D'Aprano wrote:
> > and therefore
> > would become the only thing that offers "full MI", displacing other
> > languages. It's a meaningless concept, unless there is some form of
> > absolute completeness that can be attained
>
> Well duh Chris, sometimes I
On Sat, 16 Apr 2022 at 11:07, Chris Angelico wrote:
>
> On Sat, 16 Apr 2022 at 11:00, Steven D'Aprano wrote:
> > > and therefore
> > > would become the only thing that offers "full MI", displacing other
> > > languages. It's a meaningless concept, unless there is some form of
> > > absolute
On Fri, Apr 15, 2022 at 11:12:26PM +1000, Chris Angelico wrote:
> > If you look at languages that implement MI, and pick the implementations
> > which allow it with the fewest restrictions, then that is "full MI".
>
> I'm with Greg on this one, for the simple reason that a future
> language
On Fri, Apr 15, 2022 at 2:44 PM malmiteria wrote:
> I got an idea that *should* allow for some (keyword : some) of the
changes
> i want without any breaks, i kinda wanna take the time to think about it,
and
> once i'm a bit more sure of it, i'll talk about it in details.
Since you are thinking
Chris Angelico writes:
> I'm with Greg on this one, for the simple reason that a future
> language could have fewer restrictions than Python does, and therefore
> would become the only thing that offers "full MI", displacing other
> languages. It's a meaningless concept, unless there is some form
Greg Ewing writes:
> > malmiteria xD not malmalitia
> Sorry! Should have gone to Specsavers...
No worries :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On Fri, 15 Apr 2022 at 20:40, Steven D'Aprano wrote:
>
> On Thu, Apr 14, 2022 at 10:46:46AM +1200, Greg Ewing wrote:
> > On 13/04/22 8:29 am, Steven D'Aprano wrote:
> > >>When multiple parent provide candidate to a method resolution, raise an
> > >>error.
> > >
> > >Then you aren't doing full MI
On Thu, Apr 14, 2022 at 10:46:46AM +1200, Greg Ewing wrote:
> On 13/04/22 8:29 am, Steven D'Aprano wrote:
> >>When multiple parent provide candidate to a method resolution, raise an
> >>error.
> >
> >Then you aren't doing full MI any more,
>
> That sounds like a "true Scotsman" argument. Who
On 15/04/22 4:45 am, malmiteria wrote:
malmiteria xD not malmalitia
Sorry! Should have gone to Specsavers...
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Greg Ewing writes:
> That sounds like a "true Scotsman" argument. Who defines what
> "full MI" means?
+1
for the record, i consider it multiple inheritance as soon as one class can
inherit from multiple parents, no matter anything else.
> I can think of at least two languages that do something
On Thu, 14 Apr 2022 at 08:47, Greg Ewing wrote:
>
> On 13/04/22 8:29 am, Steven D'Aprano wrote:
> >> When multiple parent provide candidate to a method resolution, raise an
> >> error.
> >
> > Then you aren't doing full MI any more,
>
> That sounds like a "true Scotsman" argument. Who defines
On 13/04/22 8:29 am, Steven D'Aprano wrote:
When multiple parent provide candidate to a method resolution, raise an error.
Then you aren't doing full MI any more,
That sounds like a "true Scotsman" argument. Who defines what
"full MI" means?
I can think of at least two languages that do
On 4/13/2022 7:22 AM, malmiteria wrote:
Eric V. Smith writes:
My
suggestion is to rework your proposal to not break any existing code
I've been doing that already, and i'll keep doing it, i'm very aware of this
constraint.
What are the biggest breaking change i haven't covered yet, in your
On Wed, 13 Apr 2022 at 21:24, malmiteria wrote:
>
> Chris Angelico writes:
> > A proposal that breaks existing code, and which introduces a new way
> > to do things, will usually require multiple versions of deprecation
> > time in order to be accepted.
> Nothing is preventing us from doing that
Chris Angelico writes:
> A proposal that breaks existing code, and which introduces a new way
> to do things, will usually require multiple versions of deprecation
> time in order to be accepted.
Nothing is preventing us from doing that here.
I already intend to have the adoption syntax come
> And, on top of that, the actual change needed to switch from today's
solution to adoption is extremly simple.
> replace
> ```
> class A(B,C): ...
> ```
> with
> ```
> class A(B(C)): ...
> ```
> That's it.
`class A(B(C))` is already a valid Python syntax (for example you could use
`class
On Wed, 13 Apr 2022 at 15:02, Ganesh B wrote:
>
> I hope nicer on the code text please.
Sure. Sorry about that. malmiteria's "lib" code is
```
class HighGobelin:
def scream(self):
print("raAaaaAar")
class CorruptedGobelin(HighGobelin):
def scream(self):
print("my
On Wed, 13 Apr 2022 at 04:28, malmiteria wrote:
>
> Idk, what do you think?
I would need to see more examples to determine the limit of the
current strategy for method resolution and super. For the example at
hand, I can be happy with the following code as a lib user (using your
lib code).
```
On 4/12/2022 12:57 PM, malmiteria wrote:
So the amount of actual breakings left shouldn't be enough to justify denying
this feature IMO. Again, we'll have a clearer view on that once we get
experimental data.
What's to look for is usage of super in MI cases, since each super call in MI
today
On Tue, Apr 12, 2022, 4:31 PM Steven D'Aprano
> Except the most important one: why are you using multiple inheritence when
> you clearly don't want multiple inheritence, instead you want delegation?
>
I'll note that hundreds of posts ago, I made the FIRST reply to this
silliness, and that it
On 2022-04-12 11:02, malmiteria wrote:
My proposal would completely detach method resolution from calls to super.
essentially:
```
class A:
val = 1
class B:
val = 2
class C(A,B): pass
C.val # raises an explicitness required error
```
If you think you can come up with code that
On Tue, Apr 12, 2022 at 11:17:27AM -, malmiteria wrote:
> Steven D'Aprano writes:
>
> > So in the general case, order matters. We have to linearize the
> > superclasses, and call them in that linear order, and the best way to do
> > that is with the MRO and super.
> Why would we *have* to
Eric V. Smith writes:
> I've said this before, but I'll repeat it here: if your proposal is to
> have super().something raise an error if "something" exists on more than
> one parent class (via the MRO), then that's a breaking change and it
> will not be accepted.
The expliciteness required
On Tue, Apr 12, 2022 at 1:59 PM malmiteria wrote:
> Ronald Oussoren writes:
>
> > To be blunt: That’s not going to happen because this is big backward
> compatibility break. Either that, or this adds a
> > second way to define classes. Both are good reasons to keep the status
> quo.
>
> the
A general note on breaking changes:
On Wed, 13 Apr 2022 at 03:01, malmiteria wrote:
>
> Ronald Oussoren writes:
>
> > To be blunt: That’s not going to happen because this is big backward
> > compatibility break. Either that, or this adds a
> > second way to define classes. Both are good
Matsuoka Takuo writes:
> I don't think this is better than the failing code in any way. It
> will fail in the same way.
Yeah! i completely forgot that :p I've been redoing this exemple so many times
now, it's hard to always keep the brain turned on when writing it. Thanks for
pointing it out.
Ronald Oussoren writes:
> To be blunt: That’s not going to happen because this is big backward
> compatibility break. Either that, or this adds a
> second way to define classes. Both are good reasons to keep the status quo.
the breaking is limited MI with name collision, so likely rare
On Wed, 13 Apr 2022 at 02:00, Matsuoka Takuo wrote:
>
> Thanks for your answer.
>
> On Mon, 11 Apr 2022 at 00:46, malmiteria wrote:
> >
> > There's a few problems, mainly, if you provide ProudGobelin and
> > CorruptedGobelin as a lib author, you're very likely not to think of the
> > HalfBreed
On 4/12/2022 7:43 AM, malmiteria wrote:
Brendan Barnwell writes:
You seem to be envisioning a system in which multiple inheritance
gives a subclass a "menu" of behaviors from which it may explicitly choose,
but does not actually combine the superclasses' behaviors into a single,
definite
> On 12 Apr 2022, at 13:17, malmiteria wrote:
>
> Steven D'Aprano writes:
>
>> So in the general case, order matters. We have to linearize the
>> superclasses, and call them in that linear order, and the best way to do
>> that is with the MRO and super.
> Why would we *have* to do that?
>
Thanks for your answer.
On Mon, 11 Apr 2022 at 00:46, malmiteria wrote:
>
> There's a few problems, mainly, if you provide ProudGobelin and
> CorruptedGobelin as a lib author, you're very likely not to think of the
> HalfBreed use case, so the lib users wanting to create the HalfBreed class is
Steven D'Aprano writes:
> Do you think that the order of arguments in func(a, b) doesn't matter?
Actually it doesn't:
```
def func(a, b):
print(a)
print(b)
func(b=10, a=5)
```
would print 5, then 10
But i get what you mean, and i know very much it matters here.
> One of the reasons why
Brendan Barnwell writes:
> You seem to be envisioning a system in which multiple inheritance
> gives a subclass a "menu" of behaviors from which it may explicitly choose,
> but does not actually combine the superclasses' behaviors into a single,
> definite behavior of the subclass. In that
Steven D'Aprano writes:
> So in the general case, order matters. We have to linearize the
> superclasses, and call them in that linear order, and the best way to do
> that is with the MRO and super.
Why would we *have* to do that?
When multiple parent provide candidate to a method resolution,
Steven D'Aprano writes:
> In any case, how do you know what "most people" think? Have you done a
> survey, or are you just guessing?
I haven't done a survey, but I'm getting one ready, I also wanna let you all
have a read at it before running it, so we can all agree the data we would get
from
On Mon, Apr 11, 2022 at 3:39 AM Chris Angelico wrote:
On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull
> wrote:
> > [1] They don't have to be big problems or proprietary code; computing
> > Fibonacci sequences will do, if you can find a way to make MI relevant
> > to that task.
> >
>
>
> We
On Sun, Apr 10, 2022 at 11:50:40AM -0700, Brendan Barnwell wrote:
> You seem to be envisioning a system in which multiple inheritance
> gives a subclass a "menu" of behaviors from which it may explicitly
> choose,
> but does not actually combine the superclasses' behaviors into a
On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull
wrote:
> [1] They don't have to be big problems or proprietary code; computing
> Fibonacci sequences will do, if you can find a way to make MI relevant
> to that task.
>
Okay, I'll bite. Unfortunately for the OP, super() works perfectly here.
malmiteria writes:
> You'd need to return A.bar in C bar methods to get more symmetry,
> but what if you wanted foo to visit the inheritance tree in this
> order?
I don't want that, however. Please give up this notion that you can
tell anybody else what they might want. You need to show
On Sun, Apr 10, 2022 at 05:56:14PM -, malmiteria wrote:
> No, i'm arguing that MI is intuitively different enough from other
> context in which we use parenthesis so that most people will
> intuitively understand it to work differently (which it does, we're
> not defining argument to be
David, when you exaggerate the strength of your argument, you make all
of us look bad. Like this:
> Can you think of ANY context in Python in which the order of items in
> parentheses isn't important?!
Sure: operator.add(1, 2) == operator.add(2, 1)
For that matter, there are plenty of mixins
On Sun, Apr 10, 2022 at 03:50:48PM -, malmiteria wrote:
> Steven D'Aprano writes:
> The order in which parents are placed in case of multiple inheritance
> is far from being that obviously assymetrical, and the syntax does not
> hint it is, quite less than inheritance syntax.
Do you
On 2022-04-10 08:50, malmiteria wrote:
The order of inheritance as in, one class inherits from another do matter,
quite obviously, since it's not a symetrical operation, and accordingly, the
syntax is not symettrical.
The order in which parents are placed in case of multiple inheritance is
On Mon, 11 Apr 2022 at 03:57, malmiteria wrote:
>
> David Mertz, Ph.D. writes:
> > Can you think of ANY context in Python in which the order of items in
> > parentheses isn't important?!
> kwargs
>
Since Python 3.6, order of kwargs is preserved, and some functions do
care about it (although only
David Mertz, Ph.D. writes:
> Can you think of ANY context in Python in which the order of items in
> parentheses isn't important?!
kwargs
> You are arguing that defining inheritance order is "intuitively" the one
> and only context in which the order of items in parentheses makes no
> difference.
Can you think of ANY context in Python in which the order of items in
parentheses isn't important?!
(a, b, c) != (c, b, a)
func(a, b, c) != func(c, b, a)
etc.
You are arguing that defining inheritance order is "intuitively" the one
and only context in which the order of items in parentheses
David Mertz, Ph.D. writes:
> Are you likewise "confused" by the fact that `a = b - c` is generally
> different from `a = c - b`?!
Why do you always quote confused?
I'm not, but that's because i've been taught / i've experienced that since
primary school. I have been taught math, but not python,
On Sun, Apr 10, 2022, 11:51 AM malmiteria
> "class A(B)" feels very different from "class B(A)"
> but "class A(B,C)" doesn't feel so obviously different from "class A(C,B)"
>
Are you likewise "confused" by the fact that `a = b - c` is generally
different from `a = c - b`?!
>
Steven D'Aprano writes:
> Yes well that was just silly. Of course the order matters.
The order of inheritance as in, one class inherits from another do matter,
quite obviously, since it's not a symetrical operation, and accordingly, the
syntax is not symettrical.
The order in which parents are
On Sun, Apr 10, 2022, 10:35 AM Steven D'Aprano
> I don't believe that David's denials that people are confused by super()
> are even a little bit reasonable.
I take the words "unconcerned" and "confused" to be distinct.
___
Python-ideas mailing list
On Mon, 11 Apr 2022 at 00:35, Steven D'Aprano wrote:
> Yes well that was just silly. Of course the order matters.
>
> Even in single inheritance, the order matters:
>
> Spam inherits from Eggs inherits from Cheese
>
> is not the same as
>
> Spam inherits from Cheese inherits from Eggs
>
>
On Sun, Apr 10, 2022 at 01:53:37PM -, malmiteria wrote:
> David Mertz, Ph.D. writes:
> > I guess the main threshold to try to cross is ONE person other than
> > malmiteria in the universe of Python users.
I don't believe that David's denials that people are confused by super()
are even a
Stephen J. Turnbull writes:
> It may not be flexible, but it is quite useful. In most cases it's
> quite trivial to pick up the version from the second parent:
>
> class C(A, B):
> def foo(self, *args):
> return B.foo(self, *args)
> # we don't define bar() because we
David Mertz, Ph.D. writes:
> Malmiteria is the FIRST person I've met "confused" by super().
No need to capitalise the first letter in malmiteria.
I'm not sure what the quotes surrounding confused mean. What do you mean by
those?
> I guess the main threshold to try to cross is ONE person other
Matsuoka Takuo writes:
> For your particular case of a diamond, the solution below seems
> simpler to me than yours. What problems may it create which your
> solution won't? Or you might refine the problem. It's not easy to
> see the real value of your suggestions.
>
> ```
> class HighGobelin:
For your particular case of a diamond, the solution below seems
simpler to me than yours. What problems may it create which your
solution won't? Or you might refine the problem. It's not easy to
see the real value of your suggestions.
```
class HighGobelin:
def scream(self):
On Sat, Apr 9, 2022, 7:31 AM malmiteria wrote:
> Joao S. O. Bueno writes:
> > You are still repeating this:
> > "more in line with the expectation of the majority, "
> > Though, as already asked, there is zero (nothing) to support that.
>
Here's some more evidence of a sort: I've taught
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
Joao S. O. Bueno writes:
> You are still repeating this:
> "more in line with the expectation of the majority, "
> Though, as already asked, there is zero (nothing) to support that.
I'm also still repeating:
People most common experience with super informs their understanding and
expectations
On Fri, 8 Apr 2022 at 22:56, Joao S. O. Bueno wrote:
>
> Hi. I've replied to the first e-mail on this thread, more than 10 days ago.
> I am back, though I've read most of what was written.
>
> I don't think things have improved, but you sure are consuming everyone's time
>
> You are still
Hi. I've replied to the first e-mail on this thread, more than 10 days ago.
I am back, though I've read most of what was written.
I don't think things have improved, but you sure are consuming everyone's
time
You are still repeating this:
"more in line with the expectation of the majority, "
On Thu, Apr 07, 2022 at 11:52:31AM -, malmiteria wrote:
> I believe my gobelin exemple is a fair case of MI since we can
> definitely say halfbreed *is a* corruptedgobelin *and a* proudgobelin.
That is the most common relationship modelled by inheritance.
> In such a case with multiple
On 7/04/22 11:11 pm, malmiteria wrote:
But if there was a way to tell super what class it should be a proxy of, that
would be very easy to explain : when there's two parent, just give the parent
you want to target as an argument to super.
That sounds like exactly what Class.method(self) does
On 7/04/22 11:52 pm, malmiteria wrote:
I believe my gobelin exemple is a fair case of MI since we can definitely say
halfbreed *is a* corruptedgobelin *and a* proudgobelin.
I'm not so sure about that. I would agree that it's a gobelin, just as
you are (presumably) a human.
But a child is
If these examples were possible (I wouldn't say they are smart designs)
they would lead to recursion errors.
Limitations on MRO are good, they force to keep a quite simple structure.
Le jeu. 7 avr. 2022 à 17:41, malmiteria a écrit :
> Antoine Rozo writes:
> > If the only feature you need from
malmiteria writes:
> to dive into conceptual ideas a bit more:
I'm not sure why you assume that nobody knows this stuff, at least at
the extremely high and fuzzy level of your discussion.
Executive summary: I see a lot of theory in your posts, but it's very
difficult to tie it to *my*
Antoine Rozo writes:
> If the only feature you need from super is the proxy one, why don't you
> code your own parent-proxy-type?
I did :
https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py
This is irrelevant to the discussion we're having i think.
Essentially, I'm
malmiteria writes:
> Stephen J. Turnbull writes:
> > One really plausible example is given in Raymond's piece: a later
> > version of the same library refactors a "monolithic" class as a child
> > of one or more "private" classes that are not intended to be exposed
> > in the public API,
to dive into conceptual ideas a bit more:
inheritance is usually what we do when we mean *is a*
for exemple, a cat *is an* animal, so we would write it like that:
```
class Animal: pass
class Cat(Animal): pass
```
I believe my gobelin exemple is a fair case of MI since we can definitely say
If the only feature you need from super is the proxy one, why don't you
code your own parent-proxy-type?
class parentproxy:
def __init__(self, cls, obj):
self.__thisclass__ = cls
self.__self_class__ = type(obj)
self.__self__ = obj
def __getattr__(self, name):
Greg Ewing writes:
> If I were teaching a newcomer about super, I wouldn't even tell them
> that it *has* a class argument. So they wouldn't have any expectation
> about targeting, because they wouldn't know about it.
I would probably teach newcomers the argumentless form only too. That's all
Chris Angelico writes:
> I'm curious when you would ever be subclassing something from another
> library without knowing its hierarchy.
When the class is a public API, no? I'm not sure why this isn't
obvious, am I missing something?
One really plausible example is given in Raymond's piece: a
On Thu, 7 Apr 2022 at 15:41, Greg Ewing wrote:
> > if proudgobelin and corruptegobelin are published by a game_engine library,
> > the game_engine user would most likely not be aware (nor should he care)
> > that they both inherit from a same parent.
>
> If someone is going to munge those
On 7/04/22 5:22 am, malmiteria wrote:
Also, i believe the idea of using anything but super to access a parent methods
is far from obvious to most people.
That might be true for people who learned Python recently enough. When
I started using Python, super didn't even exist, so I got used to
Steven D'Aprano writes:
> > All we have today is the screwhammer, and in cases the screw part
> > don't work, you're telling me to get rid of it all. hammer part
> > included.
> That's not how I see it.
> I see that we have a screwdriver (inheritence, including multiple
> inheritence) which
On Wed, Apr 06, 2022 at 08:28:59PM +1200, Greg Ewing wrote:
> I actually think super() is misnamed and should really be called
> next_class() or something like that. There might be less confusion
> about its intended use then.
Heh, we should rename it frábær(), that will ensure that nobody will
1 - 100 of 193 matches
Mail list logo
