"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Archive for the ‘python’ Category

Sphinx developpment : Implemented improved glossary markup which allows multiple terms per definition.

Posted by patrick sur 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.

 

--- a/tests/root/markup.txt
+++ b/tests/root/markup.txt
 
 .. glossary::
+   :sorted:
 
    boson
       Particle with integer spin.
 
-   fermion
+   *fermion*
       Particle with half-integer spin.
 
+   tauon
+   myon
+   electron
+      Examples for fermions.
+
+   über
+      Gewisse
+
+   änhlich
+      Dinge
+

 

This development is very interesting. Use of the visitor pattern.

. rst:directive:: .. glossary::
155
155
156
   This directive must contain a reST definition list with terms and
157
   definitions.  The definitions will then be referencable with the :rst:role:`term`
158
   role.  Example::
156
   This directive must contain a reST definition-list-like markup with terms and
157
   definitions.  The definitions will then be referencable with the
158
   :rst:role:`term` role.  Example::
159
159
160
160
      .. glossary::
161
161
@@ -169,10 +169,25 @@ Glossary
169
169
            The directory which, including its subdirectories, contains all
170
170
            source files for one Sphinx project.
171
171
172
   In contrast to regular definition lists, *multiple* terms per entry are
173
   allowed, and inline markup is allowed in terms.  You can link to all of the
174
   terms.  For example::
175
176
      .. glossary::
177
178
         term 1
179
         term 2
180
            Definition of both terms.
181
182
   (When the glossary is sorted, the first term determines the sort order.)
183
172
184
   .. versionadded:: 0.6
173
185
      You can now give the glossary directive a ``:sorted:`` flag that will
174
186
      automatically sort the entries alphabetically.
175
187
188
   .. versionchanged:: 1.1
189
      Now supports multiple terms and inline markup in terms.

Posted in 2011, Documentation, Doc_sphinx, python, reStructuredText, Sphinx | Leave a Comment »

Doxylink is a Sphinx extension to link to external Doxygen API documentation

Posted by patrick sur septembre 19, 2010

http://packages.python.org/sphinxcontrib-doxylink/

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.

Posted in 2010, Années, C++, Documentation, Doc_sphinx, Génie logiciel, Langages, reStructuredText, Sphinx | Tagué: , , , | Leave a Comment »

PythonC 2.6 for Java : Py4J 0.4 is out

Posted by patrick sur septembre 19, 2010

Py4j (http://py4j.sourceforge.net/index.html)

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.

py4j

See also

http://www.jython.org/index.html (« Python for the Java Platform »)

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.

Posted in 2010, Années, Documentation, java, jython, Langages, python, Sphinx | Tagué: , , | Leave a Comment »

Quelques liens sur des modules python intéressants: plac, tox, shinken, six

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 placplac 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‘)

Posted in 2 to 3, 2010, Administration, Administration système, Années, Génie logiciel, python, tests, tests | Tagué: , , , , , , , | Leave a Comment »

An other ctypes based python module : pyUSB 1.0 (alpha) is out !

Posted by patrick sur avril 22, 2010

http://pyusb.sourceforge.net
http://pyusb.sourceforge.net/docs/1.0/tutorial.html 

=======================================
PyUSB 1.0 – Easy USB access from Python
=======================================

Introduction
============

The PyUSB module provides Python with easy access to the host
machine’s Universal Serial Bus (USB) system.

Until 0.4 version, PyUSB used to be a thin wrapper aroung libusb.
With 1.0 version, things changed considerably. Now PyUSB is an
API rich, backend neutral Python USB module easy to use.

As with most Python modules, PyUSB’s documentation is based on Python
doc strings and can therefore be manipulated by tools such as pydoc.

You can also find a tutorial at: http://pyusb.sourceforge.net/docs/1.0/tutorial.html.

PyUSB is being developed and tested in Linux and Windows, but it should work
fine in any platform running Python >= 2.3, ctypes and at least one of the
builtin backends.

PyUSB supports libusb 0.1, libusb 1.0 and OpenUSB, but the user does not need
to worry about that, unless in some corner cases.

If you have any question about PyUSB, you can use the PyUSB mailing list
hosted in the SourceForge. In the PyUSB website (http://pyusb.sourceforge.net)
you can find instructions on how to subscribe to the mailing list.

Installing PyUSB on GNU/Linux Systems
=====================================

These instructions are for Debian-based systems.  Instructions for
other flavors of GNU/Linux should be similar.

You will first need to install the following packages:

1) python (PyUSB is useless without it), version >= 2.3
2) At least one of the supported libraries (libusb 1.0, libusb 0.1 or OpenUSB)
3) If your Python version is < 2.5, you have to install ctypes as a separate package,
because these versions of Python does not ship it.

For example, the command

sudo apt-get install python libusb

should install all these packages on most Debian-based systems with
access to the proper package repositories.

Once the above packages are installed, you can install PyUSB
with the command

python setup.py install

run as root from within the same directory as this README file.

Installing PyUSB on Windows
===========================

Now that PyUSB is 100% written in Python, you install it on Windows
in the same way you do on Linux, but libusb for Windows is done
through libusb-win32 package (libusb 1.0 backend is in progress).
To install it you do as usual:

python setup.py install

Reporting bugs/Submitting patches
=================================

Some people have been sending me patches and reporting bugs directly
in my email. Please, do it through SourceForge tracker, I had
a hardtime tracking their names to put them in the acknowledgments file. 😉

PS: this README file was based on the great Josh Lifton’s one… ^_^

import usb.core
import usb.util

# find our device
dev = usb.core.find(idVendor=0xfffe, idProduct=0x0001)

# was it found?
if dev is None:
    raise ValueError('Device not found')

# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()

# get an endpoint instance
ep = usb.util.find_descriptor(
        dev.get_interface_altsetting(),   # first interface
        # match the first OUT endpoint
        custom_match = \
            lambda e: \
                usb.util.endpoint_direction(e.bEndpointAddress) == \
                usb.util.ENDPOINT_OUT
    )

assert ep is not None

# write the data
ep.write('test')

Voir aussi

  • http://docs.python.org/library/ctypes.html (‘ctypes is a foreign function library for Python. It provides C compatible data types, and allows calling functions in DLLs or shared libraries. It can be used to wrap these libraries in pure Python’)
  • http://pypi.python.org/pypi/jaraco.windows/1.8 (‘jaraco.windows aims to provide a pure-python interface to Windows APIs using ctypes. This package is not designed to be exhaustive, but rather to supply interfaces as they are needed by the contributors.’)

Posted in 2010, ctypes, Operating Systems, python, USB | Tagué: , | Leave a Comment »

Python packaging : Hitchhiker guide, toydist, envbuilder

Posted by patrick sur 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://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.’)

Posted in 2010, Développement logiciel, distribute, Distribution de logiciel, Doc_sphinx, Génie logiciel, package_management, packaging, toydist | Leave a Comment »

Le service de construction de paquetages d’openSUSE : openSUSE build service (OBS)

Posted by patrick sur 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…..)

Posted in 2010, command line interface, Développement logiciel, Distribution de logiciel, logiciel libre, openSUSE build service, packaging, python | Tagué: , , , , , , | Leave a Comment »

Sortie de python 2.6.5, python 3.1.2, pypy 1.2

Posted by patrick sur mars 21, 2010

Quelques liens en vrac sur les sorties de python 2.6.5 , python 3.1.2 et pypy 1.2

  • 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. »)

Posted in 2010, PyPy, python, Tkinter | Leave a Comment »

Python: quelques liens sur pycon 2010 : state of packaging, PEP345, PEP 386, unittest, cmd2, GIL, distributing, etc..

Posted by patrick sur février 28, 2010

pycon 2010 Atlanta

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‘)

Posted in 2010, Génie logiciel, python, tests | Tagué: , , , , , | Leave a Comment »

Python documentation: news sphinx/numpydoc + flexirest + sphinx sourceforge theme/{gsdview,bestgui}

Posted by patrick sur 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.’)

Posted in 2009, Documentation, Génie logiciel, python, reStructuredText | Tagué: , | Leave a Comment »