The recipe book at ActiveState has these recipes which look like they may be useful at one time or another:
* Pyro - python remote object invokation
* Python Recipe for reading Excel tabular data
* Python Recipe: only on change decorator
* Python Recipe: run once decorator
* Python Recipe: Communicate between processes using mmap
Lastly, there is a free .NET interoperability book:
Is anyone still experimenting with IronPython? The last time I really mucked with it , it was barely usable. Version .72 has just come out and I would dare say not much has changed in the last 8 months. Here is the simplest working snippet of invoking a .NET ListView from IronPython.
import sys sys.LoadAssemblyByName("System.Drawing") sys.LoadAssemblyByName("System.Windows.Forms") from System.Windows.Forms import * from System.Drawing import * f = Form(Text=" Forms ListView ") f.FormBorderStyle = FormBorderStyle.FixedDialog f.StartPosition = FormStartPosition.CenterScreen mainList = ListView(Location=Point(30,30), Size=Size(300,300)) mainList.View = View.Details mainList.GridLines = True mainList.Columns.Add("Column A", 100, HorizontalAlignment.Left) mainList.Columns.Add("Column B", 200, HorizontalAlignment.Left) mainList.Columns.Add("Column C",300, HorizontalAlignment.Left) for i in range(20): mainList.Items.Add("item " + str(i), i) f.Controls.Add(mainList) f.ShowDialog()
I tried making the sample dump a list of running processes in the system. It would be a very simplistic mimic of the task manager. Unfortunately import os bombs in IronPython .7. In .72, it succeeds but the methods and attributes lists are empty. Quite a useless import if the module is empty.
Oh well, I suggest people wait a couple of years before using IronPython for serious work. For now though, experiment away.
The code to this and its concept is relatively simple. Yet as I continue to use Unix more and more, the occasional need to do this type of thing from the command-line shell recurs again and again. This script takes a file containing a text list of items and applies a command on each of the items. Thus the notion: foreach
import os, sys cummulativeOutput = "" if (len(sys.argv) != 3): print "Usage: foreach.py [file with list] [action to apply]\n" else: f = open(sys.argv, "r") z = f.readline() while z: cmd = sys.argv + " " + z outfp = os.popen(cmd) out = outfp.read() cummulativeOutput = cummulativeOutput + "\n" + out z = f.readline() print cummulativeOutput
It saves a lot of typing as well as cut-N-pasting.
Since I have been experimenting with IronPython, I just wanted to share a picture that shows how it will play well with other languages. Hopefully there will be more developers willing to join the fray if they see how beneficial it might be in helping them do their work.
For background, IronPython is the new Python implementation that works with dotNet's CLR. I asked this
on comp.lang.python on "how to interface with a collection via IronPython". The right answer is to use: get_Item(index) . However accessing instances of a collection this way makes a mess of reading code. I certainly hope that I am using this wrong or that there is a bug in IronPython that needs to be fixed. The nagging problem will be that when you are trying to access an index of a collection, how will you know it is a Python datastructure or a CLR datastructure?
Yeah for being able to use Ctypes to quickly prototype using python. I needed to quickly find out the screen resolution of a Windows machine. After mucking about, here is the quick snippet of python with a sprinkle of Ctypes:
from ctypes import * user= windll.LoadLibrary("c:\\windows\\system32\\user32.dll") h = user.GetDC(0) gdi= windll.LoadLibrary("c:\\windows\\system32\\gdi32.dll") xdpi = gdi.GetDeviceCaps(h, 88) ydpi = gdi.GetDeviceCaps(h, 90) print xdpi, ydpi
This gives you the screen resolution in the x and y direction. Now the question I have is "how different would this be in SWIG"?
Ok, a co-worker just passed by and mentioned that since I live in Zone A of the evacuation area, I may think about evacuating to Orlando when the hurricane hits. Yikes....!!!
For some time now I have been wanting to use a simple editor to write emails and articles. The tool doesn't have to be complex but the main point is that it should allow me to organize my thoughts while composing. Ideally, the outline feature that Microsoft Word provides is what was needed. However, Word (like the other applications in the Office Suite) is very bulky when compared to the other extreme (notepad). On a moderate machine, Word can take upwards of 20 seconds to load. This takes a toll on a person's patience and the usability factor is greatly diminished. So, for some time after not finding a usable tool, I dismissed that desire.
For the past year, I have become quite enamoured with a programmer's editor feature: code-folding. In many sense, it fits in well with the Object Oriented way of thinking. What I mean is that the object should hide the details and only expose enough information to allow the designer to work at a higher abstraction level. This is absolutely the exact concept of an outliner. The new editors have the feature to hide code with are "between the curly braces". This is great, and for coding, it can't be beat. However, outlining ideas "between the curly braces" is something a writer would not willingly embrace.
Enter Python. Python uses white spaces instead of the C/C++ favorite "curly braces". A writer can just use the editor and separate sub-topics with a blank space. Additionally SciTe (a popular free code editor) already has Python recognition built-in. SciTe is small, fast, and simple to use. Voila, an outline editor within code-folding.