Question on ABC classes

[Julio Di Egidio]

On Friday, 30 October 2020 05:09:34 UTC+1, Chris Angelico  wrote:
> On Fri, Oct 30, 2020 at 1:06 PM Julio Di Egidio <julio at diegidio.name> wrote:
> > On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer  wrote:
> > > I think you are trying to use Python in a way contrary to its nature.
> > > Python is a dynamically typed language. Its variables don't have types,
> > > only its objects. And basically everything can be changed at runtime ...
> >
> > Consider this example:
> >
> > def abs(x):
> >   return math.sqrt(x.re**2 + x.im**2)
> >
> > That of course fails if we pass an object not of the correct
> > (duck) type.  But the exception is raised by math.sqrt, which,
> > properly speaking, beside considerations on usability, is a
> > private detail of the implementation of abs.
> 
> Not sure what sorts of errors you're expecting, but for the most part,
> if it's not a complex number, you should get an AttributeError before
> you get into the sqrt.
<snip>

Yes, sorry, I was glossing over an example that was meant
to be just general.  I could have written something like:

def abs(x):
  ...bunch of possibly complex operations...

and that that is completely opaque both to the user of the
function as well as, in my opinion, to its author (code must
speak to speak for itself!).

Not to mention, from the point of view of formal verification,
this is the corresponding annotated version, and it is in fact
worse than useless:

def abs(x: Any) -> Any:
  ...some code here...

Useless as in plain incorrect: functions written in a totally
unconstrained style are rather pretty much guaranteed not to
accept arbitrary input... and, what's really worse, to be
unsound on part of the input that they do accept: read
undefined behaviour.

> But here's the thing: even if that IS the case, most Python
> programmers are fine with getting an AttributeError stating exactly
> what the problem is, rather than a TypeError complaining that it has
> to be the exact type some other programmer intended. A good example is
> dictionaries and dict-like objects; if your code type checks for a
> dict, I have to give you a dict, but if you just try to do whichever
> operations you need, I can create something more dynamic and give you
> that instead.

I did say "duck-typing or not". I was not talking of restricting
dynamism (python protocols are an implementation of duck typing
and can be used in typing annotations, even generic protocols),
the point is making intentions explicit: to the benefit of the
user of that code, but also to that of the author, as even the
author has to have some "plan" in mind.  As well as, eventually,
to the various tools and checkers.

> Python doesn't push for heavy type checking because it's almost
> certainly not necessary in the majority of cases. Just use the thing
> as you expect it to be, and if there's a problem, your caller can
> handle it. That's why we have call stacks.

I am learning Pandas and I can rather assure you that it is an
absolute pain as well as loss of productivity that, whenever I
misuse a function (in spite of reading the docs), I indeed get
a massive stack trace down to the private core, and have to
figure out, sometimes by looking at the source code, what I
actually did wrong and what I should do instead.  To the point
that, since I want to become a proficient user, I am ending up
reverse engineering the whole thing...  Now, as I said up-thread,
I am not complaining as the whole ecosystem is pretty young,
but here the point is: "by my book" that code is simply called
not production level.

Julio