Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Lo primero que hicimos fue conectar un método al evento Edited del CellRendererText de la columna correspondiente. De esta forma, cuando terminamos la edición en el primer campo, podemos colocar allí el código correspondiente para actualizar el modelo del TreeView y otras operaciones más, entre ellas (la que nos interesa) dar el foco al segundo campo en modo edición. La parte final de este método (el evento se activa al finalizar la edición) había quedado así:

/* ... */

this.tvItems.SetCursor(path,
					   this.tvcCodigoProducto,
					   true);

Hay que tener cuidado al utilizar la función SetCursor. En algunos casos, si no la usamos cuidadosamente, el TreeView no se comportará en forma correcta. Esos casos son por ejemplo cuando el usuario, al estar editando el campo, hace click en otra fila. Esto hace que se dispare el evento Edited, y por lo tanto se activa el modo edición en el segundo campo (SetCursor), pero el foco lo tiene otra fila, y esto hace que el funcionamiento sea incorrecto.

La solución es, antes de ejecutar SetCursor, verificar qué tipo de evento ha ocurrido. En nuestro caso, ejecutamos dicha función sólo si se ha oprimido la tecla Return. El código queda así:

/* Una vez editada la cantidad, automáticamente
 * pasamos el foco al campo de 'código' en modo
 * edición, pero en una nueva fila. A esto lo hacemos
 * únicamente si el usuario presionó la tecla Enter */

Gdk.Event ev = Gtk.Application.CurrentEvent;

if (ev.Type == Gdk.EventType.KeyPress) {
	Gdk.EventKey evKey = (Gdk.EventKey)ev;

	if (evKey.Key == Gdk.Key.Return)
		this.tvItems.SetCursor(path,
							   this.tvcCodigoProducto,
							   true);
}

Lo cual es más lógico también: si se hace click en otra fila, seguramente es porque se quiere editar otro ítem y por lo tanto no es correcto forzar el foco en otro lugar. Además, como se dijo, esto hacía que el TreeView quede en un estado inconsistente.

miltondp@wasabi:~$ csharp
Mono C# Shell, type "help;" for help

Enter statements below.
csharp> using System.Text;
csharp> var a = new StringBuilder("Milton");
csharp> a.Remove(a.Length-1,1);
Milto
csharp> a.Remove(a.Length-1,1);
Milt
csharp> a.Remove(a.Length-1,1);
Mil
csharp> a.Remove(a.Length-1,1);
Mi
csharp> a.Remove(a.Length-1,1);
M
csharp> a.Remove(a.Length-1,1); 

csharp>

Si, funcionaba como me lo imaginaba Esta shell para C# está disponible en la versión 2.2 de Mono.

Los reportes que se pueden realizar son de personas y asistencias (aquí y aquí tienen ejemplos). Éstos se producen en formato PDF. Lamentablemente no hay una forma de imprimir los reportes directamente, por lo que puede ser complicado para usuarios inexpertos.

Al final, estoy utilizando iTextSharp para generar los PDFs, no MonoReporter, que si bien actualmente puede generar reportes básicos, decidí por el momento utilizar algo ya hecho y maduro. Con MonoReporter (que utiliza GtkPrint) sí podría imprimir el reporte directamente, o ver previsualizaciones. Pero bueno, será algo a hacer más adelante.

Para realizar reportes más personalizados, tengo pensando añadir a Zaspe# posibilidades de extensión, con Mono.Addins. Estaría bueno poder definirlos en un lenguaje tipo Boo (ya que los reportes con iTextSharp habría que diseñarlos con código fuente, nada gráfico), de sintaxis parecida a Python, y sin la necesidad de compilar el código. Así sería muy fácil incluso añadir funcionalidad en forma de plugin.

En la wiki hay una página TODO donde voy anotando las características que me gustaría añadir más adelante.

Un screenshot simple del diálogo para generar los reportes:

Si, muy simple y limitado.

En los releases anteriores, nunca subía el código fuente de la versión, aunque sí hacía un copia de la revisión en ‘trunk’ correspondiente a la versión liberada en la carpeta ‘tags’. Esta vez pueden bajarse en un archivo comprimido los binarios y los fuentes.

Hay algunas cuestiones a tener en cuenta con respecto a la versión de Gtk# en Windows, que se pueden leer en el archivo README de los binarios. En GNU/Linux funciona bien en Ubuntu Hardy Heron con Gtk# 2.12.

import System.Net
import System.IO

if argv.Length != 2:
	print "You must pass [prefix] [path] as parameters"
	return

prefix = argv[0]
path = argv[1]

if not Directory.Exists(path):
	print "Could not find ${path}"
	return

listener = HttpListener()
listener.Prefixes.Add(prefix)
listener.Start()

while true:
	context = listener.GetContext()
	file = Path.GetFileName(context.Request.RawUrl)
	fullPath = Path.Combine(path, file)
	if File.Exists(fullPath):
		context.Response.AddHeader("Content-Disposition","attachment; filename=${file}")
		bytes = File.ReadAllBytes(fullPath)
		context.Response.OutputStream.Write(bytes, 0, bytes.Length)
		context.Response.OutputStream.Flush()
		context.Response.Close()
	else:
		context.Response.StatusCode = 404
		context.Response.Close()

Y ejecutando el comando:

$ booi prueba.boo http://localhost:8085/ ~/Escritorio/

tenemos funcionando un webserver localmente. Me acuerdo como en una de las charlas de alguna de las jornadas Python en Santa Fe el disertante hacía algo similar. La verdad, muy útil este tipo de código.

Por ejemplo, supongamos que tenga un método RegistrarAsistencia(int, int), que registra que la persona asistió al evento (los argumentos serían los IDs). Este método inventado, tendría como dependencia la clase ControladorPersonas y ControladorEventos, para levantar los objetos necesarios y realizar el registro. Pero esto (levantar los objetos Persona y Registro), a nosotros, no nos interesa probar en el test de unidad, sino verificar que el método RegistrarAsistencia realmente funciona, registrando que la persona asistió al evento.

Otro ejemplo podría ser algún método ImprimirFactura, que toma los datos del formulario, e imprime la factura. ¿Cómo podemos escribir un test de unidad para esto?

Una solución viene de la mano de la técnica de MockObjects, y Rhino.Mocks es un framework para .NET.

Para el caso del método RegistrarAsistencia, podríamos crear objetos mock que simulen a los respectivos controladores, e indicarles a los mismos que cuando sean llamados con determinados argumentos, retornen determinados objetos. De esta forma, la lógica del método a probar siempre obtendrá resultados de los controladores, no hay que preparar la base de datos, y obtenemos un comportamiento determinístico.

Necesitamos manejarnos con interfaces. Así, para el controlador de personas, habrá una interfaz IControladorPersonas que éste implementará. Así podemos escribir un test de unidad utilizando Rhino.Mocks de la siguiente forma:

[Test]
public void RegistrarAsistencia()
{
	IControladorPersonas cp = this.mocks.CreateMock();
	Expect.Call(cp.ObtenerPersona(38))
		.Return(new Persona("Pividori", "Milton"));
	ControladorPersonas.Instancia = cp;

	IControladorEventos ce = this.mocks.CreateMock();
	Expect.Call(ce.ObtenerEvento(11))
		.Return(new Evento(new DateTime(1, 1, 2000)));
	ControladorEventos.Instancia = ce;

	ISession session = this.mocks.CreateMock();
		Expect.Call(session.Save(1))
			.Return(null)
			.IgnoreArguments();
		Expect.Call(session.Close());

	this.mocks.ReplayAll();

	Asistencia asistencia = controladorAsistencias.RegistrarAsistencia(session, 38, 11);
	Assert.AreEqual("Pividori", asistencia.Persona.Apellido);
	Assert.AreEqual(new DateTime(1, 1, 2000), asistencia.Event.Fecha);

	this.mocks.VerifyAll();
}

El objeto this.mocks es de tipo MockRepository, y lo utilizamos para crear nuestros objetos mock. En la primera línea estamos creando un objeto simulado (mock) que implementará la interfaz IControladorPersonas. Luego lo configuramos para que al ejecutarse en el mismo el método ObtenerPersona con el argumento “38″, éste devuelva el objeto Persona que creamos allí. Como RegistrarAsistencia utilizará la propiedad estática Instancia para obtener el controlador que necesita, guardamos en éste el objeto mock que acabamos de crear.

Al crear el objeto simulado con el método CreateMock, estamos diciéndole a Rhino.Mocks que verifique estrictamente la llamada a los métodos que definimos. En este caso no tiene mucho sentido porque se llama un sólo método, pero al ser varios, el test fallará si los mismos no se llaman en orden, o incluso si se llama otro que no hayamos definido. Hay otras opciones, como DynamicMock que exige que se llamen todos los métodos definidos, pero no en orden estricto, y si se llama a uno no definido retornará 0 o null, según corresponda.

Luego de configurar el objeto IControladorEventos, creamos un objeto de tipo ISession (de NHibernate), que pasamos al método RegistrarAsistencia para que utilice. Grabamos los métodos “Save” y “Close”, que deberán llamarse en ese orden.

Al terminar la fase de configuración, pasamos a la ejecución llamando this.mocks.ReplayAll(). Aquí ejecutamos el método por probar. Luego verificamos los resultados con NUnit. Finalmente llamamos a VerifyAll para verificar que la ejecución se halla llevado a cabo según nuestra configuración.

Para el otro caso, ImprimirFactura, podemos utilizar algo similar. Supongamos que tenemos una clase que se encarga de las funciones de la impresora. Podríamos crear una interfaz, configurar los métodos necesarios, y correr los test todas las veces que quieramos para verificar que el método funciona, aislando en el test de unidad sólo la porción de código que nos interesa probar.

El problema es que el driver utilizado por NHibernate para esta base de datos utiliza un binding desactualizado. Además Mono trae una implementación mejor, que soporta el standard ADO.NET 2.0, que es Mono.Data.Sqlite, disponible a partir de la versión 1.2.4.

El post es especialmente útil para aquellos que quieran utilizar en GNU/Linux (yo uso Ubuntu Gutsy), con Mono, NHibernate y SQLite, utilizando el binding Mono.Data.Sqlite. Si bien puede parecer esto tan fácil como seguir el documento QuickStart y cambiar las opciones correspondientes, no lo es si se intenta utilizar SQLite. Por eso, en este post no voy a explicar todas las cosas, ya que no me interesa y se pueden aprender en la documentación, sino que voy a desarrollar un ejemplo muy sencillo y mostrar cómo utilizar SQLite, ya que hay que solucionar unos problemas no muy triviales.

Cabe aclarar que, si bien todavía no lo he probado, los archivos de mapeo (hbm.xml) y el schema SQL se pueden autogenerar.

Primero creo la tabla que almacenerá los objetos en un archivo llamado, por ejemplo, data.db.sql:

DROP TABLE IF EXISTS personas;

CREATE TABLE personas (
	id integer primary key,
	nombre varchar(20),
	apellido varchar(20)
);

Para el ejemplo utilicé la última versión de SQLite. Para crear la base de datos en el archivo data.db, ejecutamos:

$ sqlite3 data.db < data.db.sql
$

La clase de ejemplo (Persona.cs):

using System;

namespace PruebaNHibernate
{
	public class Persona
	{
		private int id;
		private string nombre;
		private string apellido;

		public Persona()
		{
		}

		public int Id {
			get { return id; }
			set { this.id = value; }
		}

		public string Nombre {
			get { return nombre; }
			set { this.nombre = value; }
		}

		public string Apellido {
			get { return apellido; }
			set { this.apellido = value; }
		}
	}
}

Luego hay que escribir el archivo de mapeo, que es un XML.

Este archivo se debe agregar como recurso en MonoDevelop.

Luego escribimos el archivo de configuración para nuestra aplicación (app.config):

Nota: Debido a problemas con el hosting no puedo colocar, arriba, el string correcto en la última parte. La palabra prohibida "p r o x y" (sin espacios) tiene un espacio de más entre la "x" y la "y". En fin, deshabilito en esas lineas la comprobación de clases p r o x y.

Luego en un archivo como Main.cs agrego código en el método principal Main para jugar con todo esto:

using System;
using NHibernate;
using NHibernate.Cfg;

namespace PruebaNHibernate
{
	class MainClass
	{
		public static void Main(string[] args)
		{
			Configuration conf = new Configuration();
			/* Con la siguiente línea leo todo los archivos con extensión
			 * hbm.xml embebidos como recurso en el assembly especificado */
			conf.AddAssembly("PruebaNHibernate");

			ISessionFactory sessionFactory = conf.BuildSessionFactory();

			ISession s = sessionFactory.OpenSession();

			ITransaction tx = s.BeginTransaction();

			Persona p = new Persona();
			p.Nombre = "Milton";
			p.Apellido = "Pividori";
			s.Save(p);
			tx.Commit();

			Console.WriteLine("p - Id: " + p.Id);
			Console.WriteLine("p - Nombre: " + p.Nombre);
			Console.WriteLine("p - Apellido: " + p.Apellido);
			Console.WriteLine();

			Persona p2 = (Persona)s.Load(typeof(Persona), p.Id);

			Console.WriteLine("p2 - Id: " + p2.Id);
			Console.WriteLine("p2 - Nombre: " + p2.Nombre);
			Console.WriteLine("p2 - Apellido: " + p2.Apellido);
			Console.WriteLine();

			/* Verifico si son el mismo objeto p y p2, ya que estamos
			 * dentro de la misma sesión */
			if (p == p2)
				Console.WriteLine("p y p2 son el mismo objeto");

			p2.Apellido = "Paduán";

			s.Flush();

			s.Close();
		}
	}
}

En el proyecto agregué estas referencias:

• NHibernate.dll
• System

Ahora vamos a lo que nos interesa. En el archivo app.config (que al compilar se traducirá a .exe.config en el directorio de salida), observemos estas lineas:

        ...
        
        ...

NHibernate trae un driver para SQLite, como dije al principio, pero que utiliza un provider que fue discontinuado. Por lo tanto, para utilizar Mono.Data.Sqlite, cree una clase en mi assembly (PruebaNHibernate) con el nombre que se indica allí (MonoDataSqliteDriver):

using System;
using NHibernate.Driver;

namespace PruebaNHibernate
{
	public class MonoDataSqliteDriver : ReflectionBasedDriver
	{
		public MonoDataSqliteDriver()
			: base("Mono.Data.Sqlite",
			       "Mono.Data.Sqlite.SqliteConnection",
			       "Mono.Data.Sqlite.SqliteCommand")
		{
		}

		public override bool UseNamedPrefixInSql
		{
			get { return true; }
		}

		public override bool UseNamedPrefixInParameter
		{
			get { return true; }
		}

		public override string NamedPrefix
		{
			get { return "@"; }
		}

		public override bool SupportsMultipleOpenReaders
		{
			get { return false; }
		}
	}
}

En el constructor de la misma le paso a mi clase padre los argumentos que necesita: nombre del assembly (en este caso "Mono.Data.Sqlite"), clase para crear la conexión y ejecutar comandos. Desconozco los detalles de SQLite, así que copié los métodos sobreescritos del driver viejo.

No pude hacer que NHibernate cargue el assembly "Mono.Data.Sqlite" desde el GAC, así que hay que copiarlo al directorio del ejecutable. Es necesario copiar otros archivos, como las dependencias de NHibernate y la base de datos (data.db). Se pueden bajar el proyecto completo para MonoDevelop aquí. El archivo obviamente no es un png, pero sino no lo puedo subir

Ahora bien, hay un problemita... el archivo System.Data.dll que viene con Mono 1.2.4 en Gutsy tiene un bug que hará que el ejemplo no funcione. El mismo ya fue solucionado en la versión 1.2.6. Así que, como workaround, pueden bajarse el paquete de Debian libmono-system-data2.0-cil correspondiente a la versión 1.2.6 de Mono y sobreeescribir ese archivo, que se ubica en /usr/lib/mono/gac/System.Data/2.0.0.0__b77a5c561934e089/. Reporté el problema en Ubuntu, así que quizá lo actualicen dentro de poco.

Con esto podremos utilizar SQLite con NHibernate, bajo Mono, con un binding actualizado.

Pero el motivo del post no es este trabajo en sí, sino la solución a un problema que se había presentado. Utilizamos Remoting para comunicar los clientes con el servidor. Remoting es una tecnología para comunicar procesos, en la que podemos instanciar, por ejemplo, objetos remotos y llamar métodos del mismo, ejecutándose éstos en el servidor. Lo veo como algo muy parecido a RPC. Tampoco es el objetivo del post hablar de Remoting, sino simplemente decir que cuando ejecutamos un método remoto, se abre un thread nuevo para llevar a cabo la ejecución del mismo en el servidor.

En nuestro diseño (que quizá no sea el mejor, pero no importa), el servidor mantenía actualizada la lista de contactos de todos los clientes. Así, cuando se conectaba alguien, el servidor ejecutaba un método remoto de un objeto propio de los clientes, que se encargaba de actualizar el TreeView con el nuevo contacto recién conectado. Lo mismo pasaba cuando se recibía un mensaje nuevo enviado por un cliente a otro.

Gtk.Application.Invoke()

Notábamos que cuando se disparaban estos métodos remotos en el cliente, el cual actualizaba la interfaz gráfica, a veces se colgaba. No entendíamos por qué hasta que leímos un poco más sobre el funcionamiento interno de Gtk+. Algunos insultos recibió el toolkit antes de eso El artículo interesante y que nos ayudó es éste. Resulta que Gtk+ es thread-aware, pero no thread-safe. O sea que, por lo que entiendo, en nuestra aplicación solamente el thread que ejecutó Application.Run puede acceder a los elementos de Gtk. Entonces nuestro problema era que ese thread (el que manejaba la ejecución del método remoto, distinto al thread principal) intentaba actualizar un TreeView directamente.

Entonces, lo que debemos hacer en el código de nuestro thread es encolar un evento para que sea ejecutado por el thread principal:

Gtk.Application.Invoke (delegate {
      label.Text = "Listo";
});

Con ese delegate estoy declarando un método anónimo. La alternativa es crear un método aparte y pasarle a Invoke el nombre del método.

Idle Handlers

Todavía no me surgió la necesidad de usar esto, pero esta muy interesante, para tener en cuenta. Si necesitamos realizar cierta actividad cuando nuestro programa no está haciendo nada, podemos usar el siguiente código:

void Start ()
{
	GLib.Idle.Add (new IdleHandler (OnIdleCreateThumbnail));
}

bool OnIdleCreateThumbnail ()
{
	Image img = GetNextImage ();

	// If no more images remain, stop the idle handler.
	if (img == null)
		return false; 

	CreateThumbnail (img, img.ToString () + ".thumbnail");

	// There are more images, invoke this routine again on the next Idle moment.
	return true;
}

Esto está bueno, porque nos olvidamos de la complejidad de usar threads para éste proposito en particular. El funcionamiento parece ser bastante entendible al mirar el código de ejemplo de arriba.

Mi idea era hacer algo que no sólo me sirva a mí, sino que lo pueda usar otra persona también. Cuando le comenté la idea a Nacho, sobre un lenguaje basado en XML para describir el reporte, me propuso leer un SVG, hecho con Inkscape por ejemplo… así me ahorraría un futuro diseñador de reportes. Eso es lo que he hecho.

MonoReporter entonces lee de un SVG hecho con Inkscape (lo aclaro porque sobre este software hice las pruebas), y lo transforma a instrucciones para dibujar con Cairo y GtkPrint (el nuevo sistema de impresión de Gtk+). Es posible, por ejemplo, exportar directamente a PDF, o mostrar el diálogo de impresión, tanto en GNU/Linux como Windows (previa instalación de los runtimes de gtk-sharp que se pueden encontrar en la web de zaspe#). A esto lo realiza en forma nativa.

Para leer el XML (SVG), simplemente uso las clases en el namespace System.Xml. No utilizo ninguna librería externa. He probado una, SvgNet, un proyecto poco activo (último release en el 2003). Y me he dado cuenta de que tenía que adaptarlo mucho… así que opté por crear mis propias clases de lectura del SVG, que terminó siendo un trabajo bastante sencillo en realidad.

Debido a algunas limitaciones que tengo en Windows (como los bindings de Cairo sólo disponibles para el profile 1.0), el diseño en general de las clases no es el mejor, o por lo menos el que me hubiese gustado.

Este es un ejemplo de uso de MonoReporter con C# (en realidad, se puede utilizar con cualquier lenguaje de .NET):

using System.Data;
using MonoReporter;

...

Report report = new Report("PruebaMonoReporter", "test.svg");
report.Data["titulo"] = "Listado de personas";

DataTable personsTable = new DataTable();

DataColumn[] columns = new DataColumn[4];
columns[0] = new DataColumn("nombre");
columns[1] = new DataColumn("apellido");
columns[2] = new DataColumn("dni");
columns[3] = new DataColumn("direccion");
personsTable.Columns.AddRange(columns);

DataRow d1 = personsTable.NewRow();
d1["nombre"] = "Milton";
d1["apellido"] = "Pividori";
d1["dni"] = "99999999";
d1["direccion"] = "dirección";
personsTable.Rows.Add(d1);

d1 = personsTable.NewRow();
d1["nombre"] = "Pepe";
d1["apellido"] = "Biondi";
d1["dni"] = "11111111";
d1["direccion"] = "alguna dirección";
personsTable.Rows.Add(d1);

d1 = personsTable.NewRow();
d1["nombre"] = "Juan";
d1["apellido"] = "Sanchez";
d1["dni"] = "33333333";
d1["direccion"] = "otra dirección";
personsTable.Rows.Add(d1);

report.DataTables["personas"] = personsTable;

report.Run(myWindow);

DataTable es una clase del namespace System.Data.

Report es una clase de MonoReporter, la principal. En las primeras lineas se crea un nuevo reporte con un título dado, y un archivo SVG de donde leer el diseño del reporte. La propiedad Data devuelve un Hashtable, en el que podemos setear el texto que queramos al elemento SVG indicado por la clave. En este caso, se está diciendo que al momento de generar el reporte, al elemento con id (lo cambiamos desde Inkscape) “titulo” le asigne el valor “Listado de personas”.

Una vez creado el DataTable, le indicamos la fuente de datos para la “tabla” llamada “personas”. Una “tabla” es un concepto inventado, que se forma creando varios elementos de texto en Inkscape, tantos como columnas haya, y dándole a cada uno el nombre de la columna (que definimos en el DataTable). Luego se los agrupa, y a esa agrupación se le coloca un nombre. El nombre en este caso es “personas”.

De esta forma cuando MonoReporter encuentra un layer con sólo nodos “text”, sabe que se trata de una tabla. Este es el archivo PDF final que genera el código de arriba.

Quedan muchas (muchísimas) cosas por hacer, a tal punto de que ni siquiera es usable: por el momento se pueden generar reportes de una sola página Algunas cosas que faltan por hacer:

• Soporte para reportes largos (de más de una página).
• Soporte para más elementos gráficos de SVG (por ahora reconoce rectángulos, líneas y texto).
• Mayor nivel de personalización: por ejemplo, el espacio entre filas no se puede cambiar.
• Soporte para la inclusión de imágenes.
• Etc etc etc…

Algunas limitaciones:

• A los textos sólo se los puede redimensionar aumentando su tamaño de fuente, o sea, sin utilizar las flechas.
• Raramente, algunos colores son bien leidos, pero otros no, como el verde.
• Y muchas más…

El código fuente se encuentra aquí, en el mismo repositorio que Zaspe#. Está bajo la GPLv3.

Si alguien tiene algún comentario, alguna mejora o sugerencia para encarar esto mejor… bienvenido sea!

Funciona en GNU/Linux con Mono (yo lo estoy probando con la versión 1.2.3 que viene en Ubuntu Feisty) o en Windows con .NET Framework 2.0 y el runtime de gtk-sharp 2.10 (que se lo pueden bajar de la página del proyecto).

Si les interesa probarlo, se pueden bajar los archivos desde la página de descargas del proyecto.

Una aclaración para el uso: cuando lo ejecutan, verán al inicio la lista de asistencias vacía. Para que se habilite tienen que ingresar por lo menos una persona, y por lo menos un evento anterior a la fecha actual (ya que no tiene sentido ingresar las asistencias para un evento futuro). Si a alguien le es útil algo así, y tiene ideas para mejorarlo, por favor, están invitados a dejar un comentario en este post, o un issue.

Bueno, estuve haciendo unas pruebas con Python y C#. Hay una implementación de código abierto (bajo la licencia de Microsoft Ms-PL) del intérprete de Python escrita en C#, que permite ejecutar estos programas compilando el código Python a CIL (el código intermedio). También tiene una consola, como Python, y es posible utilizar toda la biblioteca de .NET. Se llama IronPython.

Esta implementación, en su versión estable actual 1.1, tiene compatibilidad con CPython 2.4.4. Esto significa que un programa escrito para ser corrido con Python 2.4.4 puede correrse también con IronPython 1.1. Sin embargo no es que podemos correr cualquier cosa hecha para Python con IronPython: un juego que utiliza el módulo PyGame no funciona (por lo menos yo no pude).

Les voy a mostrar un ejemplo en el que desde Python creo una clase que hereda de otra creada en C#. Sip, ¡esto está muy bueno!

Esta es la clase Persona (si, es algo bien sencillo) en C#:

using System;

public class Persona
{
	private string nombre;
	private string apellido;

	public Persona(string nombre, string apellido)
	{
		this.nombre = nombre;
		this.apellido = apellido;

		Console.WriteLine("Constructor C#");
	}

	public string Nombre
	{
		get { return this.nombre; }
		set { this.nombre = value; }
	}

	public string Apellido
	{
		get { return this.apellido; }
		set { this.apellido = value; }
	}

	public string NombreEnMayusculas
	{
		get {
			return this.nombre.ToUpper();
		}
	}

	public string ApellidoEnMayusculas
	{
		get {
			return this.apellido.ToUpper();
		}
	}
}

Para los que no conocen C#, esas cuatro ultimas cosas raras que están definidas se llaman propiedades. Vienen a reemplazar los getters y setters. Así, en lugar de setear el nombre con un objeto.setNombre(“Nombre nuevo”), lo hacemos con un objeto.Nombre = “Nombre nuevo”. Pueden ser de sólo lectura (cuando hay sólo un get), sólo escritura, o lectura/escritura.

En fin, la clase Python es esta:

import clr
clr.AddReferenceToFile("Persona.dll")

import Persona

class Mujer(Persona):

    def imprimirNombreCompleto(self):
        print self.Nombre + ' ' + self.Apellido

    def nombreEnMinusculas(self):
        return self.Nombre.lower()

    def apellidoEnMinusculas(self):
        return self.Apellido.lower()

x = Mujer('Juana', 'Vargas')
x.imprimirNombreCompleto()

print x.NombreEnMayusculas + ' ' + x.ApellidoEnMayusculas
print x.nombreEnMinusculas() + ' ' + x.apellidoEnMinusculas()
print x.nombreEnMinusculas() + ' ' + x.ApellidoEnMayusculas

(Cuando copian y pegan, las comillas simples se cambian. Así que no va a compilar a menos que las reemplacen)

Los pasos para probar este codigo son:

1. Compilar la clase hecha en C# a una librería (Persona.dll) ejecutando: “mcs -t:library -out:Persona.dll Persona.cs”, suponiendo que han llamado al archivo de la clase C# Persona.cs
2. Instalan la versión Community Edition de IronPython (IPCE). La pueden bajar aquí. Hay que agregar a la variable de entorno PATH el lugar donde lo descompriman.
3. Corren el archivo Mujer.py (suponiendo que así lo han llamado) con IronPython: “ipy.exe Mujer.py”

La salida de eso es:

Constructor C#
Juana Vargas
JUANA VARGAS
juana vargas
juana VARGAS

Python desde C#

Lamentablemente el ejemplo anterior invertido no es posible (crear una clase en C# que herede de la de Python), sin embargo obvio que sí se pueden ejecutar métodos y otras cosas.

Python es un lenguaje dinámico, y esta característica complica las cosas. Si bien IronPython ha demostrado que CLR (Common Language Runtime) tiene buen soporte para los lenguejes dinámicos, se está trabajando en una capa que está encima de CLR, llamada DLR (Dynamic Language Runtime) que lo hace muchísimo mejor para este tipo de lenguajes. DLR hace que sea mucho más fácil implementar lenguajes dinámicos en .NET, además de poder compartir código con otros lenguajes (dinámicos y estáticos).