Skip to main content
Software Engineering

Return to Question

added 8 characters in body
Source Link
Vorac
Vorac
  • 7.2k
  • 8
  • 43
  • 60

Having recently discovered python, I attempted to write a simple logger. Data is read from a device, processes, displayed and stored on disc. Those different tasks belong to different modules, of course.

What appeared to be cool at the time, was to provide command-line interface to each module, as explained here: https://docs.python.org/2/tutorial/modules.html#executing-modules-as-scripts

The result is tat although the program as a whole uses import x and the uses the classes in the modules, the modules can be used form the command line as well. For example, invoking hw_comm.py would open the default device with default options and stream to stdout. Also plot.py expects data form stdin and draws a plot.

I can see a ton of advantages to this design, such as

  • easy to debug
  • easy to adapt for different use cases
  • easy to test
  • provides immediate value to the end user, long before the project is finished.

I have read only a few thousand lines of python yet, but haven't seen this approach but haven't seen this approach (modules as both importable classes and stand-alone scripts) elsewhere. Why would be that?elsewhere. Why would be that? Is the extra work to support this format too much for an enterprise project? Or maybe, unlike my tiny project, business scale projects can not easily support this behavior, with hundreds of modules doing different things just to accomplish one complex goal together?

Having recently discovered python, I attempted to write a simple logger. Data is read from a device, processes, displayed and stored on disc. Those different tasks belong to different modules, of course.

What appeared to be cool at the time, was to provide command-line interface to each module, as explained here: https://docs.python.org/2/tutorial/modules.html#executing-modules-as-scripts

The result is tat although the program as a whole uses import x and the uses the classes in the modules, the modules can be used form the command line as well. For example, invoking hw_comm.py would open the default device with default options and stream to stdout. Also plot.py expects data form stdin and draws a plot.

I can see a ton of advantages to this design, such as

  • easy to debug
  • easy to adapt for different use cases
  • easy to test
  • provides immediate value to the end user, long before the project is finished.

I have read only a few thousand lines of python yet, but haven't seen this approach (modules as both importable classes and stand-alone scripts) elsewhere. Why would be that? Is the extra work to support this format too much for an enterprise project? Or maybe, unlike my tiny project, business scale projects can not easily support this behavior, with hundreds of modules doing different things just to accomplish one complex goal together?

Having recently discovered python, I attempted to write a simple logger. Data is read from a device, processes, displayed and stored on disc. Those different tasks belong to different modules, of course.

What appeared to be cool at the time, was to provide command-line interface to each module, as explained here: https://docs.python.org/2/tutorial/modules.html#executing-modules-as-scripts

The result is tat although the program as a whole uses import x and the uses the classes in the modules, the modules can be used form the command line as well. For example, invoking hw_comm.py would open the default device with default options and stream to stdout. Also plot.py expects data form stdin and draws a plot.

I can see a ton of advantages to this design, such as

  • easy to debug
  • easy to adapt for different use cases
  • easy to test
  • provides immediate value to the end user, long before the project is finished.

I have read only a few thousand lines of python yet, but haven't seen this approach (modules as both importable classes and stand-alone scripts) elsewhere. Why would be that? Is the extra work to support this format too much for an enterprise project? Or maybe, unlike my tiny project, business scale projects can not easily support this behavior, with hundreds of modules doing different things just to accomplish one complex goal together?

Source Link
Vorac
Vorac
  • 7.2k
  • 8
  • 43
  • 60

Is this a pattern: stand-alone classes

Having recently discovered python, I attempted to write a simple logger. Data is read from a device, processes, displayed and stored on disc. Those different tasks belong to different modules, of course.

What appeared to be cool at the time, was to provide command-line interface to each module, as explained here: https://docs.python.org/2/tutorial/modules.html#executing-modules-as-scripts

The result is tat although the program as a whole uses import x and the uses the classes in the modules, the modules can be used form the command line as well. For example, invoking hw_comm.py would open the default device with default options and stream to stdout. Also plot.py expects data form stdin and draws a plot.

I can see a ton of advantages to this design, such as

  • easy to debug
  • easy to adapt for different use cases
  • easy to test
  • provides immediate value to the end user, long before the project is finished.

I have read only a few thousand lines of python yet, but haven't seen this approach (modules as both importable classes and stand-alone scripts) elsewhere. Why would be that? Is the extra work to support this format too much for an enterprise project? Or maybe, unlike my tiny project, business scale projects can not easily support this behavior, with hundreds of modules doing different things just to accomplish one complex goal together?