[pyar] Bug o feature?

[Roberto Alsina]

On 2/21/2011 8:58 AM, Daniel Moisset wrote:
> 2011/2/20 Roberto Alsina<ralsina en netmanagers.com.ar>:
>> On 2/20/2011 12:31 PM, Matias Graña wrote:
>>> 2011/2/20 Roberto Alsina<ralsina en netmanagers.com.ar>:
>>>> Si se construyeran los defaults cada vez que se invocan sería trivial
>>>> creal
>>>> efectos secundarios aún más misteriosos.
>>> Muy posiblemente. Yo supongo que si
>>> *) cuando se compila la función se ponen los parámetros default en un
>>> sector de memoria inaccesible desde la función (y desde afuera), y
>>> *) cada vez que se ejecuta una función se copian (con una deep copy)
>>> estos parámetros
>>> no habría efectos secundarios.
>> El primer efecto secundario es que hay cosas que cuando les haces deepcopy
>> se cuelgan :-)
> Otro es que las funciones no deepcopian, y son mutables:
>
> In [14]: def f():pass
>     ....:
>
> In [15]: f.verbose_name = 'efe'
>
> In [16]: g = copy.deepcopy(f)
>
> In [17]: g.verbose_name = 'ge'
>
> In [18]: f.verbose_name
> Out[18]: 'ge'
Entonces, resumiendo:

* Con el status quo, se explica fácil: "No uses objetos mutables como 
defaults, a menos que sepas lo que hacés".

* Con las alternativas, probablemente terminemos con cosas como "No uses 
esto esto y esto, y no uses esto si tal cosa".

Me parece que medio termina siendo el costo de que python sea asi de 
dinámico. En lenguajes digamos "de la misma categoría" como Ruby, pasa 
lo mismo?

Ah, por supuesto que hay una alternativa obvia: siempre definir el 
default en la invocación. Sospecho que eso es un lío si, por ejemplo, el 
default tiene distintos significados por scope. Ejemplo:


x = 4

def f(y=x):
     return x*2

def g():
     x = []
     f()

f()
g()

Ahí cuando llamamos a f dentro de g, no tiene manera de saber cuanto 
vale su default x, a menos que lo haya tomado en tiempo de definicion.

Para evitar esto, los defaults tendrian que ser constantes o literales, 
pero eso es demasiado feo!