gmane.org.user-groups.python.argentina

Re: Problema asignando valores a variables

Sebastian Bassi — 2008-12-04T03:41:36

2008/12/3 Manuel Kaufmann gmail.com>: .... .... No, para mi depende de que lado de la curva estes. Lo que comentas sucede cuando vas cuesta abajo.

Re: Re: cuestiones teoricas - y mini presentacion de proyecto

Ernesto Savoretti — 2008-12-04T03:33:56

El día 4 de diciembre de 2008 0:28, Gabriel Genellina public.gmane.org> escribió: ................................. Fascinante, buenísima la explicación, es más, me parece aplicable a una serie de situaciones que se dan con frecuencia en el diseño de un sistema. No debería esto quedar en alguna parte (más allá de la lista en sí) no se si el recetario, o algún howto que se pueda crear en el site de PyAr?

Re: cuestiones teoricas - y mini presentacion de proyecto

Gabriel Genellina — 2008-12-04T02:28:42

En Wed, 03 Dec 2008 22:35:02 -0200, Juan B Cabral public.gmane.org> escribió: No hay diferencia entre lambda y una funcion "normal" (aparte de que es anonima, y tiene sintaxis restringida). Tambien podrias usar una clase que defina __call__. Todo eso se chequea genericamente usando callable(basic_attack_damage); ver más abajo sobre si conviene hacerlo o no. Realmente te importa? Qué tiene de malo si fuera otra cosa, no una string? Y si la aventura transcurre en el mundo Wu-Wei donde los personajes usan su arbol genealogico como nombre? De última, siempre podes hacer self.name = str(name) al crear el objeto. 1) Primero preguntate si *realmente* te importa que los items hereden de PyCrosElement. Tal vez sólo te interese verificar que tengan cierto atributo --"name" por poner un ejemplo--, no que hereden de una clase particular. La primera condicion se chequea con hasattr(obj, "name"). La segunda, con isinstance(obj, PyCrosElement); esta condición es muchisimo mas restrictiva que la primera. (En Python la herencia se usa principalmente para heredar comportamiento, no para declarar la interfase que soporta un objeto) 2) Despues hay que preguntarse de dónde proceden esos items. Si están generados dentro mismo de tu propia aplicación/librería, deberia haber unit tests en el lugar en que se generan, donde verificas que lo que sale sea del tipo correcto. Y de ultima podrias poner un assert en el lugar en que se reciben, porque si recibis algo que no es del tipo correcto significa que hay algo mal en el flujo de tu programa. 3) Una situacion distinta es si los ítems vienen "de afuera" -- donde el "afuera" es lo que no esta bajo tu control: lo que tipea el usuario, lo que se lee desde un archivo, o --si estas desarrollando una libreria o framework-- los objetos que crea el usuario de tu libreria. Ahí sí, hay que validar lo mas pronto posible (tan pronto caen "adentro", bajo tu control). Yo uso este criterio para ver si chequeo o no: Cuando recibis un objeto y lo usas ahi al toque, usualmente no vale la pena chequear nada: simplemente lo usas, esperando que tenga los atributos y metodos que deberia tener; si no los tiene, el NameError/AttributeError/loquesea te va a decir exactamente qué es lo que anduvo mal. Pero el caso que vos estas planteando es justo el que -según mi criterio- *sí* vale la pena chequear: porque entre el momento en que recibis el objeto y lo guardas dentro de la lista, y el momento en que el personaje efectivamente lo termina usando, puede pasar un monton de tiempo y ya se perdio el contexto original, y es mucho mas dificil saber qué es lo que anduvo mal si algo falla. Es decir, supongamos que descubrís que el ítem nro. 17 de la lista es una tupla (3.25, 'Hola') en lugar de ser un PyCrosElement -- de dónde salió eso? Darse cuenta de que es un ítem que el personaje recogio del piso de una habitación 3 niveles mas arriba por ahi no es nada fácil; por eso en estos casos yo sugiero validar al momento de insertar el objeto en la lista. Y eso se podría lograr de, uhm, 3 formas: 1) usar una lista normal, pero sólo accederla a traves de metodos de quien la contiene. O sea, si las instancias de la clase Personaje tienen un atributo "mochila", le agregas metodos poner_en_mochila, quitar_de_mochila a la clase Personaje, y ahi validas. 2) usar una clase que hereda del tipo list, y le sobrecargas todos los metodos que le pueden agregar ítems: append, extend, insert, __setitem__. Ventajas: . es una verdadera lista (si es que a alguien le importa) . heredas automaticamente todo el comportamiento del tipo list Desventajas: . si te olvidas de sobrecargar algun metodo (por ejemplo __iadd__, usado por a+=b ) puede que tu invariante ya no se cumpla. 3) usar una clase que *contiene* una lista (composicion, en lugar de herencia) Ventajas: . controlas exactamente cuánto emulas del comporamiento: si no queres que se pueda hacer a+=b no escribis el __iadd__ y listo. Desventajas: . tenes que escribir todos los metodos que quieras usar, no te vienen "de arriba". Aunque si buscas por ahi podes encontrar recetas genericas. . isinstance(obj, list) es falso (si es que a alguien le importa). (uf, bueno, el make ya termino y el microondas tambien, asi que paro de escribir :) )

Re: cuestiones teoricas - y mini presentacion de proyecto

Gustavo Villada — 2008-12-04T02:23:17

Así que vos creaste CS? pues felicitaciones... un buen sistema que ya hemos usado con un par de amigos para partidas armadas en 5' ;) Gustavo

Re: Problema asignando valores a variables

Ernesto Savoretti — 2008-12-04T00:50:16

El día 3 de diciembre de 2008 15:42, Alejo Prats public.gmane.org> escribió: No, bueno, no te enojes, fue una manera risueña de plantearlo, además no es necesario vomitar, se ensucia todo, es feo, hay que gastar plata en Reliveran, no va. En el caso de tu aplicación con escribir 100 veces (no vale usar bucles) "No debo usar variables globales" y ya que estamos otras 10 veces (poquito) "No debo hacer top posting" se arregla todo.

Re: Problema asignando valores a variables

Manuel Kaufmann — 2008-12-04T00:35:36

A mi me pasa exactamente al revés. O sea, cuando veo código que escribí hace mucho me doy cuenta que antes realmente era inteligente y pensaba lo que hacía. Ahora sabré un poco más de Python pero cada vez pienso menos lo que hago. Por ejemplo, me ha pasado que he dicho: "No, mirá que buena onda como lo encaré. Nunca se me hubiera ocurrido a mí" :D o, "Por Dios, ¿En qué momento tuve tantas ganas de escribir todo esto?" o, "Qué bien que lo resolví". Todo esto, por supuesto que teniendo en cuenta los conocimientos que tenía en la época que escribí ese código. ¿Tendrá algo que ver esto con la cantidad de cervezas que se toman en las reuniones? ¿O las drogas duras?

cuestiones teoricas - y mini presentacion de proyecto

Juan B Cabral — 2008-12-04T00:35:02

Gurisada, los molesto bueno resulta que estamos haciendo un juego(tipo ogame[-1])[0] con un par de changos, como yo tengo un sistema de rol chiquito[1], me comprometí en hacer un api[2] del cual derivar para trabajar de ahi en mas. Bueno como todo juego de rol(nerrrrrd), obviamente tenemos armas.Esta la clase armas que es este bicho class PyCrosWeapon (PyCrosElement): def __init__(self, name, basic_attack_name, basic_attack_damage, basic_attack_dif, min_strengt, alternate_attack=None, alternate_attack_damage=None, alternate_attack_dif=None): pass ... las preguntas son estas: A- Si quiero que basic_attack_damage y alternate_attack_damage sean lambdas, debo verificarlo y hacer un raise de no ser así? (pros y contras) (esta pregunta también se aplica en si me fijo si el nombre es un string, o si alguien enchufa cualquier otra cosa lo dejo pasar) B- La clase personaje mas adelante tendrá un bolsillo profundo (los roleros entenderán) donde guarda sus armas, items y armaduras. Como cuerno verifico que lo que le enchufe ahi adentro es efectivamente un 'PyCrosElement'. (pregunta re boluda pero o estoy muy lelo hoy pero google no me responde) Bue creo que es es todo lo que necesito de momento links! [-1] Ogame! http://www.ogame.com.es/ [0] CodeName: SteamEnd Post Apocaliptico + steam punk http://code.google.com/p/steamend/ [1] Cros mi sistemita de rol, esta en fase de "debugueo" el texto del 2.0 en el cual se basa el api http://crossystem.sourceforge.net/ [2] pyCros https://sourceforge.net/projects/pycrossystem/

Re: Miércoles 3/12: Reunión PyAr BsAs

Gonzalo Larralde — 2008-12-03T22:55:17

Nos estamos yendo a otro lugar, todavía no definido. Quien quiera venir, que mande mail. On 02/12/2008, at 13:59, "Marcelo Alaniz" public.gmane.org> wrote:

Re: Porque elegir Python?

Roberto Alsina — 2008-12-03T19:32:48

Nonono, así es un lenguaje intérprete. O interpretante ;-)

Re: Problema asignando valores a variables

Daniel Perez — 2008-12-03T19:00:50

Hmm creo que estoy muy avanzado; yo vomito imaginando el código que *escribiré* en 6 meses.

Re: Porque elegir Python?

Facundo Batista — 2008-12-03T18:54:18

2008/12/3 Alejandro J. Cura public.gmane.org>: Python es un lenguaje interpretado, porque interpreta lo que estoy justo pensando y trabaja de esa manera... (o será que yo justo pienso de la manera que Python trabaja?... no sé, "it fits my brain"). Abrazo,

Re: [OT] performante?

Gabriel Brunacci — 2008-12-03T18:42:45

Les aseguro que me estan abriendo la cabeza con las discusiones de los ultimos tres días. Un humilde pero siempre presente espectador se esta nutriendo de las experiencias ajenas.

Re: Problema asignando valores a variables

Mariano Guerra — 2008-12-03T18:15:15

coincido, el día que vea código que escribí hace 6 meses y no le pueda mejorar algo, me voy a preocupar, ya no voy a estar aprendiendo nada ;)

Re: [OT] performante?

Julian Agustin Cardonnet — 2008-12-03T18:13:56

2008/12/3 John Rowland Lenton public.gmane.org>: Creo que una mejor traduccion seria "coincidir/coincide". Pero si bien uno de sus significados se ajusta al del verbo "to match" en gral se lo asocia a otra de sus acepciones que tiene que ver con lo fortuito o la casualidad, por eso confunde un poco y a la mayoria tampoco le gusta. Yo uso la alternativa "matchea" (del verbo inventado matchear (to match), igual que "loguear" y "resetear"). Sigue siendo una chanchada pero por lo menos el tiempo verbal esta bien. Decir "hacer matching" es sintacticamente incorrecto porque el objeto directo no puede ser un verbo. Ciertas palabras se impusieron por falta de una alternativa aceptable en el castellano, pero en el caso de "performante" ya habia una forma de decirlo clara y de uso comun. Saludos. Julian

Re: Problema asignando valores a variables

Matigro — 2008-12-03T18:02:57

2008/12/3 Alejo Prats public.gmane.org>: Si, y cuando en 3 meses, máximo, vuelvas a ver un código que hiciste y no lo reconzcas o te de picazón en la espalda... ese es el 2do paso hacia ser un verdadero desastre. :)

Re: Problema asignando valores a variables

Alejo Prats — 2008-12-03T17:51:50

ah, cuando uno dice "que pedazo de chanchada que estoy haciendo" cuenta? =P entonces estoy en camino 2008/12/3 Roberto Alsina public.gmane.org>:

Re: Problema asignando valores a variables

Roberto Alsina — 2008-12-03T17:50:39

Uno no es pro de verdad hasta que no vomita viendo código propio. Yo soy pro casi desde que aprendí a programar.

Re: Problema asignando valores a variables

Alejo Prats — 2008-12-03T17:42:39

gracias, algun dia sere pro y podre vomitar yo al ver otros codigos, pero en algun momento hay que sentarse y aprender El día 3 de diciembre de 2008 14:40, John Rowland Lenton public.gmane.org> escribió:

Re: [OT] performante?

Daniel Perez — 2008-12-03T17:41:18

2008/12/3 Enrique Martín public.gmane.org>: Lo cual dice mucho acerca de esa gente. Saludos,

Re: [OT] performante?

Lucio Torre — 2008-12-03T17:40:47

2008/12/3 Gustavo Villada public.gmane.org>: Bueno, masomenos. Obviamente, en C se puede alcanzar la performance de java siempre, cosa que no siempre es posible en java alcanzar la performance de C. Pero Java tiene cosas como el JIT y el manejador de memoria (cosas que no usamos normalmente en nuestros programas de C) que hace que en dos apps que sean traducciones masomenos literales de codigo (java y c) la de java puede ir mas rapido. No se donde encontre ese paper o comentario, pero me suena creible. Lucio.

Re: Problema asignando valores a variables

John Rowland Lenton — 2008-12-03T17:40:14

porque el menu que vos querés decir es global al módulo, mientras que el menu que asignás a la función es local a la función. Poné "global menu" en la función y debería andar. Eso, y que acabo de vomitar un poquito; es una forma muy muy asquerosa de hacer las cosas.