This thread is a little head-spinning. OP and replies are almost as difficult
to understand as the official documentation of super() :D
I'm not going to pile on, but I will provide an example I recently worked on
that illustrated to me both the difficulties and possibilities of the current
system. I'm just going to present the problem, not my solution (sorry). I hate
the often over-simplified examples that are included in these sort of
discussions, but a lot of us would probably be fired if we ever posted real
world examples here, so...
Let's say we have one of your class-ical ( :D ) geometrical shapes hierarchy,
including an abstract Shape class.
```
class Shape(abc.ABC):
@abc.abstractmethod
def area(self):
""""""
class Circle(Shape):
def __init__(self, r):
self.r = r
def area(self):
return 3.14159*self.r**2
class Conic(Circle):
def __init__(self, r, k):
super().__init__(r)
self.k = k
def area(self):
""" Imagine it's a formula """
```
This is pretty close to my real life example. Now, in my real life example,
what I have a need, or perhaps I should say a strong desire for, is the ability
to assign callback or property to these parameters r or k, or whatever else. I
could re-write these classes so that all parameters are explicitly callbacks,
but then consumers of this library would need to adjust their use accordingly.
I could re-implement the __init__ functions, use hidden private variables, and
add properties to achieve the same effect. I could even write decorators to
reduce the amount of copy-pasta needed to make it all work. But this would, in
my situation, likely discourage other potential collaborators from making
contributions to the code.
In my mind, the best way to make the code work, and promote use and
contribution to it, is to make it so that users can pass in callables instead
of fixed values to __init__, and the machinery that returns an object will
create properties to represent that value if it is a callable, otherwise
attributes as shown above. I will not detail my solution here, but if you know
how properties work, then you know that this solution requires classes to be
generated on the fly. This problem was a tough nut to crack, and I'm only 95%
happy with my solution. It eventually consisted of custom metaclasses and a
__new__ each for both the metaclasses and the "real" classes. Don't forget, the
base class is an abstract base class, which has its own metaclass. I did
eventually get it to work with an acceptable amount of hoops to jumps through
for potential collaborators, and none for potential users. But it was not made
any easier by the current implementation of super(), and definitely not by the
lack
of detailed documentation on what exactly super() does. "Returns a proxy..." -
but what is a proxy? If you ever really need to know, you might be in for a
long night.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CQR7M2ETHGY3WKV24F533KIK6TV63LVZ/
Code of Conduct: http://python.org/psf/codeofconduct/
