J'ai trouvé un moyen pour copier une fonction, avec new.
Exemple :
def fff():
a=1
b=2
c=10
return a+b+c
print fff()
fa=fff
print fa()
import new
titi=new.function(fa.func_code,globals())
print titi()
Seulement, ça ne copie pas les attributs. Pour tester un peu plus, je
chercher un moyen d'adresse l'objet-fonction depuis l'intérieur (de
lui-même), sans indiquer son nom littéralement.
En gros, comment avoir un self ?
Ou, comment avoir l'équivalent de la seconde ligne :
def fff():
this=fff
sans indiquer "fff" ?
(peut-être un truc du genre __func__ ou im_func ou im_self ou
callee(javascript) )
copy.deepcopy va copier une instance (comme dans ton exemple), mais pas une fonction (et, comme on ne peut pas instancier une fonction...)
C'est d'ailleurs clairement dit, dans la doc du module copy : "This version does not copy types like module, class, function, method, stack trace, stack frame, file, socket, window, array, or any similar types. "
@+
MCI
Ce qui me confond dans ta question c'est que tu parles de fonction _et_ d'attributs (que je traduis par variable d'instance ... et donc fonction devient méthode)
Python 2.4.1 (#1, Jul 23 2005, 00:37:37) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
def toto(): ... print "toto"
...
toto.__class__ <type 'function'>
toto.__dict__ {}
toto.__dict__['aaa'] = 'aaa' toto.aaa 'aaa'
En Python, une fonction est une instance de la classe function.
OK, je suppose qu'il y a des applications ... mais là tout de suite je vois pas ...
Moi si. Combiné à un décorateur, ça peut être très utile dans un framework, ie:
class MyController(BaseController): @action(permissions="edit_object", template="object/edit.tpl") def edit(self, **params): # code here
mais bon j'utilise jamais de fonctions
Heu... Tu veux dire que tu copie-colle ton code à la place ???
Bruno Desthuilliers wrote:
Méta-MCI wrote:
'soir !
copy.deepcopy va copier une instance (comme dans ton exemple), mais pas
une
fonction (et, comme on ne peut pas instancier une fonction...)
C'est d'ailleurs clairement dit, dans la doc du module copy : "This
version does not copy types like module, class, function, method, stack
trace, stack frame, file, socket, window, array, or any similar types. "
@+
MCI
Ce qui me confond dans ta question c'est que tu parles de fonction _et_
d'attributs (que je traduis par variable d'instance ... et donc fonction
devient méthode)
Python 2.4.1 (#1, Jul 23 2005, 00:37:37)
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on
linux2
Type "help", "copyright", "credits" or "license" for more information.
def toto():
... print "toto"
...
toto.__class__
<type 'function'>
toto.__dict__
{}
toto.__dict__['aaa'] = 'aaa'
toto.aaa
'aaa'
En Python, une fonction est une instance de la classe function.
OK, je suppose qu'il y a des applications ... mais là tout de suite je vois
pas ...
Moi si. Combiné à un décorateur, ça peut être très utile dans un
framework, ie:
class MyController(BaseController):
@action(permissions="edit_object", template="object/edit.tpl")
def edit(self, **params):
# code here
mais bon j'utilise jamais de fonctions
Heu... Tu veux dire que tu copie-colle ton code à la place ???
copy.deepcopy va copier une instance (comme dans ton exemple), mais pas une fonction (et, comme on ne peut pas instancier une fonction...)
C'est d'ailleurs clairement dit, dans la doc du module copy : "This version does not copy types like module, class, function, method, stack trace, stack frame, file, socket, window, array, or any similar types. "
@+
MCI
Ce qui me confond dans ta question c'est que tu parles de fonction _et_ d'attributs (que je traduis par variable d'instance ... et donc fonction devient méthode)
Python 2.4.1 (#1, Jul 23 2005, 00:37:37) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
def toto(): ... print "toto"
...
toto.__class__ <type 'function'>
toto.__dict__ {}
toto.__dict__['aaa'] = 'aaa' toto.aaa 'aaa'
En Python, une fonction est une instance de la classe function.
OK, je suppose qu'il y a des applications ... mais là tout de suite je vois pas ...
Moi si. Combiné à un décorateur, ça peut être très utile dans un framework, ie:
class MyController(BaseController): @action(permissions="edit_object", template="object/edit.tpl") def edit(self, **params): # code here
mais bon j'utilise jamais de fonctions
Heu... Tu veux dire que tu copie-colle ton code à la place ???
Bruno Desthuilliers
Bruno Desthuilliers wrote:
mais bon j'utilise jamais de fonctions
Heu... Tu veux dire que tu copie-colle ton code à la place ???
ben oui, pareil avec les boucles: je suis payé à la ligne de code !
Ah, tu me rassures !-)
(snip)
... Non, je voulais dire que je ne code en general ... non toujours .... qu'en OO et que donc je ne crée que des méthodes dans des classes
Considérant qu'en Python, une fonction est un objet, utiliser des fonctions n'est en rien contradictoire avec l'approche 00.
copy.deepcopy fait mon affaire.
C'est pourtant une fonction ? Quoi que, c'est aussi un objet, attribut d'une instance du module copy, et accessoirement répondant au message __call__... Donc c'est bien de l'OO, ouf, on est sauvé !-)
Bruno Desthuilliers wrote:
mais bon j'utilise jamais de fonctions
Heu... Tu veux dire que tu copie-colle ton code à la place ???
ben oui, pareil avec les boucles: je suis payé à la ligne de code !
Ah, tu me rassures !-)
(snip)
... Non, je voulais dire que je ne code en general ... non toujours ....
qu'en OO et que donc je ne crée que des méthodes dans des classes
Considérant qu'en Python, une fonction est un objet, utiliser des
fonctions n'est en rien contradictoire avec l'approche 00.
copy.deepcopy fait mon affaire.
C'est pourtant une fonction ? Quoi que, c'est aussi un objet, attribut
d'une instance du module copy, et accessoirement répondant au message
__call__... Donc c'est bien de l'OO, ouf, on est sauvé !-)
Heu... Tu veux dire que tu copie-colle ton code à la place ???
ben oui, pareil avec les boucles: je suis payé à la ligne de code !
Ah, tu me rassures !-)
(snip)
... Non, je voulais dire que je ne code en general ... non toujours .... qu'en OO et que donc je ne crée que des méthodes dans des classes
Considérant qu'en Python, une fonction est un objet, utiliser des fonctions n'est en rien contradictoire avec l'approche 00.
copy.deepcopy fait mon affaire.
C'est pourtant une fonction ? Quoi que, c'est aussi un objet, attribut d'une instance du module copy, et accessoirement répondant au message __call__... Donc c'est bien de l'OO, ouf, on est sauvé !-)
Méta-MCI
Bonjour !
En Python, une fonction est une instance de la classe function.
Oui, mais ça me pose un problème : les instances de classes sont (deep)copiables. Or, les fonctions ne le sont pas. Y'a un sophisme quelque part...
@+
MCI
Bonjour !
En Python, une fonction est une instance de la classe function.
Oui, mais ça me pose un problème : les instances de classes sont
(deep)copiables. Or, les fonctions ne le sont pas.
Y'a un sophisme quelque part...
AMHA, tu devrais considérer Intercal. Bien qu'ancien, ce langage reste imbattable, pour ce qui est de le productivité en termes de lignes de codes.
Mais, attention, il faut être (très) poli !
@-salutations
Michel Claveau
Méta-MCI
Salut !
c'est bien de l'OO, ouf, on est sauvé !-)
Je suis réservé. Car : - un langage peut avoir une structure objet, sans pour autant permettre la POO (Programmation Orientée Objet) - il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue (sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self, Lisaac, Javascript, ...). Et, je ne sais pas si Erlang peut ou non être classé dans la POO (avec les objets-thread), et dans laquelle.
Et, si on continue, on risque de p... les mouches ;o)))
@-salutations
Michel Claveau
Salut !
c'est bien de l'OO, ouf, on est sauvé !-)
Je suis réservé. Car :
- un langage peut avoir une structure objet, sans pour autant permettre la
POO (Programmation Orientée Objet)
- il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue
(sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self,
Lisaac, Javascript, ...). Et, je ne sais pas si Erlang peut ou non être
classé dans la POO (avec les objets-thread), et dans laquelle.
Et, si on continue, on risque de p... les mouches ;o)))
Je suis réservé. Car : - un langage peut avoir une structure objet, sans pour autant permettre la POO (Programmation Orientée Objet) - il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue (sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self, Lisaac, Javascript, ...). Et, je ne sais pas si Erlang peut ou non être classé dans la POO (avec les objets-thread), et dans laquelle.
Et, si on continue, on risque de p... les mouches ;o)))
@-salutations
Michel Claveau
Bruno Desthuilliers
Salut !
c'est bien de l'OO, ouf, on est sauvé !-)
Je suis réservé. Car : - un langage peut avoir une structure objet, sans pour autant permettre la POO (Programmation Orientée Objet)
Oui, certes. Java, par exemple...
oops, désolé.
- il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue (sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self, Lisaac, Javascript, ...).
Et Io (si ça existe encore).
Ca ne change pas grand chose aux principes de base la POO : objets (=> identité + comportement + etat) communiquants par envois des messages. La notion de classe n'est qu'un détail d'implémentation.
Accessoirement, bien qu'ayant cette notion de "classe", Python est bien plus proche d'un langage à prototype que d'un langage à classe "traditionnel" : il est parfaitement possible d'ajouter / supprimer / remplacer des attributs (méthodes comprises) à une instance, ou à toute une classe. De ce point de vue, les "classes" Python sont très proches des prototypes de Javascript.
Et, je ne sais pas si Erlang peut ou non être classé dans la POO (avec les objets-thread), et dans laquelle.
J'aurais tendance à penser que oui. Il n'a jamais été précisé que les messages devaient être synchrones (il y a même une notation pour les messages asynchrones dans cette couennerie d'UML).
On peut aussi considérer que l'utilisation des fermetures en programmation fonctionnelle non stricte - lesquelles fermetures permettent d'"instancier" un ensemble de fonctions (comportements) partageant un jeu de données (état) particulier - relève de l'approche objet.
D'un autre côté, ne perdons pas de vue qu'en Smalltalk (qui reste la référence en matière de POO), les messages peuvent être paramétrés par des "blocs de code" - on a là un équivalents des fonctions d'ordre supérieur de la programmation fonctionnelle, laquelle notion est supportée en Python par le fait que les fonctions soient des objets (au sens OO). Bref, quoi qu'en pensent certains, il n'y pas si loin de l'approche objet à l'approche fonctionnelle...
Et, si on continue, on risque de p... les mouches ;o)))
'p...' ??? Pas 'e...' ???
Bref, si tu veux, et pour résumer, l'idée générale était que, contrairement à hg, je n'ai aucun scrupule à utiliser des fonctions quand c'est de ça que j'ai besoin !-)
Salut !
c'est bien de l'OO, ouf, on est sauvé !-)
Je suis réservé. Car :
- un langage peut avoir une structure objet, sans pour autant permettre la
POO (Programmation Orientée Objet)
Oui, certes. Java, par exemple...
oops, désolé.
- il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue
(sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self,
Lisaac, Javascript, ...).
Et Io (si ça existe encore).
Ca ne change pas grand chose aux principes de base la POO : objets (=>
identité + comportement + etat) communiquants par envois des messages.
La notion de classe n'est qu'un détail d'implémentation.
Accessoirement, bien qu'ayant cette notion de "classe", Python est bien
plus proche d'un langage à prototype que d'un langage à classe
"traditionnel" : il est parfaitement possible d'ajouter / supprimer /
remplacer des attributs (méthodes comprises) à une instance, ou à toute
une classe. De ce point de vue, les "classes" Python sont très proches
des prototypes de Javascript.
Et, je ne sais pas si Erlang peut ou non être
classé dans la POO (avec les objets-thread), et dans laquelle.
J'aurais tendance à penser que oui. Il n'a jamais été précisé que les
messages devaient être synchrones (il y a même une notation pour les
messages asynchrones dans cette couennerie d'UML).
On peut aussi considérer que l'utilisation des fermetures en
programmation fonctionnelle non stricte - lesquelles fermetures
permettent d'"instancier" un ensemble de fonctions (comportements)
partageant un jeu de données (état) particulier - relève de l'approche
objet.
D'un autre côté, ne perdons pas de vue qu'en Smalltalk (qui reste la
référence en matière de POO), les messages peuvent être paramétrés par
des "blocs de code" - on a là un équivalents des fonctions d'ordre
supérieur de la programmation fonctionnelle, laquelle notion est
supportée en Python par le fait que les fonctions soient des objets (au
sens OO). Bref, quoi qu'en pensent certains, il n'y pas si loin de
l'approche objet à l'approche fonctionnelle...
Et, si on continue, on risque de p... les mouches ;o)))
'p...' ??? Pas 'e...' ???
Bref, si tu veux, et pour résumer, l'idée générale était que,
contrairement à hg, je n'ai aucun scrupule à utiliser des fonctions
quand c'est de ça que j'ai besoin !-)
Je suis réservé. Car : - un langage peut avoir une structure objet, sans pour autant permettre la POO (Programmation Orientée Objet)
Oui, certes. Java, par exemple...
oops, désolé.
- il n'y a pas une, mais des, POO. La POO "à classes" est la plus connue (sur tout avec Python), mais il existe aussi la POO "à prototypes" (Self, Lisaac, Javascript, ...).
Et Io (si ça existe encore).
Ca ne change pas grand chose aux principes de base la POO : objets (=> identité + comportement + etat) communiquants par envois des messages. La notion de classe n'est qu'un détail d'implémentation.
Accessoirement, bien qu'ayant cette notion de "classe", Python est bien plus proche d'un langage à prototype que d'un langage à classe "traditionnel" : il est parfaitement possible d'ajouter / supprimer / remplacer des attributs (méthodes comprises) à une instance, ou à toute une classe. De ce point de vue, les "classes" Python sont très proches des prototypes de Javascript.
Et, je ne sais pas si Erlang peut ou non être classé dans la POO (avec les objets-thread), et dans laquelle.
J'aurais tendance à penser que oui. Il n'a jamais été précisé que les messages devaient être synchrones (il y a même une notation pour les messages asynchrones dans cette couennerie d'UML).
On peut aussi considérer que l'utilisation des fermetures en programmation fonctionnelle non stricte - lesquelles fermetures permettent d'"instancier" un ensemble de fonctions (comportements) partageant un jeu de données (état) particulier - relève de l'approche objet.
D'un autre côté, ne perdons pas de vue qu'en Smalltalk (qui reste la référence en matière de POO), les messages peuvent être paramétrés par des "blocs de code" - on a là un équivalents des fonctions d'ordre supérieur de la programmation fonctionnelle, laquelle notion est supportée en Python par le fait que les fonctions soient des objets (au sens OO). Bref, quoi qu'en pensent certains, il n'y pas si loin de l'approche objet à l'approche fonctionnelle...
Et, si on continue, on risque de p... les mouches ;o)))
'p...' ??? Pas 'e...' ???
Bref, si tu veux, et pour résumer, l'idée générale était que, contrairement à hg, je n'ai aucun scrupule à utiliser des fonctions quand c'est de ça que j'ai besoin !-)
