Dissecting Python inside out

The task isn't so tough it might seem because the major rules are naturally entangled. There are only a thriple primals: True, False and None. The rest are derivatives based on the them.

Undoubtedly it prunes down the lesson. All what you need is to build the tree-like structure of obtained lore in your mind. Of course it requires from reader a lot of perseverance and diligence to achieve a true knack in programming, but it is definetely not a rocket science!

Naturally there are several formal syntactical rules, but all them are naive and would be learn without any effort at all.

A major killer feature of this book is its style: it is not yet another user manual, journal or TTY input/output spiced with comments. It might deem a bit strange though. What if the book will be directly written in programming language? Initially you will wittingly immerse in a full-dressed Python-written program text, the valid program, which might be successfuly executed by machine, I mean.

Another noticeable discrepancy is a test-driven approach in disclosing programming language features. All material being wrote down as a chain of tests from beginning to the end. Generally speaking the next one based on the previous and you should incessantly compare them one against each over, detect the difference and make conclusions by your own.

In addition I strive to compose each program in a paramount clarity and density in expectation that instantly the reader will being capable to gaze its incredible power and naked beauty from inside.

The main intention of this book is to take to the reader a chance to be fun while reading. At the another hand it might be impossible to write a giddy novel for human readers and an absolutely precise set of instructions for computer at the same time. Bear it in mind the text deliberately splitted into two main chunks by its purpose: the comments and the program itself. The comments are for humans only, the program is for two sides of software industry: it is human-readable and machine-executable simultaneously.

The side effect might be a cramming gap during learning. All material compounded into a monolith by a logical intersection. Thus it is highly welcomed to follow the sequence of chapters by its nature, from first and foremost to the second one, the third etc.

A multiplied repetition in hope to rehearse the chunk of studied material verbatim and forget it forever — short, attractive but lousy way to achieve knowledge. It is a cognition trap. And yes, it is a dogged determination in self-deception. It is an eloquent illustration of redundant, tedious and, in same time, popular way to do things wrong.

All what you are need in is to delve into Python depths leading by an experience guide. That's it.

All articles are short enough to being grasped less than 25 minutes. Self-pace is highly welcomed: going forward only after you sure that know the present point as a back of your hand. No need to subdue yourself to read down and down without any comprehension. It is not a learning at all, it is a foolish torture. Slow your pace, please. You can't fathom it all of a sudden.

A minuscule free time in the early morning before yours breakfast would be an ideal time for learning programming. It is not a joke, guys, moving forward.

Initially at the uprise of programmable machines there was the single set of plain instructions embedded into the automaton. This set was defined by a creator of this machine once, being incompatible with other machines, so it was a life-long program solution for each particular mechanism only.

Further technical evolution produced a new demand: it might being convenient if one particular mechanism obey different set of instructions and thus produce a various sequence of operations. In other words it was demand to easily reprogram machine to do something new.

At programming early beginning there was a machine code only. It is a kind of machine's language by its purpose, thus casual programming obliged an operator with a true wit and grasp in translation from human language into machine code.

The idea of compiler as a middleware between humans and machines exactly for automatic translation was on the tip of the tongue at those days, but implemented by Grace Hopper's titanic efforts and phenomenal persistence only in 50s. It was the basement for all modern high-level programming languages establishment. Since that time and forever it is possible to write program not in machine code only, but utilizing some particular programming language which by its purpose is much human-friendly.

As you might expected what bright win of human ingenuity and infinite lucidity all the sudden became a natural feature in the industry, and it is a wrong conclusion: an old style of writhing machine code begot a source code term initiation and popularization. But what this source code ever means?

It is a code by the definition and it is a source of machine code before compilation by the intention. These peculiar niceties allow to write programs as a code, neglecting the most significant feature of high-level programming language - its readability, and name this pseudo-program as a source code. Yes, it is wierd, and in a few cases this transference is convenient: it permits to type less, to comment nothing at all, to name variables absolutely meaningless like bar, foo, or even a, b, c, d, e, f, g!

Yes, seems like things go wrong there: for some vital reasons all specialist in software industry still write only the source code and shrink to switch on writing programs instead. I observe like it goes on and on for several decades already. And seems like nobody capable to take a challenge to erradicate this distortion except me.

for a casual software developer and often it consumes up to 40% of their efforts to develop and maintain software nowadays.

“We do not describe the world we see, we see the world we can describe.”

— Rene Descartes

At one hand we have a relatively simple job: to tame a machine to execute the precise sequence of operations utilizing the programming language clear enough to be understood by humans and machines. At another hand we might notice a plethora of manuals, tutorials and intimidatingly large books which take an attempt to dismantle the programming as a professional skill using a plain English commonly and a handful of real code snippets as an unavoidable exclusion out of this rule.

It is straightly inherent to a human nature. Even an experienced professional software developer often can't explain what the machine should do even in a plain English. Misleading in human language should spawn only erroneous decidions with the following often wrong conclusions. The slogan "Keep clear" is a paramount goal of most humans, it is difficult to detour the brain fog after the some time spent in mulling around something enough tough.

There are tons of material and most of it represents programming language in an imperative style.

“Youth is easily deceived because it is quick to hope.”

— Aristotle

The median age in a casual team of software developers is something below 30 years. Yes, this is a pledge of physical health, mental flexibility and, in most cases, a squad emotional stability. At the other hand it is too young to be experienced enough to perceive reality as a sum of events in the past.

Yes, 30 years old for human being intellectually is like a new born toddler physically. They capable to do anything, but it requires time and effort to learn it up. Nowadays they're learning a modern programming by tutorials, manuals and books. That's right.

But, how these learning material is written and why? Why it is so intimidatingly large?

“There are no facts, only interpretations.”

• Friedrich Nietzsche

If I ask you what you see on the picture above your average answer would be: “There are two small boys playing cubes together.” Right? But what if I tell you: “These two boys are conducting a series of test to cognate the hidden features of cubes. The older one demonstrating his knowledge in this particular area, and the youngest one assisting him and learning by testing.”

This is a simple and straight evidence of human innate ability to learn. And it requires no words at all, just attention, patience and perseverance to deduce the meaning of this show.

Well, it is about playing cubes, right? Not at all. It is a general approach to learning: an experience tutor should demonstrate you some particular niceties by a sequence of obvious and explicit tests. All you have to do are observe them, take them into consideration, catch the essence out of them and put results into your memory.

It was initially introduced by computer scientists in 80s, and became a wide-spread and popular concept in the industry only in the beginning of 21st century. Thus, it is easy to deduce that initially almost all modern programming languages, which was developed earlier this date, was happily built without any unit testing at all.

Yes, it was.

“If the only tool you have is a hammer, one tends to treat everything as if it were a nail.”

• Abraham Maslow

or cognition inertia in writing book about programming. First books about programming were written in a plain English and it was ample at that time: there wasn't any programming languages, the large set of hexadecimal commands only. Later, when full-fledged programming languages was introduced, authors predictably included wee chunks of programs into the text of books about programming by these languages. It's right. It is much more illustrative and comprehensible for readers.

When later unit testing was introduced it consider as an extra special concept in software development. What if I ask you: “What should be the next step to get rid of coding and switch on writing programs bear in mind all these observations above?”

It should be the programs as the textbook, written in particular programming language, with plentiful number of tests to examplify concepts, ideas, approaches hidden behind the wall of mutual understanding between a man and machine.

Avoidance of source code reading (escapism); Actually it is a downright grueling task to do

It's naturally to draw the boundaries around your invention. It's neither a silver bullet nor panacea for learners. Cognition demands a lot of time for reading and digesting each chapter. Nothing misterious.

• Conversion a boring manual into a fiction book;
• Black (Pandorra) Box approach;
• Programming languages genealogy:
  • Atavisms:
    • 72 char per string;
• Codex as a phenomena disclosure;
• Related material allocation on two pages at once;
• Pomodoro technique realization;

Now it is time to concoct our first primitive set of tests to determine the existence of Python primals True, False and None. It is intentionally simplified to show you the threshold of primitivity in valid Python programming.

import unittest


class TestLanguagePrimals(unittest.TestCase):

    def test_does_true_ever_exist(self):
        self.assertTrue(True)

    def test_does_false_ever_exist(self):
        self.assertFalse(False)

    def test_does_none_ever_exist(self):
        self.assertIsNone(None)

Yes, that's it! Try to launch this code snippet to be ensured that it works as expected:

cd tests
python3 -m unittest test_00_primal_testing_oversimplified.py

Now lets embellish our dry code with inline comments:

import unittest  # <-- import header


class TestLanguagePrimals(unittest.TestCase):  # <-- class definition

    def test_does_true_ever_exist(self):  # <-- an atomic test case itself
        # and the sample of in-line comment
        # self-explanatory name of the test case to focus attention
        self.assertTrue(True)  # <-- straight assertion
        # If this test passed successfully than True is really exists

    def test_does_false_ever_exist(self):  # another test case
        self.assertFalse(False)  # False also exists

    def test_does_none_ever_exist(self):  # the last primitive test case
        self.assertIsNone(None)  # None also predefined by the language

Tip It is convenient to compare these two files when you open them in two panels simultaneously on the screen:

You've got to catch the essence of the lesson

Now you're checked up an existence of three primary Python constants using unittest module and its three methods:

• assertTrue
• assertFalse
• assertIsNone

It is a simple, minuscule and plain step onto the right path opting knowledge in its natural order.

Now you're ready and steady to read, compare and comprehend Python programs. Yes, there are only two of them, they are intentionally simplified, but suddenly you're got a seismic shift in your mind. From now and forever lets compose our programs in a self-explanatory manner, and Python would alleviate the pain in mulling around how the program works.

You might notice that we used the set of inline comments to describe some significant niceties. Yes, they are not obligatory though. To accomplish the switch on pure Python we should utilize a multi-line comment feature for the much broad depictions. Yes, they are not an obligation too, but in many cases they are indispensable as a source of clarity for author during writing the program and later for all its readers.

Naturally what such cool feature was already established by Python and well-known as a docstrings, the special sort of comments. Multi-line docstrings consist of a summary line, followed by a blank line, followed by a more elaborate description.

Warning, atavism! #!/usr/bin/python # -*- coding: utf-8 -*-

These two topmost strings in each Python program are optional and in most cases redundant.

"A universal convention supplies all of maintainability, clarity, consistency, and a foundation for good programming habits too. What it doesn't do is insist that you follow it against your will. That's Python!"

• Tim Peters

"""A module-level docstring brief single-line description

A module-level docstring multi-line description. Notice the second line
with a straight encoding definition. 

Docstrings do appear in the bytecode, so you can access this through
the ``__doc__`` attribute. This is also what you'll see if you call
help() on a module or any other Python object.

"""

import unittest  # <-- import header

"""The place below an import section reserved for multi-line comments
which might be utilized as a preamble to your Python program. It is
being red only by humans, not compiled ever, and permits author to
write down all stuff necessary to be at the foremost place.

It might be unnecessary in our case, when we write a simplified
version of programs. But our basic aim is to serve as paragon of
clarity thus it should contain all lucidity's attributes.

By its purpose all programming languages should allow readers to
perceive what exactly this particular text do in a much explicit
manner. The real state of things, when programs are habitually
clogged, requires from a literate reader tons of time and perceverance
for litter decluttering and a core idea grasp. Noticeable that
nowadays most programs demand from its reader such literacy that it
made them actually indecipherable for humans and in most cases
extremely knotty even to its author.

Nevertheless, this fact usually omitted by specialists, who spent a
huge amount of time reading so overcomplicated texts of programs.
Through time, it became a normal if anybody can't make an idea out
from program's text on the fly.

“It is just lack of experience!”: they say usually. You might object
by notation that several professionals can't catch the essence out
from that text because it is poorly written, they answer something
like: “It works well enough to be scrutinized much diligently.”

"""


class TestLanguagePrimals(unittest.TestCase):  # <-- class definition
    """The class-level for a brief single-line docstring

    Class defininition begins this reserved word /class/ following by
    the /name of class/ and its /parent class/ in the brackets. On
    first steps it might be like a magic mantra to enter the /test
    suite/

    """

    def test_does_true_ever_exist(self):  # <-- an atomic test case itself
        """A single-line brief description for particular test case"""
        self.assertTrue(True)  # <-- straight assertion
        # If this test passed successfully than True is really exists

    def test_does_false_ever_exist(self):  # another test case
        """A single-line brief description for particular test case"""
        self.assertFalse(False)  # False also exists

    def test_does_none_ever_exist(self):  # the last primitive test case
        """A single-line brief description for particular test case"""
        self.assertIsNone(None)  # None also predefined by the language


"""This is a conclusion multi-line comment section. It is useful to
put all bottom-line conclusion there."""