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 -- 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/CQR7M2ETHGY3WKV24F533KIK6TV63LVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to