checking protocols.

[DL Neil]

Avi

Haven't noticed an answer to this. Did I miss anything?


On 20/01/19 11:07 AM, Avi Gross wrote:
> Short question. Checking if a protocol is set up?

=do you mean that to check/require that a class exhibits a particular 
protocol we should use abstract classes - will not instantiate unless 
all the required components are coded?


> Many python improvements are changes to classes that implement a protocol.
> There are things you can do to make your own classes work with the protocol
> by setting various dunder variables like __iter__, __next__ and writing
> appropriate ode including throwing the right error class when done.
> Similarly the "with" statement works with objects that implement __enter__
> and __exit__. There can be plenty of others like this and more can be
> anticipated in the future.
> 
> So, several related questions. Tools that help a developer add appropriate
> things to an object to implement the protocol or to test if it was done
> right. Perhaps a function with a name like is_iterable() that tells if the
> protocol can be applied. For the specific case of an iterable, I found
> something that seems to work for at least some cases:
> 
> from collections import Iterable
> item = [1, 2, 3, 4]
> 
> isinstance(item, Iterable)
> 
> Not sure if it would work on one I created that did the right things or what
> it checks.

=your code should be 'approved' if it implements the next() method, etc. 
Did you try such?


> I am interested in a pointer to something that describes many of the known
> protocols or extensions and maybe to modules designed sort of as I said
> above. I am aware some protocols may be not-quite standard with parts of the
> protocol embedded in different objects like wrappers or objects returned
> upon a request to have a proxy and many other techniques that seem to abound
> and allow multiple layers of indirection or seemingly almost magical as in
> multiple inheritance drop-ins and so on. That is what may make these things
> harder if someone uses something like __getattr__ or descriptors to
> intercept calls and provide the functionality without any actual sign of the
> dunder key normally expected.

=Questioning similarly, I recall finding one of these - but do you think 
that I can re-find it now? Apologies.

I (too) think it would be handy to have such a list. There are many for 
the 'magic methods' themselves, in all the better Py3 texts.

Yesterday I needed to add __LT__() to allow a list of class instances to 
be sorted, __EQ__ to enable a list of (other) instances to be searched 
(if element in list_of_instances), and made a class callable 
(__call__()). Each time I wondered: is this the best way to accomplish 
or is there already a mechanism I could be employing/not 'reinventing 
the wheel'. (perhaps incompletely!)


For your further reading pleasure (maybe):

On the this topic, one of many references is Interfaces in Python: 
Protocols and ABCs 
http://masnun.rocks/2017/04/15/interfaces-in-python-protocols-and-abcs/

Which reminded me of the amusingly titled: Duck Typing vs. Goose Typing, 
Pythonic Interfaces 
https://dgkim5360.github.io/blog/python/2017/07/duck-typing-vs-goose-typing-pythonic-interfaces/

Diving into the docs (although not finding exactly what we seek):
https://docs.python.org/3/library/abc.html
- didn't include all, eg context managers:
https://docs.python.org/3/library/contextlib.html

At a deeper level:
https://docs.python.org/3/c-api/abstract.html?highlight=abstract
and
https://docs.python.org/3.6/c-api/object.html
- again, incomplete in the sense (I gained) of this enquiry.

Hopefully there's something to keep your mind occupied...

-- 
Regards =dn