def run(k,uv):
u=uv[0]
v=uv[1]
st=["u["+str(x)+"]" for x in xrange(len(u))]
st2=[ str(sk)+"="+repr(sv) for sk,sv in v.iteritems() ]
s=",".join(st+st2)
sf="lambda(z): k("+s+")"
dic1=globals().copy()
dic1.update({'k':k ,'u':u,'v':v})
f=eval(sf,dic1,None)
return f('&')
def wait(k,*a,**b):
yield run(k,[a,b])
###############################
#Gen ne sert pas. Ce fut une fonction ou j'ai cherché des solutions a
diverse pbm
def gen(k):
a=k.func_code.co_argcount
if k.func_code.co_flags & 0x04 :
b=a+1
else :
b=a
if k.func_code.co_flags & 0x08 :
c=b+1
else :
c=b
print "nb argument : "+str(a)
print "nom des argument : "+str(k.func_code.co_varnames[0:a])
####################################"
class continuation(object):
"""
Une instance de continuation est crée par l'appel a la fonction décorer
par @lazy
l'objet attend une quelconque utilisation pour s'évaluer et renvoyer la
réponse adéquate.
"""
st=["_oo_","_calc_","_resu_"]
def __init__(self,o):
#self._oo_=o
object.__setattr__(self,'_oo_',o)
#self._calc_=False
object.__setattr__(self,'_calc_',False)
#self._resu_=None
object.__setattr__(self,'_resu_',None)
def _calcule(self) :
if not self._calc_ :
iprint("Calcule de la valeur")
a=self._oo_.next()
#self._resu_=a
object.__setattr__(self,'_resu_',a)
#self._calc_=True
object.__setattr__(self,'_calc_',True)
iprint( "fin calcule valeur")
if sys.version_info < (2, 0):
# They won't be defined if version is at least 2.0 final
def __getslice__(self, i, j):
iprint ("getslice")
self._calcule()
return self._resu_.__getslice__(i,j)
def __setslice__(self, i, j, seq):
iprint ("setslice")
self._calcule()
self._resu_.__setslice__(i,j,seq)
def __delslice__(self, i, j):
iprint ("delslice")
self._calcule()
self._resu_.__delslice__(i,j,seq)
Le premier conseil que je pourrais donner serait que tu fasses un joli schéma UML de classes ... En effet, la classe continuation me parraît "un poil" chargée. Pour que cela soit plus clair, je pense qu'il faudrait que tu essaies de redécouper cette classe ...
Je sais pas... peut être regrouper les fonctions par types ... les opérations booléennes dans un type, arithmétiques dans un autre, etc ...
Ha oui aussi rien ne vaut une bonne "commentation" du code ...
Sinon à quoi sert ce module ... enfin concrètement ?
Le premier conseil que je pourrais donner serait que tu fasses un joli
schéma UML de classes ...
En effet, la classe continuation me parraît "un poil" chargée.
Pour que cela soit plus clair, je pense qu'il faudrait que tu essaies
de redécouper cette classe ...
Je sais pas... peut être regrouper les fonctions par types ... les
opérations booléennes dans un type, arithmétiques dans un autre, etc
...
Ha oui aussi rien ne vaut une bonne "commentation" du code ...
Sinon à quoi sert ce module ... enfin concrètement ?
Le premier conseil que je pourrais donner serait que tu fasses un joli schéma UML de classes ... En effet, la classe continuation me parraît "un poil" chargée. Pour que cela soit plus clair, je pense qu'il faudrait que tu essaies de redécouper cette classe ...
Je sais pas... peut être regrouper les fonctions par types ... les opérations booléennes dans un type, arithmétiques dans un autre, etc ...
Ha oui aussi rien ne vaut une bonne "commentation" du code ...
Sinon à quoi sert ce module ... enfin concrètement ?
Do Re Mi chel La Si Do
Bonjour !
Juste un détail ; remplacer les print "xxx="+str(xxx) par des print "xxx="+repr(xxx)
L'avantage de repr(, sur str( c'est que l'on obtiens la même chose qu'un print
MCI
Bonjour !
Juste un détail ; remplacer les
print "xxx="+str(xxx)
par des
print "xxx="+repr(xxx)
L'avantage de repr(, sur str( c'est que l'on obtiens la même chose qu'un
print
Juste un détail ; remplacer les print "xxx="+str(xxx) par des print "xxx="+repr(xxx)
L'avantage de repr(, sur str( c'est que l'on obtiens la même chose qu'un print
MCI
Attention à bien faire la différence entre les deux opérateurs car l'un
convertit alors que l'autre affiche simplement tout dépend de ce que l'on veut faire. Dans ce cas il est préférable d'utiliser repr() car il s'agit d'afficher et non de convertir une donnée en une chaîne de caractère. Cependant, il faut noter que ceci existe aussi:
a = "Hello World" b = "Salut Monde" separation = " -- " print "Vos phrases: %s %s %s" % (a, separation, b)
Cette notation permet d'être très clair car le lecteur de la source saura de quel type est une variable.
YL
Bonjour !
Juste un détail ; remplacer les
print "xxx="+str(xxx)
par des
print "xxx="+repr(xxx)
L'avantage de repr(, sur str( c'est que l'on obtiens la même chose qu'un
print
MCI
Attention à bien faire la différence entre les deux opérateurs car l'un
convertit alors que l'autre affiche simplement tout dépend de ce que
l'on veut faire. Dans ce cas il est préférable d'utiliser repr() car il
s'agit d'afficher et non de convertir une donnée en une chaîne de
caractère. Cependant, il faut noter que ceci existe aussi:
a = "Hello World"
b = "Salut Monde"
separation = " -- "
print "Vos phrases: %s %s %s" % (a, separation, b)
Cette notation permet d'être très clair car le lecteur de la source
saura de quel type est une variable.
Juste un détail ; remplacer les print "xxx="+str(xxx) par des print "xxx="+repr(xxx)
L'avantage de repr(, sur str( c'est que l'on obtiens la même chose qu'un print
MCI
Attention à bien faire la différence entre les deux opérateurs car l'un
convertit alors que l'autre affiche simplement tout dépend de ce que l'on veut faire. Dans ce cas il est préférable d'utiliser repr() car il s'agit d'afficher et non de convertir une donnée en une chaîne de caractère. Cependant, il faut noter que ceci existe aussi:
a = "Hello World" b = "Salut Monde" separation = " -- " print "Vos phrases: %s %s %s" % (a, separation, b)
Cette notation permet d'être très clair car le lecteur de la source saura de quel type est une variable.
YL
Do Re Mi chel La Si Do
Bonsoir !
J'ai regardé le lien. Mais l'exemple date de Python 1.5... Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses, les décorateurs, le threading, les générateurs, les modules, etc.
@-salutations
Michel Claveau
Bonsoir !
J'ai regardé le lien. Mais l'exemple date de Python 1.5...
Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses,
les décorateurs, le threading, les générateurs, les modules, etc.
J'ai regardé le lien. Mais l'exemple date de Python 1.5... Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses, les décorateurs, le threading, les générateurs, les modules, etc.
@-salutations
Michel Claveau
Eric Brunel
On Sun, 30 Oct 2005 23:17:26 +0100, Do Re Mi chel La Si Do wrote:
Bonsoir !
J'ai regardé le lien. Mais l'exemple date de Python 1.5... Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses, les décorateurs, le threading, les générateurs, les modules, etc.
Oh là! Il n'y a meme pas besoin d'aller si loin: rien que les fonctions ne sont pas représentables.
Mais soyons quand meme honnetes: l'héritage multiple est supporté par UML (il l'est en C++ et beaucoup de concepts UML viennent du C++), de meme que le threading (ça s'appelle des classes actives). Pour tout le reste, c'est comme d'habitude: UML étant une grande auberge espagnole, tu arriveras toujours à représenter tout ce que tu veux, mais au final, tu auras un gros modèle complètement incompréhensible par quelqu'un d'autre que toi sans une grosse doc à coté, ce qui supprimera au passage le soi-disant plus gros avantage d'UML, qui est censé etre d'avoir une notation standard pour tout. Au lieu de faire un UML 2 pour permettre au vendeurs d'outils de vendre encore plus d'outils, ils feraient mieux de lever un peu le nez de leur C++ et de leur Java et de commencer à incorporer des choses venant d'autres langages... Quand on pense que meme des concepts Objective-C ou Eiffel ne sont pas représentables en UML, alors que ce sont deux langages qui sont franchement proches du C++ ou du Java, tout le buzz autour d'UML fait quand meme doucement rigoler...
Mais je m'égare. Tout ça n'a pas grand chose à voir avec Python... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65'*9--56l7+-'])"
On Sun, 30 Oct 2005 23:17:26 +0100, Do Re Mi chel La Si Do <enleverlesO.OmcO@OmclaveauO.com> wrote:
Bonsoir !
J'ai regardé le lien. Mais l'exemple date de Python 1.5...
Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses,
les décorateurs, le threading, les générateurs, les modules, etc.
Oh là! Il n'y a meme pas besoin d'aller si loin: rien que les fonctions ne sont pas représentables.
Mais soyons quand meme honnetes: l'héritage multiple est supporté par UML (il l'est en C++ et beaucoup de concepts UML viennent du C++), de meme que le threading (ça s'appelle des classes actives). Pour tout le reste, c'est comme d'habitude: UML étant une grande auberge espagnole, tu arriveras toujours à représenter tout ce que tu veux, mais au final, tu auras un gros modèle complètement incompréhensible par quelqu'un d'autre que toi sans une grosse doc à coté, ce qui supprimera au passage le soi-disant plus gros avantage d'UML, qui est censé etre d'avoir une notation standard pour tout. Au lieu de faire un UML 2 pour permettre au vendeurs d'outils de vendre encore plus d'outils, ils feraient mieux de lever un peu le nez de leur C++ et de leur Java et de commencer à incorporer des choses venant d'autres langages... Quand on pense que meme des concepts Objective-C ou Eiffel ne sont pas représentables en UML, alors que ce sont deux langages qui sont franchement proches du C++ ou du
Java, tout le buzz autour d'UML fait quand meme doucement rigoler...
Mais je m'égare. Tout ça n'a pas grand chose à voir avec Python...
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65'*9--56l7+-'])"
On Sun, 30 Oct 2005 23:17:26 +0100, Do Re Mi chel La Si Do wrote:
Bonsoir !
J'ai regardé le lien. Mais l'exemple date de Python 1.5... Je n'ai rien trouvé, pour représenter l'héritage multiple, les métaclasses, les décorateurs, le threading, les générateurs, les modules, etc.
Oh là! Il n'y a meme pas besoin d'aller si loin: rien que les fonctions ne sont pas représentables.
Mais soyons quand meme honnetes: l'héritage multiple est supporté par UML (il l'est en C++ et beaucoup de concepts UML viennent du C++), de meme que le threading (ça s'appelle des classes actives). Pour tout le reste, c'est comme d'habitude: UML étant une grande auberge espagnole, tu arriveras toujours à représenter tout ce que tu veux, mais au final, tu auras un gros modèle complètement incompréhensible par quelqu'un d'autre que toi sans une grosse doc à coté, ce qui supprimera au passage le soi-disant plus gros avantage d'UML, qui est censé etre d'avoir une notation standard pour tout. Au lieu de faire un UML 2 pour permettre au vendeurs d'outils de vendre encore plus d'outils, ils feraient mieux de lever un peu le nez de leur C++ et de leur Java et de commencer à incorporer des choses venant d'autres langages... Quand on pense que meme des concepts Objective-C ou Eiffel ne sont pas représentables en UML, alors que ce sont deux langages qui sont franchement proches du C++ ou du Java, tout le buzz autour d'UML fait quand meme doucement rigoler...
Mais je m'égare. Tout ça n'a pas grand chose à voir avec Python... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65'*9--56l7+-'])"
Do Re Mi chel La Si Do
Salut !
Je me doutais un peu du truc. Merci de m'avoir conforté dans ma réserve, vis-à-vis d'UML.
@-salutations
Michel Claveau
Salut !
Je me doutais un peu du truc. Merci de m'avoir conforté dans ma réserve,
vis-à-vis d'UML.
Je me doutais un peu du truc. Merci de m'avoir conforté dans ma réserve, vis-à-vis d'UML.
@-salutations
Michel Claveau
DAIREAUX Jean-Baptiste
Désoler pour le temps de réponse ...
L'objectif est que le calcule ne se déclanche que lorsque le résultat va étre utilisé.
La classe Continuation sert à encapsuler un calcule, elle doit doit pouvoir se comporter comme le résultat du calcule. Pour se faire j'implémente tout les opérateurs utilisable : +,-,*,/, >,<, [], appel méthode , accés au champ d'un objet , ... en fait je n'ai aucune idée du type du résultat du calcule à Continuer.
la représentation UML ne me sert à rien ici je n'ai qu'une classe et pas de relation le schema serait frustre.
Mon soucis est de rendre la fonction lazy plus propre, le fait de devoir modifier explicitement l'environnement globals me géne. Quelqu'un aurai une solution plus propre ?
def lazy(f): iprint ("appel de la lazy fonction")#iprint : un print ou rien selon mes options de débugage. a=None c="""def m"""+str(hash(f))+"""(*a,**b) : return continuation(wait(m"""+str(hash(f))+"""._k,*a,**b)) a=m"""+str(hash(f))+""" """ iprint(c) d=compile(c,'<string>','exec') exec(d) a._k=f globals().update({a.func_name:a}) return a
Désoler pour le temps de réponse ...
L'objectif est que le calcule ne se déclanche que lorsque le résultat va
étre utilisé.
La classe Continuation sert à encapsuler un calcule, elle doit doit pouvoir
se comporter comme le résultat du calcule.
Pour se faire j'implémente tout les opérateurs utilisable : +,-,*,/, >,<,
[], appel méthode , accés au champ d'un objet , ...
en fait je n'ai aucune idée du type du résultat du calcule à Continuer.
la représentation UML ne me sert à rien ici je n'ai qu'une classe et pas de
relation le schema serait frustre.
Mon soucis est de rendre la fonction lazy plus propre, le fait de devoir
modifier explicitement l'environnement globals me géne. Quelqu'un aurai une
solution plus propre ?
def lazy(f):
iprint ("appel de la lazy fonction")#iprint : un print ou rien selon mes
options de débugage.
a=None
c="""def m"""+str(hash(f))+"""(*a,**b) :
return continuation(wait(m"""+str(hash(f))+"""._k,*a,**b))
a=m"""+str(hash(f))+"""
"""
iprint(c)
d=compile(c,'<string>','exec')
exec(d)
a._k=f
globals().update({a.func_name:a})
return a
L'objectif est que le calcule ne se déclanche que lorsque le résultat va étre utilisé.
La classe Continuation sert à encapsuler un calcule, elle doit doit pouvoir se comporter comme le résultat du calcule. Pour se faire j'implémente tout les opérateurs utilisable : +,-,*,/, >,<, [], appel méthode , accés au champ d'un objet , ... en fait je n'ai aucune idée du type du résultat du calcule à Continuer.
la représentation UML ne me sert à rien ici je n'ai qu'une classe et pas de relation le schema serait frustre.
Mon soucis est de rendre la fonction lazy plus propre, le fait de devoir modifier explicitement l'environnement globals me géne. Quelqu'un aurai une solution plus propre ?
def lazy(f): iprint ("appel de la lazy fonction")#iprint : un print ou rien selon mes options de débugage. a=None c="""def m"""+str(hash(f))+"""(*a,**b) : return continuation(wait(m"""+str(hash(f))+"""._k,*a,**b)) a=m"""+str(hash(f))+""" """ iprint(c) d=compile(c,'<string>','exec') exec(d) a._k=f globals().update({a.func_name:a}) return a
Patemino
Bon je ne suis qu'à moitié d'accord sur vos réserves sur l'UML ...
En effet UML ne permet pas de modéliser toutes les subtilités des langages mais en ce qui concerne la POO, un schéma UML est très clair et relativement complet ...
Par contre quand tu dis que UML ne te servirais à rien ... parce que tu n'as qu'une classe ... Et bien pour moi c'est ça le problème ... de n'avoir q'une classe.
En ce qui concerne lazy ... ça me chagrine aussi mais j'ai pas d'idée ...
Bon je ne suis qu'à moitié d'accord sur vos réserves sur l'UML ...
En effet UML ne permet pas de modéliser toutes les subtilités des
langages mais en ce qui concerne la POO, un schéma UML est très clair
et relativement complet ...
Par contre quand tu dis que UML ne te servirais à rien ... parce que
tu n'as qu'une classe ... Et bien pour moi c'est ça le problème ...
de n'avoir q'une classe.
En ce qui concerne lazy ... ça me chagrine aussi mais j'ai pas d'idée
...
Bon je ne suis qu'à moitié d'accord sur vos réserves sur l'UML ...
En effet UML ne permet pas de modéliser toutes les subtilités des langages mais en ce qui concerne la POO, un schéma UML est très clair et relativement complet ...
Par contre quand tu dis que UML ne te servirais à rien ... parce que tu n'as qu'une classe ... Et bien pour moi c'est ça le problème ... de n'avoir q'une classe.
En ce qui concerne lazy ... ça me chagrine aussi mais j'ai pas d'idée ...