"…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 décembre 2008

Infos python: bytecodes, python parser, AST, gajim

Posted by patrick sur décembre 19, 2008

http://spyrit.svn.sourceforge.net/viewvc/spyrit/trunk/dist (‘A la question: Comment concentrer en un seul script toutes les classes et fonctions nécessaires (mais seulement ce qui est nécessaire) pour obtenir le résultat ? Sundance  a répondu : j’ai développé un petit système qui permet de faire ce genre de chose: tu lances ce programme en lui passant en paramètre le nom du script à packager, et ça cherche les modules dont dépend ce script, ça les compile en bytecode, et ça génère un seul script contenant 1) le bytecode des modules dans un dictionnaire, et 2) un hook d’import qui cherche les imports dans ce dictionnaire. »)

#!/usr/bin/python
## -*- coding: utf-8 -*-

import sys
import imp
import bz2
import time
import struct
import marshal
import os.path

LAUNCHER_STUB = """#!/usr/bin/python
## -*- coding: utf-8 -*-

EMBEDDED_MODULES = {
%s
}

import sys
import imp
import bz2
import marshal

class embedded_module_importer:

  def find_module( s, fullname, path=None ):

    if fullname == "MAIN":
      fullname = "__main__"

    return EMBEDDED_MODULES.has_key( fullname ) and s or None

  def load_module( s, fullname ):

    if fullname == "MAIN":
      fullname = "__main__"

    filename, code = EMBEDDED_MODULES[ fullname ]
    code =  marshal.loads( bz2.decompress( code ) )

    mod = sys.modules.setdefault( fullname, imp.new_module( fullname ) )
    mod.__file__ = filename
    mod.__loader__ = s

    exec code in mod.__dict__

    return mod

sys.meta_path.append( embedded_module_importer() )

import MAIN
"""

def get_timestamp_long():
  return struct.pack( "l", long( time.time() ) )

def make_bytecode( filename ):

  m  = compile( file( filename ).read(), filename, 'exec' )
#  bc = imp.get_magic() + get_timestamp_long() + marshal.dumps( m )
  bc = bz2.compress( marshal.dumps( m ) )

  return bc

def make_module_dict( modules ):

  mods = []

  for ( modulename, f ) in modules:
    bc = make_bytecode( f )
    mods.append( "  %s: ( %s, %s )" % ( modulename.__repr__(),
                                        f.__repr__(),
                                        make_bytecode( f ).__repr__() ) )

  return ",\n".join( mods )

def make_launcher( main, modules ):

  return LAUNCHER_STUB % ( make_module_dict( modules ) )

def build( scriptname, outputname=None ):

  mainname, ext = os.path.splitext( scriptname )

  from modulefinder import ModuleFinder

  p = os.path.abspath( os.getcwd() )

  if os.path.dirname( scriptname ):
    os.chdir( os.path.dirname( scriptname ) )

  mf = ModuleFinder( [ "." ] )
  mf.run_script( os.path.basename( scriptname ) )

  libs = [ ( name, mod.__file__ ) for ( name, mod ) in mf.modules.iteritems()
                                  if mod.__file__ ]

  output = make_launcher( mainname, libs )

  os.chdir( p )

  if not outputname:
    print output

  else:
    file( outputname, "wb" ).write( output )

def main():

  if not len( sys.argv ) > 1:
    return

  if len( sys.argv ) > 2:
    build( sys.argv[1], sys.argv[2] )

  else:
    build( sys.argv[1] )

if __name__ == "__main__":
  main()

Dans le même genre de choses:

http://svn.python.org/view/python/branches/release30-maint/Tools/freeze/README?rev=67499&view=markup (‘What is Freeze ? Freeze make it possible to ship arbitrary Python programs to people who don’t have Python. The shipped file (called a « frozen » version of your Python program) is an executable, so this only works if your platform is compatible with that on the receiving end (this is usually a matter of having the same major operating system revision and CPU type). ‘)

http://svn.python.org/view/python/branches/release30-maint/Python/compile.c?rev=67499&view=markup(‘This file compiles an abstract syntax tree (AST) into Python bytecode‘)

http://svn.python.org/view/python/branches/release30-maint/Python/ast.c?rev=67499&view=markup(‘This file includes functions to transform a concrete syntax tree (CST) to * an abstract syntax tree (AST). The main function is PyAST_FromNode()‘)

http://pypi.python.org/pypi/sourcecodegen/0.6.2 (‘This package provides a module-level source-code generator which
operates on the AST from the built-in compiler.ast module.Note that this AST is not compatible with the new ast module in
Python 2.6

The generator works on AST parse trees.

from compiler import parse
tree = parse("""\
...     print 'Hello, world!'
... """)

We can now generate Python-code equivalent to the original using the source-code generator.

from sourcecodegen import ModuleSourceCodeGenerator
generator = ModuleSourceCodeGenerator(tree)
print generator.getSourceCode()
print 'Hello, world!'

‘)

http://svn.python.org/view/python/branches/release30-maint/Demo/parser/#dirlist
http://svn.python.org/view/python/branches/release30-maint/Demo/parser/README?rev=67499&view=markup (‘These files are from the large example of using the `parser’ module. Refer
to the Python Library Reference for more information.
It also contains examples for the AST parser.

Files:
——

FILES — list of files associated with the parser module.

README — this file.

example.py — module that uses the `parser’ module to extract
information from the parse tree of Python source
code.

docstring.py — sample source file containing only a module docstring.

simple.py — sample source containing a « short form » definition.

source.py — sample source code used to demonstrate ability to
handle nested constructs easily using the functions
and classes in example.py.

test_parser.py program to put the parser module through its paces.

unparse.py AST (2.5) based example to recreate source code
from an AST. This is incomplete; contributions
are welcome.

Enjoy!‘)

http://svn.python.org/view/python/branches/release30-maint/Doc/library/parser.rst?rev=67499&view=markup (‘Access parse trees for Python source code…From Python 2.5 onward, it’s much more convenient to cut in at the Abstract  Syntax Tree (AST) generation and compilation stage, using the :mod:`ast` module’)

http://linuxfr.org/2008/12/18/24812.html(‘Gajim, le client Jabber aérien (écrit en Python et GTK+ pour ceux que ça intéresse) vient de sortir en version 0.12, quasiment un an jour pour jour après la 0.11.4 et deux ans après la 0.11.
L’avantage par rapport à d’autres de ce client de messagerie instantanée, sous licence GPLv3, est qu’il ne fait que le protocole Jabber (XMPP), et le fait bien. On a même accès à une console XML dans laquelle on peut injecter le XML qu’on veut, très fun pour jouer avec les copains pendant ces froides soirées d’hiver. Gros plus non négligeable, il est l’un des rares à prendre en charge GnuPG (peut-être même le seul en GTK+), pour la confidentialité de vos conversations ou pour authentifier votre interlocuteur.
Au programme des nouveautés :

  • Amélioration du support des sessions ;
  • Chiffrement point à point (transparent pour l’utilisateur) ;
  • Amélioration de l’interface graphique en général ;
  • Validation des certificats SSL ;
  • Intégration de Kerberos ;
  • Salons de discussion dans le roster ;
  • Conversion d’une conversation privée en salon de discussion ;
  • Événements personnels (PEP) : humeur, activité, musique écoutée ;
  • Et bien sûr, la classique corrections des bugs.

Il ne reste qu’à l’installer 😉

Publicités

Posted in package_management, python | Tagué: , , , | Leave a Comment »

Java : « Will Open-Sourcing Java Remove Competetive Corporate-Think? » de Bruce Eckel

Posted by patrick sur décembre 19, 2008

  • http://www.artima.com/weblogs/viewpost.jsp?thread=244996 (« Will Open-Sourcing Java Remove Competetive Corporate-Think? The problem with public corporations is that, no matter what they say, « maximize quarterly profits » is the real mantra…Java was created in a company run by a hyper-competitive CEO and the whole culture around it has been competitive. Many decisions were made without the consumer (programmers) in mind, but with Sun’s apparent best interests in mind…Early on, the « write once, run everywhere » chant started and that justified everything. If you want to talk to something OS-specific, you can use JNI, right? What a nightmare. And the joke became « write once, test everywhere »…Sun, as is its habit, never learns from its mistakes. Sometime in the last couple of years, rumor has it that Adobe apparently extended the possibility of working with Sun so that Flex would integrate seamlessly with Java. This would seem like a best-of-all-worlds situation, to pal up with the folks who have been specializing in UI programming. Instead, that seems to be around the time that JavaFX was started (which even poached Flex’s « Fx »). The classic « not invented here » response is the standard reply of corporate competitive-think…Open-sourcing Java is not going to make it an open-source project. The culture that has built up around Java for over ten years is not going to change just by moving to a new license…A truly open-source programming language does not have shareholders to serve. It can only serve its actual customers, the programmers who are consuming the language. For example, Python has always been about « what do you want to do today? » If you want to create a cross-platform app, no problem. And if you want to talk directly to the OS, that’s been made as easy as possible. This makes sense because Python is an « enabling » language — it’s about helping you do what you need to do, rather than telling you what you can and can’t do (these comments also apply to Ruby and other enabling languages, but I only occasionally tinker with Ruby so I can’t speak authoritatively about it).Python, after thrashing around with many different approaches, also solved the « interfacing to native code » problem. In Python 2.5, ctypes were added. Now you only have to say « there’s the DLL, connect to it as efficiently as possible » and it does it. And amazingly, the DLLs are the only things that are different on different platforms; your Python code can be the same. That’s the right solution to the problem. (When Jython 2.5 comes out, I’ve heard it will have ctypes working so that may be the reasonable alternative to JNI)…Java won’t die. But the adoption of new Java versions and features is going to continue to slow. People have been bitten too many times. Java lost its status of being a leader awhile ago, and it’s now a legacy language — it’s just taking awhile for everyone to realize it…Full disclosure: My consulting contract (mostly speaking, some free-form writing) with Adobe expired around last May (and yes, Adobe is a full-on corporation with all of the problems that implies — but according to rumor it was Adobe that suggested the liaison with Sun); I decided on my own that Flex is a good solution for UIs, both before and after that contract. Also, James Ward and I just published our coauthored book (written under our own steam, not part of the Adobe contract) First Steps in Flex. I’m working on an open-source book on Python 3. And before you say I’ve gone totally anti-Java, I also organize The Java Posse Roundup with The Java Posse (so think « tough love »).« )

Voir:

  • http://wiki.debian.org/Java
  • http://en.wikipedia.org/wiki/IcedTea (‘IcedTea is a software development and integration project launched by Red Hat in June 2007.[1] The goal is to make the OpenJDK software which Sun Microsystems released as free software in 2007 usable without requiring any other software that is not free software. For Red Hat, this would make it possible to add OpenJDK to the Fedora Linux distribution, as well as other distributions. This goal has been met, and a version of IcedTea based on OpenJDK was packaged with Fedora 8 in November 2007. April 2008 saw the first release[2] of a new variant, IcedTea6 which is based on Sun’s build drops of OpenJDK6, a fork of the OpenJDK with the goal of being compatible with the existing JDK6. This was released in Ubuntu and Fedora in May 2008. The IcedTea package in these distributions has been renamed to OpenJDK using the OpenJDK trademark notice‘)
  • http://packages.debian.org/sid/java-package (‘This program currently works with the following Java(TM) 2 Runtime Environments and Development Kits:
     * Sun Microsystems(TM) 1.4, 5 and 6 Standard Edition
     * IBM(TM) 1.3, 1.4, 5 and 6 Standard Edition
     * Blackdown Java-Linux 1.3 and 1.4 Standard Edition')

Posted in 2008, java, jython, python | Tagué: , , , , | Leave a Comment »

Python: news du 17 décembre 2008

Posted by patrick sur décembre 18, 2008

  • http://tarekziade.wordpress.com/2008/12/16/pycon-2009-talks/ (‘The talks that made it:
    • How AlterWay releases web applications using zc.buildout
    • On the importance of PyPI in delivering and building Python softwares – mirroring, fail-over and third-party package indexes »)
  • http://jessenoller.com/2008/12/16/pycon-2009-talks-accepted/ (‘Last night I got two emails – both of my talks I proposed for PyCon 2009 were accepted, here’s the title and abstract from both:
    • Introduction to Multiprocessing in Python
      • This talk will cover the new multiprocessing package included with Python 2.6 (and 3.0) focusing on design, benefits, practical usage, application construction, gotchas and how to use it to build multi-core and distributed applications.
    • Concurrency and Distributed Computing with Python Today
      • This talk will cover the recent changes to Python 2.6, including a brief introduction to the threading module and multiprocessing inclusion and changes but will primarily focus on the concurrent and distributed ecosystem for Python today.‘)

Posted in 2008, DotNet, Ironpython, Multiprocessing, package_management, python | Tagué: | Leave a Comment »

Python package management: « using pip requirements » from Ian Bicking

Posted by patrick sur décembre 17, 2008

Un article très dense et très instructif de Ian Bicking reproduit dans son intégralité:

Source: http://blog.ianbicking.org/2008/12/16/using-pip-requirements/

================================

Following onto a set of recent posts (from James, me, then James again), Martijn Faassen wrote a description of Grok’s version management. Our ideas are pretty close, but he’s using buildout, and I’ll describe out to do the same things with pip.

Here’s a kind of development workflow that I think works well:

  • A framework release is prepared. Ideally there’s a buildbot that has been running (as Pylons has, for example), so the integration has been running for a while.
  • People make sure there are released versions of all the important components. If there are known conflicts between pieces, libraries and the framework update their install_requires in their setup.py files to make sure people don’t use conflicting pieces together.
  • Once everything has been released, there is a known set of packages that work together. Using a buildbot maybe future versions will also work together, but they won’t necessarily work together with applications built on the framework. And breakage can also occur regardless of a buildbot.
  • Also, people may have versions of libraries already installed, but just because they’ve installed something doesn’t mean they really mean to stay with an old version. While known conflicts have been noted, there’s going to be lots of unknown conflicts and future conflicts.
  • When starting development with a framework, the developer would like to start with some known-good set, which is a set that can be developed by the framework developers, or potentially by any person. For instance, if you extend a public framework with an internal framework (or even a public sub-framework like Pinax) then the known-good set will be developed by a different set of people.
  • As an application is developed, the developer will add on other libraries, or use some of their own libraries. Development will probably occur at the trunk/tip of several libraries as they are developed together.
  • A developer might upgrade the entire framework, or just upgrade one piece (for instance, to get a bug fix they are interested in, or follow a branch that has functionality they care about). The developer doesn’t necessarily have the same notion of « stable » and « released » as the core framework developers have.
  • At the time of deployment the developer wants to make sure all the pieces are deployed together as they’ve tested them, and how they know them to work. At any time, another developer may want to clone the same set of libraries.
  • After initial deployment, the developer may want to upgrade a single component, if only to test that an upgrade works, or if it resolves a bug. They may test out combinations only to throw them away, and they don’t want to bump versions of libraries in order to deploy new combinations.

This is the kind of development pattern that requirement files are meant to assist with. They can provide a known-good set of packages. Or they can provide a starting point for an active line of development. Or they can provide a historical record of how something was put together.

The easy way to start a requirement file for pip is just to put the packages you know you want to work with. For instance, we’ll call this project-start.txt:

Pylons
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary

You can plug away for a while, and maybe you decide you want to freeze the file. So you do:

$ pip freeze -r project-start.txt project-frozen.txt

By using -r project-start.txt you give pip freeze a template for it to start with. From that, you’ll get project-frozen.txt that will look like:

Pylons==0.9.7
-e svn+http://mycompany/svn/MyApp/trunk@1045#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk@1058#egg=MyLibrary

## The following requirements were added by pip –freeze:

Beaker==0.2.1
WebHelpers==0.9.1
nose==1.4
# Installing as editable to satisfy requirement INITools==0.2.1dev-r3488:
-e svn+http://svn.colorstudy.com/INITools/trunk@3488#egg=INITools-0.2.1dev_r3488

At that point you might decide that you don’t care about the nose version, or you might have installed something from trunk when you could have used the last release. So you go and adjust some things.

Martijn also asks: how do you have framework developers maintain one file, and then also have developers maintain their own lists for their projects?

You could start with a file like this for the framework itself. Pylons for instance could ship with something like this. To install Pylons you could then do:

$ pip -E MyProject install  -r http://pylonshq.com/0.9.7-requirements.txt

You can also download that file yourself, add some comments, rename the file and add your project to it, and use that. When you freeze the order of the packages and any comments will be preserved, so you can keep track of what changed. Also it should be ameniable to source control, and diffs would be sensible.

You could also use indirection, creating a file like this for your project:

-r http://pylonshq.com/0.9.7-requirements.txt
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp

-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary

That is, requirements files can refer to each other. So if you want to maintain your own requirements file alongside the development of an upstream requirements file, you could do that.

Posted in 2008, Distribution de logiciel, Génie logiciel, Gestion de version, Intégration continue, package_management, python | Tagué: , , | Leave a Comment »

Michele Simionato: The decorator module version 3 is out!

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/decoratorThis 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é: , | Leave a Comment »

Python package management: critiques de setuptools et louanges de pip et virtualenv

Posted by patrick sur décembre 16, 2008

La compréhension de la gestion des packages Python est devenue essentielle avec l’arrivée de 2 nouvelles versions de Python: python 2.6 et Python 3000 (ou Python 3k)

Voici quelques articles récents:

http://blog.ianbicking.org/2008/12/14/a-few-corrections-to-on-packaging/ (‘James Bennett recently wrote an article on Python packaging and installation, and Setuptools. There’s a lot of issues, and writing up my thoughts could take a long time, but I thought at least I should correct some errors, specifically category errors. Figuring out where all the pieces in Setuptools (and pip and virtualenv) fit is difficult

pip:
This is an alternative to easy_install. It works somewhat differently than easy_install, but not much. Mostly it is better than easy_install, in that it has some extra features and is easier to use. Unlike easy_install, it downloads all distributions up-front, and generates the metadata to read distribution and version requirements. It uses Setuptools to generate this metadata from a setup.py file, and uses pkg_resources to parse this metadata. It then installs packages with the setuptools monkeypatches applied. It just happens to use an option python setup.py –single-version-externally-managed, which gets Setuptools to install packages in a more flat manner, with Distro.egg-info/ directories alongside the package. Pip installs eggs! I’ve heard the many complaints about easy_install (and I’ve had many myself), but ultimately I think pip does well by just fixing a few small issues. Pip is not a repudiation of Setuptools or the basic mechanisms that easy_install uses.
virtualenv:
This is a little hack that creates isolated Python environments. It’s based on virtual-python.py, which is something I wrote based on some documentation notes PJE wrote for Setuptools. Basically virtualenv just creates a bin/python interpreter that has its own value of sys.prefix, but uses the system Python and standard library. It also installs Setuptools to make it easier to bootstrap the environment (because bootstrapping Setuptools is itself a bit tedious). I’ll add pip to it too sometime. Using virtualenv you don’t have to worry about different library versions, because for any one environment you will probably only need one version of a library. On any one machine you probably need different versions, which is why installing packages system-wide is problematic for most libraries. (I’ve been meaning to write a post on why I think using system packaging for libraries is counter-productive, but that’ll wait for another time.

…I don’t think zipping libraries up is all that useful, and while it should work, it doesn’t always, and it makes code harder to inspect and understand. So since it’s not that useful, I’ve disabled it when pip installs packages. I also have had it disabled on my own system for years now, by creating a distutils.cfg file with [easy_install] zip_ok = False in it. Sadly App Engine is forcing me to use zip files again, because of its absurdly small file limits… but that’s a different topic. (There is an experimental pip zip command mostly intended for App Engine.

…Another pain point is version management with setup.py and Setuptools. Indeed it is easy to get things messed up, and it is easy to piss people off by overspecifying, and sometimes things can get in a weird state for no good reason (often because of easy_install’s rather naive leap-before-you-look installation order). Pip fixes that last point, but it also tries to suggest more constructive and less painful ways to manage other pieces.

Pip requirement files are an assertion of versions that work together. setup.py requirements (the Setuptools requirements) should contain two things: 1: all the libraries used by the distribution (without which there’s no way it’ll work) and 2: exclusions of the versions of those libraries that are known not to work. setup.py requirements should not be viewed as an assertion that by satisfying those requirements everything will work, just that it might work. Only the end developer, testing the system together, can figure out if it really works. Then pip gives you a way to record that working set (using pip freeze), separate from any single distribution or library….

  1. I am new to pip, so I hope I don’t write silly things ;)It’s a good idea to have the requirements outside the package, instead of what setuptools does. So you can share them amongst several packages.

    So basically, pip’s requirements files are what Zope calls the “Known Good Set” and what Turbogears 2 does by maintaining its own PyPI server to distribute TG2 packages : a list of versions that are known to interact well in the same environment, right ?

    But it’s not really different from setuptools there, except that you change the requirements in a different place if something goes wrong.

    So to simplify the problem, couldn’t we have juste ONE requirement file in the whole Python ?

    This could be the clue for os packagers : they would be able to tweak this file, while developers would be able to try out their package over different requirements files (”the debian etch python requirement file” “the debian unstable python requirement file”, etc). And for specific, isolated stuff, using virtualenv would allow developer to have their own custome requirement files….

  1. As Brett points out, apt and other package managers are inappropriate because they don’t allow multiple versions of packages to be installed, local environments, and ad hoc packages

  1. Hey Ian,

    This is an excellent and unbiased summary. More or less the missing manual of the current state of packaging under Python.

    I need to add that I really like pip. It doesn’t change much to easy_install, but it is day and night to me. Thanks for making it available.)

  • http://www.b-list.org/weblog/2008/dec/15/pip/ (‘Why I like pip. So yesterday I explained some of the reasons why I don’t like setuptools. In essence, my objections boil down to one idea: application packagingdevelopment should be orthogonal concerns. The way setuptools works, however, seems to tend, inevitably, toward coupling them to each other…But toward the end of yesterday’s article I suggested pip as an alternative to pkg_resources/easy_install toolchain, and today I’d like to explain a bit more about why I prefer pip and some of the concrete benefits it offers and application as an alternative to the setuptools… in his response to my article yesterday Ian clarified that pip just uses the setuptools APIs to do this. Which is saying something: glossing over setuptools’ warts to the point where you don’t even realize it’s being used is a pretty big deal… pip looks before it leaps, can bail out early if it’s not going to be able to install your package and will leave behind a useful log file explaining what went wrong…The point where pip really shines, though, is in the ease of specifying and creating reproducible builds. If you’ve ever dealt with having to deploy the same code base across multiple machines, you know what a headache this can be, since a huge number of factors (operating system and version, pre-installed packages and versions, system package managers and configuration, etc., etc.) can change the results of your deployment process, sometimes in subtle and difficult-to-debug ways. With pip, this is not (so much of) a problem…I mentioned pip requirements files yesterday as an alternative to the way setuptools specifies dependencies directly in setup.py, and that’s certainly one useful application of the feature, but you can take it much further: once you know which packages (and, just as important, which versions of which packages) you need, you can write them down in a simple, plain-text file, point pip at it, and it’ll install them…The last piece of the puzzle, for me, is virtualenv; virtualenv is a tool for creating and working with isolated Python environments, and is basically the only way I work with Python these days…pip integrates quite nicely with virtualenv; normally, when working in an active virtualenv, Python packaging/installation tools (pip included) will install into that virtualenv, but pip also lets you:
  • Specify a virtualenv to install into (using the -E flag), and
  • Create a new virtualenv and install into it.

The second one is really the killer feature, because it means you can set up a requirements file specifying a list of packages, and get pip to create a virtualenv for you and install the packages into it…… well, there’s a heck of a lot more I could write here about pip (and about virtualenv, and about some other interesting tools), but I think this is a good start and hopefully I’ve at least got you interested enough to explore a bit on your own. And I hope I’ve managed to communicate some of the practical reasons why I’ve ditched easy_install for package installation; compared to what pip can do right now (not even considering what it might be able to do in the future), easy_install just doesn’t measure up enough to justify the headaches it can create… »)

  • http://tarekziade.wordpress.com/2008/12/15/python-isolated-environment-pie/ (‘Right now, when Python is loaded, it uses the site module to browse the site-packages directory to populate the path with packages it find there.  .pth files are also parsed to provide extra paths. Python 2.6 has introduced per-user site-packages directory, where you can define an extra directory, which is added in the path like the central one. But both will append new paths to the environment without any rule of exclusion or version checking…A few workarounds exist to be able to express what packages (and version) an application needs to run, or to set up an isolated environment for it:
  • setuptools provides the install_requires mechanism where you can define dependencies directly inside the package, as a new metadata. It also provides a way to install two different versions of one package and let you pick by code or when the program starts, which one you want to activate.
  • virtualenv will let you create an isolated Python environment, where you can define your own site-packages. This allows you to make sure you are not conflicting with a incompatible version of a given package.
  • zc.buildout relies on setuptools and provides an isolated environment a bit similar in some aspects to virtualenv.
  • pip provides a way to describe requirements in a file, which can be used to define bundles, which are very similar to what zc.buildout provides.

But they all aim at the same goal : define a specific execution context for a specific application, and declare dependencies with no respect to other applications or to the OS environment…This proposal describes a solution that can be added to Python to provide that feature. A new file called a  Python Isolated Environment file (PIE file) can be provided by any  application to define the list of dependencies and their versions…’)

Posted in 2008, Distribution de logiciel, Génie logiciel, Gestion de version, package_management, python | Tagué: , , , , , , , | Leave a Comment »

Logiciel libre: La Campagne d’ahésion à l’APRIL continue…

Posted by patrick sur décembre 15, 2008

banniere_campagne-adhesion-objectif-5000-adherents1

http://www.april.org/fr/roman-photo-campagne-adhesion

Le roman photo

Pour illustrer sa campagne d’adhésion de manière humoristique, l’April a réalisé un roman photo en forme que questionnaire à choix multiple. Nous espérons ainsi expliquer de manière ludique les raisons de notre campagne … saurez vous les trouver ?

Ce roman photo a été tourné au local de l’April le 4 décembre 2008 sous la direction de Luc Fievet.

Les photos sont de Jérémie Zimmermann et sont placées sous licence art libre.

Les acteurs

Luc FIEVET
Le réalisateur du roman photo !
Sous l’influence des libristes acharnés et précoces de l’université de Paris 8, j’ai été sensibilisé au libre assez tôt mais n’étant pas informaticien la chose manquait d’aspect pratique pour moi. Puis l’élargissement des problématiques (avec les licences libres et de libre diffusion appliquées en dehors de l’informatique) ainsi que des logiciels libres accessibles aux utilisateurs de base dont je suis m’ont permis de rentrer dans le mouvement dont la grande qualité à mon sens est de permettre d’allier pratique et idéologie.

Benoît SIBAUD
Président.
Membre du conseil d’administration depuis le 18/12/2002. Ingénieur en informatique dans un centre de R&D Télécoms. Il a découvert GNU/Linux dans un magazine en 1996. Après des implications dans un GULL et à LinuxFr.org, il adhère à l’APRIL en 2001 pour sa dimension nationale, et pour être plus actif dans la défense du logiciel libre. À l’APRIL, il a entre autres créé le groupe de travail pour obtenir un classement du logiciel libre au patrimoine immatériel de l’humanité et est président depuis décembre 2004. En dehors de l’APRIL, il est encore co-webmestre du site LinuxFr et fait partie de l’organisation des Rencontres Mondiales du Logiciel Libre. Un mini-cv est aussi disponible.
Jérémie ZIMMERMANN
Vice-président.
Membre du CA depuis le 16/11/2004. Ingénieur-conseil indépendant, artisan-intégrateur passionné de logiciels libres depuis sa découverte de GNU/Linux en 1996. Il s’interesse tout particulièrement à la rencontre entre le droit et les technologies numériques, notamment depuis la promulgation du DMCA, et les batailles des brevets logiciels et du DADVSI. Multitâche frénétique, il papillonne entre de nombreux projets professionnels, associatifs et personnels (photos, musiques, fromages, etc.)
Benjamin DRIEU
Trésorier.
Informaticien, fondateur et membre du CA depuis le 29/11/1996. Il a découvert le libre à la fac et s’est lancé dans l’APRIL pour essayer de le démocratiser auprès du public. Il occupe les fonctions de trésorier, effectue des tâches d’administration système et assure le développement du SI. En dehors de l’APRIL, il est aussi impliqué dans le projet Grisbi.
Tony BASSETTE
Trésorier adjoint.
Il a découvert les logiciels libre sur les bancs de l’université Paris 8 en 1992. Fondateur, trésorier et maintenant administrateur de l’association. Il a fondé l’APRIL afin d’aider à la démocratisation des logiciels libre auprès du grand public. La démocratisation des logiciels libres dans le monde de l’entreprise s’est faite au travers de son activité professionnelle.
Tangui MORLIER
Membre du CA.
Diplômé de l’INSA de Lyon et de l’IUT de Vannes, Tangui Morlier est ingénieur en informatique indépendant. À partir de 1998, date à laquelle il découvre GNU/Linux, il s’intéresse aux logiciels libres et à la culture libre en général. Il s’investit dans Copyleft Attitude à partir de 2000. Afin de soutenir le travail de diffusion et de défense du logiciel libre, il devient membre de l’APRIL en 2006. Tangui est également membre du collectif StopDRM.
Frédéric COUCHET
Délégué général.
Fondateur et président pendant presque 10 ans. Informaticien de formation, marié et père de deux enfants, il a découvert le libre dès 1990 à l’université Paris 8. A travers l’APRIL, et la FSF France, il cherche à créer et défendre un écosystème politique et juridique favorable au logiciel libre. Plus d’info sur Frédéric avec son mini-cv ou sur son site perso.
Alix CAZENAVE
Permanente.
Alix Cazenave a rejoint en octobre 2007 l’équipe des permanents de l’APRIL. Elle est en charge des dossiers institutionnels, législatifs et réglementaires. Après l’École internationale de commerce et développement 3A (EICD 3A), Alix a complété sa formation par un master Ingénierie de l’information, de la décision et de la connaissance. Dans son parcours professionnel elle a notamment été chargée de veille technologique à SOITEC, leader mondial du silicium sur isolant (SOI), avant de devenir assistante parlementaire de 2005 à 2007. À ce poste, elle a notamment travaillé sur les dossiers brevets logiciels, RGI et DADVSI.
Eva MATHIEU
Permanente.
Eva Mathieu a rejoint l’équipe de l’APRIL le 9 octobre 2006 au poste d’assistante de direction. Outre les tâches de gestion et d’organisation de l’association, Eva Mathieu intervient comme support au développement de l’association. Diplômée d’une maîtrise de philosophie, trilingue, Eva a assumé depuis vingt ans diverses fonctions telles que chargée de projet, assistante de direction et documentaliste, dans des contextes humains et professionnels variés.

http://www.april.org/fr/campagne-dadhesion-april-plus-de-1-000-nouveaux-adherents

La campagne en chiffres

Pour encore mieux promouvoir et défendre le logiciel libre, l’April a lancé le 12 novembre 2008 une campagne d’adhésion qui a pour objectif de renforcer l’April dans sa représentativité et dans ses moyens d’actions.

Un mois après le lancement de la campagne d’adhésion nous venons de dépasser les 1 000 nouveaux adhérents.

Près de 900 personnes, 58 entreprises, 25 associations, 1 collectivité locale et 2 départements universitaires ont rejoint l’April suite à son appel à soutien.

Le nombre actuel d’adhérents est désormais de 3 613 répartis ainsi: 3 338 personnes, 162 entreprises ou réseaux d’entreprises, 107 associations, 3 collectivités et 2 départements universitaires.

Une nouvelle collectivités et deux départements universitaires

Nous avons donc le plaisir d’accueillir une nouvelle collectivité : la ville de Yerres dont le conseil municipal a approuvé à l’unanimité le 11 décembre 2008 l’adhésion à l’April.

villedyerres

Nous accueillons également un nouveau type d’adhérent personne morale à savoir deux départements universitaires :

  • la licence professionnelle « Communication, Logiciels Libres et Sources Ouvertes » qui est une formation universitaire professionnalisante qui s’adresse aux communicant(e)s ou aux personnes qui recherche à compléter une compétence initiale avec des connaissances et des savoir faire des metiers de la communication
  • Le laboratoire LE2I (Laboratoire d’Electronique, Informatique et Image), qui est associé au département STIC du CNRS depuis Janvier 2001 (FRE CNRS 2309 puis UMR CNRS depuis janvier 2003). Il est composé d’enseignants-chercheurs provenant des sections 27, 61 et 63 du CNU, de collaborateurs techniques et administratifs et de doctorants répartis sur quatre sites géographiques.

Institut de la communication - Licence Pro Colibre - Université Lumière Lyon2 LABORATOIRE ELECTRONIQUE INFORMATIQUE ET IMAGE (UMR CNRS 5158)

Soutiens

Parmi les soutiens de notre campagne d’adhésion nous avons notamment : Tristan Nitot, Alexis Kauffmann, LinuxFr, Framasoft, Ubuntu-fr (communauté francophone des utilisateurs d’Ubuntu), le projet VideoLAN, Fedora-Fr (communauté francophone des utilisateurs de Fedora), l’Association des Utilisateurs Francophones de Mandriva Linux, Sésamath (association ayant pour but, la création collaborative et le partage gratuit sur Internet de ressources pédagogiques en mathématiques).

Causerie April sur la campagne

Les « Causeries April » sont des interviews ou des discussions d’une durée d’une ou deux heures, sur un sujet donné. La causerie du mardi 9 décembre 2008 a eu lieu de 21h à minuit sur le thème «Causerie sur l’April, sa campagne d’adhésion, ses actions passées et à venir», avec l’équipe de l’April dont Benoît Sibaud, président de l’April, Frédéric Couchet délégué général, Alix Cazenave chargée des affaires publiques. Le compte-rendu a été publié, bonne lecture.

Le roman photo et la causerie sont deux éléments différents et utiles pour permettre d’expliquer les raisons de la campagne d’adhésion.

N’hésitez pas donc à diffuser largement ces éléments sur vos blogs, sites…

Posted in 2008, april, logiciel libre | Tagué: , , , , , , , | Leave a Comment »

Logiciel libre: nouvelle campagne d’adhésion de l’APRIL: objectif 5000 adhérents pour la fin de l’année 2008

Posted by patrick sur décembre 11, 2008

banniere_campagne-adhesion-objectif-5000-adherents
  • Presque un mois après le lancement c’est plus de 880 personnes qui ont répondu présente à notre appel ainsi que plus de 50 entreprises  et près de 25 associations.  Nous approchons donc la barrre des 1 000 nouveaux adhérents. Symboliquement ce serait bien de la dépasser d’ici le 12 décembre.  Ce jour-là nous organisons en effet (ou participons à) quatre soirées (voir http://www.april.org/fr/lapril-fete-ses-12-ans) et nous organisons  une conférence de presse de bilan 2008. À cette occasion sera d’ailleurs  annoncée l’adhésion à l’April d’un nouveau type de personne morale. Il est important de continuer à bien relayer la campagne pour que le rythme  se maintienne.

Parmi les récents soutiens notons Ubuntu-fr :

Adhérer à l'APRIL pour lutter contre les brevets abusifs:
  • http://www.numerama.com/magazine/10718-L-Office-europeen-des-brevets-en-greve-pour-denoncer-les-abus.htm (‘« Chaque année, le nombre de brevets déposés en Europe augmente. Alors que les gouvernements y voient le signe d’une recherche en bonne santé, des examinateurs de l’Office européen des brevets manifestent et dénoncent un emballement néfaste à la qualité de l’innovation, encouragé pour des raisons purement financières et politiques…Les attaques contre les abus de propriété intellectuelle se multiplient ces dernières années sous l’influence des lobbys du logiciel libre, des groupes de défense des intérêts publics, des internautes qui réclament la possibilité de partager librement les oeuvres, des organisations qui militent contre la brevetabilité du vivant ou en faveur d’un assouplissement des règles de protection des molécules des médicaments à destination des pays les plus défavorisés. Après plus d’un siècle de laisser-faire où la propriété intellectuelle s’est toujours renforcée à coups d’accords internationaux (ce qu’ils essayent encore de faire), le balancier ne demande qu’à partir dans l’autre sens...Vendredi dernier, des examinateurs de brevets et d’autres employés de l’Office Européen des Brevets (OEB) ont ainsi manifesté dans les rues de Bruxelles devant la Commission Européenne, non pas pour demander une réévaluation de leur statut ou de leur salaire… mais simplement pour demander une réforme du système des brevets qui arrêterait enfin de freiner l’innovation au lieu de l’encouragerLe nombre de demandes de brevets augmente chaque année. Alors qu’il était de 60.000 demandes en 1990, 209.000 brevets ont été déposées en 2006. Or plus le nombre de brevets augmente, plus le risque juridique des entreprises qui innovent grossit. Statistiquement, les chances de violer un brevet sont multipliées par le nombre de titres octroyés en circulation. Par crainte de représailles, et par manque de solidité financière pour acquérir les licences, les petites et moyennes entreprises gèlent leurs travaux de recherche et développement lorsqu’elles s’aperçoivent qu’elles exploitent de près ou de loin un procédé breveté, ou qu’elles le craignent. Quand bien même la validité du brevet serait à coup sûr annulée en justice en cas de procès, les entreprises préfèrent abandonner leurs recherches que de risquer une procédure judiciaire très longue, très coûteuse, qui les mènerait à la faillite avant son terme.‘)

A voir

carte-membre-tristan-nitot

  • vlc-logo1« VideoLAN encourage ses utilisateurs français à adhérer à l’association amie April. L’April, par le passé, a soutenu VideoLAN dès le début de son aventure dans le logiciel libre. L’action de l’April, lors de son engagement contre des projets de lois bloquant le logiciel libre ou pour la défense de la GPL, est soutenue par l’équipe de VideoLAN. »

Faites comme Tristan Nitot et les autres membres de l’association :

A lire et relire 🙂

  • block-aprilhttp://www.april.org/ (‘Pionnière du logiciel libre en France, l’April, constituée de 3520 adhérents (3252 individus, 268 entreprises, associations et collectivités), est depuis 1996 un acteur majeur de la démocratisation et de la diffusion du logiciel libre et des standards ouverts auprès du grand public, des professionnels et des institutions dans l’espace francophone’)
  • 200px-april_logo_for-big-prints_rgbsvghttp://fr.wikipedia.org/wiki/April_(association) (‘L’April (Association pour la Promotion et la Recherche en Informatique Libre) est une association qui a pour but la promotion et la défense du logiciel libre dans l’espace francophone. À ce titre, elle entretient depuis le début des rapports étroits avec la Free Software Foundation, et traduit depuis longtemps la section philosophie[1] du projet GNU.’)
  • http://www.april.org/fr/brevets-sur-les-logiciels (‘Les brevets sur les logiciels constituent une menace pesante sur l’ensemble de l’industrie du logiciel, qu’il soit libre ou non. ‘)
  • ssp-468-96 http://www.ffii.org/ The Foundation for a Free Information Infrastructure (FFII) is a non-profit organisation dedicated to establishing a free market in information technology, by the removal of barriers to competition. The FFII was largely responsible for the rejection of the EU software patent directive in July 2005, working closely with the European Parliament and many partners from industry and civil society. CNET awarded the FFII the Outstanding contribution to software development award for this work, which was the result of years of research, policy, and action. Today we continue to defend your right to a free and competitive software market by working towards sane patent systems and open standards.

Posted in 2008, april, Développement logiciel, GPL, licence libre, logiciel libre, migration vers le libre, Richard Stallman | Tagué: , , , , , , , , | Leave a Comment »

« Python 3.0 and 2.6 and Executable Zipfiles »: a great way of distributing applications as a single file

Posted by patrick sur décembre 8, 2008

Source: http://www.voidspace.org.uk/python/weblog/arch_d7_2008_12_06.shtml#e1038

A new feature that was quietly sneaked into Python 2.6 (NDLR, and Python 3.0), without the fanfare it deserves, is the ability to distribute Python applications as executable zipfiles.

What is new is the ability to make zip archives executable. If you call the Python 2.6+ (or 3.0+) interpreter passing in a zip file instead of a Python file – the interpreter looks inside the zip file for a Python file named __main__.py (at the top-level) and executes it. The zip file can also contain all the (pure-Python only) modules and packages your app depends on.

This is a great way of distributing applications as a single file. The nice thing is that the Python interpreter doesn’t depend on the extension to recognise zipfiles, instead recognising them automagically.

Floris Bruynooghe notes in the comments that you can add a hash-bang line to a zipfile and make it executable:

$ cat > __main__.py
print('hi there')
^D
$ zip test.zip __main__.py
adding: __main__.py (stored 0%)
$ cat > hashbang.txt
#!/usr/bin/env python3.0
^D
$ cat hashbang.txt test.zip > my_exec
$ chmod +x my_exec
$ ./my_exec
hi there
$

Posted in 2008, package_management, python, Python 3000 | Leave a Comment »

Un grand événement pour Python: la sortie de la version 3.0: Python 3000, Py3k

Posted by patrick sur décembre 5, 2008

voir https://pvergain.wordpress.com/py3k/ pour les mises à jour.

Ca y est:Python 3000 est arrivé !

Bien sûr la version 2.5 qui est installée sur un très grand nombre de systèmes ne va pas être remplacée de sitôt car un grand nombre de frameworks python ne sont pas encore sous Python 3000. La démarche qui est recommandée est de passer par une version 2.6 et ensuite passer sur Py3k.

Voir à ce sujet:

D’abord un grand bravo à tous les core-développeurs Python qui ont participé à son développement !.

Ci-dessous quelques réactions à la sortie de Python 3000:

http://www.python.org/download/releases/3.0/ (‘

We are pleased to announce the release of Python 3.0 (final), a new production-ready release, on December 3rd, 2008.

Python 3.0 (a.k.a. “Python 3000” or “Py3k”) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places.’)

http://jeremyhylton.blogspot.com/2008/12/python-3000.html (‘Python 3000 is ready! The official release may not come until tomorrow, but Barry has tagged the source and is preparing the release. We’ve been waiting for this release for almost nine years. The earliest reference I can find is a message from Guido to python-dev in Jan. 2000.’)

http://sayspy.blogspot.com/2008/12/holy-crap-30-is-done.html (‘As Jeremy Hylton has pointed out, Python 3000 was first discussed nine years ago. When I first started following python-dev back in June 2002, Python 3000 was this somewhat mythical version that pretty much any idea that seemed somewhat reasonable somehow to someone was attached to. To an extent I viewed it as a joke for a while since the Py3K title was tossed about so loosely.’)

http://regebro.wordpress.com/2008/12/04/python-30-released/ (‘1 minute before midnight according to the website, Python 3.0 was released. Yes, all the incompatibility tests still runs.’)

http://blog.dscpl.com.au/2008/12/python-30-and-modwsgi.html (‘Now that Python 3.0 has been released, it is probably worth while pointing out that mod_wsgi has been ported to Python 3.0 for quite a while now. It didn’t always work, but that was actually because various versions of the Python 3.0 betas and release candidates managed to break support for sub interpreters. All these issues in Python 3.0 have been fixed now and mod_wsgi appears to be working fine for a basic WSGI test case. Of course, with Python 3.0 being so new and with the internal changes required to mod_wsgi to handle Unicode strings, there are no doubt some gremlins lurking in the mod_wsgi changes still. One can just hope that the WSGI folks out there don’t ignore Python 3.0 for too long and start on porting some stuff to Python 3.0. This will then give me some decent code on which to test out mod_wsgi support for Python 3.0.’)

http://jessenoller.com/2008/12/04/python-30-some-multiprocessing-info-administrative-notes/ (‘So, first off – unless you’ve lived under a rock for the last 24 hours, you should know Python 3000 final is hot off the bit presses. This marks a huge milestone for the language, and major props are deserved to all of the python-core people who have spent so much time working on it.

Python 3000 marks an interesting point in the evolution of the language – we all know it is meant to clean up some of the warts of the python 2.x series. It’s designed and implemented knowing full well it breaks backwards compatibility – but I would argue it doesn’t fall in the black and white camp of revolution vs. evolution. In my mind, Python 3 actually falls right in the middle. Yes, it is revolutionary in the aspect that it breaks compatibility with 2, but it is not so significant a series of breakages that it falls outside of the evolutionary camp.’)

http://plnews.org/posts/python_30_final_released_20081203_210004.html (‘Python 3.0 final has been released. Python is a portable, dynamic, object-oriented language. The new features are described in the “What’s New in Python 3.0” document. This release includes: the replacement of the print statement with the print() function, simplified rules for ordering comparisons, a new form for octal literals, binary literals, a single Unicode string type, function argument and return value annotations, the ‘nonlocal’ statement, a new ‘raise’ statement syntax, new reserved words, a new metaclass syntax, library updates, a new system for string formatting, new and removed builtins, changes to the C API, and other changes.’)

http://holdenweb.blogspot.com/2008/12/python-30-is-out.html (‘I posted a short article a while ago about 3.0 (in)compatibility, but the differences between 2.6 and 3.0 aren’t so great. It’s perfectly possible to write 3.0 code that will run on 2.6 too, as most of the language hasn’t changed at all.

The preferred strategy for writing code that runs on both versions is to write in 2.6 and then apply the 2to3 converter and verify that it produces a correct 3.0 program. There’s no guarantee that it will, so you may need to paraphrase the 2.6 code a few times before you get a transatable program.

Once all the third-party modules you and extensions you rely on are 3.0-ready, and you no longer have clients requiring 2.6 version of your software, you can simply drop the 2.6 compatibility requirement and start to make use of the few 3.0-only constructs that have been introduced.’)

http://rhodesmill.org/brandon/2008/comprehension-consistency-at-last-in-python-30/ (‘A new era is begun: Python 3.0 has been released, bringing the bright and burning lights of reason, consistency, and symmetry to bear on my favorite language. Guido van Rossum, the creator of Python, has carefully guided this final attempt to remove the warts that have accumulated over the language’s 17-year lifetime, and the result is magical.

Python 3.0 (r30:67503, Dec  4 2008, 10:23:44)
[GCC 4.3.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>
>>> [ n*n for n in range(5) ]
[0, 1, 4, 9, 16]
>>>
>>> { n*n for n in range(5) }
{0, 1, 4, 16, 9}
>>>

>>> { n: n*n for n in range(5) }
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

... After the aching and painful years of the Python 2 series, the language
once again shines bright and clear as a model of clever symmetries and
low mental impedance. Python’s famously tight “feature set” can, now
more easily than ever, fit comfortably into the programmer’s brain.')

Autres liens

Posted in 2008, python, Python 3000 | Tagué: , , , , | Leave a Comment »