VISIBILIDAD

LLANOS DE LAS CAÑADAS CON RETAMAS COMENZANDO LA INFLORESCENCIA SOBRE SUELO DE PUMITA, CON LOS ROQUES DE GARCÍA A LA DERECHA, COMO COLMILLOS E PIEDRA, Y EL TEIDE NEVADO EN SU CUMBRE AL FONDO, PARQUE NACIONAL DE LAS CAÑADAS DEL TEIDE, TENERIFE.

      

      La primera pregunta que debemos plantearnos es qué queremos decir con "visibilidad" y qué significa esto para Python. El concepto de visibilidad es obvio: refiere algo que se puede ver, que es visible, que no está oculto. Y en el ámbito de la programación, se refiere a que el código escrito por cualquier programador o programadora sea visible para cualquier otro programador o programadora distinto, en todo momento y en cualquier lugar.

Esto ocurre cuando desarrollamos un programa, lo terminamos, comprobamos que nos funciona a las mil maravillas y con el rostro henchido de gozo, lo publicamos y hasta lo comercializamos. Una vez hecho esto, podemos dejar el código (open source) abierto para que otros programadores aporten nuevas características al programa, lo optimicen aquí y allá ("Mira, si cambiamos este trocito de código por esta función de aquí, y usamos un iterador entre ésto y aquéllo, nos podemos ahorrar diez líneas de código y, además, se ejecuta más rápidamente"), contribuyan a su mantenimiento adaptándolo a nuevas versiones del programa, mejoren su rendimiento, etc.

Esto es lo ideal porque no siempre podremos nosotros, como desarrolladores únicos, mantener en condiciones un programa si éste es largo, a veces, muy largo, con miles y miles de líneas de código. Aquí nos vendría bien citar el aforismo aquél que decía: "Sólo no; con amigos, sí".

Pero, a veces, el propio programador o programadora original entiende que hay partes de su código que considera , "sensibles", "delicadas", "problemáticas",... En la mayor parte de los casos, se trata de código que estima que no debe tocarse o modificarse porque el cambiar parte o todo de ese código alteraría gravemente la funcionalidad original del programa e, incluso, hacer que dejara de funcionar. Podemos imaginar, por ejemplo, que se ha desarrollado un método que permite discriminar entre usuarios que dispongan de un determinado tipo de clave y otra, de tal manera que según la que posea el usuario, podría acceder a unos aspectos del programa y no a otros que le quedan vedados. ¿Qué sucede si otro programador, por error o despiste, modifica el diccionario que almacena los identificadores de usuario con su clave de acceso asignada? Pues que buena parte del trabajo (y de las intenciones) del programador o programadora original se irían al garete. 😡

Para casos como el que describimos en el ejemplo, casi todos los lenguajes de programación suelen implementar herramientas de PRIVACIDAD, a las que el programador puede acudir lindamente para evitar que a este "código sensible" pueda acceder otro programador o programadora distinto, lo modifique o adultere accidentalmente y el programa original "ya no sea el mismo".

Ya sabemos que Python es muy particular. Y en esto también lo es.

Python no dispone de herramientas de privacidad.

Efectivamente, con Python no disponemos de esas herramientas de privacidad de la que sí disponen otros lenguajes de programación, por lo que todas nuestras virtudes y vergüenzas  programáticas quedan en manos de cualquier escudriñador de intimidades que importe o maneje nuestros atributos y métodos de una clase a otra (en el ejemplo de las claves restringidas que expusimos antes, el que por ejemplo, el nombre de la referencia al espacio de memoria, la variable, que almacena el diccionario de un determinado tipo de clave y que está dentro del cuerpo de una clase concreta, pongamos por caso, clase AccesoPago, se desplace por error a la clase AccesoGratuito. ¿Podemos imaginarnos lo que significaría algo así desde el punto de vista comercial o de empresa? No, no podemos impedir el acceso desde una clase a otra clase distinta a donde un objeto, el diccionario que citamos arriba con los identificadores de usuario/claves de acceso, fue instanciado de manera original y donde tiene su razón de ser).

La razón fundamental por la que Python "actúa" así es por COHERENCIA. Sí, coherencia con su filosofía zen, minimalista y de código abierto donde todo el mundo tiene la opción de contribuir a desarrollar el lenguaje y a mejorar constantemente, con aportaciones externas, la funcionalidad de cualquier programa codificado con él.

Así las cosas, sólo nos queda recurrir a la buena fe de los programadores quienes han establecido "por convención", como sucede con tantas cosas en Python, que para caracterizar a un atributo o propiedad o a un método como privado, sea suficiente con anteponer un único guión bajo (underscore) al nombre de la propiedad o metodo, aunque ello no tenga significación alguna pa ra Python. Vamos, es algo que queda entre nosotros.

Sin embargo, cuando en lugar de un único guión bajo utilizamos dos guiones bajos, declaramos tal atributo o propiedad o método es "privado" de facto, inaccesible, de tal modo que Python, esta vez sí, previene cualquier intento de acceso limitando la acción mediante el lanzamiento de una excepción específica para el caso de tipo AttributeError que luego, en caso necesario, como ya estudiamos en TRATAMIENTO DE EXCEPCIONES, podremos manejar de acuerdo a nuestros intereses.

Veamos un ejemplo:

Para terminar, los programadores más experimentados en Python aconsejan eludir todo mecanismo de privacidad en nuestros programas y quedarnos, como mucho, tanto con un comentario de línea (# Tener cuidado con esta variable pues tal y tal... o # Recordar que este método pertenece a la clase tal) o de varias, si se tercia, con triple comillas, y usar sólo un único guión bajo.

TEIDE Y NORIAS.