The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!
I always felt that Python’s ConfigParser API could be better. I like to access my config options like this:
To solve this, I wrote ConfigProvider which can copy options from ConfigParser into a Python instance:
class ConfigProvider: __doc__ = 'Interface which can copy values from ConfigParser into a config object' def __init__(self, cfg): self.cfg = cfg def update(self, section, cfg): __doc__ = 'Updates values in cfg with values from ConfigParser' for name, value in inspect.getmembers(cfg): if name[0:2] == '__' or inspect.ismethod(value): continue #print name if self.cfg.has_option(section, name): setattr(cfg, name, self.cfg.get(section, name))
The magic happens in update() which examines the config object that you pass in and which copies the values from the external ConfigParser into it.
The gist “Comfortable config access with Python” contains the whole code and a demo.
The new features: There is now a tool to analyze the M2 repository for oddities. Currently, it can find these issues:
- Dependencies which are used but not part of the repository
- Dependencies which are used with different versions or version ranges (i.e. when one POM includes a dependency with 1.0 and another POM pulls in the very same dependency with version 1.1)
- Dependencies which are used without versions or version ranges or a catch-all version like [0,)
- Several versions of the same artifact in the repository
Plus it prints a list of all POMs in the repo with files (jar, pom, sources, test-sources, …). Here is a sample report.
The last tool can create a POM file with a dependencyManagement element containing the versions of the POMs in the repository. You can use this to nail down all versions to the ones existing in your repository (so you don’t accidentally pull in something you don’t want).
Lastly, I’ve enhanced the patch tool. Instead of overwriting replaced dependencies, it will now move them into a new profile. This way, users of the repository can specify which dependency they want (the one from the repository or, say, one from Maven Central).
I will try to build a new testing repo over the weekend so we can start wrapping up the necessary patches for a release.
Related posts: Eclipse 3.6.2 Artifacts for Maven 2
I’ve done some more work on PyScan. Most work is under the hood but I’ve got a system to load and save projects and a bug was fixed: If you pressed the Scan button too quickly with 0.4, the last image could have been overwritten. PyScan is now based on hplip 3.9.8.
PyScan 0.6.tar.gz (16KB, MD5 Sum: 2b5e23099be438ceceb69ec23d64cec6)
See the original post for features and the system requirements.
mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=...path/to/eclipse, you might have lots of source JARs but they aren’t in the right place for Maven 2 to pick them up.
This little Python script fixes that. Just run it after
Note: You may be wondering why I use
eclipse:make-artifacts instead of the recommended
eclipse:to-maven. Simple: I don’t like to have a dozen
core-*.jar in my project.
"""Maven 2 Eclipse Artifact Source resolver After importing Eclipse artifacts into an M2 repository with > mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=.../eclipse run this script to move all source JARs in the right place for Maven 2 to pick them up. """ import os, sys from shutil import copyfile def processGroup(path): print 'group %s' % path for dir in os.listdir(path): path2 = os.path.join(path, dir) if '.' in dir: processArtifact(path2) else: processGroup(path2) def processArtifact(path): srcPath = path + '.source' #print 'processArtifact',srcPath if os.path.exists(srcPath): processArtifactWithSource(path) def processArtifactWithSource(basePath): binPath = basePath srcPath = basePath + '.source' baseName = os.path.basename(basePath) print 'artifact', baseName for version in os.listdir(binPath): vbinPath = os.path.join(binPath, version) vsrcPath = os.path.join(srcPath, version) srcJar = os.path.join(vsrcPath, '%s.source-%s.jar' % (baseName, version)) destJar = os.path.join(vbinPath, '%s-%s-sources.jar' % (baseName, version)) if os.path.exists(srcJar): print '%s -> %s' % (srcJar, destJar) copyfile(srcJar, destJar) m2repo = os.environ['M2_REPO'] if not m2repo: raise Exception('Env variable M2_REPO is not set') root = os.path.join(m2repo, 'org', 'eclipse') for dir in os.listdir(root): path = os.path.join(root, dir) processGroup(path)
Updated 01. December 2009: The script now figures out where your M2 repo is. Plus a minimum of documentation.
During the weekend, I tried to print my family tree. It was pretty simple to generate with GenealogyJ but frankly, the family tree view sucks. I was constantly shifting my “root” node to be able to see the parts I was interested in, etc. And printing this sucks even more. GJ will use lots of paper, printing huge empty boxes with lots of space around them. If I reduced the size of the parts which I don’t need, the layout fell apart. In short, I needed something better.
Graphviz to the rescue. A small Python program (100 lines) read the GED file and turned it into a graph with the layout of the persons just the way I wanted them to be. dot thought about the graph for a few seconds until it emitted a nice SVG which I could then print. Or so I thought.
I opened Inkscape and clicked on print. Yeah … that looks like the document … or rather a small part of it. Where is the poster print option? Ah, there is none. Great. Export as PNG with … oh … 150 DPI. Starting GIMP. No poster printing either. lpr tries to scale the image by .114537 which results in a 87 MB file. You gotta be kidding! kprinter? Nope … unless the command poster can be found.
A word of warning: The poster for openSUSE 11.1 (which you get with zypper) is broken. I tried it with both PostScript and Encapsulated PostScript and both resulting files were unusable in GhostView, GhostScript and Okular. Use this one instead.
After installing psutils, I could rotate the file to fit better on the page, too.
Conclusion: Most programs on Linux create PostScript files but printing them is still something for the command line. The recent print dialogs all look somewhat similar (but are different in tiny, annoying ways), each version is missing some important detail and most of them fail to simply print an oversized image on a single piece of paper or spread it over several. That Inkscape spits out an empty page after the document is just a minor issue.
What’s worse: The print preview either doesn’t work or doesn’t exist, printing to file is not implemented either or isn’t persistent. In the whole process, I ruined roughly 50 sheets of paper. *sigh*
In the end, I had a process which involved six different programs (GenealogyJ, Python, graphviz, Inkscape, pstops, poster) just for this standard task. Printing on Linux has some way to go, yet. On the positive side, I could script all these tasks and I could do it.