Posted by patrick sur juillet 13, 2010
- http://pypi.python.org/pypi/plac/ (‘…There is no want of command line arguments parsers in the Python world. The standard library alone contains three different modules: getopt (from the stone age), optparse (from Python 2.3) and argparse (from Python 2.7). All of them are quite powerful and especially argparse is an industrial strength solution; unfortunately, all of them feature a non-zero learning curve and a certain verbosity. They do not scale down well, at least in my opinion. It should not be necessary to stress the importance of scaling down; nevertheless, a lot of people are obsessed with features and concerned with the possibility of scaling up, forgetting the equally important issue of scaling down. This is an old meme in the computing world: programs should address the common cases simply and simple things should be kept simple, while at the same keeping difficult things possible. plac adhere as much as possible to this philosophy and it is designed to handle well the simple cases, while retaining the ability to handle complex cases by relying on the underlying power of argparse. Technically plac is just a simple wrapper over argparse which hides most of its complexity by using a declarative interface: the argument parser is inferred rather than written down by imperatively. Still, plac is surprisingly scalable upwards, even without using the underlying argparse. I have been using Python for 8 years and in my experience it is extremely unlikely that you will ever need to go beyond the features provided by the declarative interface of plac: they should be more than enough for 99.9% of the use cases. plac is targetting especially unsophisticated users, programmers, sys-admins, scientists and in general people writing throw-away scripts for themselves, choosing the command line interface because it is the quick and simple. Such users are not interested in features, they are interested in a small learning curve: they just want to be able to write a simple command line tool from a simple specification, not to build a command-line parser by hand. Unfortunately, the modules in the standard library forces them to go the hard way. They are designed to implement power user tools and they have a non-trivial learning curve. On the contrary, plac is designed to be simple to use and extremely concise, as the examples below will show…’)
- http://micheles.googlecode.com/hg/plac/doc/plac.html#plac-vs-the-rest-of-the-world (‘…Originally plac boasted about being « the easiest command-line arguments parser in the world ». Since then, people started pointing out to me various projects which are based on the same idea (extracting the parser from the main function signature) and are arguably even easier than plac: opterator by Dusty Phillips CLIArgs. Luckily for me none of such projects had the idea of using function annotations and argparse; as a consequence, they are no match for the capabilities of plac. Of course, there are tons of other libraries to parse the command line. For instance Clap by Matthew Frazier which appeared on PyPI just the day before plac; Clap is fine but it is certainly not easier than plac. plac can also be used as a replacement of the cmd module in the standard library and as such it shares many features with the module cmd2 by Catherine Devlin. However, this is completely coincidental, since I became aware of the cmd2 module only after writing plac. by Pavel Panchekha ..’)
- http://codespeak.net/tox/ (‘tox aims to automate state-of-the-art packaging, testing and deployment of Python software right from your console or CI server, invoking your tools of choice‘)
- http://packages.python.org/six/ (‘Six provides simple utilities for wrapping over differences between Python 2 and Python 3.‘)
- http://www.shinken-monitoring.org/faq/ (‘Shinken is a new monitoring tool in AGLv3 written in Python compatible with Nagios. The main goal of Shinken is to allow users to have a fully flexible architecture for their monitoring system that can easily scale to large environments. Shinken is backward compatible with the Nagios configuration standard and plugins. It works on any operative system and architecture that supports Python, which includes Windows and Mac OS X/Darwin‘)
- http://en.wikipedia.org/wiki/Shinken_%28software%29 (‘Shinken is an open source computer systemnetwork monitoring software application compatible with Nagios. It watches hosts and services, alerting users when things go wrong and again when they get better. The major improvement of Shinken over Nagios is the availability to have a load balanced and high available architecture very easily. The administrator only has to manage one configuration, the system automatically « cuts » it into parts and dispatch it to workers nodes. It take its name from this functionality, a Shinken is a sharp Japanese sword and ‘)
- http://fr.wikipedia.org/wiki/Shinken_%28informatique%29 (‘…Ce qui diffère Shinken de son aîné Nagios n’est pas tant le langage de programmation utilisé que son architecture qui repose sur le principe Unix : à une tâche, un outil. C’est pour cette raison que Shinken n’est pas monolithique comme Nagios, mais utilise cinq processus différents qui travaillent ensembles et permettent d’obtenir une flexibilité bien supérieure au Nagios originel. C’est cette architecture qui permet d’obtenir la mise en place facile d’une supervision distribuée : un processus s’occupe de lire la configuration de l’utilisateur et la découpe intelligemment (en respectant les relations entre les éléments) afin de distribuer les morceaux vers des processus chargés d’absorber la charge de supervision. De cette manière, en cas de nouvelle charge, l’utilisateur peut rajouter des processus sans avoir à modifier sa configuration en profondeur. C’est un lissage de charge automatique. C’est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de katana très tranchant, représente l’objectif du projet, à savoir de découper la configuration pour la renvoyer sur des daemons.’)
- http://www.gabes.fr/jean/2010/07/12/retour-des-rmll/ (‘…J’espère qu’elle fera réagir l’auteur de Nagios dans le bon sens, il est encore temps de se mettre à travailler ensemble. En tout cas, le projet avance, il semble plaire à beaucoup de monde. J’ai ainsi pu rencontrer l’équipe de Fusion Inventory lors des RMLL et il semble que nos projets soient amené à coopérer fortement dans l’avenir…’)
Posted in 2 to 3, 2010, Administration, Administration système, Années, Génie logiciel, python, tests, tests | Tagué: command line argument parser, Gerhard Laußer, Jean Gabès, Michele Simionato, nagios, plac, shinken, six | Leave a Comment »
Posted by patrick sur décembre 16, 2008
Source: http://www.artima.com/weblogs/viewpost.jsp?thread=245050 (« After a few weeks of work, version 3 of the decorator module is finally out. The new version is a major rewrite of the original implementation, lots of things have been improved under the hood, and the documentation has had a major overhaul too. The module is hosted on the PyPI site: http://pypi.python.org/pypi/decorator…This post is intended for users of old versions of the decorator module who want to know what’s new and the reasons for the change. Version 3 is a major release and it breaks compatibility with the past in a minor way, but I expect 99.9% of my users to upgrade to the new version without seeing any difference. You can download the tarball here.
Here is a list of the most relevant changes/improvements.
- I have completed the move to PyPI. For a long time I have wanted to move the package from my site (which is hosted on the Pittsburgh University servers and completely out of my control) to PyPI. The first version to be hosted on PyPI was version 2.3.2, released two weeks ago. The impressive thing – to me, at least – is that I had 1008 downloads in thirteen days: incredible! I have no idea of how many downloads I had for the previous versions, so I cannot compare, but from now on I can have an idea of the popularity of the module. That’s good. The move to PyPI was not complete however, since, the documentation for the module was still hosted on my site. With version 3.0, instead, everything is hosted on PyPI….
There are also a few considerations I would like to make.
From the start the decorator module was developed with the attitude of teach a man to fish: instead of providing a large API, I have provided a significant collections of examples and recipes. The idea is that you should be able to write your own decorators by yourselves. Version 3 of the module is going even more in that direction.
I have refactored the internals so that now you can not only write you decorators on your own, but you can also write your own decorator facility – the equivalent of decorator – by means of the FunctionMaker class. At the same time the rewriting makes the module more of a library and less of a framework. For instance, in past versions you were forced to write your decorators in terms of caller functions with the signature caller(f, *args, **kw); now you can write your own decorator framework and use the conventions you like. In the documentation I give the example of decorator_apply, which is able to convert third party decorators into signature preserving decorators without rewriting them.
I did not expect the decorator module to leave so long (it is nearly four years old already). In my original intentions, the module was intended to be provisional, a workaround that should have been dropped once better support for decorators entered in the standard library. Unfortunately that never happened. It is true that Python 2.5 added some support for decorators in the functools module, but that support is insufficient in my opinion. Also, I had great hopes for the Function Signature Object (PEP 362) but after more than two years nothing happened. I still hope it will become possible to change the signature of functions in future versions of Python: when that will happen, the decorator module will become obsolete and I will have less code to maintain.. »)
Posted in decorators, python | Tagué: decorator 3.0, Michele Simionato | Leave a Comment »