lunes, 15 de abril de 2019

Cuando unos leguajes tratan los arrays por referencia y otros por copia

¿Qué ocurre cuando asignamos un array a otro? En la mayor parte de los lenguajes, lo habitual es que la nueva variable sea un puntero (referencia) al primer array. Por ejemplo, en Python:

array2 = array1 = {'uno': 1, 'dos': 2}

print('array1 antes:', array1)
print('array2 antes:', array2)

array2['dos'] = 22
array1['tres'] = 3

print('array1 después:', array1)
print('array2 después:', array2)


La salida de este script sería la siguiente:

~ $ python3 testarray.py 

array1 antes: {'uno': 1, 'dos': 2}
array2 antes: {'uno': 1, 'dos': 2}
array1 después: {'uno': 1, 'dos': 22, 'tres': 3}
array2 después: {'uno': 1, 'dos': 22, 'tres': 3}


Como era previsible, al cambiar algo en array1 o en array2, el otro array se modifica, porque las dos variables son una referencia al mismo array. (En Python a este tipo de datos se le llama diccionario, pero podemos asumir que es equivalente al array asociativo de PHP)

Este sencillo ejemplo es muy adecuado para explicar a alguien lo que son las referencias. Se ve claramente que cambiar algo en una variable tiene efectos colaterales.

Sin embargo, podemos encontrarnos sorpresas en otros lenguajes. PHP, por ejemplo, copia el array en la nueva variable y a partir de ese momento, son dos referencias independientes. Mucho cuidado si nuestro array contiene muchos datos, se duplica el consumo de memoria:

<?php 
$array1 = $array2 = array("uno" => 1, "dos" => 2);

echo "array1 antes:"; var_dump($array1); echo "\n";
echo "array2 antes:"; var_dump($array2); echo "\n";

$array1["tres"] = 3;
$array2["dos"] = 22;

echo "array1 después:"; var_dump($array1); echo "\n";
echo "array2 después:"; var_dump($array2); echo "\n";


La salida de este script es la siguiente:

~ $ php testarray.php 

array1 antes:array(2) {["uno"]=> int(1), ["dos"]=> int(2)}
array2 antes:array(2) {["uno"]=> int(1), ["dos"]=> int(2)}

array1 después:array(3) {["uno"]=> int(1), ["dos"]=> int(2), ["tres"]=> int(3)}
array2 después:array(2) {["uno"]=>, int(1), ["dos"]=> int(22)}

¿Qué ha pasado en este caso? Las dos variables son independientes, los cambios en una no afectan a la otra. Cada una apunta a una región de memoria diferente. En PHP se puede conseguir el mismo comportamiento que en otros lenguajes, esto es, que asignar una variable a otra por referencia:

<?php 
$array1 = array("uno" => 1, "dos" => 2);
$array2 = &$array1;

echo "array1 antes:"; var_dump($array1); echo "\n";
echo "array2 antes:"; var_dump($array2); echo "\n";

$array1["tres"] = 3;
$array2["dos"] = 22;

echo "array1 después:"; var_dump($array1); echo "\n";
echo "array2 después:"; var_dump($array2); echo "\n";

En este caso el comportamiento es el mismo que en el primer script en Python.
La expresión $array2 = &$array1asigna por referencia la variable 1 a la variable 2.

¿Qué comportamiento es deseable o más conveniente en un lenguaje de programación? La aproximación de PHP puede parecer más ineficiente, pero si reflexionamos un momento, tiene algo a su favor: es consistente.

<?php
$a = $b = 4;
$a = 5;
var_dump($a); var_dump($b);

La salida es:

int(5)
int(4)

Cada variable es una copia.

En Python, los tipos de datos simples sí que se asignan por copia:

Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
>>> a = b = 4
>>> a = 5
>>> a
5
>>> b
4
>>>

También se ve cómo son variables independientes. 

Todos los tipos de datos, simples y compuestos, se comportan igual PHP, sin embargo, en Python los tipos de datos compuestos (diccionarios, listas,... se asignan por referencia y los tipos de datos simples (enteros,...), se asignan por copia.

Esto no es bueno ni malo... pero hay que estar atento.

martes, 9 de octubre de 2018

Modo "inserción" en Vi(m)

¿A que más de una vez nos hemos encontrado con algo así en el fuente de una web?


pt type="text/javascript">
  function blabla() {
    //
  }
</script>



Curioso... ¿puede que tenga que ver con que el comando para empezar a escribir texto en vi(m) sea "i"?

sábado, 15 de septiembre de 2018

Refrescando Django (1)

A lo tonto, Django ya tiene unos cuantos añitos. Van por la versión 2.1 en el momento de escribir estas líneas (septiembre de 2018). Refresquemos un poco Django.

Vamos a hacer una web que sirva para guardar marcadores, parecido a lo que hacía Del.icio.us (qué tiempos...)

Requisitos


- La app debe presentar una pantalla de login y ofrecer al usuario la posibilidad de registrarse. El email será la clave para identificar al usuario.

- Una vez autentificado, la aplicación listará los marcadores que el usuario haya ido guardando, así como las etiquetas que el usuario haya asignado al marcador.

- En la pantalla de listado, se puede filtrar por etiquetas.

- Para añadir un marcador, se presenta un formulario al usuario. El sistema debe tratar de hacer una vista previa del marcador (extraer el título, algún resumen, foto representativa...)
El usuario puede asignar etiquetas a cada marcador. Las etiquetas se pueden sugerir autocompletando a partir de las que ya hay.

Preparación del proyecto


Empecemos instalando Django según las instrucciones de la documentación. Una vez instalado, inicializamos el proyecto.


django-admin startproject bookmarks

Lo primero que vamos a hacer es definir los diferentes entidades y sus correspondientes modelos.

Tag: representa una etiqueta para uno o varios marcadores. Sus campos serían, aparte del id, que ya lo autogenera Django, name y description. Sólo es obligatorio name.

Bookmark: representa un marcador. Sus campos serían title, description, url e image. Son obligatorios title y url.


Un marcador puede tener muchas etiquetas, a su vez, una etiqueta puede estar presente en muchos marcadores. Esto nos sugiere una relación ManyToMany. Solo es necesario hacer la asociación entre marcadores y etiquetas en un punto, según nos indican en la documentación. Lo más razonable parece hacer la asociación en la entidad Bookmark, puesto que es la entidad sobre la que todo gira.

User: representa un usuario. Vamos a reutilizar todo el sistema de gestión de usuarios de Django.

Una vez definidos las vistas que queremos y los modelos que vamos a necesitar, empezamos el desarrollo.

Dentro de un proyecto Django podemos tener varias apps, en este caso, para un proyecto tan pequeño, probablemente sólo necesitaremos una app. El proyecto es un contenedor, lo que "hace algo" son las diferentes apps que hay en un proyecto. Llamemos a la app bookmarks.

python3 manage.py startapp bookmarks 

CommandError: 'bookmarks' conflicts with the name of an existing Python module and cannot be used as an app name. Please try another name

No podemos, lógicamente. Ya hay un módulo llamado bookmarks (el correspondiente al proyecto). Tenemos que pensar un nombre para la aplicación que no entre en conflicto y que describa un poco la naturaleza de la función de esta aplicación. Llamémosla manager, ya que esta app será el gestor de marcadores.

En este punto tenemos en el proyecto dos módulos, uno llamado "bookmarks", que corresponde al proyecto en su globalidad, con sus ajustes comunes, rutado... y otro llamado "manager", que corresponde a la aplicación (para este proyecto probablemente sea la única app que lleguemos a hacer).



La carpeta de "fuera", la que contiene el proyecto, nos da igual como se llame, de hecho la vamos a renombrar.



Mejor así. Comprobemos que funciona:

BookmarksManager david$ python3 manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).

You have 15 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.

September 15, 2018 - 11:10:40
Django version 2.1.1, using settings 'bookmarks.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
[15/Sep/2018 11:10:49] "GET / HTTP/1.1" 200 16348
[15/Sep/2018 11:10:49] "GET /static/admin/css/fonts.css HTTP/1.1" 200 423
[15/Sep/2018 11:10:49] "GET /static/admin/fonts/Roboto-Regular-webfont.woff HTTP/1.1" 200 80304
[15/Sep/2018 11:10:49] "GET /static/admin/fonts/Roboto-Bold-webfont.woff HTTP/1.1" 200 82564

[15/Sep/2018 11:10:49] "GET /static/admin/fonts/Roboto-Light-webfont.woff HTTP/1.1" 200 81348

Ya hemos terminado de montar la estructura del proyecto.

Definición de modelos

Vamos con los modelos del ámbito de la aplicación: Bookmark y Tag




Empezamos desde el principio utilizando la riqueza de tipos que Django nos aporta. Por ejemplo, un URLField no es más que un campo de texto con un validador adicional que nos comprueba si la URL que pretendemos guardar está bien formada.

Al utilizar un campo ImageField nos salta un error:

ERRORS:
manager.Bookmark.image: (fields.E210) Cannot use ImageField because Pillow is not installed.

HINT: Get Pillow at https://pypi.org/project/Pillow/ or run command "pip install Pillow".


Nos recuerda que para tratar imágenes, debemos instalar Pillow.

Instalamos la aplicación editando el settings.py del proyecto:



Nos quedan definir las relaciones entre Bookmark y Tag y los usuarios del sistema. Para ello, vamos a heredar nuestra entidad BookmarkUser de la clase AbstractUser.



Ejecutamos los comandos makemigrations y migrate y ya tenemos la base de datos preparada.



Preparando el admin

Para que en la aplicación admin de Django aparezcan estas entidades debemos registrarlas en admin.py de la aplicación.



También vamos a crear un usuario administrativo para la interfaz administrativa. Este usuario no es un usuario de la aplicación de marcadores, es un usuario interno de Django. Lo llamaremos "root", en analogía a UNIX.



Si accedemos a la interfaz admin con este usuario, ya podemos empezar a cacharrear con las entidades.




Hasta ahora no hemos hecho nada diferente de lo que el tutorial de Django nos enseña. Vamos a empezar a desarrollar en este punto nuestras funcionalidades.







miércoles, 8 de agosto de 2018

Clean Code

Lectura recomendada:



Hay veces que repasando código ajeno uno se puede encontras cosas muy farragosas. Este método simplemente pretende buscar entre una lista de rangos cuál corresponde a un valor en concreto.
Por ejemplo: "A", para valores entre 100 y 51; "B" para valores entre 50 y 31; "C" para valores por debajo de 30.

Partíamos de este código, que prácticamente da miedo verlo:

  • El nombre del método es excesivamente largo y para un lector angloparlante, está mal escrito.
  • Los nombres de las variables también son muy largos y con elementos redundantes: "nameNosequé" es innecesario: toda variable se usa precisamente para nombrar algo.
  • La iteración es poco natural (con una condición negada como primer control del bucle) y usa construcciones del lenguaje (en este caso, la función "each" de PHP) que están "deprecated".
    Con nombres tan largos y esta asignación metida en el control del bucle, queda realmente ilegible:

    while (!isset($nameOfMatchedTransparencyRanking) && (list($transparencyRankingName, $arrayTransparencyRankingInterval) = each($arrayTransparencyRankings))) {
    // Cuerpo del bucle
    }
Para recorrer una estructura de datos de este tipo (array asociativo) es más natural y legible -y posiblemente, más eficiente- usar un bucle foreach.


No es la mejor implementación del mundo, pero al menos ya es más legible y se entiende un poco mejor qué hace este método. Si quisiéramos que fuese más genérico, y no estuviese atado a una aplicación en concreto, los nombres de variables podrían ser aún más genéricos (p.ej, $value en vez de $transparency).

Hacer un return entre medias del bucle no es muy académico ni formal, pero permite un código compacto y sencillo. Esta forma de escribir la utilizaban los mismísimos creadores de C, y en funciones cortas como esta, es perfectamente aceptable. En un método más largo, más allá de 10 líneas, personalmente, ya no lo utilizaría porque tendríamos un punto de salida descontrolado que no se ve claramente.



(Capturas del libro "The C Programming Language" de D. Ritchie y B. Kernighan. Si no sabes quiénes son estos señores, no sé que haces leyendo este blog ;-)