Showing posts with label #python3.1 #stringformatting #mining. Show all posts
Showing posts with label #python3.1 #stringformatting #mining. Show all posts

Monday, January 11, 2010

Python 3.1 String Formatting - Positional Arguments

Last time I did a goofy little trick with the new Python 3 string formatting.  This time I'd like to demo something a little more practical.


I had heard a lot about positional arguments being more flexible and easier in Python 3's string formatting.  The basic gist is that the positions being referred to are on the right side of the string's format method as opposed to the left.  This usually results in fewer positions, and, hopefully, less confusion.


Quickie example:


>>> class Foo:
>>>    def __init__(self):
>>>        pass
>>>
>>> a = Foo()
>>> a.foo = 24
>>> a.bar = 33
>>> a.baz = 6
>>> # Python 2 string formatting
>>> # print '%d %d %d' % (a.foo, a.bar, a.baz)
>>> print('{0.foo} {0.bar} {0.baz}'.format(a))


24 33 6


It's true that the left side is a bit more involved now with the new string formatting.  There are more options for formatting, which I have omitted.  My main goal here is to understand the new formatting to the point where I can leverage it to my advantage in my work.  Let's see what, if anything, I've learned.


In the mining industry I did a lot data tracking on various production metrics - flows through pipes, broken rock moved to its final location, explosive power, etc.  One of the most challenging things to track was production in the open pit.  It all centered around big multimillion dollar electric shovels.


Anyway, to make a long story longer, by the time you worked your way up the object hierarchy to the shovel, you ended up with about 20 or more "fields" in the database, or members of your shovel object.  Smithing csv output from these objects could get pretty hairy, because there were so many fields to track, and they changed frequently.


Out of reality - it's just too complex - back to the programming world.  This Python 3 string formatting could have helped out some in this situation.  Let's go back to the Foo object:

UPDATE!
I had made an error in the print statment below by mixing quotes.  It is now corrected.
Yet another example of why code must be tested :-\


>>> # make two more Foo objects
>>> b = Foo()
>>> b.foo = 'hello'
>>> b.bar = 'cruel'
>>> b.baz = 'world'
>>> c = Foo()

>>> c.foo = '99.234'
>>> c.bar = '23.715'
>>> c.baz = '18.6'
>>> for objx in a, b, c:
>>>     for strx in 'foo', 'bar', 'baz':
>>>         print(('{0} = {1.' + strx + 
                            '}').format(
                           strx, objx))


foo = 24
bar = 33
baz = 6
foo = hello
bar = cruel
baz = world
foo = 99.234
bar = 23.715
baz = 18.6

Simple example, but it illustrates some of the utility of the new string formatting.  If I were trying to track a bunch of data, I would only have to redefine my "fields" once in a global constant ['foo', 'bar', 'baz'].  objx could be cycling (actually, iterating) through a list of objects.  Any writing or crunching could be done in a separate (small) function or method outside the loop (since ['foo', 'bar', 'baz'] is constant).

Turns out this new string formatting is something I could get used to . . .   ;-)