Archives de la catégorie ‘python’
Publié par patrick le janvier 7, 2011
Implemented improved glossary markup which allows multiple terms per definition
+ In contrast to regular definition lists, *multiple* terms per entry are
+ allowed, and inline markup is allowed in terms. You can link to all of the
+ terms. For example::
+ .. glossary::
+ term 1
+ term 2
+ Definition of both terms.
+ (When the glossary is sorted, the first term determines the sort order.)
.. versionadded:: 0.6
You can now give the glossary directive a ":sorted:" flag that will
automatically sort the entries alphabetically.
+ .. versionchanged:: 1.1
+ Now supports multiple terms and inline markup in terms.
Particle with integer spin.
Particle with half-integer spin.
+ Examples for fermions.
This development is very interesting. Use of the visitor pattern.
- CHANGES (3 lines added, 0 lines removed)
- doc/markup/para.rst (18 lines added, 3 lines removed)
- sphinx/addnodes.py (3 lines added, 0 lines removed)
- sphinx/domains/std.py (86 lines added, 22 lines removed)
- sphinx/roles.py (0 lines added, 1 lines removed)
- sphinx/writers/html.py (4 lines added, 0 lines removed)
- sphinx/writers/latex.py (5 lines added, 1 lines removed)
- sphinx/writers/manpage.py (4 lines added, 0 lines removed)
- sphinx/writers/texinfo.py (3 lines added, 0 lines removed)
- sphinx/writers/text.py (4 lines added, 0 lines removed)
- tests/root/markup.txt (13 lines added, 1 lines removed)
Publié dans 2011, Documentation, Doc_sphinx, python, reStructuredText, Sphinx | Poster un commentaire »
Publié par patrick le septembre 19, 2010
Doxylink is a Sphinx extension to link to external Doxygen API documentation.
It works much like the extlinks extension but it does some more processing to link C++ symbols against their Doxygen HTML documentation.
When generating your Doxygen documentation, you need to instruct it to create a ‘tag’ file. This is an XML file which contains the mapping between symbols and HTML files
Doxylink is a Sphinx extension to link to external Doxygen API documentation.
Publié dans 2010, Années, C++, Documentation, Doc_sphinx, Génie logiciel, Langages, reStructuredText, Sphinx | Tagué: C++, c++ documentation, doxygen, sphinx extension | Poster un commentaire »
Publié par patrick le septembre 19, 2010
Py4J enables Python programs running in a Python interpreter to dynamically access Java objects in a Java Virtual Machine. Methods are called as if the Java objects resided in the Python interpreter and Java collections can be accessed through standard Python collection methods. Py4J also enables Java programs to call back Python objects. Py4J is distributed under the BSD license.
- http://www.jython.org/index.html ("Python for the Java Platform")
Publié dans 2010, Années, Documentation, java, jython, Langages, python, Sphinx | Tagué: jython, py4j, python and java | Poster un commentaire »
Publié par patrick le 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…’)
Publié dans 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 | Poster un commentaire »
Publié par patrick le avril 22, 2010
Toujours beaucoup de mouvement en ce qui concerne la distribution de modules python.
- http://cournape.wordpress.com/2010/04/22/first-public-release-of-toydist/ (‘The goals of toydist are simplicity and extensibility. There should be only one way to package simple packages (ideally, relying only on the toysetup.info file), while being flexible enough to handle complex softwares. The ultimate goal of toydist is to replace the hideous distutils extensions to build NumPy and SciPy. ‘)
- http://cournape.github.com/toydist/ (‘Welcome to toydist main (sphinx) documentation. Toydist is a no-nonsense packaging tool solution for python softwares. Packaging simple python code consists in writing a simple declarative text file. Toydist aims at being simpler, more pythonic and more extensible than existing python packaging tools.’)
- http://pypi.python.org/pypi/envbuilder/0.3.0 (‘ A package for automatic generation of virtualenvs Envbuilder is a system for automatically building virtualenvs in Python. To do this, it uses a .env config file to define parcels, which are individual pieces of software to be checked out and installed into the virtualenv. It is mainly tested under Linux, but it should work under any platform that supports unix-y commands (including cygwin). In fact, you might even be able to make one config file work on both Windows and *nix if you’re careful.’)
Publié dans 2010, Développement logiciel, distribute, Distribution de logiciel, Doc_sphinx, Génie logiciel, package_management, packaging, toydist | Poster un commentaire »
Publié par patrick le avril 7, 2010
- http://en.wikipedia.org/wiki/OpenSUSE_Build_Service ("…The openSUSE Build Service is an open and complete distribution development platform designed to encourage developers to compile packages for multiple Linux distributions including openSUSE, Red Hat, Mandriva, Ubuntu, Fedora and Debian. It typically simplifies the packaging process, so developers can more easily package a single program for many distributions, and many openSUSE releases, making more packages available to users regardless of what distribution version they use. The build service software is published under the GPL. In an acknowledgement of its usefulness to the wider Linux community, the Linux Foundation has announced that the project will be added to the Linux Developer Network (LDN)")
- http://fr.opensuse.org/Build_Service (" … OpenSUSE Build Service (OBS) est une plateforme complète de développement de distribution fournissant l’infrastructure nécessaire pour le développement des futures distributions basées sur openSUSE. Il comporte également les services qui permettent la compilation et la création de paquets pour les autres distributions Linux, comme Fedora, Debian, Ubuntu, et bien d’autres. Les utilisateurs d’openSUSE peuvent facilement passer en revue les différents paquets via l’interface web http://software.opensuse.org/ et télécharger les derniers paquets. Les interfaces ouvertes permettent aux services externes (par ex: SourceForge) et aux pages web d’interagir avec le Build Service et d’utiliser ses ressources…..)
- voir aussi: GNU/Linux magazine N°126, avril 2010 "OpenSUSE Build Service: créez vos paquets binaires pour (presque) toutes les distributions. ..OBS supporte les distibutions suivantes: OpenSUSE (bien sûr) et SELES, Fedora et RHEL, Mandriva, Debian et xUbuntu, pour les architectures i586 et x86_64." Auteur: Alexandre Courbot.)
- https://build.opensuse.org/ ("…The openSUSE Build Service is the only service that allows developers to package software for all major Linux distributions. The service provides software developers with a convenient and easy to use tool to create and release open source software for openSUSE and other Linux distributions on different hardware architectures and for a broad user audience…")
- http://www.novell.com/communities/node/9226/using-opensuse-build-service-create-and-distribute-kernel-module-packages ("Using the OpenSUSE Build Service to Create and Distribute Kernel Module Packages")
- http://en.opensuse.org/Build_Service/CLI#osc.2C_the_Python_command_line_client (‘osc is written in Python, and in addition to the commandline interface it also provides a Python module, for use by other Python programs. osc is a subversion-like client. It serves as client for the source code repository part of the build service, and it is used to edit metadata or query about build results. Introductory usage examples are shown below. Note the Build_Service_Tutorial, which gives a more systematic introduction.osc is extensible. You can modify the behavior or write your own commands.’)
- http://sourceforge.net/projects/monoosc/ (‘MonoOSC is a project composed of two parts. A CSharp, C#, library used to access the openSUSE Build Service, OBS. The second part is a nice GUI which uses this library. MonoOSC requires the Mono 2.1 version of the distribution.’)
Publié dans 2010, command line interface, Développement logiciel, Distribution de logiciel, logiciel libre, openSUSE build service, packaging, python | Tagué: avril 2010, create kernel modules, GNU/Linux magazine N°126, http://software.opensuse.org/search, monoosc, openSUSE build service, osc | Poster un commentaire »
Publié par patrick le mars 21, 2010
Quelques liens en vrac sur les sorties de python 2.6.5 , python 3.1.2 et pypy 1.2
- http://www.python.org/download/releases/2.6.5/ (‘The final release for Python 2.6.5 is now available. Python 2.6.5 fixes dozens of issues in the core, built-in modules, libraries, and documentation since Python 2.6.4 was released back in October 2009. We highly recommend that you upgrade to Python 2.6.5. Please see the NEWS file for all the gory details.’)
- http://docs.python.org/whatsnew/2.6.html (‘The major theme of Python 2.6 is preparing the migration path to Python 3.0, a major redesign of the language. Whenever possible, Python 2.6 incorporates new features and syntax from 3.0 while remaining compatible with existing code by not removing older features or syntax. When it’s not possible to do that, Python 2.6 tries to do what it can, adding compatibility functions in a future_builtins module and a -3 switch to warn about usages that will become unsupported in 3.0′)
- - http://www.python.org/download/releases/3.1.2/ (The second bug fix release for the Python 3.1 series is now available, Published: Sun, 21 Mar 2010, 12:30:00 -0500)
- http://morepypy.blogspot.com/2010/03/introducing-pypy-12-release.html ("We are pleased to announce PyPy’s 1.2 release. This version 1.2 is a major milestone and it is the first release to ship a Just-in-Time compiler that is known to be faster than CPython (and unladen swallow) on some real-world applications (or the best benchmarks we could get for them). The main theme for the 1.2 release is speed.")
- http://pypy.org/features.html (‘PyPy 1.2 implements Python 2.5. It supports all of the core language, passing the Python test suite (with minor modifications that were already accepted in the main python in newer versions). It supports most of the commonly used Python standard library modules. For known differences with CPython, see our compatibility page. PyPy 1.2 runs essentially only on Intel x86 (IA-32). On 64-bit platforms you have to use the 32-bit compatibility mode, for now — or contact us to help’)
- Speed: thanks to its Just-in-Time compiler, Python programs often run faster on PyPy. (What is a JIT compiler?)
- Memory usage: large, memory-hungry Python programs might end up taking less space than they do in CPython.
- Sandboxing: PyPy provides the ability to run untrusted code in a fully secure way.
- Stackless: PyPy can be configured to run in stackless mode, providing micro-threads for massive concurrency.
- As well as other features.")
Publié dans 2010, PyPy, python, Tkinter | Poster un commentaire »
Publié par patrick le février 28, 2010
pycon 2010 Atlanta
State of python packaging
- http://blip.tv/file/3259547 (‘:Deployment, development, packaging, and a little bit of the cloud’ by Ian Bicking)
- http://blip.tv/file/2061678 (‘Eggs and Buildout Deployment in Python, Puzzled about Python eggs and packages? Wondering how to repeatably pull together collections of packages into standalone development, testing and deployment environments, all while managing inter-dependencies? In this participatory tutorial, we’ll start with distutils, walk through using eggs in the cheeseshop and creating your own eggs, touch a bit on using virtualenv to set up a development environment, and then dig into using zc.buildout to rigorously control assembly specifications, with build recipes, versioning and dependency management. We’ll close by showing how to create your own recipes. Attendees are strongly encouraged to bring a laptop or partner with someone who does.’)
- http://blip.tv/file/2080263 (‘How I Distribute Python applications on Windows – py2exe & InnoSetup’ by Brian Dorsey There are many deployment options for Python code. I’ll share what has worked well for me on Windows, packaging command line tools and services using py2exe and InnoSetup. I’ll demonstrate a simple build script which creates windows binaries and an InnoSetup installer in one step. In addition, I’ll go over common errors which come up when using py2exe and hints on troubleshooting them. This is a short talk, so there will be a follow-up Open Space session to share experience and help each other solve distribution problems )
- http://blip.tv/file/2072580 (‘[VIDEO HAS ISSUES: no audio first 1.5m] If you’ve ever created a nifty application that makes people’s lives easier you know the truly hard part is convincing others to use it. One way to increase the number of people installing your software is to convince Linux distributions to package your software so that their end users can install by using the system tools they’re used to. One way of convincing them is by making your application easy to package.’)
- http://blip.tv/file/3263882 (‘New *and* Improved: Coming changes to unittest, the standard library test framework’ by Michael Foord)
- http://blip.tv/file/3261338 (‘Easy command-line applications with cmd and cmd2′ by Catherine Devlin)
- http://catherine.devlin.googlepages.com/cmd2.html (‘cmd2 is a tool for writing command-line interactive applications. It is based on the Python Standard Library’s cmd module, and can be used anyplace cmd is used simply by importing cmd2 instead’)
- http://blip.tv/file/3254256 (‘Understanding the Python GIL by David Beazley‘)
Publié dans 2010, Génie logiciel, python, tests | Tagué: Brian Dorsey, Catherine Devlin, innosetup, Michael Foord, py2exe, Tarek Ziadé | Poster un commentaire »
Publié par patrick le novembre 16, 2009
- http://pypi.python.org/pypi/numpydoc/0.3.1 (Sphinx extension to support docstrings in Numpy format)
- http://pypi.python.org/pypi/flexirest/ (‘ The medium-featured, flexible reStructuredText utility. Flexirest is a project that was born out of the authors long-running interest for reStructuredText, and the idea of writing everyday documents like letters, invoices and other simple documents in this way. Flexirest tries to strike a middle ground between docutils own command line tool chain (rst2html et al), that I find a little to minimalistic and Sphinx, that I find very nice but a little heavy to use for a quickie document like a random letter or some such. In short, the goal of flexirest is to enable you to use the reST format for everyday documents instead of a word processor or similar with minimal fuzz. Hence you get to stay in the comfy environment of your text editor and tool chain. And you can check in your docs in text format into your version control system of choice. And, if used correctly, you get to reuse a couple of stylings that you only need to create once. There are some modestly advanced tricks you can do too, primarily writing your own docutils roles, but I wouldn’t consider those the major points of flexirest. For more information on how to operate flexirest, see the quick manual.’)
- http://groups.google.fr/group/sphinx-dev/browse_thread/thread/8e97570a6321dd8d?hl=fr (‘sphinx theme that could be useful to authors of sourceforge hosted projects. The look is more or less the same of the default theme but there are some facilities that could be useful.
A more detailed description of the theme can be found at:
And, finally, two projects of using it:
- http://gsdview.sourceforge.net/ (‘GSDView (Geo-Spatial Data Viewer) is a lightweight viewer for geo-spatial data and products. It is written in python and Qt4 and it is mainly intended to be a graphical front-end for the GDAL library and tools. GSDView is modular and has a simple plug-in architecture.’)
- http://bestgui.sourceforge.net/ (‘BESTGUI is a Graphical User Interface (GUI) for BEST written in Python and GTK+. The Basic Envisat SAR Toolbox (BEST) is a collection of executable software tools that has been designed to facilitate the use of ESA (the European Space Agency) SAR data. It operates according to user-generated parameters files. For more detail you should refer to the BEST Home Page.’)
Publié dans 2009, Documentation, Génie logiciel, python, reStructuredText | Tagué: sourceforge, sphinx theme | Poster un commentaire »