[pyar] [Consulta]Programación: constante

[Angel Java Lopez]

Ah! con respecto a:

"Y de ahí en mas, si hago ONE = 2 es error? En tiempo de compilación o de
ejecución? "

yo pondria que

ONE = 2

es un error de ejecucion, si yo tuviera que implementarlo. No conozco todas
las caracteristicas de Python para decir que el compilador podria
detectarlo en todos los casos.

Con respecto a:
"Y acá te pregunto: como creás un segundo 1 distinto de este 1 en python?
;-)
No es importante en el caso de los enteros porque son inmutables y
"fungibles", pero, con objetos en general? "

Me limito al tema del thread: por que no hay constantes en Python?
Justamente, en otros lenguajes hay constantes, pero contra elementos
inmutables, como enteros y strings, si estos lo son. Por eso, no planteo el
tema para objetos en general, solo para constantes como en otros lenguajes,
en gral: enteros y strings, que suelen ser inmutables. Me llamo la atencion
la pregunta inicial: por que no hay constantes en Python?

Agrego pregunta: hay simbolos en Python, como en Ruby? En Ruby se puede
poner :lunes, :martes, :miercoles...

Desconozco Python internamente, pero en otros lenguajes se crea un distinto
1 a cada momento que ese 1 se obtiene de distintos origenes, por ejemplo
dos registros en una base de datos, o dos entradas de consola por parte del
usuario. La implementacion interna no "se mata" viendo que el numero 123
que recien ingreso el usuario, y que convirtio a entero, YA esta en otro
lado.

Se podria usar un patron Flyweight
http://en.wikipedia.org/wiki/Flyweight_pattern

pero en general los lenguajes no lo hacen, para enteros ni para strings
(una vez lo implemente para caracteres, pero fue en los tiempos donde no
tenia Unicode ;-). Es decir, esos lenguajes no se toman el trabajo de que
todos los 1 del programa en ejecucion sean el MISMO 1 (en el mismo lugar de
memoria, digamos).

Por supuesto, al ser enteros y strings inmutables, que dos 1, o dos "isaac"
sean o no el mismo, solo tienen implicancias en el tema de manejo de
memoria.

Y ahora si, me aparto mas del thread:

En java

String name = "isaac";
String name2 = "isaac";

el compilador se toma el trabajo de hacer que name y name2 apunten al mismo
objeto "isaac", confiando en la inmutabilidad. Sospecho que lo hace HASTA
CUANDO name y name2 estan definidos en DOS archivos distintos.

Pero no lo hace si en algun momento name y name2 se llenan por ingreso
desde consola y el usuario pone dos veces "isaac". En ese caso:

name == name2 // es falso
name.equals(name2) // es verdadero

que recuerde

name.getHashCode() == name2.getHashCode()

Para que sean el MISMO string, se recurre a name.intern(), name2.intern(),
que es un resabio de los Symbol de Smalltalk (y supongo los symbol de Ruby).

En .NET, CLR en general, se tomo la decision de

name == name2 // verdadero, porque para los strings se tomo la decision de
hacerlos value objects, no importan que sean distintos objetos, importan
que tengan el mismo contenido
name.Equals(name2) // verdadero

Disculpen lo largo, y algo offtopic, pero el tema me interesa. Estoy por
implementar un interprete mini-python, y quiero conocer bien cual es su
semantica.

Gracias a Hernan, por la informacion sobre lo inmutable de los string en
Python. Curiosamente, en Ruby no lo son:
http://stackoverflow.com/questions/2608493/why-did-matz-choose-to-make-strings-mutable-by-default-in-ruby
http://stackoverflow.com/questions/93091/why-cant-strings-be-mutable-in-java-and-net

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez



2012/3/4 Roberto Alsina <ralsina en netmanagers.com.ar>

>  On 03/04/2012 07:32 PM, Angel Java Lopez wrote:
>
> Hola gente!
>
>  Ah! Interesante tema....
>
>  Hmmm... no me cierra lo de:
>
>  "Lo que no existe es la constante "con nombre" porque en python la
> asignación es en realidad creación de alias para objetos."
>
>  Se me ocurren lenguajes donde puedo tener creacion de alias, pero si los
> objetos apuntados son inmutables (como lo son los enteros y strings en
> Java, .NET, etc... (no se si son inmutables los string en Python)),
> entonces bastaria agregar "variables" writeonce (o assign-once) declarando
> algo como
>
>
> Si, los strings son inmutables en Python.
>
>
>  const ONE = 1
>
>  una "variable"/"alias"/"punterosiquierenverloasi" que se puede asignar
> una vez y solo una vez, para tener semantica de constantes.
>
>
> Y de ahí en mas, si hago ONE = 2 es error? En tiempo de compilación o de
> ejecución?
>
>
>
>  Es asi? O como es como escribe Roberto, un tema derivado de tener alias?
> O hay algo mas en Python que impide o por lo menos complica tener
> constantes?
>
>  No se si me explique bien... a ver... busco, y encuentro via Google:
> http://software-carpentry.org/4_0/python/alias/
>
>  If the data in question is immutable—i.e., if it cannot be modified in
> place—then aliasing doesn’t matter
>
>  Ahi muestra aliasing de dos nombres contra el string "isaac". Eso es lo
> que pasa en Java y en .NET. Sin embargo, ahora que lo leo, me surge una
> duda: el autor no grafica aliasing para enteros en Python (pone un arreglo
> donde cada elemento apunta a un numero 1 , "diferente", en vez de que cada
> elemento apunte al mismo 1). Eso de no tener aliasing de enteros, aparece
> hasta en implementaciones de Smalltalk, que seria el "papa de todos los
> aliasing". ;-)
>
>   Y acá te pregunto: como creás un segundo 1 distinto de este 1 en
> python? ;-)
> No es importante en el caso de los enteros porque son inmutables y
> "fungibles", pero, con objetos en general?
>
>
>
> _______________________________________________
> 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/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20120304/e37c13ae/attachment.html>