[Python-Dev] type categories

[Samuele Pedroni]

some thoughts of mine

[GvR]
> Agreeing on an ontology seems the hardest part to me.

Why does it seem such a daunting task?

i) much of python code depends concretely on interfaces with the granularity
from one to a bunch of methods, especially code expecting base-type-like
implementations.
ii) people appreciate to be able to implement just the minimal subset of
methods that makes things work

[Obviously here I'm not talking about large frameworks like Zope]

We are not in vacuum. There is Python code out there, and progammers with ideas
about what is like programming in Python.

[Maybe I just restate the obvious and repeat myself but it seems that for some
people not only type checking but in general explicitness about types is a tabu
for Python code.
OTOH there _exists_ Python code that  as input depends/requires subclasses of
some _specific_ abstract classes. And even Smalltalk has - when "reasonable"
and "necessary" - a kind of interface notion, in the form of isFoo method
defined on Object and overridden to return "yes sir" down the hierarchy]

It seems to me that there is no route to the advantages of type categories
without some explicitness.

Now to the point.
[Here my target is more dispatching and "distinguishing" by type categories
than type checking, PEP 246 issue is far from orthogonal but here I will ignore
it because I don't want my head to explode <wink>]

Maybe it is obvious but anyway type categories' "problem" should be framed wrt:
- what kind of coding style we want to enable (or maybe respectively
deprecate)?
- what problems are we solving?
- what kind of code will not work anymore?
- what "migration path" for such code, or to the new style?

Let's consider an exemplar fragment:

if hasattr(f,'write'):
 ... # needs just f.write
else: # f is not file-like
 ...

possible future styles:

1)

if doesimplement(f,FileLike):
 ...
else:
 ...

problems: the "exponential" ontology problem, or the problem, if we limit
ourselves only to large granularity interfaces and we interpret them
strictly[*], that the programmer must implement more methods than strictly
necessary.

[*] the point is whether an interface should be interpreted as "all the
signatures implemented" . Here is not relevant this is checked or enforced at
class definition time.

2)

if doesimplement(f,Category('write')):
 ...
else:
 ...

if we allow for such on-the-fly constructed interfaces (I hope one can
extrapolate what I mean with that) we maybe solve the "exponential" ontology
problem, but this code is not really an improvement over the code using
hasattr; what we are interested in is not whether f has some kind of write
method but whether f has a file-like write method. Through interfaces one wants
to check and convey commitment more than at the signature level.

Can we do better?

It would be nice to find some kind of middle-ground between hasattr(.,'write')
and large granularity strict interfaces (LGSI).

My humble ideas: these are just two points picked in that entire range
(hasattr - LSGI), other variations are maybe useful, necessary, or reasonable.

a) As a "workaround" it should be possible to declare that a class implements
an interface partially, that means some subset of it.
Then it is an open issue whether there should be ways to check both for strict
and non-strict implementation, or some general control to tweak all checkings
and/or enable warnings. [Do Zope interfaces already allow for this?]

b) OK with a) but if I want potentially to be strict and still deal with:

"b) much of python code concretely depends on interfaces with the granularity
from one to a bunch of methods"

we should let people be precise about what subset of an interface they are
implementing, like

- I'm implemeting a subset of FileLike so consider the corresponding matching
signatures
- or, with finer control, I'm implementing FileLike 'write' and - no  - my
'tell' has nothing to do with file-like
...

and more importantly it should be possible to check for such subsets:

if doesimplement(f,PartCategory(FileLike,['write'])):
   # Yup, I know, this is ugly and begs for sugar
 ...
else:
 ...

[And mildly interestingly such code can degrade to just check for
hasattr(.,'write') for "migration" and possibly emit warnings]

regards, Samuele Pedroni.

PS: I know, here I have not dealt with implementation or performance problems
and the killing details.