Monthly Archives: June 2010

Instance Inheritance – Python (My Project Cont’d)

What puzzled me at first was how to not only make a class inherit attributes from a parent class but how to have an instance of a class inherit the instantiated attribute data from a parent.

EXAMPLE (also see last post):

I have a PROJECT parent class.

class PROJECT:
    def __init__(self, projectnumber, Title=””,Title2=””,Name=”” … ):

is instantiated as newproject = PROJECT()

and I have a POINT (borehole) child class.

class POINT(PROJECT):
    def __init__(self, name=””, depth=”” ….):

Now, I would like to create boreholes, i.e. instantiate the POINT class, for this project and have each POINT instance inherit not only the PROJECT attributes but the information for the object newproject.

I found the solutiom here on Stackoverflow.com (great site !). And after adapting it to my project, I came up with his.

class PROJECT:
    def __init__(self, Title=””,Title2=””,  …more attributes … )

class POINT(PROJECT):
       
    _inherited = [‘Title’,’Title2′,’Name’ …more attributes …  ]

    def __init__(self, project, name):
        self._parent = project
        self.name = name
       
    def __getattr__(self, name ):
        if name in self._inherited:
            return getattr(self._parent, name)

        return self.__dict__[name]

Leave a comment

Filed under Uncategorized

Data Entry Routine (for gINT) using Python Code

This continues my last post.

So, say you want to write a console program that collects user information to populate the fields of a spreadsheet, i.e. provide the attribute data for the instance of a class. Here are some thoughts I had starting out.

There is a class Project, which – for the time being – has attributes Title and Location. In my first version I wanted to do this.

Classes.Py

class PROJECT:

    def __init__(self, Title, Location)
        self.Title = Title
        self.Location = Location

DataEntry.py

Title = raw_input(“Enter Project Title: “)
Location = raw_input(“Enter Project Location: “)

newproject = PROJECT(Title, Location)

That was straight forward. But I was going to need this same routine for many more attributes, not only for PROJECT but even more attributes for the borehole class (POINT). Plus, I wanted to include a routine, e.g. dataEntry(), that would allow me to change any one attribute after creating the instance. So how about:

Classes.Py

class PROJECT:
     def __init__(self):
         pass
     def dataEntry(Title, Location):
         self.Title = raw_input(“Enter Project Title: “)
         self.Location = raw_input(“Enter Project Location: “)

DataEntry.py

newproject = PROJECT()
newproject.dataEntry()

This seems cleaner to me. The program part only instantiates and then calls the method. The rest of code is in the class. One reason I didn’t like the gINT interface is because I had to always enter the same information over and over again. Some things never changes, some things didn’t change during the project but had to be entered 50 times for 50 boreholes. So assigning some attributes default values in def __init__ (those that never change) and then starting the dataEntry routine for attributes that change, makes the most sense to me. So for example:

Classes.Py

class Borehole:
     def __init__(self, ProjectTitle=“New Title”, Driller=“New Driller”, DrillRig=“New DrillRig”):
          pass

     def dataEntry(self, Depth, Date):
         self.Depth = raw_input(“Enter BoreHole Depth: “)
         self.Date= raw_input(“Enter Date Drilled: “)

DataEntry.py

newBorehole = Borehole()
newBorehole.dataEntry()

What this does is instantiate the class Borehole, using dafault values for Title, Driller, Drillrig (which remain the same for all borehole instances) and then prompt for borehole specific input…. TO BE CONTINUED

2 Comments

Filed under Uncategorized

Python Program – Data Entry for gINT

I have started working on my first real Python programming project. This goes way beyond writing a simple GIS related script. Here is the background.

If you happen to work in geotechnical engineering, you might be familiar with a ghastly piece of software called gINT, GEOTECHNICAL AND GEOENVIRONMENTAL SOFTWARE. gINT is a very powerful package for storing, analysing, and displaying geotechnical data. But I personally don’t enjoy working with it, although I have put in many 100s of hours doing so. What I like least about gINT is the non-intuitive GUI that doesn’t seem to have much in common with any standard Windows program. So what I would like is an alternate way of getting my geotechnical data (e.g. lab data, borehole data) into gINT.

Essentially, entering data in gINT comes down to stepping through a bunch of spread sheet like pages and doing a lot of copy/pasting. One obvious way to improve on the program’s interface is by doing all your data entry in something like Excel, and then copy pasting it into gINT, or – since the program allows you to import from various formats – saving your spreadsheet (e.g. as XLS) and importing it into gINT.

But rather than set-up an Excel template (I find Excel equally annoying, especially after finally updating to 2007) , I thought I’d try importing TXT into gINT, and write a Python program for data entry, that will output a TXT file. Plus, in the back of my mind, I am already thinking about converting all existing gINT projects (GPJ files) to TXT so that I can read and work with them using Python, and eventually link all this information to my GIS database.

Yes, gINT provides some kind of add-in for ArcGIS. But considering the program’s general level of user unfriendliness I don’t want to go there. Also, it looks like that extension merely lets you plot gINT borehole/project locations in ArcGIS. I want full access to years of existing gINT files and data ! I would much rather have a simple Python program that reads/writes TXT in a format that gINT understands. That will give me a lot more flexibility. It will even allow me to input data on computer not running gINT. And once, I figure out how to automate exporting all those GPJ files to TXT, I can dig through them and plot them myself in ArcGIS using Python. There is something called gINT RULES, a VBA like scripting language that I might have to befriend. We’ll see.

Creating my Python program starts with setting up a bunch of classes for the different spreadsheet tabs in gINT. For example, there will be a class for PROJECT that contains all the data fields for project information, and there will be a class with fields for the user’s borehole information. Then we go down the list of lab testing and other data that belong to each sample from each borehole. Therefore, the Borehole Class should be a child of the Project Class, and the Sample Class should be a child of the Borehole Class. Some sort of data entry routine, prompts the user for input and invokes instances of these classes to setup new boreholes or samples.

Moreover, an instance of the Sample Class should inherit from the applicable instance of the Borehole Class, i.e. that borehole from which the sample was collect. That way, something like the project number starts at PROJECT.ProjectNumber but is inherit by the Sample instance, and can be called as SAMPLE.ProjectNumber. More about how to accomplish this in the next post…

2 Comments

Filed under Uncategorized

Python Modules REVISITED

I’ve had my share of headaches with Python modules (see last post and less recent ones). So I decided to review the use(s) and rules concerning modules.

Turns out that the best place to look things up is still Mark Lutz’s “Learning Python”, see chapters 18 – 21. I was glad to read the following, which I had wondered about just the other day:

Code at the top level of a module file (not nested in a function) runs as soon as Python reaches it during an import; because of that, it can’t reference names assigned lower in the file.

Because when importing modules, code is compiled right then, line by line.

Leave a comment

Filed under Uncategorized

Iron Python – Importing Modules

I have been playing around with Iron Python, and it’s a joy. Mostly it’s a joy because I don’t have to look at curly braces all day, but I can do a lot of the same stuff I could do with C#.

But I learned the hard way (and I guess I should’ve known) that:

import module

is not the same as

from module import *

I was working on the example in ProIronPython (Apress) Chapter 5 (if you care to know), and was instructed to  import the NotQuitePad.py module (page 102, bottom). So I tried using version 1 (above), and got an error upon building, more specifically an ArgumentType Exception in this line of NotQuitePad.py.

Application.Run(NotQuitePad.NotQuitePad())

The message read: module object is not callable. – – – There is lots of information about importing modules in IronPython on this page here. But the real help came from the Python help pages: “Chapter 6.12 The import Statement“. Even if you don’t know much about modules, the error message leads you in the right direction. Turns out it’s all about namespaces.

Quoting from docs.python.org:

 

The first form of import statement binds the module name in the local namespace to the module object…  The from form does not bind the module name: it goes through the list of identifiers, looks each one of them up […], and binds the name in the local namespace to the object thus found.

Leave a comment

Filed under Uncategorized