[pyar] [RFC] PyOpaque - soporte de atributos privados en python

[Luciano Bello]

On Wed, Jun 27, 2012 at 8:46 AM, david <tenuki en gmail.com> wrote:
> Es que es una pavada lo que digo.. es de como está armado el ejemplo... piso
> "random" con un random que funciona igual que el de python y hago que me
> muestre el mazo cada vez que se calcule uno:
> ...
> aweil en patashnik:~/tmp/bvdelft-PyOpaque-fd29f6b/examples$ cp
> /usr/lib/python2.7/random.py .
> aweil en patashnik:~/tmp/bvdelft-PyOpaque-fd29f6b/examples$ vim random.py

MMmm... entiendo. Como en todo mecanismo de seguridad, se asumen
ciertas garantías en cierto punto. En este caso se asume que el
ambiente es seguro. Tal vez con alguna forma de sandboxing. Es
parecido a la situación con el tema de los imports.

> Por eso.. lo que muestro ahí arriba, está bien, es un ejemplo trucho,
> abusando quizás de como está armado el challenge.

Bart sugirió agregar "then" en la definición del challenge. El mismo ahora es:

You are callenged to run "python -i croupier.py" and *then* find a way
to learn the content of the deck of Jack, the croupier.

> Una cosa que tiene python,
> ni hace falta que lo diga en realidad, es que es todo muy abierto, entonces
> genera muchos lugares por donde "acceder" a lo mismo. Ojo no critico que sea
> muy abierto.. me gusta que sea así.

Si. A mi también me gusta. Sin embargo es algo complicado de defender
en el mundo académico. Un lenguaje es tan expresivo como cantidad de
programas permite escribir. Sin embargo, hay programas que se pueden
escribir en haskell (tipos estáticos, puaj :P) y no en Python, como
por ejemplo, un mecanismo para enforce information flow [1]. Así que
esto es lo que motivó el trabajo práctico... hacer python más
expresivo, en algún sentido.

[1] Este paper es un ejemplo de dicho mecanismo:
http://www.cse.chalmers.se/%7Erusso/publications_files/haskell11-ext.pdf
Nuestro trabajo práctico inicial era llevar las ideas de este paper a
un lenguaje más dinámico.

> Y por eso mismo, creo, es muy interesante lo que hicieron uds. Después voy a
> probar si con import hooks se puede hacer lo mismo que hago con random, sin
> tener que copiarme el módulo random, que siempre se puede hacer pero en
> algún caso puede ser trabajoso.
> Y me gustaría entender que es lo que hace, de lo poco que ví en el código,
> el tema de los safe-imports y la black list de los mismos. Está para no
> permitir cosas como ctypes?

Como comenté, el objetivo del modulo no es controlar el acceso a los
imports (supone que de alguna forma ya está sandboxeado). La función
disableDangerousImports intenta evitar que accedas a cosas como gc
(simpático es el hecho que usa el mismo mecanismo que se usa para
evitar el acceso a objetos que se quiere segurizar).

> Saludos, y perdón que no hice antes el ejemplo, estoy medio a full con
> varias cosas, y además, también está bueno escribir.. :-)

Je.. no hay ningún problema. Si preferís, podes también abrir un issue
en github por cada agujero que encuentres y así modularizar más la
discusión, pero no creo que sea necesario :)

> Y por cierto, esto no lo mandé a pyar, porque era un challenge.... pero
> bueno :-)

Ehmm.. no entiendo esta última parte. Te estoy leyendo desde pyar:
http://listas.python.org.ar/pipermail/pyar/2012-June/018939.html

Gracias por tu tiempo! -luciano