Modularity

I called this posting simply – ModularityI promised myself that I shall be very clear and concise around this concept, trying to follow, as well as my not-so-easy-to-understand nature permits me, the KISS principle. 😀

Scraping the internet in order to get a better understanding around the modularity concept, I have realized that the best way of understanding its principles is by writing a few ideas about this, by myself. I know for sure, that there, in the big mass of internet, there are a lot of articles regarding modularity, but for me personally, Pluralsight courses have made their point.

Why? Simply, modularity gives us the power to make self-contained, reusable pieces which can be combined in new ways to solve different problems. Even easier said, it gives us the possibility to reuse functions/methods.

What? Collections of related functions are typically grouped into source code files, called modules. All Python source files use the .py extension. The most widely used Integrated Development Environment (IDE) for Python is PyCharm, but we also can use as a tool any text editor. In this case, we have to pay a little more attention to readability.

How? Modules can be executed directly with <module_name>.py. Also, modules can be used (imported) from other modules, as long as we take care not to introduce a circular dependency.

In order to import a certain module, we have the following possibilities:

  • import <modulename>
  • from <modulename> import (function1, function2)
  • from <modulename> import *
  • from <modulename> import <functionname> as alias

Zen recommends us:

  • documenting our code using Docstrings:

“””Function purpose.

Args:
         arg1: Short argument description.

Returns:
          Function result.
“””

  • documenting our code with comments – explain how to use the facilities your module provides rather than how it works.
  • the Whole Shebang – #! 
    • documenting at the top of a file weather the Python code is Python 2 or 3;
    • helps the program loader to identify which interpreter should be used.

Moment of Zen: Sparse is better than dense – two between functions, that is the number of lines PEP 8 recommends. According to PEP 8 style guide, it’s customary to use two blank lines between module level functions.

Acknowledgments: Pluralsight

 

Advertisements
Tagged with: , , , , , , , ,
Posted in Little Python
One comment on “Modularity
  1. […] Source: Modularity […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: