[pyar] Revisando mis picas con Python

[Roberto Bozzacchi]

También está la de encontrar un buen IDE que te solucione el tema de usar
solo un editor de texto.
SPE (Stani´s Python Editor) es un buen ejemplo.
Otro que probé pero no viene en la versión de Portable Python es usar
NetBeans.

Cualquiera de estos IDE no solo te marcan de dónde a dónde es un FOR (por
ejemplo), si no los errores de sintaxis.

Ahora, a la hora de que es o no un lenguaje typado... me molesta mucho que
siendo Python un lenguaje que se dice orientado a objeto no tenga su
correspondiente y obligatoria declaración de tipos....


El 6 de junio de 2010 23:19, Pablo Ziliani <pablo en kultroom.com> escribió:

> Julio Cesar Gazquez wrote:
>
>> No, no estoy con ánimos masoquistas... Pero sí es cierto que durante años
>> esquivé Python por cosas que no me gustaban, una la sintaxis, no es
>> simplemente que me gusten las llaves (a mi hijo también, durante 3 días no
>> pudimos salir al patio hasta la encontramos)
>>
>
> mi hijo tiene 6 días de vida y un mordillo con 10 llaves de plástico de
> todos los colores. Dios le da llaves al que no tiene dientes... quizás
> deberías conseguirle uno de estos al tuyo[1]
>
>
>  , creo que cualquiera que haya visto pegado en un foro un snippet de
>> Python destrozado, que te deja rascándote la cabeza preguntándote donde
>> termina ese for, me entenderá.
>>
>>
>
> no hay caso, a mí nunca me pasó. De hecho toda la vida me resultó más fácil
> guiarme por la indentación que por la correspondencia del número de llaves
> abiertas y cerradas. Incluso en lenguajes menos civilizados que python llego
> al extremo de confiar más en la analidad del autor con el blanco que en mi
> capacidad de reconocer pares de llaves correspondientes.
>
>  Pero no es por la identación que escribo, es por otros motivos que, si
>> bien ahora, con algo así como 1 año y medio (por lo menos) desde que empecé
>> a usar Python con alguna asiduidad, comprendo mejor el lenguaje y los
>> porqués. Otros lenguajes tienen decisiones de diseño similares, si bien en
>> una u otra forma hay demostrado algún arrepentimiento, como pasa en PHP y
>> Perl[1].
>>
>> Me explico: Me gustan las cosas bien definidas. Me gustan las
>> declaraciones de variables, si ese token aparece en una expresión es porque
>> primero dije que podía aparecer allí. Me gusta que si las variables han de
>> manejar determinado tipo de datos, esto esté explícito. Y por supuesto, me
>> gusta que cuando los primeros síntomas de demencia senil se cuelan en el
>> código, el compilador y/o intérprete no me lo deje pasar.
>>
>> Ahora, la intención no es que me recomienden programar en Pascal o en
>> Java[1] :-) Pero quiero que me digan como hace un veterano programador
>> Python para aliviar estas cosas. Dos ejemplos rápidos, el otro día quería
>> daemonizar un thread, estaba mirando la doc de Python 2.6 pero estaba usando
>> 2.5, puse
>> mithread.daemon=True
>>
>> en lugar de
>> mithread.setDaemon(True)
>>
>> y estuve un día completo hasta que me di cuenta que pasaba. Otra, por no
>> mirar bien en lugar de poner en un report de Geraldo
>> milabel.style= {'alignment':TA_RIGHT }
>>
>> puse
>>
>> milabel.alignment=TA_RIGHT
>>
>> Por supuesto, fueron errores míos, pero no es posible no cometer errores o
>> estar siempre con toda la concentración deseable. Por otra parte errores
>> como estos muchas veces son difíciles de detectar.
>> En conclusión, ¿que recomendación puede darme un Python evangelist ante
>> problemas como éstos, o ante variables mal escritas, o cualquier tipo de
>> problema adjudicable al hecho de que cualquier asignación a un atributo o
>> variable no existente en Python alegremente crea una variable o atributo
>> nuevos?
>>
>> Gracias desde ya.
>>
>> PD: Podría dar mi opinión sobre el duck typing, pero mejor no revuelvo más
>> el avispero :-P
>>
>> (...)
>>
>>
>
> Además de cosas como pylint y pyflakes, depende donde te pares podés
> agregar otro boilerplate. Te tiro algunas puntas que nunca usé pero sé que
> existen:
>
>   - unittest / test-driven development (TDD) [2] <-- empezá por acá
>   - method signature checking decorators [3]
>   - anotaciones de Python 3 + "algo" [4]
>
> Respecto de [4], Python 3 permite anotaciones OPCIONALES para las
> funciones[5], algo que imagino que eventualmente terminará portado a la rama
> 2.x (segúramente Facundo Batista podrá confirmarme o desmentirme). No sé si
> a esta altura habrá algo estándar para forzar un "modo estricto", pero no me
> sorprendería que aparezca algo de la mano de unladen swallow[6].
>
> Claro, otra opción es aumentar la dosis de cafeína, lo cual sirve para
> implementar behavior checks además de type checking :P
>
>
> [1] Sí, soy consciente de lo irritantes que son los  OT de los padres
> primerizos. Juro que intentaré controlarme.
> [2] TDD: http://openp2p.com/pub/a/python/2004/12/02/tdd_pyunit.html
> [3]
> http://code.activestate.com/recipes/426123-method-signature-checking-decorators/
> [4] http://stackoverflow.com/questions/1275646/python-3-and-static-typing
> [5] PEP 3107: http://www.python.org/dev/peps/pep-3107/
> [6] Unladen Swallow:
> http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>



-- 

Robbie Bozzacchi
Metasigno Brain
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20100607/49a579f1/attachment.html>