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