Python Sequence VS Iterable protocols

Wednesday, August 25th, 2010 | Computer Science

Recently my colleague Luca got an extracted chapter of Python 3 Object Oriented Programming book to review. As I am a long time Python developer and lover I couldn’t stop myself from taking a look at the chapter so satisfy my curiosity.

A little excerpt from the chapter talks about len, reversed and zip functions illuminated me about the fact that usually due to duck typing Python developers tend to consider sequences and iterables quite the same.

The author of the books says that “The zip function takes two or more sequences and creates a new sequence of tuples” and also the help(zip) documentation says “Return a list of tuples, where each tuple contains the i-th element from each of the argument sequences”.

Indeed the zip function works on every iterable, not just sequences. Python tends to define non-formals protocols and looking around in the doc one can discover that the sequence protocol is defined as implementing __len__() and __getitem__() while the iterable protocol requires to implement __iter__() and return an iterator.

This made me think that having duck typing not only allows easier development of code, but also easier communication of concepts. In any other language commonly using formal protocols (ie interfaces, protocols, or any other formal definition of them) the author of the book would have been required to specify also the definition of the two protocols and the differences between them before the reader would have been actually able to use the zip function. In the Python case the author just had to write the sentence in natural language and the reader is aware that he/she can actually call zip on any collection, container or even generator. Anything that he unconsciously recognizes as a sequence without even having to know the existance of the protocol itself..

Indeed I recognize that duck typing and non-formal protocols tend to be more error prone, but its interesting to notice that they also help to simply communication of concepts as human tend to find easier to feel intuitions over formal definitions.

Tags:

  • amol
    I would say that you are all actually right. I was just recognizing the fact that non-formal protocols tend to fail at runtime instead of compile/syntax checking time. Which might lead to errors caused by disattention.

    I'm both a long time C++ and Python user, so I tend to try to recognize strenghts and weakness in both strictly static typed languages and strongly duck typed ones.

    Also as there are discussions about which is better between static/dynamic typing and formal/non-formal protocols since the begin of dynamic languages I don't think that we can end the discussion quickly :D
  • gaubert
    "... duck typing and non-formal protocols tend to be more error prone"

    Like the others comments, I do not think that this statement is true. Also why obfuscating your code with static type declarations when you will have to strongly validate it anyway (independently of the typing mode) with unit and acceptance tests. Testing will make your code more robust not static typing.
  • Since you use test you can validate it, but while you are writing/compiling you might not spot errors that you'll catch hopefully way later with runtime tests. So in the end you would agree
  • Optionsanarchist
    > .. that duck typing and non-formal protocols tend to be more error prone

    Do they? I've not seed one shred of evidence to support that claim.
  • Paddy3118
    "... duck typing and non-formal protocols tend to be more error prone"

    Howso?

    Less code == less errors for me.
blog comments powered by Disqus

Search