Usos. Datos.

Puntuación de un ítem. Presentar y puntuar (1)

Existen diferentes formas de resolver el problema de cómo plantear y puntuar un ítem, tarea simple (al menos en principio), pero de gran importancia para el desarrollo de documentos-soporte y docap de evaluación. En esta entrada voy a explicar cómo se planteó la cuestión en el documento-soporte PLONrFono_2016.

El documento-soporte PLON-R fue creado originalmente en 2016, derivado de otros soportes de fecha muy próxima, aunque ligeramente anterior (probablemente 2014). Se trata pues de una formulación previa a la creación de docap en la que los soportes se basaban fundamentalmente en formato Word y los que se creaban sobre Excel eran escasos y se basaban en el uso de funciones integradas en la hoja de cálculo, no en macros o script.

En la entrada dedicada a este test y en esta misma versión describí su estructura y funcionamiento, incluyendo la presentación y corrección de los ítem, pero ahora quiero centrarme específicamente en el modo en que se construye el cuestionario de ítem, dado que el propio test y su antigüedad se presta al análisis del modo en que se afrontó esta cuestión en los momentos iniciales de creación de recursos para la evaluación.

Como sabes, se trata de un test para la evaluación del lenguaje oral que se basa en solicitar al alumno la producción oral de un modelo lingüístico elicitado mediante imagen. El estímulo que se presenta se identifica inequívocamente con una respuesta verbal concreta, por lo que no cabe otra opción de calificación de éste que V o F o cualquier forma equivalente.

La forma en que se plantea el soporte debe facilitar su uso durante la aplicación de la prueba (lo cual se realiza presentando al niño una colección de imágenes que proporciona el test), por lo que la puntuación debe ser sencilla y no retrasar la aplicación de la prueba para que su incidencia en esta aplicación sea equivalente a la que tiene el uso del formulario en papel.

Para hacer esto efectivo, la presentación se basó en una tabla creada en la hoja de cálculo (1) en una de cuyas columnas (E) se destina a que el examinador pulse la tecla 1 (V) o 0 (F). La referencia para la puntuación viene dada por la presencia de la respuesta correcta en la columna D, con lo que la valoración de la respuesta es inmediata: si el alumno reproduce la palabra escrita (el nombre correcto y esperado en función de lo que elicita la imagen), el ítem se considera acertado, si se diferencia de esa respuesta de la forma que sea o no responde, se valora negativamente.

La puntuación del ítem es, por tanto, directa, y queda bajo el control del examinador, pero lo que sigue (que podemos identificar como identificación de la respuesta dada por el alumno) (columna E) está automatizado mediante una función condicional (SI()). 

Dado que nos centramos en el acierto más que en el error, lo que recogemos mediante este condicional es la respuesta correcta, quedando el fallo únicamente identificado como error: =SI(E4=1;D4;"Error")

Este procedimiento busca que no se demore la aplicación del test, por lo que está pensado para que el examinador disponga de forma inmediata del resultado obtenido por el alumno en términos de Superado/No superado, tal y como corresponde a un test de tipo screening.

Y efectivamente cumple este objetivo a la perfección, ya que proporciona un sumatorio por bloque de edad y un perfil total que permite formular una valoración provisional del nivel de desarrollo fonológico alcanzado por el alumno.

Ahora bien, no permite realizar un análisis cualitativo del tipo de errores y el modo en que éstos se manifiestan.

Parcialmente esta limitación se puede considerar atendida mediante la tabla que complementa la anterior y que se centra en valorar el nivel de adquisición de cada uno de los fonemas testados.

Esta tabla está diseñada para recoger la información de identificación que se precisa (edad de referencia, fonema evaluado y % de nivel de adquisición en función de dos rangos de edad) y la valoración se produce de forma automática y en dos fases:

• En la primera (columna M) mediante un sumatorio (=E4+E5)
• Y en la segunda (columna N), mediante un condicional (=SI(M5=2;"Adquirido";SI(M5=1;"En proceso";"No adquirido")))

Si este procedimiento no resultara suficiente (2), caben dos soluciones que quedan a disposición del OE:

• Realizar una grabación de audio como soporte para un análisis posterior, centrado en los errores producidos.
• O plantear, en su caso, un proceso específico de evaluación de corte más cualitativo, a desarrollar en una segunda fase (3)

En cualquier caso, atendiendo a la naturaleza del test (screening), el procedimiento de valoración y análisis planteado es totalmente satisfactorio y se ajusta a la finalidad que cabe esperar de un proceso de evaluación como el que implica el uso de un recurso como PLON-R. Es más, yo diría que posibilita ir más allá de lo que sería exigible en función del objetivo de una evaluación que no puede ser otra cosa que educativa, que no clínica (4).

NOTA 1. Como se muestra en la imagen que sigue al párrafo, esta tabla cuenta con información adicional que ahora resulta irrelevante, pero que ayuda a ubicar el ítem en su marco cronológico de referencia (columna B) e identifica el contenido fonológico específico (columna C)

NOTA 2.  Y es probable que así sea si se pretenda fundamentar una intervención de apoyo (de AL) sobre los resultados de la evaluación.

NOTA 3. Recomiendo que, de optarse por la primera opción, se realice una grabación digital de la muestra del lenguaje, sea estas con una grabadora o utilizando una app de grabación. AL menos para el análisis posterior recomiendo el uso del programa Audacity. En cualquier caso, se opte por la opción que se sea, se puede optar, a su vez, por tres formas diferentes de concretarla: como responsabilidad del OE, como responsabilidad de la profesora de AL o como derivación a una especialista externa (logopedia clínica, Foniatra...) No obstante, esta cuestión es más compleja de lo que aquí se puede plantear, siendo necesario una mayor explicación que merece un análisis que no es pertinente realizar en esta entrada.

NOTA 4. Un poco más de lo mismo que en 3. Mejor tratar este tema en otra entrada de forma específica y con más referencias.

Evaluación. Fonología

PLON-R. Fonología

Ampliando el contenido de la sección Evaluación y aprovechando para profundizar en el análisis del uso de las Hojas de cálculo como soportes para la evaluación, dedico esta entrada a analizar en profundidad un recurso desarrollado inicialmente en 2016, así como el proceso que devino en su concreción como tal recurso. 

PLON-R

La Prueba de Lenguaje Oral de Navarra-Revisada (PLON-R) es un recurso diseñado por Aguinaga, Armentia, Fraile, Olangua y Uriz con el objetivo de facilitar la evaluación del desarrollo del lenguaje oral en edades tempranas (de 3 a 6 años), concretamente para la detección de dificultades del desarrollo del lenguaje. 

Actualmente comercializa PLON-R la Editoral TEA con un coste de 206,32 € (IVA incluido) y actualmente incorpora, como novedad, un manual on-line (con un coste específico de 36,32 € (IVA incluido), aunque el sistema de aplicación sigue siendo en papel y la corrección manual.

Y digo actualmente porque PLON, que tuvo una primera versión así, sin R, es ya un test vetusto, incluso incorporando la R al nombre (1), pero la actual, por lo que sé, no difiere sustancialmente de la que se maneja aquí.

Por lo que se refiere a las creaciones de soportes documentales, en los materiales consultados constan soportes en versión doc, pdf, File Maker y Excel del sistema de registro, todos ellos creados en fechas próximas a 2016, aunque es posible que algunos de ellos sean anteriores. Los primeros dos formatos están pensados para ser utilizados en papel como modo de ahorro de recursos, pero los otros dos tienen objetivos más ambiciosos: facilitar el registro electrónico en primer lugar, pero también permitir el uso directo alternativo al papel y, en cierta medida también automatizar la corrección del test.

Al ser PLON un test complejo, se desarrollaron tres versiones (2) del sistema de registro: prueba completa, versiones por niveles de edad y versione por dimensión o nivel lingüístico. En esta entrada me voy a detener en el análisis del soporte Fonología.

Y quiero hacerlo en comparación con otra prueba de similar enfoque y metodología, el Registro Fonológico Inducido de Monfort y Juárez. No para hacer comparación entre ambos en cuanto pruebas (aunque algo al respeto diré), sino, sobre todo, para comparar el diseño de los soportes documentales de ambos.

Aunque bien pensado, me temo que la comparación no va a dar para mucho, pero puede ser suficiente para entender la evolución de estos soportes ahora sí con cierta perspectiva temporal, ya que las versiones básicas (doc y pdf) de PLON-R no difiere en nada de la versión (en este caso única) del soporte RFI, lo que nos permite situar a las primeras en una ubicación temporal ajustad en términos de funcionalidad: 2007 (3).

Lo que caracteriza a estas primeras versiones de adaptación y soportes es que su finalidad principal era la de ahorrar materiales que tenían un coste económico y no estaban tan inmediatamente disponibles como lo pueden estar ahora; si acaso podían tener el beneficio complementario de servir como recurso para digitalizar el expediente del alumnado, pero no parece que este haya sido una utilidad realmente aplicable, ya que no constan en los expedientes recursos de este tipo (4).

Por ello se puede concluir que en estas fases iniciales, no parece haber habido mucha conciencia de utilizar soportes digitales en el proceso de evaluación, aunque es posible que sí cierto interés por formas básicas de digitalización, entendidas en su formulación más simple: ahorro de documentos en papel e incremento de la portabilidad.

Es por ello que es siguiente paso lógico pudiera haber sido precisamente hacer efectiva esa digitalización, aun en contradicción con la reducción de la carga de trabajo, aunque es posible que ese fuera precisamente un motivo nada desdeñable para que no se generalizara esta "estrategia" (5).

Sólo cuando a la informatización se añade la lógica de la sustitución del papel durante la aplicación de la prueba es posible hablar de verdadero ahorro de trabajo, y eso sólo es posible cuando se crean soportes Hc o BD suficientemente funcionales y accesibles (6), proceso en el que realmente aun estamos inmersos, aunque pasos sí que se han dado al respecto... y significativos.

Cierto; significativos y no necesariamente basados en la creación de macros-script (7), pudiendo constatarse unas características y líneas de  evolución en parte ya indicadas en entradas anteriores, pero que expondré ahora con mayor detalle.

Empezando por el formulario de entrada de datos de identificación, lo que pudimos ver en el soporte PSL_2013, no dista nada de lo que podemos mostrar en PLONrFono_2016: un 'formulario' diseñado directamente sobre las celdas, si acaso enmarcado o coloreado, pero simple y llanamente 'dibujado' a modo de trampantojo para ser cumplimentado del mismo modo que la versión precedente en formato doc o en papel. De hecho una mera copia del original en papel.

A pesar de su simplicidad, o precisamente por ella, la funcionalidad en términos de uso directo durante la evaluación no se ve comprometida por tener que usar las celdas en lugar de controles de formulario (cosa que sí se da en la versión BD), pero tampoco se puede decir que esta fórmula permita avanzar en la automatización del procedimiento de trabajo, lo que constituiría el tercer objetivo y siguiente nivel de desarrollo en la implementación de estos soportes.

De hecho, lo único automatizado que hay en este 'formulario' el el cálculo de la edad del alumno, la cual se base en una serie de fórmulas y cálculos simples, que muestro parcialmente en la imagen que sigue y describo a continuación:

• Asociadas a las celdas D6 y D7 (año de nacimiento y fecha actual, respectivamente), las fórmulas gemelas  =(AÑO(D6)*365)+(MES(D6)*30)+DIA(D6) y =(AÑO(D5)*365)+(MES(D5)*30)+DIA(D5) permiten calcular el número de días que representan dichas fechas
• Estos valores se ubican en las celdas I5 e I6. La diferencia entre ambas (I7) permite obtener la diferencia en días...
• Los cuales se convierten en años al ser divididos entre 365 (=COCIENTE(I7;365)), con lo que en J7 obtenemos el dato años.
• en I8, también mediante cálculos obtenemos el número de días que restan de la división anterior (=I7-(J7*365))
• Y de nuevo una división (esta vez entre 31) nos convierte esos días en meses (=COCIENTE(I8;31)), dato que ubicamos en J8
• Finalmente, mediante la función CONCATENAR(), construimos un texto que nos da en D7 la edad del sujeto en años y meses (=CONCATENAR(J7;":";J8))

Finalizada la primera fase, toca ahora desplazarse a la hoja Fonologia para aplicar el 'cuestionario' (8), para ello nos situamos en la celda E4 y escribimos 1 (acierto) o 0 (fallo) y nos desplazamos a la celda inferior mediante intro. Todo el proceso de corrección y puntuación que sigue se ejecuta de forma automática mediante  funciones propias, como...

• La columna F (a partir de F4) que se cubre automáticamente mediante =SI(E4=1;D4;"Error"), pero que admite ser cumplimentada manualmente si la respuesta del alumno difiere en cuanto a error del que se presupone en el modelo o parece necesario recoger expresamente la producción del sujeto (9)
• El cómputo de las celdas de la columna G en la que se contabilizan los aciertos por años de edad cronológico-evolutiva (vg, G24 para 3 años, =SUMA(E4:E24)) 
• Los sumatorios de fonemas de la columna M (vg, M4, =E4+E5) y su calificación para análisis cualitativo en la columna N(vg N4, =SI(M5=2;"Adquirido";SI(M5=1;"En proceso";"No adquirido")))

Una vez que la prueba ha sido aplicada, regresamos a la hoja Portada para comprobar el resultado global y por edades. Éste se encuentra también automatizado y se ubica en el conjunto C12-G12, en cuyas celdas se valora con 1 (nivel alcanzado) o 0 (nivel deficitario o no alcanzado) mediante asociación con las celdas correspondientes de la hoja Fonologia (columna G) haciendo uso de la función SI(), como muestro para tres años (=SI($Fonologia.G24=21;1;0)).

Lo que no está automatizado en este soporte (que no docap, ya que no se hace uso de macros ni script) es la generación de un informe descriptivo y/o analítico. Además, también queda para la ejecución 'manual' cumplimentar los espacios B18:G20, B23:G26 y B29:G32 que se reservan para realizar anotaciones respecto a articulación espontánea, uso espontáneo del lenguaje y conducta global.

Este es el soporte creado en 2016. Como hemos podido comprobar en estas mismas fechas ya había creado soportes que incluían desarrollos que sería de esperar también estuvieran presentes en éste, pero que no lo están, aunque no existan razones que expliquen el motivo. La que ahora mismo me llama más la atención es la ausencia de un informe descriptivo como el que sí consta en otros soportes creados en esta misma época. Es posible que las dificultades para tratar colecciones de datos como las que constituyen los grupos de celdas  C12:F12, y de  mayor  complejidad aun, la columna N de Fonología, hiciera poco viable este tipo de desarrollo, ya que aun hoy en día supone todo un reto.

Abordemos o no ese reto (queda por ver), lo que sí hará ahora es dar por finalizada esta entrada, dejando pendiente para otra la actualización del soporte PLONrFono_2016 y su conversión en docap. De momento, y a continuación, te dejo acceso a éste y a otro más básico aun y en formato texto sobre RFI.

Documentos:

• RFI. Item. Soporte original en formato .doc 
• PLONrFono_2016. Soporte original revisado en formato ods (Calc)

Estos documentos no sustituyen a los materiales originales. Ambos los requieren para poder ser empleados, especialmente los recursos gráficos, a los que sirven de apoyo.

Notas:

NOTA 1. Como dato, la portada que ilustra esta entrada corresponde a la publicación de 2005 por la editorial TEA, pero antes que esta hubo una edición anterior.

NOTA 2. Me refiero al soporte Excel, pero algo parecido podría decirse de las versiones File Maker.

NOTA 3. Cierto que de RFI constan documentos fechados con anterioridad (2004 e incluso 1999), pero éstas correspondería (en su caso) con versiones anteriores de PLON, por lo que ya no estaríamos hablando de esta prueba en sentido estricto, además de que no consta que existan documentos equivalentes de dicha versión del PLON y menos específicamente de su desglose por niveles o ámbitos estructurales del lenguaje.

NOTA 4. Dado que este análisis no está concluido, la afirmación anterior debe tomarse con reservas y ser considerada como provisional, aunque existen indicios de que no se alejará mucho de las conclusiones finales. En realidad, como hemos visto y comentado en una entrada anterior la presencia real de soportes documentales en cualquier formato (incluso en doc o pdf) el uso de materiales.

NOTA 5. De hecho esas formas básicas (soportes doc) suponen un aumento de trabajo, ya que se deben trasladar las anotaciones en papel al documento Word. Este doble trabajo ya es de por sí suficientemente disuasorio como para explicar la escasa presencia de documentos de este tipo o fase.

NOTA 6. Aunque el formato BD (recordemos, en File Maker) es igual de funcional o incluso más que los soportes en Hc, existen en ambos (y aun más en BD) problemas de accesibilidad y algunos no siempre resueltos satisfactoriamente de funcionalidad. Los primeros tienen que ver con las posibilidades de uso de medios informáticos adaptados al contexto de evaluación (en algunos test un ordenador de sobremesa no es precisamente una buena herramienta) y los segundo con el nivel de desarrollo del soporte, lo que equivale a decir, de habilidad de 'programación' del orientador.

NOTA 7. En realidad, la mayor parte de los soportes Hc creados en los años de mayor uso de estos medios (2014, 2015 y 2026), pero también a posteriori, apenas cuentan con macros o script, siendo predominante el uso de funciones integradas en Excel y posteriormente en Calc. Solo las herramientas creadas en File Maker hacen uso de macros, en realidad funciones cerradas, creadas en un lenguaje específico de macros que permiten automatizar ciertos procesos; pero estas funciones son equivalentes a un producto intermedio a una función propia y una macro de las que es posible crear en una hoja de cálculo. 

NOTA 8. La aplicación real requiere las láminas PLON-R o su sustitución por una presentación PPT o similar, pero eso queda a tu cargo.

NOTA 9. En el caso de pruebas de evaluación del lenguaje oral es recomendable hacer grabaciones de audio de las producciones del niño, al menos para asegurar y/o comprobar cuestiones concretas que puedan dar lugar a dudas. Personalmente recomiendo el programa Audacity, que puede estar actuando en segundo plano en el mismo ordenador a la vez que empleamos nuestro soporte Calc en primer plano.

Recursos. Evaluación

Prueba de Segmentación del Lenguaje (PSL)

Presento en esta entrada la versión Hoja de cálculo (sin código OOo Basic) del test PSL, material de elaboración propia (la versión Hc) realizada en 2009. Esta prueba fue elaborada por Jiménez y Ortiz (1998) y se presenta en versión libro (1), mi versión fue realizada originalmente sobre MSO.Excel en 2009 y posteriormente  adaptada a formato LO.Calc.

La Prueba de Segmentación del Lenguaje (PSL) tiene como objetivo la evaluación de diferentes componentes de la conciencia fonológica. La versión que ahora presento carece de cualquier tipo de código, por lo que su funcionamiento no presente ninguna complejidad, lo que facilitó el cambio de la versión MSO.Excel a la actual LO.Calc

Este soporte fue creado para uso personal y conta de dos partes, coincidentes con las dos hojas de que consta el documento-soporte:

• Ejercicios, donde se presenta el listado de ítem de la prueba. Este listado está dispuesto verticalmente en una hoja protegida donde quedan accesibles las celdas de la columna siguiente a la de redacción del ítem, de modo que el desplazamiento en vertical se ve favorecido por el simple uso de intro.
• La segunda hoja, Resultados, es un computo de las puntuaciones que alcanza el sujeto en los diferentes subtest (16) de la prueba, la suma de esas puntuaciones parciales y la valoración en términos de percentil.

Las funciones Calc empleadas son las siguientes:

• las asociaciones de celdas entre hojas
• la fórmula SUMA()  para el parcial de cada subtest y para el total de la prueba
• y un condicional SI() encadenado para el cálculo del percentil correspondiente a la puntuación total. Dado que es una prueba que se aplica a I3, el baremo es único, lo que simplifica el diseño del sistema de corrección.

Esta prueba en su simplicidad de aplicación y de composición muestra el modo inicial de uso de Hc en el proceso de evaluación, tanto en lo positivo (su sencillez) como en sus limitaciones: no contiene ningún procedimiento de análisis y/o valoración de los resultados al margen de la categorización que establecen los autores y que se manifiesta mediante al función condicional SI().

A pesar de ello, la funcionalidad del recurso se puede considerar satisfactoria y supera ampliamente lo que el material original aporta sin suponer un coste significativo ni de tiempo ni de nivel de conocimiento y manejo de las Hc. Además evidencia las ventajas de utilizar Hc como soporte sobre una versión precedente en Word, que nada añade a una fotocopia en papel, salvo la posibilidad de "informatizar" el documento para archivarlo directamente como tal.

Esta es un poco la esencia del formato inicial de los documentos Hc:

• Sencillez de creación y bajo coste de tiempo y de conocimientos informáticos
• Empleo de una  herramienta conocida o, cuanto menos, accesible, al formar parte de los componentes del paquete ofimático.
• Aplicación de pocas pero suficientes funciones propias de las Hc
• Uso directo del instrumento contando con acceso al ordenador en el momento de la evaluación (y sin necesidad de instalar ningún programa)
• Computo directo de los resultados y estimación de valores muestrales (en caso de baremos simple)
• Posibilidad de almacenamiento informatizado y directo tras la aplicación de la prueba.

Como principal limitación, la ausencia de mecanismos de automatización del análisis sobre la que basar la elaboración de un informe-base. En el caso concreto de este test se hace notar especialmente por la ausencia de análisis de resultados parciales, ya que, teniendo en cuenta la estructura de la propia prueba, en su diseño está implícito un uso directo para definir procesos de intervención de apoyo en el ámbito de la logopedia clínica.

Documento:

• Test PSL

Nota:

(1) Jiménez y Ortiz (1998) Prueba de segmentación lingüística (PSL)

Usos. Datos.

 Calc. Funciones propias (3). Números

Calc dispone de dos funciones para controlar si un dato es numérico o no lo es.  Estas funciones son ESNUMERO() y N(). La primera función devuelve VERDADERO si un dato es numérico y FALSO si no lo es.

Los datos numéricos que lo parecen, pero que no lo son, son los que resultan de escribir números como palabras, como, ñor ejemplo, cuando escribimos un numero dentro de una cadena ('"tengo 24 años"), pero también cuando utilizamos controles de formulario como Cuadro de texto para introducir datos numéricos y los asociamos a celdas.

Cuando usamos estos controles de formulario como forma de entrada de datos y asociamos la entrada a una celda, si en el cuadro de texto escribimos un texto no se produce ningún problema, pero si escribimos números, el resultado esperado puede no corresponderse con lo que obtenemos, presentando un comportamiento irregular.

• Si aplicamos la función ESNUMERO() a esa celda, nos devolverá FALSO, 
• pero si en otra celda recogemos el resultado de aplicar un operador aritmético al valor de la celda asociada al control, la función ESNUMERO() devuelve VERDADERO.
• Ahora bien, si ese dato está incluido en un conjunto de datos, unos numéricos y otros string, y aplicamos funciones que suponen trabajar con el conjunto, como SUMA(), PROMEDIO() y otras, ESNUMERO() devuelve VERDADERO, pero el cálculo excluye los valores no numéricos.

Lo que sucede en estos casos es que las citadas funciones (SUMA() y PROMEDIO()) realizan los cálculos respectivos sobre el conjunto de datos que sí son número sin tomar en cuenta los valores que se presentan como tales pero que no los son, como es el caso de los que proceden de los controles del formulario.

Si utilizamos controles de formulario como recurso de entrada de datos en sustitución de la entrada directa en celdas, y mediante funciones específicas trasladamos sistemáticamente estos valores a una tabla sobre la que realizamos cálculos, no es difícil imaginar el efecto que el comportamiento observado anteriormente va a tener en los resultados que obtengamos de tales cálculos. 

En estos caso, para evitar estos errores sugiero recurrir a multiplicar el valor original por 1 (D2*1), lo que convierte el dato en un número reconocido como tal por ESNUMERO() y por las funciones de cálculo del conjunto, como SUMA() y PROMEDIO().

Calc dispone de la función N(), que transforma un carácter en número, pero que puede ser que devuelva 0, convertido eso sí, en un valor numérico, tal y como revela ESNUMERO(), por lo que altera obviamente, nuestro cálculo.

Opinión. Sobre evaluación.

Hoja de cálculo y evaluación

Hablé en una [entrada anterior] sobre la escasa pero relevante presencia en los expedientes SEO de soportes informatizados de pruebas de evaluación y analicé el uso de documentos pfd como resultado de la aplicación de bases de datos y de hojas de cálculo como documentos-soporte para la recogida y el análisis de información. En esa misma entrada comenté la conveniencia de profundizar en este segundo tipo de documentos, quedando pendiente para una entrada posterior. Esta es esa entrada.

La idea es complementar el trabajo iniciado en su momento analizando la forma en que se han presentado "históricamente" estos soportes basados en hojas de cálculo (Hc), ya que el uso de bases de datos (BD) exigiría salirse ampliamente de la temáticas de este (y otros) blog, puesto que los documentos pdf no son otra cosa que la finalización de un complejo proceso de elaboración que involucra un servicio complejo específico, ajeno a Libre Office: File Maker.

Digo "históricamente" porque en efecto, esta estrategia tiene ya su historia (1) y conocerla es útil para comprender el camino recorrido y el punto en que se encuentra en la actualidad. Por situarnos por aproximación, constan recopilados instrumentos basados en hoja de cálculo fechados en 2014, y a partir de este año abundan los fechados en los años que siguen a 2014. Ni siquiera puedo confirmar que no tenga versiones anteriores a 2014, pero en su caso se trataría de recursos escasos y básicos (2)

Decir lo anterior es mostrar una excepción a la regla: son pocos los OE que utilizamos hojas de cálculo con fines de registro de actuaciones de algún tipo, y menos aun como recurso para el trabajo con medios de evaluación. De hecho, en los expedientes consultados todas las hojas de cálculo que encontré eran exclusivamente producto de mi propia actuación (3)

Tampoco hay que echar las campanas al vuelo, ya que tampoco yo es que me haya extendido especialmente en el uso de este tipo de soporte. Y para ejemplo el escaso (pero significativo) número de las encontradas en los expedientes.

¿Cuáles son las causas del bajo nivel de uso de las Hc por parte de los SEO?.

Posiblemente esta pregunta no tenga una respuesta ni única ni clara, pero tal vez aporte algo el conocimiento del tipo de datos que se recogen en las Hc: fundamentalmente numéricos y listados. Los análisis numéricos son poco relevantes (4) en la intervención "normal" de los SEO, y la creación y uso de listados (que es y especialmente fue mucho más frecuente) es perfectamente asumible desde un procesador de texto (usando tablas).

Ciertamente, el contacto de los SEO con la informática, que no tuvo (ni aun tiene claramente) como objetivo la automatización de los procedimientos, fue inicialmente con el servicio procesador de texto como principal (por no decir única) herramienta informática. Esto es lógica consecuencia del contenido central de las actuaciones de los SEO: la realización de informes de diverso tipo, fundamentalmente de evaluación psicopedagógica y cumplimentar documentos exigidos por la Administración educativa.

Esta hegemonía de la creación de documentos y, por consiguiente, del procesador de texto (heredero directo de la máquina de escribir, que fue herramienta indispensable en los inicios de los SEO), deja poco margen para otros servicios. Si acaso podría resultar de utilidad el uso de hojas de cálculo para realizar análisis cuantitativos de actuaciones en los procesos de evaluación de la actuación anual (memorias de trabajo), pero aun en este ámbito tan limitado el uso de Hc fue siempre limitado (por no decir anecdótico) y un tanto "extraño" al hacer profesional (5).

Si nos fijamos ahora más específicamente en el uso de Hc como soportes para la evaluación, a los motivos anteriores hay que unir el de la irrelevancia: las editorial que publican los test ya proveen de soportes (papel) para la aplicación y recogida de datos, con lo que hacen innecesario crear soportes específicos. Posteriormente y en ciertos casos, proveyeron de sistemas automáticos de corrección y (más limitadamente) de análisis (informes básicamente descriptivos, pero informe al fin), primero como software anexo al material de test y después (en algunos casos, vuelvo a insistir) on-line.

He insistido doblemente en la excepcionalidad de los soportes informáticos que proveen las editoriales porque efectivamente lo son: excepcionales y escasos, aunque es posible que al menos algunas editoriales (TEA, por ejemplo)  hayan invertido  más en estos soportes, tanto por ayuda al profesional como por interés propio: a la editorial de aporta una información muy importante para mejorar sus propias herramientas.

En Cualquier caso, la consecuencia es que existen pocos estímulos para que un OE se dedique a "perder" un tiempo del que no dispone en la creación de un soporte que teóricamente no necesita, que no puede llegar al nivel de utilidad que le sería realmente necesario (la corrección automática) y que, por lo general, no le evita tener que realizar el análisis (aun el meramente descriptivo) "a mano", salvo que se aventure en peripecias de más hondo calado (y mucho más costosas en tiempo y esfuerzo) como el la creación de macros. Y no digamos de script.

Efectivamente no parece razonable ni ser una prioridad dedicarse a crear soportes Hc para herramientas de evaluación, salvo que exista un interés personal, no directamente profesional (cierto es que ambos pueden converger) en conocer más a fondo las herramientas informáticas y, motivados por ese interés general, nos adentremos en el mundo de la programación, aun en sus formas básicas.

Esto o que la carga de trabajo lleva a plantear la necesidad de automatizar los recursos, empezando por la elaboración de documentos y (una cosa lleva a la otra) también, por qué no, los de evaluación psicopedagógica.

Aunque sea otro ámbito (no el de la evaluación), si a los nuevos alicientes de automatización unimos los que derivan de la necesidad de desarrollar procesos de registro y análisis de la intervención más detallados, centrados en el  cumplimiento de objetivos al menos parcialmente cuantitativos, se va haciendo cada vez más necesario a los SEO manejar hojas de cálculo y, en consecuencia, conocerlas con mayor profundidad.

A ello también contribuyen las exigencias de la Administración de cumplimentar documentos en este tipo de soportes. Cierto es que esta exigencia burocrática es relativamente reciente y, sobre todo, que no aporta gran cosa en términos de automatización y/o programación (incluso puede decirse que, en cierto sentido, obra en contra de estas dinámicas), pero al menos ha visibilizado a los SEO la pertinencia de las HC como soporte documental, obligando a cierto nivel de uso  (aun muy limitado, cierto es) y, por consiguiente, de familiaridad. Y algo queda.

Algo queda que no sirve para dar pasos en dirección a la automatización, pero al menos rompe la expectativa negativa del profesional respecto a incorporar el uso del servicio como parte del bagaje profesional.

Ahora bien, otro factor que incide negativamente en la creación y uso de soportes Hc es que, si la elaboración de éstos requiere tiempo y cierto conocimiento al menos de las funciones Calc (y mucho mejor aun de la creación de macros), se reduce de forma importante la lista de posibles creadores de soportes, algo que no de da respecto a la creación de modelos documentales simples (en .doc).

Esta reducción lleva a que las limitaciones que derivan del obligado respeto a los derechos de autor frene la creación "para el mercado de colegas", y más aun la distribución de recursos de este tipo. Uno puede crearlos para sí mismo sin contravenir derechos ajenos, pero es mucho más dudoso que ciertos soportes no impliquen infracción de normativas, algo cuyas consecuencias nadie quiere encontrarse por el camino, y menos aun "por hacer un favor".

Esto hace aun más complejo recorrer el resto del camino, que además exige tratar otras cuestiones e indagar en las propias Hc y sus funcionalidades. 

A ello dedicaré la entrada que sigue. En ésta, una vez cumplido el primer objetivo y para no hacerla más extensa, hasta aquí hemos llegado.

Notas:

(1) Y también "prehistoria", pero esta está escrita con procesadores de texto: los primeros soportes documentales de recursos para la evaluación fueron creados como documentos-base en formato .doc y similares.

(2) En una revisión de tanteo he localizado herramientas basadas en Hc fechadas en 2009 y 2010. Efectivamente son pocas  y simples, pero no tanto como presuponía.

(3) Lo mismo tendría que decir respecto al uso de BD,  que serían aun más minoritarias y esto fuera posible. 

(4) Matizaré más adelante esta valoración tan tajante como incorrecta en sentido amplio y con perspectiva temporal, pero en este contexto inmediato es correcta.

NOTA 5. Digamos que los procedimientos de análisis realizados en las memorias anuales no exigían precisamente complejos cálculos ni la elaboración frecuente de gráficos estadísticos. En todo caso, el empleo de Hc para estos fines siempre fue muy reducido y simple. 

Opinión. Sobre expedientes.

Expedientes SEO. Pruebas de evaluación.

Siguiendo con el análisis de los expedientes SEO y su nivel de informatización, trato en esta entrada sobre un aspecto muy concreto del proceso de informatización: el de las pruebas de evaluación. Es este un ámbito de especial importancia para estudiar el nivel de informatización por el peso que ha tenido históricamente la evaluación en la intervención de los SEO, así como el predominio en ésta de la evaluación individualizada y el uso de test. Conocer en qué media se han informatizado este tipo de documentos es relevante para una correcta valoración del fenómeno. 

scoop.it

Retomando el análisis del proceso de revisión de expedientes ya iniciado en entradas anteriores, por lo que llevamos trabajado en la actualidad podemos decir que contamos con un volumen de expedientes revisados ya satisfactoriamente relevante, que nos permite confirmar la pertinencia del propio proceso de revisión (a continuación explico esta afirmación), además de aportar datos suficientes para la realización de análisis como el que me propongo hacer en esta entrada respecto al uso de recursos y/o soportes informáticos en la aplicación y el análisis de instrumentos de evaluación.

Decía que ha resultado pertinente realizar esta revisión (aun en proceso) de los expedientes tal y como se encontraban originalmente porque el número de documentos eliminados (por irrelevantes, impropios o duplicados) está resultando ser elevado. De hecho estos documentos representan algo más del 24% del número inicial de documentos de los expedientes revisados hasta el momento, muy cerca del límite (25%) que establecí en el diseño del proceso para considerar relevante el grado de supresión. 

De hecho esta muestra de expedientes arroja el siguiente balance respecto a supresión de documentos:

• El 36% de los expedientes se ven afectados significativamente por la supresión de documentos, luego estaba claramente sobredimensionada en ellos la presencia de documentos informatizados.
• Cerca del 48% presentan niveles de afectación de moderada o baja, lo que indica niveles aceptables de ajuste en el mantenimiento de los expedientes informatizados.
• Y en un 16% de los expedientes no ha sido necesario realizar ninguna supresión de documentos, luego se pueden considerar muy satisfactoriamente actualizados.
• No se aprecia una correlación relevante entre el tamaño inicial de los expedientes y la incidencia de la supresión de documentos, luego no se confirma que a mayor número de documentos, mayor desajuste o peor nivel de mantenimiento. Otras son posiblemente la causas, y no menos relevantes para lo que debería implicar a nivel funcionamiento del EOE como equipo de trabajo: el cambio de profesionales responsables de su mantenimiento.

Centrándonos en lo prometido, el análisis de la informatización del uso de instrumentos de evaluación, aclarar que su complementario es el uso de recursos en soporte papel, tal y como está constituido formalmente el material en su diseño original o en el que ha devenido con el paso del tiempo en función del uso de estos recursos por parte de los profesionales del SEO. Digo esto (verdad de Perogrullo) para evitar errores de interpretación: la ausencia de materiales informatizados o su escasez no implica irrelevancia del uso de test, escalas y demás formalizaciones de recursos de evaluación estandarizados en referencia a norma o una baja incidencia de la evaluación individualizada. Dicho de otro modo, lo que indica esta posible baja incidencia de informatización es el desarrollo del proceso por vías "tradicionales".

Dicho lo anterior y entrando en materia, el volumen de documentos sobre pruebas, tras la supresión de  documentos innecesarios representa en el total de los expedientes revisados el 16,5% del total de dichos documentos válidos. Dado que no se han contemplado los documentos relativos a informes y dictámenes, este porcentaje se refiere únicamente al uso de pruebas de evaluación.

Se trata de un porcentaje reducido, modesto, pero no tan bajo como el que personalmente yo había previsto (sobre el 10% como máximo) en función del peso de las hojas de cálculo en el total de los documentos de los expedientes antes de revisión (8,38%). Esta realmente moderada diferencia en relación a la previsión está relacionada con la resistencia de las hojas de cálculo a la supresión (mayor que otros tipos de documentos, especialmente los .doc, como era de esperar), pero sobre todo a la fuerte incidencia del soporte .pdf que recogen formatos de uso de pruebas de evaluación creados sobre bases de datos. También estos documentos se han mostrado resistentes a la supresión.

Efectivamente, si analizamos la contabilidad de documentos de pruebas, confirmamos que:

• Cerca del 90% lo son en .pdf u hojas de cálculo, presentando ambos porcentajes similares (46% y 43% respectivamente).
• Ni los documentos .doc ni otro tipo de documentos resultan soportes relevantes en este ámbito específico (ambos suman el 10% del total)

Aunque los datos anteriores son mejores que la previsión, no por ello muestran un nivel de informatización de pruebas realmente significativo, ya que se trata de un material que, en principio y en función de la práctica profesional, debería ser mucho más abundante (y de hecho lo es en los expedientes-papel). 

Además estos datos reflejan una realidad muy parcial y hasta cierto punto excepcional: la de un profesional especialmente interesado en crear y utilizar soportes informáticos. Más excepción aun es el uso de soportes Hc y, extremadamente excepcional la creación y uso, en algunos casos se puede considerar que sistemático, de bases de datos (BD). Es muy probable que fuera de casos como el que analizo, los expedientes sostenidos por la mayoría de los OE presenten un nivel de informatización de pruebas (y más aun de uso de BD y Hc) muy inferior al que muestra este análisis.

Otros indicios del bajo nivel de informatización lo proporciona el análisis de las pruebas afectadas por estos sistemas de trabajo. Aunque se recoge un total de 37 pruebas, sólo en 6 se puede confirmar un uso suficientemente frecuente de algún tipo de soporte (y en dos de ellas, sólo un tipo concreto: CARAS y SENA: la primera sobre BD creada por el OE y la segunda por la obligatoriedad de corrección on-line que genera informe en .pdf).

Las otras cuatro presentan un número de documentos .pdf y Hc que indican uso relativamente frecuente de soporte informático. Ambas combinan BD propias y Hc también propias con predomino alternativo de uno u otro soporte: ENFEN, PROLEC-PROESC, RIST-RIAS y WPPSI-WISC. En algunas la presencia relativamente frecuente de documentos informatizados es debido al uso de los mismos sobre partes o subtest de dichas pruebas, lo que facilita que el número se incremente respecto a lo que sería el formato normativo del test.

Soy consciente que este análisis queda inconcluso, tanto por no corresponder con el conjunto de los expedientes (para eso aun queda), por no analizar datos que sería relevantes para mejor dimensionar el nivel de informatización de los expediente (como la comparación de los datos anteriores con el total de documentos de las carpetas INFORMES) y por no indagar en la tipología de documentos .pdf y Hc que se utilizan con estos fines concretos.

Esta última cuestión sí es posible abordarla en breve (de hecho en parte ya se ha hecho, y me explicaré en su momento), pero no en esta entrada ni necesariamente tampoco en este blog. Te mantendré informado.

Python. Lenguaje.

Funciones para segmentar cadenas

Siguiendo con el interesante mundo de las cadenas en Python, después de la revisión de opciones de concatenación que hice en una entrada anterior, deseo en ésta revisar las principales funciones de que disponemos para manejar y formatear el contenido de las cadenas. La importancia de estos contenidos deriva de la propia del uso de cadenas en la automatización de documentos.

 

Enumeraré aquí las principales funciones, ejemplificando su modo de uso. Tiempo habrá de utilizarlas en la creación de un recurso concreto. 

Función len(cadena)...

... permite conocer el número de caracteres que contiene una cadena esto es, devuelve el entero de dicho valor, incluyendo los espacios en blanco que separan sus componentes en caso de estar formada por varias palabras. También se consideran como caracteres los signos de puntuación.

print(len('Hola'))        -> 4

print(len('Ho la'))       -> 5 

print(len('¡Hola!'))      -> 6

len() también evalúa variables que contienen o referencian string...

nom = 'Maria'

print(len(nom))        -> 5

... y en su uso admite concatenación con literales y variables

cad1 = 'Los verdes prados de Oviedo'

print('La cadena ' , cad1 , ' tiene ' , len(cad1), ' caracteres')

... así como diferentes procedimientos de concatenación

print(f'La cadena {cad1} tiene {len(cad1)} caracteres')

print('La cadena {} tiene {} caracteres'.format(cad1,len(cad1)))

Si len() permite identificar el número de elementos de una cadena es porque una cadena se comporta como una lista de caracteres, motivo por el que cada carácter tiene asociado un índice en el string, índice por el que es posible acceder al carácter. Así, por ejemplo, para cad1...

print(cad1[0])         -> L (primer elemento del string asignado a cad1)
print(cad1[-1])        -> o (último elemento del string asignado a cad1)

NOTA 1 -> Obsérvese  que, en orden directo, la matriz de elementos se inicia en 0 y que los índices negativos permiten acceder a los elementos de la cadena en orden inverso. 

NOTA 2 -> Esta cualidad de la cadena como lista de caracteres y el uso de funciones de formato pueden ser de gran interés para la manipulación de segmentos de cadena. Tendremos ocasión de verlo con más detalle en una entrada que complemente a esta.

Ahora ya sabemos que una cadena se puede descomponer en una lista de caracteres, que la función len() nos permite conocer cuántos son estos y que podemos acceder a cada uno de ellos solicitándolos por su índice. 

Estos conocimientos son muy interesantes y es posible darles utilidad en el desarrollo de algoritmos de automatización de documentos. Pero no son las únicas utilidades que pueden tener utilidad en este ámbito de uso... ni en otros. Me estoy refiriendo en concreto a la utilidad que pueden tener dos métodos de trabajo con los componentes de una cadena: split() y join() 

Método split()... 

... permite identificar los segmentos de una cadena, no los caracteres que la componen, sino las subcadenas en que se divide. Su sintaxis básica es la siguiente:

 cadena.split(sep,maxsplit)    donde...

• cadena es la cadena o variable string sobre la que se aplica split()
• sep es el argumento que identifica el carácter por el que se divide la cadena. Por defecto es el espacio (' ').
• mxsplit es el argumento que establece el número de veces en que deseamos dividir la cadena (o número de apariciones de sep que deseamos utilizar como referente para separar las subcadenas). Por defecto su valor es -1, que indica que deseamos utilizar todas las apariciones del carácter sep  

 Veamos algunos ejemplos utilizando cad1="Los verdes prados de Oviedo" 

divide_cadena = cad1.split()
print(divide_cadena)                  (1)  -> ['Los', 'verdes', 'prados', 'de', 'Oviedo']

 

divide_cadena = cad1.split(' ',2)
print(divide_cadena)                  (2)  -> ['Los', 'verdes', 'prados de Oviedo']

 divide_cadena = cad1.split('d',-1)

print(divide_cadena)                  (3)  -> ['Los ver', 'es' pra', 'os de Ovie', 'o']

• La formulación 'por defecto'  (1) divide la cadena en las palabras que forma la frase.
• Cuando modificamos el parámetro mxsplit (2) obtenemos un número diferentes de secuencias. Concretamente 2 divide la cadena en tres partes: las resultantes de las dos primeras apariciones de sep (' ') ['los'] y ['verdes']  y el resto de la cadena ['prados de Oviedo']
• Si utilizamos otro criterio para sep (en 3 -> 'd'), manteniendo mxsplit por defecto (-1), obtenemos segmentos identificados en función de la aparición del carácter sep

Por eso dije subcadenas y no palabras, aunque es posible que, al menos inicialmente el uso más frecuente sea el establecido por defecto, esto es: la creación de una lita de las palabras que conforman la frase.

El resultado 'normal' del método split() nos da acceso a una lista que va a sernos de mucha utillidad cuando queramos modificar el contenido de esa  lista. Utilizaremos para ello lo que sabemos respecto al manejo de listas: acceso a elementos, sustración, adición y sustitución de elementos... Pero es posible que esto sea tema para tratar en otra entrada, así que mejor completamos la actual hablando del método join()

Método join()...

... sirve para invertir los efectos del método split(), esto es, para unir los elementos diferenciados de una lista en una única cadena. Veamos cómo:

divide_cadena = cad1.split()             1-> Divide la cadena cad1 y asigna divide_cadena
unir_cadena=' '.join(divide_cadena)  2-> Une divide_cadena y asigna a unir_cadena
print(divide_cadena)                        3-> ['Los', 'verdes', 'prados', 'de', 'Oviedo']
print(unir_cadena)                           4-> Los verdes prados de Oviedo

Si en vez de 2 escribimos el método join() precedido de '__' , obtendremos en 4 el siguientes resultado: Los__verdes__prados__de__Oviedo.

Python. Lenguaje.

Datos alfanuméricos. Formateo de cadenas

No es esta la primera vez que hablo de cadenas y de las formas de concatenación disponibles en Python, pero la revisión de lo hecho y el estudio del tema me han convencido de la necesidad de tratar de nuevo esta cuestión, profundizando más en ella y analizando con cierto detalle los diferentes modos en que se planea este procedimiento de generación de código. La importancia que tiene en procesos de automatización documental justifica sobradamente que preste especial atención al tema.

Tampoco es sobre Python el único lenguaje respecto al cual trato el tema de la concatenación, ya que también dediqué alguna que otra entrada para tratar el tema tanto respecto a las funciones nativas de LibreOffice-Calc como en el lenguaje OOo Basic. De hecho, si vuelvo ahora sobre esta cuestión en Python es precisamente a consecuencia de haber trabajado sobre el mismo tema tomando como referencia el servicio LO-Calc.

Es posible que, al retomar el tema, se produzcan repeticiones de contenido que tal vez depure en una posterior revisión del conjunto de las entradas, pero que ahora sólo puedo lamentar como consecuencia lógica del paso del tiempo y de la complejidad de la temática. Te ruego disculpas, lector, por la molestia que esta repetición te pueda suponer.

Como vimos, en OOo Basic se utilizan dos formas básicas y se puede decir que intercambiables de concatenar cadenas: mediante + y & podemos concatenar tantos segmentos de texto y/o variables como deseemos, sin más límite que la extensión del párrafo que queramos crear y la inteligibilidad del código resultante, a cual, al ser un proceso repetitivo puede ser poco elegante, pero no necesariamente disfuncional o ininteligible.

Recuerdo que en su momento recomendé utilizar en OOo Basic & para concatenar string (y variables string) y reservar + para la operación de sumar, como forma de facilitar la lectura del código, pero se trata de una opción y preferencia personal, sin que exista (que yo sepa) motivación técnica específica para defender esta opción.

Vimos en una entrada anterior que en Python también podemos concatenar cadenas de forma directa mediante , y +, pero presentan limitaciones y restricciones que no se observan en OOo Basic, por lo que son fórmulas no recomendables en cuanto la combinación de cadenas adquiere cierto grado de complejidad, siendo para ello suficiente con que queramos combinar string literal con variables.

Dado que Python es un lenguaje en desarrollo, las versiones que se han ido creando con el paso del tiempo han ido incorporando soluciones diferentes y dejando atrás como obsoletas las que se mostraron limitadas, aunque no por ello dejan de estar disponibles, como pasa con los modelos básicos anteriores.

El último desarrollo en estas funcionalidades son las llamadas cadenas f, de las cuales ya te hablé en esta entrada, pero es posible que dejara por el camino procedimientos interesantes y aun vigentes que surgieron en su momento como respuesta a las demandas del procedimiento. Trataré en esta entrada de tapar estos huecos.

Todo esto es para confirmar que el tema de la concatenación de cadenas ya ha sido tratado en este blog, pero, una vez dicho, paso a indicar que, lo que sigue constituye una reformulación sistemática y ampliada de lo que esas entradas pueden haber recogido, a la vez que una continuidad y conclusión de lo explicado respecto a LibreOffice y OOo Basic en otro blog.

Así que paso a exponer paso a paso el análisis de las diferentes formas de concatenar cadenas en Python. Tomo como referencia lo que expone Alfredo Sánchez Alberca en su material on-line Aprendiendo con Alf, al que remito y del que me declaro deudor.

Expongo en primer lugar diferentes formas de uso de conectores [, y +], que son las formas equivalentes a lo que en OOo Basic son [& y +] respectivamente.

Primera formulación. Concatenación de dos literales con separación de coma (,).

print("Hola","Javier") -> Hola Javier

Segunda formulación. Concatenación de literal y variable con separación de coma (,).

nom = "Javier"

print("Hola",nom) -> Hola Javier

Tercera formulación. Concatenación de dos variables con separación de coma (,).

sal = "Hola" 

nom = "Javier"

print("Hola",nom) -> Hola Javier

Cuarta formulación. Concatenación de dos literales con separación de signo (+).

print("Hola"+"Javier") -> HolaJavier

Quinta formulación. Concatenación de literal y variable con separación de signo (+).

print("Hola"+nom) -> HolaJavier

Sexta formulación. Concatenación de dos variable con separación de signo (+).

print(sal+nom) -> HolaJavier

NOTA 1 -> Ambas fórmulas funcionan igual (salvo en determinados casos) siendo los contenidos string, con la única diferencia que el uso de coma (,) genera un espacio de separación entre los componentes, mientras que el uso del signo más (+) no lo genera. Este caso es necesario implementarlo como parte del literal o como cadena formada por un espacio (' ' o " ") y posicionada entre los demás componentes.

Séptima formulación. Concatenación de literal string y literal numeral con coma (,)

print("Número",123) -> Número 123

 Octava formulación. Concatenación de literal string y literal numeral con signo (+)

print("Número"+123) -> [TypeError: can only concatenate str (not "int") to str]

print("Número" + str(123)) -> Número 123

NOTA 2 -> Uno de los casos en los que (,) y (+) no funcionan igual es cuando queremos combinar texto y números dentro de la concatenación. En ese caso mientras que podemos hacerlo sin problemas si usamos (,) (como en Séptima), no funciona si usamos (+) (como en Octava). En ésta opción debemos convertir el número antes a string mediante la función str().

En segundo lugar vamos a explicar el uso de la primera fórmula de formateo de cadenas que se empleó en Python desde sus primeras versiones como lenguaje de programación. Se base en el uso del signo %s, siendo % el operador que hace de marcador y s la referencia a la cadena que se anexa.  %s que se sitúa necesariamente dentro de la cadena en la posición en la que se desea ubicar el segundo segmento de la cadena y se puede utilizar tantas veces como sea necesario en combinaciones complejas. En estos casos la concatenación utiliza también los signos de las configuraciones ya vistas, especialmente el signo [,]. 

Al igual que los concatenadores [, y +] presenta también varias formulaciones, que enumeraré siguiendo el orden ya establecido.

Novena formulación. Literal cadena con unión de segundo elemento (cadena).

print('Hola, me llamo %s' % 'Javier') -> Hola, me llamo Javier

Décima formulación. Literal cadena con unión de segundo elemento (número).

print('Número %s' % 123) -> Número 123 

Undécima formulación. Literal cadena con unión de variable.

nom = 'Javier'
print('Hola, me llamo %s' % nom) -> Hola, me llamo Javier 

NOTA 3 -> En los tres casos el funcionamiento el correcto y el uso y posicionamiento del %s sigue el mismo patrón (se sitúa al final del primer literal), lo es debido al tipo simple de concatenación, pero no responde a una exigencia de la sintaxis de código.

Décimo segunda formulación.  Fórmulas mixtas y complejas.

A. print('Hola %s' % nom,',buenos días') -> Hola Javier, buenos días

B. print('Hola %s','buenos días' %nom) -> TypeError: not all arguments converted during string formatting

C. print('Hola %s', buenos días', %nom) -> Hola Javier, buenos días

D. print('Hola %s' % nom,',buenos días') -> Hola Javier, buenos días

E. annos = 24
    print('Hola %s' % nombre, ', tienes %s' % annos , 'de edad (eso quisieras)') -> Hola      Javier, tienes 24 años de edad (eso quisieras)

F. print('Hola %s, tienes %s' % nom % annos, 'de edad (eso quisieras)') ->TypeError:       not enough arguments for format string

NOTA 4 -> Lo que revela esta formulación (y sus variantes) es que es posible concatenar más de una cadena (o componente, ya que también es válido para números y para variables) siempre que se respete la sintaxis de %s que obliga a:

• Posicionar el marcador en la posición requerida por la formulación deseada de la cadena resultante de la concatenación (A)
• Uso de tantos marcadores como sea necesario en función de lo deseado (C, E)
• Pero con restricción de posicionamiento: cada uso de %s debe posicionarse tras la cadena afectada (B,D) y señalar sin ambigüedad a un contenido a anexar, no admitiendo dos marcadores dentro de una subcadena ni dos referencias sucesivas (F)

A pesar de la sencillez de este procedimiento, ya podemos advertir que su utilidad supera ampliamente los recursos disponibles en OOo Basic en cuanto al manejo de cadenas. Gracias a esto es posible idear procedimientos de personalización de documentos basados en la técnica 'cloze': sobre un texto base, los contenidos a personalizar son asumidos por variables, las cuales, a su vez, son cumplimentadas por el usuario de modo interactivo mediante la función input (ver ejemplo). Y no acaban aquí las opciones.

Efectivamente, una tercera opción (o procedimiento, si se prefiere) de formateo de cadenas es el método cadena.format(valores):

• La posición de los valores en la cadena-base se identifican con {}
• Esta cadena se sitúa al inicio de la secuencia
• El texto de reemplazo va precedido de la id de a función format()
• ... y se puede hacer por posición de forma implícita o explicitando los valores posicionales...
• ... o bien utilizando la forma diccionario clave:valor

Veamos ejemplos prácticos de todo ello

Primera forma.

print('Me llamo {}, vivo en {} y estudio {} en {}'.format('Elvira','Oviedo','Veterinaria', 'León.))

-> Me llamo Elvira, vivo en Oviedo y estudio Veterinaria en León.

 Segunda forma.

print('Dame {}, el {} y los {}'.format('la llave inglesa', 'destornillador', 'alicates'))
print('Dame{2}, la {0} y el {1}'.format('llave inglesa', 'destornillador', ' los alicates'))

NOTA 5 -> Las llaves {} indican la posición de los valores de .format(). Tanto en la primera forma como en la primera línea de código de la segunda, aunque no se especifica nada dentro de las llaves, es el orden mismo en que aparecen los valores .format() el que sirve para indicar la posición que ocuparán en el texto. LO que hago con la segunda línea de código de la segunda forma es alterar ese orden indicando dentro de las llaves un número-índice, que es la posición de las entradas en .format().

El texto resultante de 2.1 será  Dame la llave inglesa, el destornillador y los alicates y el de 2.2 Dame los alicates, la llave inglesa y el destornillador.

Tercera forma. Uso de variables.

 

nombre = 'Julia'
localidad = 'Gijón'
estudios = 'Albañilería'

print('Me llamo {}, vivo en {} y estudio {}'.format(nombre,localidad,estudios))

print('Me llamo {1}, vivo en {2} y estudio {0}'.format(nombre,localidad,estudios))

NOTA 6 -> En esta tercera forma sustituimos los valores directos por variables (lo que nos permite, por cierto. modificar interactivamente el contenido) y después empleamos las variables como contenido de .format(). las dos expresiones permiten comprobar que el uso de variables no modifica las propiedades y el modo de funcionar del procedimiento.

Cuarta forma.  Clave:Valor

print('Me llamo {nom}, vivo en {local} y estudio {estud}' .format (nom=nombre, local=localidad, estud=estudios))

NOTA 7 -> Sobre la misma base de contenido que en 3, ahora en 4  expongo la forma más evolucionada del procedimiento: una clave identifica y se diferencia del valor o contenido que no es otro que el nombre de las variables. Esa clave es la que se escribe dentro de las llaves, en sustitución y como alternativa del valor-índice empleado en formas previas. La ventaja de esta fórmula es que se asocia al uso de diccionarios.

Finalmente, la cuarta opción ya ha sido específicamente tratada en una entrada de este blog, por lo que no me detendré demasiado en ella. Se trata de las llamadas cadenas f (f-string o formatos literales), que se caracterizan porque su sintaxis incluye F o f al inicio de la cadena, en literales, antes de las comillas. Veamos un ejemplo:

nom1 = 'Juana'
nom2 = 'Lucas'
print(f'Una niña llamada {nom1} juega con un niño llamado {nom2}')

print(f'{nom1}') -> Juana

NOTA 7 ->  f-string y .format() son incompatibles, esto es: no se pueden usar en la misma concatenación. En el ejemplo anterior, tercera línea, tanto si eliminamos f como si añadimos format() para identificar la segunda variable o cualquier otra, se produce un funcionamiento anómalo.  Obsérvese en la cuarta línea cómo se utiliza f-string cuando iniciamos la cadena con una variable: necesitamos incluirla en una cadena literal, esto es: dentro de comillas (' '/" ") e identificada como tal variable entre llaves. Cualquier otra sintaxis provoca error o respuesta no deseada.

Contamos aun con una última forma de concatenar variables con cadenas, aunque esta quinta opción es en realidad una opción que podemos considerar complementaria de las anteriores, ya que no forma parte de los recursos comunes del lenguaje y precisa importar una librería específica llamada Template y las funciones asociadas a string.

 from string import Template

print(Template('Me gusta estudiar $leng').substitute(leng='Python'))

print(Template('Me gusta $accion $leng').substitute(accion='estudiar', leng='Python'))

NOTA 8 -> Puedes observar en estos dos ejemplos la sintaxis del procedimiento, en cierto modo recuerda al uso de funciones y más específicamente a .format():

1. Primero llamamos a la función Template()
2. Después incluimos dentro de cadena los marcadores, que se identifican mediante la expresión $NomVar.
3. Y finalmente, mediante la función .susbtitude(), como parámetros de ellas en, y en formato clave:valor, damos contenido a las variables.