Difference between revisions of "Python"

From mn/geo/geoit
Jump to: navigation, search
(Best Practices)
Line 34: Line 34:
 
</source>
 
</source>
  
 +
===Import Statements & Namespaces===
  
 +
In python, almost all code will be preceded with some statements such as: <code>import this</code> (try that, by the way). These are 'import statements' which pull in other modules to use within your own code.
 +
 +
You may find some examples, particularly when learning [http://matplotlib.sourceforge.net/ matplotlib] and working with 'pylab', where the tutorial uses:
 +
<source lang='py'>
 +
from pylab import *
 +
</source>
 +
 +
This is '''NOT''' recommended. This will ''contaminate'' your local namespace, meaning that the module from which you import ''everything'' indicated by the '*', may overwrite some of your own functions or even python builtins.
 +
 +
A better usage is to say:
 +
 +
    import pylab as plb
 +
 +
Then you can still use the example, but you may simply need to prefix some of the function calls with 'plb.', which refers to the 'pylab' namespace.
  
  
 
====Sub Page====
 
====Sub Page====
 
<subpages />
 
<subpages />

Revision as of 13:23, 14 September 2011

The Python programming language is a powerful language which has gained popularity over the past several years. It is widely used in the scientific community, and there are numerous tools readily available for common data analysis tasks. At NILU there is a repository for Modules developed internally. The pages herein provide important information on working with Python on the NILU servers and also with your own PC.

Best Practices

Let's start with some 'best practices' for programming with Python.

Code Style

First and foremost, one should become familiar with the PEP8. This is a 'Python Enhancement Proposal' (PEP). In Python this is the equivalent of a detailed featured request. PEP8 lays the foundation for how you should format your code.

One important feature of python to highlight are Documentation Strings:

    Conventions for writing good documentation strings (a.k.a. "docstrings")
    are immortalized in PEP 257 [3].

    - Write docstrings for all public modules, functions, classes, and
      methods.  Docstrings are not necessary for non-public methods, but you
      should have a comment that describes what the method does.  This comment
      should appear after the "def" line.

    - PEP 257 describes good docstring conventions.  Note that most
      importantly, the """ that ends a multiline docstring should be on a line
      by itself, and preferably preceded by a blank line, e.g.:

      """Return a foobang

      Optional plotz says to frobnicate the bizbaz first.

      """

    - For one liner docstrings, it's okay to keep the closing """ on the same
      line.

Import Statements & Namespaces

In python, almost all code will be preceded with some statements such as: import this (try that, by the way). These are 'import statements' which pull in other modules to use within your own code.

You may find some examples, particularly when learning matplotlib and working with 'pylab', where the tutorial uses:

from pylab import *

This is NOT recommended. This will contaminate your local namespace, meaning that the module from which you import everything indicated by the '*', may overwrite some of your own functions or even python builtins.

A better usage is to say:

   import pylab as plb

Then you can still use the example, but you may simply need to prefix some of the function calls with 'plb.', which refers to the 'pylab' namespace.


Sub Page

<subpages />