R12y wrote:On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
R12y wrote:
On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:
Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
R12y wrote:On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
R12y wrote:On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
Oui et à la première occasion, tu tombes sur une fonction qui te renvoye
un str au lieu d'un MyString par exemple et pof, plantage.
R12y wrote:
On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:
Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
Oui et à la première occasion, tu tombes sur une fonction qui te renvoye
un str au lieu d'un MyString par exemple et pof, plantage.
R12y wrote:On Mon, 12 Sep 2005 13:41:33 +0200, Jerome wrote:Je ne pense pas qu'il y ait une façon simple d'ajouter de nouvelles
methodes dans str.
class MyString(str):
Je pense que le "bordel" auquel il faisait allusion est qu'en en faisant
ça, on a des strings _et_ des MyString dans le binz...
oui mais un objet MyString est aussi une chaine classique, tu peux
l'utiliser telle quelle dans toutes les fonctions qui prennent des
chaînes en paramètres de façon transparente.
def func(s1, s2):
print s1.lower() + s2.upper()
func('begin', MyString('end'))
func('begin', 'end')
func(MyString('begin'), MyString('end'))
A partir du moment où tu sais ce que tu fais, tout est possible ;-)
Oui et à la première occasion, tu tombes sur une fonction qui te renvoye
un str au lieu d'un MyString par exemple et pof, plantage.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de partout.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de partout.
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de partout.
Christophe wrote:Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de
partout.
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir à
quoi elles servent lors d'une évolution ultérieure.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Christophe wrote:
Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de
partout.
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir à
quoi elles servent lors d'une évolution ultérieure.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Christophe wrote:Oui et à la première occasion, tu tombes sur une fonction qui te
renvoye un str au lieu d'un MyString par exemple et pof, plantage.
ben si ta fonction te retourne un str mais que tu veux un MyString tu
n'as qu'à faire un cast et tu as un MyString.
Essaye un jour de faire un projet comme ça et tu comprendras à quel
point c'est lourd pour le developeur et accessoirement pour les perfs
aussi.
En plus, le code deviens illisible avec tous ces casts inutiles de
partout.
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir à
quoi elles servent lors d'une évolution ultérieure.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir
à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer un
des types de base par une sous classe de celui-ci. Dans ce cas, il n'y a
pas de façon propre de le faire en Python pour l'instant. Si en plus
c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire comme
ça. Il suffit de définir un nouveau module contenant les fonctions
voulues et voila.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir
à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer un
des types de base par une sous classe de celui-ci. Dans ce cas, il n'y a
pas de façon propre de le faire en Python pour l'instant. Si en plus
c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire comme
ça. Il suffit de définir un nouveau module contenant les fonctions
voulues et voila.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je code tous mes projets de cette façon et pour moi c'est plus lisible
d'avoir des classes bien définies et très spécialisées plutôt que des
structures fourre-touts avec lesquelles il faut se battre pour savoir
à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer un
des types de base par une sous classe de celui-ci. Dans ce cas, il n'y a
pas de façon propre de le faire en Python pour l'instant. Si en plus
c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire comme
ça. Il suffit de définir un nouveau module contenant les fonctions
voulues et voila.
Mais c'est une question de choix perso et de préférence je te l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien. Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je code tous mes projets de cette façon et pour moi c'est plus
lisible d'avoir des classes bien définies et très spécialisées plutôt
que des structures fourre-touts avec lesquelles il faut se battre
pour savoir à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer
un des types de base par une sous classe de celui-ci. Dans ce cas, il
n'y a pas de façon propre de le faire en Python pour l'instant. Si en
plus c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire
comme ça. Il suffit de définir un nouveau module contenant les
fonctions voulues et voila.
Est-ce que tu pourrais m'expliquer comment tu voudrais faire ça de façon
"propre" ?
Pour moi il y a deux solutions :
- l'approche objet avec la dérivation de la classe str
- l'approche procédurale avec la création d'un module à coté
Les deux se valent et sont implémentables facilement en python.
Je ne connais pas de langage où tu puisses substituer un nouveau type à
un type de base comme tu voudrais le faire (je crois). Est-ce que tu as
des exemples ?
Mais c'est une question de choix perso et de préférence je te
l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien.
Pluson écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je voulais juste dire que pour ma part je suis prêt à sacrifier les
performances au profit de la lisibilité.
Je code tous mes projets de cette façon et pour moi c'est plus
lisible d'avoir des classes bien définies et très spécialisées plutôt
que des structures fourre-touts avec lesquelles il faut se battre
pour savoir à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer
un des types de base par une sous classe de celui-ci. Dans ce cas, il
n'y a pas de façon propre de le faire en Python pour l'instant. Si en
plus c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire
comme ça. Il suffit de définir un nouveau module contenant les
fonctions voulues et voila.
Est-ce que tu pourrais m'expliquer comment tu voudrais faire ça de façon
"propre" ?
Pour moi il y a deux solutions :
- l'approche objet avec la dérivation de la classe str
- l'approche procédurale avec la création d'un module à coté
Les deux se valent et sont implémentables facilement en python.
Je ne connais pas de langage où tu puisses substituer un nouveau type à
un type de base comme tu voudrais le faire (je crois). Est-ce que tu as
des exemples ?
Mais c'est une question de choix perso et de préférence je te
l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien.
Plus
on écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je voulais juste dire que pour ma part je suis prêt à sacrifier les
performances au profit de la lisibilité.
Je code tous mes projets de cette façon et pour moi c'est plus
lisible d'avoir des classes bien définies et très spécialisées plutôt
que des structures fourre-touts avec lesquelles il faut se battre
pour savoir à quoi elles servent lors d'une évolution ultérieure.
Je ne vois pas le rapport avec le cas présent. On parle de remplacer
un des types de base par une sous classe de celui-ci. Dans ce cas, il
n'y a pas de façon propre de le faire en Python pour l'instant. Si en
plus c'est pour raison aussi futile que d'ajouter quelques methodes
supplémentaires je pense que c'est une perte de temps que de faire
comme ça. Il suffit de définir un nouveau module contenant les
fonctions voulues et voila.
Est-ce que tu pourrais m'expliquer comment tu voudrais faire ça de façon
"propre" ?
Pour moi il y a deux solutions :
- l'approche objet avec la dérivation de la classe str
- l'approche procédurale avec la création d'un module à coté
Les deux se valent et sont implémentables facilement en python.
Je ne connais pas de langage où tu puisses substituer un nouveau type à
un type de base comme tu voudrais le faire (je crois). Est-ce que tu as
des exemples ?
Mais c'est une question de choix perso et de préférence je te
l'accorde.
Après pour les perfs je suis d'accord, mais on n'a rien sans rien.
Pluson écrit du code abstrait et de haut-niveau et plus les performances
vont se dégrader, au profit de l'intelligibilité du code. Soit dit en
passant, si je veux faire du code performant je fais du c ou de
l'assembleur, pas du python.
Pas daccord sur ce point. Ce genre de cast horrible poserais des
problèmes de perfs en C++ aussi. C'est juste un gros gaspillage de
ressource qui ne peut pas se justifier par le fait que l'on utilise un
langage "lent".
Je voulais juste dire que pour ma part je suis prêt à sacrifier les
performances au profit de la lisibilité.
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
J'ai été surpris que dans python 2.4, replace(), du module strig est
dans la catégorie des fonctions dépréciées. Mais il n'est indiquée
nulle part dans le chapitre la fonction qui est censée la remplacer.
Laquelle est-elle s'il vous plait?
Comme déja répondu, utilise les méthodes de la classe str sur ses instances.
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
J'ai été surpris que dans python 2.4, replace(), du module strig est
dans la catégorie des fonctions dépréciées. Mais il n'est indiquée
nulle part dans le chapitre la fonction qui est censée la remplacer.
Laquelle est-elle s'il vous plait?
Comme déja répondu, utilise les méthodes de la classe str sur ses instances.
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
J'ai été surpris que dans python 2.4, replace(), du module strig est
dans la catégorie des fonctions dépréciées. Mais il n'est indiquée
nulle part dans le chapitre la fonction qui est censée la remplacer.
Laquelle est-elle s'il vous plait?
Comme déja répondu, utilise les méthodes de la classe str sur ses instances.
Quelqu'un peut-il expliquer ce qu'est un cast en Python ?
Je rappelle qu'un cast est une "indication" au compilateur disant à peu
prés, "tu peux me faire confiance et considérer cet objet comme étant de
tel type" : ça n'a __AUCUN__ sens dans un langage dynamique. __AUCUN__
!!! Et si par la, le posteur voulait SIGNIFIER qu'on peut instancier un
objet du sous-type de str à partir de l'objet str (typiquement
aMy_str=My_str(aStr) ), ça n'a __RIEN__ à voir avec un cast. __RIEN__
!!! N'oublions pas que ce newsgroup est aussi lu par des débutants avant
d'écrire ce genre de choses ...
Faire un sous-type de str a évidemment tout son sens si on a vraiment
affaire a une sorte spécifique de str. Il faut alors réécrire certaines
méthodes pour qu'elles renvoient des instances de ce sous-type et plus
des str. Contrairement à Java (par exemple) ou ce genre d'exercice se
fait à grand coups de copier/coller et génere un code particulièrement
verbeux, Python (avec getattr par exemple) offre des outils qui
simplifient fortement ce genre de travail.
A l'inverse, si on a besoin de nouvelles fonctions sur les str, un
module est effectivement adapté.
Pour en revenir aux questions de départ:
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
Quelqu'un peut-il expliquer ce qu'est un cast en Python ?
Je rappelle qu'un cast est une "indication" au compilateur disant à peu
prés, "tu peux me faire confiance et considérer cet objet comme étant de
tel type" : ça n'a __AUCUN__ sens dans un langage dynamique. __AUCUN__
!!! Et si par la, le posteur voulait SIGNIFIER qu'on peut instancier un
objet du sous-type de str à partir de l'objet str (typiquement
aMy_str=My_str(aStr) ), ça n'a __RIEN__ à voir avec un cast. __RIEN__
!!! N'oublions pas que ce newsgroup est aussi lu par des débutants avant
d'écrire ce genre de choses ...
Faire un sous-type de str a évidemment tout son sens si on a vraiment
affaire a une sorte spécifique de str. Il faut alors réécrire certaines
méthodes pour qu'elles renvoient des instances de ce sous-type et plus
des str. Contrairement à Java (par exemple) ou ce genre d'exercice se
fait à grand coups de copier/coller et génere un code particulièrement
verbeux, Python (avec getattr par exemple) offre des outils qui
simplifient fortement ce genre de travail.
A l'inverse, si on a besoin de nouvelles fonctions sur les str, un
module est effectivement adapté.
Pour en revenir aux questions de départ:
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
Quelqu'un peut-il expliquer ce qu'est un cast en Python ?
Je rappelle qu'un cast est une "indication" au compilateur disant à peu
prés, "tu peux me faire confiance et considérer cet objet comme étant de
tel type" : ça n'a __AUCUN__ sens dans un langage dynamique. __AUCUN__
!!! Et si par la, le posteur voulait SIGNIFIER qu'on peut instancier un
objet du sous-type de str à partir de l'objet str (typiquement
aMy_str=My_str(aStr) ), ça n'a __RIEN__ à voir avec un cast. __RIEN__
!!! N'oublions pas que ce newsgroup est aussi lu par des débutants avant
d'écrire ce genre de choses ...
Faire un sous-type de str a évidemment tout son sens si on a vraiment
affaire a une sorte spécifique de str. Il faut alors réécrire certaines
méthodes pour qu'elles renvoient des instances de ce sous-type et plus
des str. Contrairement à Java (par exemple) ou ce genre d'exercice se
fait à grand coups de copier/coller et génere un code particulièrement
verbeux, Python (avec getattr par exemple) offre des outils qui
simplifient fortement ce genre de travail.
A l'inverse, si on a besoin de nouvelles fonctions sur les str, un
module est effectivement adapté.
Pour en revenir aux questions de départ:
Vaut-il mieux que je conserve le modèle en dur dans le même fichier que
le script? dans un fichier séparé? Dans la mesure ou ce script ne sera
utilisé que quand on ajoute un Vhost, c'est à dire une fois par semaine
tout au plus.
Fait au plus simple (mais écris lisiblement et commente ;-) !!!). Si ça
c'est pour raison aussi futile que d'ajouter quelques methodes
c'est pour raison aussi futile que d'ajouter quelques methodes
c'est pour raison aussi futile que d'ajouter quelques methodes