Python came into my life rather late; after Fortran, C, C++, VB, SQL, PL/SQL and Java. It was like getting married after a string of affairs. There was nothing much to discover. I knew what it offered. I also knew what I had to do with what it offered - get business logic codified and delivered. After dealing with quite a few programming languages, I had a mental checklist ready. It looked something like this:

1. Variable declaration

2. Standard datatypes

3. Statement terminator

4. Block delimiter

5. Function definition

6. And

7. Or

8. For

9. If

10. While

11. Class definition

12. Class hierarchy

13. Package structure

The rest I would learn as the project started. That was how my professional life had been the lasttwo decades. Moreover, I belong to a generation who believe in the primacy of an algorithm over the implementing language.

Things started looking weird when I started seeing visions of collections everywhere. Being from a database programming background, I was trained to spot groups of data. The four basic collection types – list, dict, set and tuple – were by definition collections of data. Yet something deep within myself told me that something was out of place. Those four entities "looked"sufficiently different from each other to expect that the same for loop syntax – for x in v – wouldwork on all of them the same way.To understand what I mean, let us look at how the collections mentioned above "look".

list →1 = ['a', 'b', 'c']

dict → d = {'a':1, 'b':2, 'c':3}

set → s = {'a', 'b', 'c'}

tuple → t = ('a', 'b', 'c')

Then I try to run the same for loop, albeit on different variables, again and again. Python does not protest! There should have been some minor change in the way you access those objects, which are structurally and logically different.

This is what I got:

I verified that I was, indeed dealing with different "types" of objects.

As I stared at my screen bewildered, a colleague of mine with many years of experience in Python just grabbed my laptop and rapidly typed a few statements. What I saw was downright spooky!

I recovered quickly. In this age of peer rivalry, one just could not allow oneself to be outsmarted so easily.

I said casually, "Python must be following the old-fashioned C way of storing a string in an array. The variable "p" is obviously an array. But in Python, he was definitely smarter than me. He again typed something on my laptop. This time, it was a much shorter statement. But I was utterly dumbfounded.

So "p" was actually a string or an instance of the class "str". For the next few days, I kept thinking that every data type in Python was a vector, with no place for scalar data types. I started having strange mental images of class attributes and methods being ruthlessly dismembered and stored in arrays looking like prison cells, much against their wishes.Fortunately, the scalar vs vector conflict showed me the way out of the mental logjam. I reasoned that if an integer were to be a collection, the members of such a collection would be binary numbers. No modern programming language would go down to the level of binary data, even if it was behind the scene and at the compiler level.

My assumption turned out to be true. I ran a few test cases to come out of the spectre of collections.

A quick search on the Internet yielded quite a few hits. It looked like one had to make a class "iterable" by implementing a specific method called _iter_() of the base class object.