Manteniendo todavía una posición a medias tintas respecto a lo que realmente busca el movimiento del software libre, Google volvió a liberar un producto libre de uso, pero con claras restricciones de despliegue. Google App Engine representa una alternativa tan tentadora que el propio autor de mod_wsgi (alternativa emergente al relegado mod_python), Graham Dumpleton, publicó en su grupo de noticias la siguiente entrada:

Google App Server makes mod_wsgi obsolete.

 

 Lo cierto es que ambas alternativas competirían en cierto grado, y es lo que Graham alega que le quita parte del interés para continuar con el mismo ímpetu.

 ¿No te recuerda esto a las tropecientas distribuciones que hay de GNU/Linux?, todas alegado ser mejores que las anteriores, con sus cientos de fans que de repente se desvanecen con su popularidad, mientras nosotros los desarrolladores peleamos continuamente por obtener una plataforma de despliegue estable y bajo nuestro control total.

 Es totalmente irónico, mod_wsgi es un proyecto de software libre y estuvo hospedado en code.google.com, y ahora el autor tiene el sentimiento de que si implementa algunas de las ideas que tiene en la cabeza será acusado de plagiarlas de Google App Engine.

 No se puede negar que cuando se tiene a mano una alternativa mas tentadora, aunque renunciando a parte del control de esta, nos inclinaremos a ésta.

 Muchos proyectos se ahogan o al menos se detienen al emerger alternativas con mayor influencia, ¿que se aprenden de estas lecciones?.

 Comparto el sentimiento de Grahan, y me imagino que si tu desarrollas software, algún día lo harás. ¡Que no te detenga!

Hace un tiempo que un colaborador de mercurial realiza un empaquetado del mismo para usuarios windows.

El instalador consta de:

• Python 2.5.1 + Setuptools and PyWin32
• Mercurial (of course)
• Putty/Plink (ssh)
  
• hgk + tclkit (visor gráfico de las revisiones)
• KDiff3 (diff/merge tool)
• qct + pyqt4 (gui commit tool)
• gpyfm + pygtk (diff/merge python tool)

Para quienes extrañan la tortuga, pueden probar tortoisehg (semi-experimental)

Más detalles | http://qct.sourceforge.net/Mercurial-NSI.html

Descarga | http://sourceforge.net/project/showfiles.php?group_id=188871&a

 

Guido van Rossum (home page: http://www.python.org/~guido/)

The first Python 3000 release is out -- Python 3.0a1. Be the first one
on your block to download it!

http://python.org/download/releases/3.0/

Excerpts:

Python 3000 (a.k.a. "Py3k", and released as Python 3.0) 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.

This is an ongoing project; the cleanup isn't expected to be complete
until 2008. In particular there are plans to reorganize the standard
library namespace.

The release plan is to have a series of alpha releases in 2007, beta
releases in 2008, and a final release in August 2008. The alpha
releases are primarily aimed at developers who want a sneak peek at
the new langauge, especially those folks who plan to port their code
to Python 3000. The hope is that by the time of the final release,
many 3rd party packages will already be available in a 3.0-compatible
form.

More links: 

• Online docs: http://docs.python.org/dev/3.0/
• What's new: http://docs.python.org/dev/3.0/whatsnew/3.0.html

• Source tar ball: http://python.org/ftp/python/3.0/Python-3.0a1.tgz
• Windows MSI installer: http://python.org/ftp/python/3.0/python-3.0a1.msi 

• PEP 3000: http://python.org/dev/peps/pep-3000/
• Issue tracker: http://bugs.python.org/
• Py3k dev list: http://mail.python.org/mailman/listinfo/python-3000/
• Conversion tool for Python 2.x code: http://svn.python.org/view/sandbox/trunk/2to3/

Python Papers es el esfuerzo de unos entusiastas apasionados por python. Donde se abarcan temáticas de interes para la industria y el mundo académico.

En esta segunda edición del volumen 2, se puede destacar los siguientes artículos:

• Python in Education
• Python for Kids 
• MPD WebAMP
• A Rails / Django Comparison 

Incluye información sobre la EuroCon 2007 y PyCon 2007 y mucho más en 54 páginas de puro contenido pythonico!

Pueden descargar la edición actual: The Python Papers, Volume 2 Issue 2, 2007 

O ediciones anteriores en su web oficial: The Python Papers

Google acaba de publicar la guía para programadores en python de su api de Google Calendar:

• El anuncio en Google Data APIs
• La guía para programadores en python
  

Tambien tiene disponible la API para java, .net y php.

La revista Computing Science & Engineering, es su actual edición, publica varios artículos sobre python, desde computación científica hasta control robots.

Contenido:

• You're Recommending What?! (PDF)
• Computationally Complete (PDF)
• Guest Editor's Introduction: Python: Batteries Included (PDF)
• Python for Scientific Computing (Abstract)
• IPython: A System for Interactive Scientific Computing (Abstract)
• Computational Physics Education with Python (Abstract)
• Python Unleashed on Systems Biology (Abstract)
• Reaching for the Stars with Python (Abstract)
• A Python Module for Modeling and Control Design of Flexible Robots (Abstract)
• Python in Nanophotonics Research (Abstract)
• Using Python to Solve Partial Differential Equations (Abstract)
• Analysis of Functional Magnetic Resonance Imaging in Python (Abstract)
• Python for Internet GIS Applications (Abstract)
• Quantum Chaos in Billiards (Abstract)
• An Ice-Free Arctic? Opportunities for Computational Science (Abstract)
• Python for Education: Computational Methods for Nonlinear Systems (Abstract)
• A Partial Solution to Last Issue's Homework Assignment: Beetles, Cannibalism, and Chaos--Analyzing a Dynamical System Model (Abstract)
• Making the Complex Simple (Abstract)
• Matplotlib: A 2D Graphics Environment (Abstract)
• Wrong Again! (PDF)

Tres artículos para empezar con mercurial:

• Conceptos generales
• Uso de Mercurial
• Publicación de proyectos

Otra de las cosas que me gusta de mercurial, es lo sencillo que es publicar los proyectos, por ejemplo estan disponibles algunos repositorios públicos acá: http://devel.memi.umss.edu.bo/rolando/hg/ 

Mercurial lo tengo corriendo como cgi, y con autentificación, que se configura de manera trivial y ningún problema con proxies ni nada.

Con subversión es mucho trámite, se tiene que integrar apache con svn a través de WebDAV, y la autentificación por los archivos ht*. Otro problema que tuvimos, son los proxies, que no soportan métodos DAV entonces, si uno esta detrás de un proxy, no se puede trabajar con un repositorio http, hay que usar https.

Aparte de que subversión, para la mayoría de sus operaciones, necesita conetarse al repositorio principal.

Con hg view se puede ver el grafo de evolución, por ejemplo, del repositorio de ajayu:

 

Mercurial es un sistema de control de versiones distribuido o descentralizado. Esta diseñado para ser eficiente, por ejemplo lo usa el proyecto Xen en su repositorio de código OpenSolaris como scm preferido.

 Uno de los problemas que tiene, y experimente, con subversion es la dependencia con el repositorio central para la mayoría de las operaciones. En cambio, con mercurial (hg) pueden existir infinitos repositorios.

 Cuando uno hace la operación clone, que sería como un checkout, se obtiene el repositorio completo con toda historia. A partir de ahí podemos hacer todas las demás operaciones (revert, commit, add, remove, etc) en el repositorio local, y cuando queramos actualizar o enviar nuestros cambios simplemente un pull o push respectivamente.

Puede trabajar mediante ssh o http, que a diferencia de subversión donde se tiene problemas con proxys por el soporte webdav, funciona como cgi (o standalone) pudiendo hacer los push/pull directamente. 

Esta a disposición el libro no oficial de mercurial: Distributed Revision Control with Mercurial [pdf]

Ah!, esta hecho en python, y las partes críticas en c. Las malas lenguas dicen que es más rápido que darcs, pero tambien leí que las últimas versiones de darcs mejoraron bastante el rendimiento. 

El siguiente script permite tener sincronizado un repositorio mercurial con un subversion. Solo es, como se diría "one-way".

  #!/usr/bin/env python # -*- coding: utf-8 -*- # $Id$ # # (c) 2007 - Rolando Espinoza La Fuente <darkrho@gmail.com> # Distributed under the BSD License # Use at your own risk! # # This script make a mercurial repository from a svn one. # Keeping revision history with authors and dates. # Just convert one-way, svn to hg. If you want two-way conversion checkout tailor. # # # Requirements: #   - Mercurial of course ;) #   - pysvn subversion bindings #     Ubuntu users: apt-get install python-svn # # Based on: #   <a href="http://www.selenic.com/mercurial/wiki/index.cgi/SubversionToMercurialSync">http://www.selenic.com/mercurial/wiki/index.cgi/SubversionToMe</a> # # (use backups) # Usage: svn2hg.py svnrepo # # Tested on Ubuntu Edgy against small repositories (<20Mb) # TODO: Need more testing   import sys, os   # really don't need cPickle # TODO: take out cPickle import cPickle   import pysvn # svn functions import mercurial.commands # hg functions   class svn2hg:       def __init__(self, args):         if len(args) != 1:            sys.stderr.write("[*] Error: have to provide one argumentn")            sys.exit(-1)           if not os.path.isdir(args[0]):            sys.stderr.write("[*] Error: argument must be a directoryn")            sys.exit(-1)           else:            self.path = os.path.realpath(args[0]) + os.path.sep            self.statefile = self.path + '.svn2hg_state'       def _pysvnrev(self, rev):         return pysvn.Revision(pysvn.opt_revision_kind.number, rev)       def savestate(self):         #TODO: try/catch errors         if self.currev:            try:                 cPickle.dump(self.currev, open(self.statefile,'wb+'))            except:                 pass             def loadstate(self):         #TODO: try/catch errors         if os.path.exists(self.statefile):            try:                 self.currev = cPickle.load(open(self.statefile))            except:                 self.currev = None                 pass         else:            self.currev = None       def builddate(self, timestamp):         from datetime import datetime         import time           format = '%Y-%m-%d %H:%M'         date = datetime.fromtimestamp(timestamp)         return time.strftime(format, date.timetuple())       def check_hg(self):         hgdir = self.path + '.hg'         hgignore = self.path + '.hgignore'           if not os.path.exists(hgdir):            self.hg.dispatch(['init',self.path])            ignoreme = ".hgignoren.svnn" + os.path.basename(self.statefile) + 'n'            open(hgignore, 'w').writelines(ignoreme)           elif not os.path.isdir(hgdir):            sys.stderr.write("[*] Error: unknown .hg directoryn")            sys.exit(-1)       def check_svn(self):         svndir = self.path + '.svn'           if not os.path.exists(svndir) or not os.path.isdir(svndir):            sys.stderr.write("[*] Error: unknown .svn directoryn")            sys.exit(-1)             def run(self):         self.loadstate()           self.svn = pysvn.Client()         self.hg = mercurial.commands           self.check_hg()         self.check_svn()           # why?         # get local repo info to get the url         self.info = self.svn.info2(self.path, recurse=False)[0][1]         #self.url = self.info['repos_root_URL']         self.url = self.info['URL']           ## Get current revisions...         #print '+ Updating svn repos... '         #self.newrev = self.svn.update(self.path)[0]         #self.newrev = self.newrev.number         #print 'donen'           # Getting last revision         print '[+] Getting last revision number from remote repo... '         self.remoteinfo = self.svn.info2(self.url, recurse=False)[0][1]         self.newrev = self.remoteinfo['last_changed_rev'].number                   # newer revision?         if not self.currev == self.newrev:              if not self.currev:                 self.currev = 0              print '[+] Getting remote changelog from r%s up to r%s)... ' % (self.currev, self.newrev)            svnlog = self.svn.log(self.url, self._pysvnrev(self.newrev), self._pysvnrev(self.currev))              # reverse to process from old to new            svnlog.reverse()              # fix, hg needs to 'be' inside the repo            os.chdir(self.path)              # cset dict            #   - author ""            #   - changed_paths []            #   - date timestamp            #   - message ""            #   - revision _pysvnrev              # process one by one            for cset in svnlog:                 # update to rev                 localrev = self.svn.update(self.path, revision=cset['revision'])[0]                   if not cset['message']:                     # dirty hack to prevent rollback on empty svn commit message                     cset['message'] = cset['author']                   # commit changes to hg                 # mantain the same author, message and date of the changeset                 print '[+] Process revision r%s ...' % (localrev.number)                 self.hg.dispatch(['commit', '-A', '-m', cset['message'],                                             '-u', cset['author'],                                             '-d', self.builddate(cset['date'])])              # save newrev as currev            self.currev = self.newrev           else:            print '[-] Nothing to do'           # save currev to a file for further updates         self.savestate()   if __name__ == '__main__':     main = svn2hg(sys.argv[1:])     sys.exit(main.run())     

 Download svn2hg.py

rolando@rho:~/src/myrepo/hg$ python fibo.py -v
Trying:
    [n for n in fibogen(-1)]
Expecting:
    [None]
ok
Trying:
    [n for n in fibogen(0)]
Expecting:
    [0]
ok
Trying:
    [n for n in fibogen(1)]
Expecting:
    [1]
ok
Trying:
    [n for n in fibogen(100)]
Expecting:
    [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
ok
Trying:
    [n for n in fibogen(1000000000000)].pop()
Expecting:
    956722026041L
ok
2 items had no tests:
    __main__
    __main__._test
1 items passed all tests:
   5 tests in __main__.fibogen
5 tests in 3 items.
5 passed and 0 failed.
Test passed.

---

 

#!/usr/bin/python

# -*- coding: utf-8 -*-
# $Id: fibo.py,v 84ad6436f97a 2006/12/11 12:09:34 -0400 $

def fibogen(n):
    """Calcula los numeros de fibo hasta n
    usando generadores

    fibogen(n) -> generator

    #for testing in doctest ;-)

    >>> [n for n in fibogen(-1)]
    [None]
    >>> [n for n in fibogen(0)]
    [0]
    >>> [n for n in fibogen(1)]
    [1]
    >>> [n for n in fibogen(100)]
    [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

    #el numero fibo más cercano a 1000000000000

    >>> [n for n in fibogen(1000000000000)].pop()
    956722026041L

    """
    n_0, n_1 = 1, 1

    if n < 0:
        yield None
    if n == 0:
        yield 0
    if n > 0:
        yield n_0
    if n > 1:
        yield n_1

    n_n = n_1 + n_0
    while n_n < n:
        yield n_n
        n_0, n_1 = n_1, n_n
        n_n = n_1 + n_0

def _test():
    import doctest
    doctest.testmod()

if __name__ == "__main__":
    _test()