Comment verifier qu'une variable est de type DateTime
38 réponses
Richard
import mx.DateTime
import types
a=mx.DateTime.now()
je voudrais faire
if type(a) is types.DateTimeType:
mais DateTimeType n'existe pas dans la lib types (ce qui est surement
normal vu que mx est externe a python)
mais alors on fait comment ?
type(a) renvoit
<type 'DateTime'>
je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet... c'est pourtant une des facons de faire recomandés par l'académie ;-)
Non.
arguments ??
Quels sont les votre ?
pour faire simple. un niveau d'abstraction pllus elevé et un plus grande souplesse.
dans mon cas
try: v = un_objet_quelconque.getvalue(x, y) except AttributeError, msg: # il y a un probleme votre objet ne comporte pas ce qu'il faut. # gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type comportant la méthode getvalue de manière transparente.
dans un cas de verification de type if type(obj_quelconque) == type1 or type(obj_quelconque) == type2: #etc etc v = obj_quelconque.getvalue(x, y) else: # gestion d'erreur
dans ce cas le code est borné sur des types spécifiques, et necessitera une/des modifications en vue d'une réutilisation
quelques explications suplémentaires <URL:http://www.voidspace.org.uk/python/articles/duck_typing.shtml>
Quelle est cette académie ?
je me permet de vous conseiller la lecture des pages rose du petit Larousse quand au sens de "recommandé par l'académie" ;-))
Et non, je ne donne pas mon argumentaire avant que vous ayez étayé votre réponse.
donc ...... ?
Cordialement
Eric
PS si vous reprennez ma réponse initiale, je conseillais l'utilisation de hasattr plutôt que type ou isinstance si l'OP veut rester dans une logique proche de celle d'analyse du typage
-- JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole? La détection de collision. Si deux chameaux se téléscopent, on retransmet un kangourou. -+- JYB in <http://www.le-gnu.net> : C'est cha mot pout mot -+-
Encolpe Degoute wrote:
Encolpe Degoute wrote:
Richard wrote:
je fais pas du python pour utiliser try except pour
determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ;-)
Non.
arguments ??
Quels sont les votre ?
pour faire simple. un niveau d'abstraction pllus elevé et un plus grande
souplesse.
dans mon cas
try:
v = un_objet_quelconque.getvalue(x, y)
except AttributeError, msg:
# il y a un probleme votre objet ne comporte pas ce qu'il faut.
# gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type comportant la
méthode getvalue de manière transparente.
dans un cas de verification de type
if type(obj_quelconque) == type1 or type(obj_quelconque) == type2: #etc etc
v = obj_quelconque.getvalue(x, y)
else:
# gestion d'erreur
dans ce cas le code est borné sur des types spécifiques, et necessitera une/des
modifications en vue d'une réutilisation
quelques explications suplémentaires
<URL:http://www.voidspace.org.uk/python/articles/duck_typing.shtml>
Quelle est cette académie ?
je me permet de vous conseiller la lecture des pages rose du petit Larousse
quand au sens de "recommandé par l'académie" ;-))
Et non, je ne donne pas mon argumentaire avant que vous ayez étayé votre
réponse.
donc ...... ?
Cordialement
Eric
PS si vous reprennez ma réponse initiale, je conseillais l'utilisation de
hasattr plutôt que type ou isinstance si l'OP veut rester dans une logique
proche de celle d'analyse du typage
-- JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole? La
détection de collision. Si deux chameaux se téléscopent, on retransmet un
kangourou. -+- JYB in <http://www.le-gnu.net> : C'est cha mot pout mot -+-
je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet... c'est pourtant une des facons de faire recomandés par l'académie ;-)
Non.
arguments ??
Quels sont les votre ?
pour faire simple. un niveau d'abstraction pllus elevé et un plus grande souplesse.
dans mon cas
try: v = un_objet_quelconque.getvalue(x, y) except AttributeError, msg: # il y a un probleme votre objet ne comporte pas ce qu'il faut. # gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type comportant la méthode getvalue de manière transparente.
dans un cas de verification de type if type(obj_quelconque) == type1 or type(obj_quelconque) == type2: #etc etc v = obj_quelconque.getvalue(x, y) else: # gestion d'erreur
dans ce cas le code est borné sur des types spécifiques, et necessitera une/des modifications en vue d'une réutilisation
quelques explications suplémentaires <URL:http://www.voidspace.org.uk/python/articles/duck_typing.shtml>
Quelle est cette académie ?
je me permet de vous conseiller la lecture des pages rose du petit Larousse quand au sens de "recommandé par l'académie" ;-))
Et non, je ne donne pas mon argumentaire avant que vous ayez étayé votre réponse.
donc ...... ?
Cordialement
Eric
PS si vous reprennez ma réponse initiale, je conseillais l'utilisation de hasattr plutôt que type ou isinstance si l'OP veut rester dans une logique proche de celle d'analyse du typage
-- JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole? La détection de collision. Si deux chameaux se téléscopent, on retransmet un kangourou. -+- JYB in <http://www.le-gnu.net> : C'est cha mot pout mot -+-
Eric Jacoboni
Eric Deveaud writes:
dans mon cas
try: v = un_objet_quelconque.getvalue(x, y) except AttributeError, msg: # il y a un probleme votre objet ne comporte pas ce qu'il faut. # gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type comportant la méthode getvalue de manière transparente.
Il n'y a pas de méthode genre respond_to? en Python ?
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
Mais ce if me semble bien moins bidouillesque. -- Eric Jacoboni, ne il y a 1448474897 secondes
Eric Deveaud <edeveaud@pasteur.fr> writes:
dans mon cas
try:
v = un_objet_quelconque.getvalue(x, y)
except AttributeError, msg:
# il y a un probleme votre objet ne comporte pas ce qu'il faut.
# gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type
comportant la méthode getvalue de manière transparente.
Il n'y a pas de méthode genre respond_to? en Python ?
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
Mais ce if me semble bien moins bidouillesque.
--
Eric Jacoboni, ne il y a 1448474897 secondes
try: v = un_objet_quelconque.getvalue(x, y) except AttributeError, msg: # il y a un probleme votre objet ne comporte pas ce qu'il faut. # gestion d'erreur
le code est générique et pourra s'appliquer à n'importe quel type comportant la méthode getvalue de manière transparente.
Il n'y a pas de méthode genre respond_to? en Python ?
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
Mais ce if me semble bien moins bidouillesque. -- Eric Jacoboni, ne il y a 1448474897 secondes
Eric Deveaud
Eric Jacoboni wrote:
Eric Deveaud writes:
Il n'y a pas de méthode genre respond_to? en Python ?
hasattr
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
oui
Eric, ne quelques secondes plus tard
-- Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule. Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) -+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Eric Jacoboni wrote:
Eric Deveaud <edeveaud@pasteur.fr> writes:
Il n'y a pas de méthode genre respond_to? en Python ?
hasattr
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
oui
Eric, ne quelques secondes plus tard
--
Je vais mettre Mouse Office pour voir combien de kilomètres je parcours
entre 2 changements de scotch et nettoyage de boule. Même dans le
domaine du petit bricolage, il faut savoir rester rigoureux. :-)
-+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Il n'y a pas de méthode genre respond_to? en Python ?
hasattr
Parce que tu veux faire me semble sémantiquement égal à
if un_objet_quelconque.respond_to?(:getvalue) ...
oui
Eric, ne quelques secondes plus tard
-- Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule. Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) -+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
jean-michel bain-cornu
Eric Deveaud wrote:
je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ;-)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je préfère un if bien propre plutôt que l'idée que ça va se planter et qu'il va falloir récupérer une exception.
AMHA c'est de vouloir déterminer le type d'une variable qui n'est pas python(ique) ;-)) "si ça fait coin coin c'est un canard" Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut paraître plus facile de faire un test qu'un try parce que plus proche du raisonnement naturel humain. Et je trouve ça plus rigoureux. Exemple: si ma variable est une date: je fais mon traitement sinon je fais autre chose Plutôt que: j'essaye: mon traitement si ça se plante pour cause de mauvais type de variable: je fais autre chose En fait tout dépend de la façon de raisonner qu'on a face à un problème. A+ jm
Eric Deveaud wrote:
je fais pas du python pour utiliser try except pour determiner le type
d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ;-)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je
préfère un if bien propre plutôt que l'idée que ça va se planter et
qu'il va falloir récupérer une exception.
AMHA c'est de vouloir déterminer le type d'une variable qui n'est pas
python(ique) ;-)) "si ça fait coin coin c'est un canard"
Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut
paraître plus facile de faire un test qu'un try parce que plus proche du
raisonnement naturel humain. Et je trouve ça plus rigoureux.
Exemple:
si ma variable est une date:
je fais mon traitement
sinon
je fais autre chose
Plutôt que:
j'essaye:
mon traitement
si ça se plante pour cause de mauvais type de variable:
je fais autre chose
En fait tout dépend de la façon de raisonner qu'on a face à un problème.
A+
jm
je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ;-)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je préfère un if bien propre plutôt que l'idée que ça va se planter et qu'il va falloir récupérer une exception.
AMHA c'est de vouloir déterminer le type d'une variable qui n'est pas python(ique) ;-)) "si ça fait coin coin c'est un canard" Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut paraître plus facile de faire un test qu'un try parce que plus proche du raisonnement naturel humain. Et je trouve ça plus rigoureux. Exemple: si ma variable est une date: je fais mon traitement sinon je fais autre chose Plutôt que: j'essaye: mon traitement si ça se plante pour cause de mauvais type de variable: je fais autre chose En fait tout dépend de la façon de raisonner qu'on a face à un problème. A+ jm
stephane
Bonsoir, Eric Deveaud wrote:
Richard wrote:
mais plutôt que de vérifier le type, pourquoi pas un try/except autour de ce que tu veux faire
parce que c'est pas comme ca que j'ai envie de faire, a mon sens c'est pas clean, je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ; -)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je préfère un if bien propre plutôt que l'idée que ça va se plan ter et qu'il va falloir récupérer une exception.
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
Stéphane.
Bonsoir,
Eric Deveaud wrote:
Richard wrote:
mais plutôt que de vérifier le type, pourquoi pas un try/except
autour de ce que tu veux faire
parce que c'est pas comme ca que j'ai envie de faire, a mon sens
c'est pas clean, je fais pas du python pour utiliser try except pour
determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ; -)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je
préfère un if bien propre plutôt que l'idée que ça va se plan ter et
qu'il va falloir récupérer une exception.
D'un point de vu fonctionnel je dirais que dans votre cas les deux
solutions sont similaires. En revanche pour qui souhaite faire du Python
"convenable" et donc de "l'objet", le formalisme try/except est bien
évidement l'écriture de choix.
mais plutôt que de vérifier le type, pourquoi pas un try/except autour de ce que tu veux faire
parce que c'est pas comme ca que j'ai envie de faire, a mon sens c'est pas clean, je fais pas du python pour utiliser try except pour determiner le type d'une varible/objet...
c'est pourtant une des facons de faire recomandés par l'académie ; -)
J'avoue que moi aussi ça me gêne. Je ne sais pas pourquoi, mais je préfère un if bien propre plutôt que l'idée que ça va se plan ter et qu'il va falloir récupérer une exception.
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
Stéphane.
Eric Jacoboni
stephane writes:
En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
Je ne vois pas en quoi l'idiome "se faire pardonner au lieu de demander la permission" serait plus "objet" mais bon...
-- Eric Jacoboni, ne il y a 1448554087 secondes
stephane <stephane@stratum-ip.net> writes:
En revanche pour qui souhaite faire du
Python "convenable" et donc de "l'objet", le formalisme try/except est
bien évidement l'écriture de choix.
Je ne vois pas en quoi l'idiome "se faire pardonner au lieu de
demander la permission" serait plus "objet" mais bon...
En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
Je ne vois pas en quoi l'idiome "se faire pardonner au lieu de demander la permission" serait plus "objet" mais bon...
-- Eric Jacoboni, ne il y a 1448554087 secondes
Eric Deveaud
jean-michel bain-cornu wrote:
python(ique) ;-)) "si ça fait coin coin c'est un canard" Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut paraître plus facile de faire un test qu'un try parce que plus proche du raisonnement naturel humain. Et je trouve ça plus rigoureux.
il m'a fallu longtemps avant de d'accepter l'usage du try/ecxept et encore plus avant de l'apprecier.
En fait tout dépend de la façon de raisonner qu'on a face à un problème.
plutot de la facon d'envisager le except. une fois que l'on a admis/compris qu'une exception systematique N'EST PAS synonyme d'erreur, mais bien comme son cas l'indique une exception a la regle, on franchis un seuil.
l'exception est l'un des mecanisme de base du langage python. par exemple "l'arret" d'une boucle for est declenche par la levee d'une exception de type StopIteration
Eric
jean-michel bain-cornu wrote:
python(ique) ;-)) "si ça fait coin coin c'est un canard"
Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut
paraître plus facile de faire un test qu'un try parce que plus proche du
raisonnement naturel humain. Et je trouve ça plus rigoureux.
il m'a fallu longtemps avant de d'accepter l'usage du try/ecxept et encore plus
avant de l'apprecier.
En fait tout dépend de la façon de raisonner qu'on a face à un problème.
plutot de la facon d'envisager le except. une fois que l'on a admis/compris
qu'une exception systematique N'EST PAS synonyme d'erreur, mais bien comme son
cas l'indique une exception a la regle, on franchis un seuil.
l'exception est l'un des mecanisme de base du langage python.
par exemple "l'arret" d'une boucle for est declenche par la levee d'une
exception de type StopIteration
python(ique) ;-)) "si ça fait coin coin c'est un canard" Pas faux.
Mais en même temps, quand on a un morceau un peu compliqué, ça peut paraître plus facile de faire un test qu'un try parce que plus proche du raisonnement naturel humain. Et je trouve ça plus rigoureux.
il m'a fallu longtemps avant de d'accepter l'usage du try/ecxept et encore plus avant de l'apprecier.
En fait tout dépend de la façon de raisonner qu'on a face à un problème.
plutot de la facon d'envisager le except. une fois que l'on a admis/compris qu'une exception systematique N'EST PAS synonyme d'erreur, mais bien comme son cas l'indique une exception a la regle, on franchis un seuil.
l'exception est l'un des mecanisme de base du langage python. par exemple "l'arret" d'une boucle for est declenche par la levee d'une exception de type StopIteration
Eric
Eric Deveaud
stephane wrote:
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
l'ecriture de code en procedural (et non fonctionel... ;-)) peut de la meme manier utiliser try/except.
ceci dis je tique legerement sur, je cite faire du Python "convenable" et donc de "l'objet"
Eric ;=))
PS ne faites pas passer ce thread a mes collegues, je suis censce etre impermeable a l'objet ;-)
stephane wrote:
D'un point de vu fonctionnel je dirais que dans votre cas les deux
solutions sont similaires. En revanche pour qui souhaite faire du Python
"convenable" et donc de "l'objet", le formalisme try/except est bien
évidement l'écriture de choix.
l'ecriture de code en procedural (et non fonctionel... ;-)) peut de la meme
manier utiliser try/except.
ceci dis je tique legerement sur, je cite
faire du Python "convenable" et donc de "l'objet"
Eric ;=))
PS ne faites pas passer ce thread a mes collegues, je suis censce etre
impermeable a l'objet ;-)
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Python "convenable" et donc de "l'objet", le formalisme try/except est bien évidement l'écriture de choix.
l'ecriture de code en procedural (et non fonctionel... ;-)) peut de la meme manier utiliser try/except.
ceci dis je tique legerement sur, je cite faire du Python "convenable" et donc de "l'objet"
Eric ;=))
PS ne faites pas passer ce thread a mes collegues, je suis censce etre impermeable a l'objet ;-)
Eric Jacoboni
Eric Deveaud writes:
une fois que l'on a admis/compris qu'une exception systematique N'EST PAS synonyme d'erreur
Oui, enfin bon... "exception" et "systématique", j'ai un peu de mal à accorder ces deux mots, moi... :-)
l'exception est l'un des mecanisme de base du langage python. par exemple "l'arret" d'une boucle for est declenche par la levee d'une exception de type StopIteration
En fait, le StopIteration, c'est l'itérateur qui le lève quand il n'y à plus rien à itérer. Partant de là, il y a deux méthodes : soit on lui demande s'il a encore quelque chose à nous dire, soit on ne lui demande pas et on attend qu'il balance une exception /parce qu'on a tenté de lire un truc qui n'existe pas/ : on a donc fait une faute et il nous jette... faut pas se leurrer, c'est ça que ça veut dire.
Et, comme j'ai été formé à la vieille école, un for (un POUR) ne s'utilise que lorsque l'on connait à l'avance le nombre d'itérations. Sinon, c'est un TQ (0 à n) ou un REPETER (1 à n).
On aura compris que je préfère la première méthode : le mécanisme des exceptions, je le réserve aux situations que je ne peux pas prévoir, donc tester, et je peux toujours prévoir la fin d'une itération (on trouve le même genre de trucs avec EOF : je préfère tester l'EOF, certains s'en foutent et attendent de se prendre un EOFException ou équivalent...).
-- Eric Jacoboni, ne il y a 1448556957 secondes
Eric Deveaud <edeveaud@pasteur.fr> writes:
une fois que l'on a admis/compris
qu'une exception systematique N'EST PAS synonyme d'erreur
Oui, enfin bon... "exception" et "systématique", j'ai un peu de mal à
accorder ces deux mots, moi... :-)
l'exception est l'un des mecanisme de base du langage python.
par exemple "l'arret" d'une boucle for est declenche par la levee d'une
exception de type StopIteration
En fait, le StopIteration, c'est l'itérateur qui le lève quand il n'y
à plus rien à itérer. Partant de là, il y a deux méthodes : soit on
lui demande s'il a encore quelque chose à nous dire, soit on ne lui
demande pas et on attend qu'il balance une exception /parce qu'on a
tenté de lire un truc qui n'existe pas/ : on a donc fait une faute et
il nous jette... faut pas se leurrer, c'est ça que ça veut dire.
Et, comme j'ai été formé à la vieille école, un for (un POUR) ne
s'utilise que lorsque l'on connait à l'avance le nombre
d'itérations. Sinon, c'est un TQ (0 à n) ou un REPETER (1 à n).
On aura compris que je préfère la première méthode : le
mécanisme des exceptions, je le réserve aux situations que je ne peux
pas prévoir, donc tester, et je peux toujours prévoir la fin d'une
itération (on trouve le même genre de trucs avec EOF : je préfère
tester l'EOF, certains s'en foutent et attendent de se prendre un
EOFException ou équivalent...).
une fois que l'on a admis/compris qu'une exception systematique N'EST PAS synonyme d'erreur
Oui, enfin bon... "exception" et "systématique", j'ai un peu de mal à accorder ces deux mots, moi... :-)
l'exception est l'un des mecanisme de base du langage python. par exemple "l'arret" d'une boucle for est declenche par la levee d'une exception de type StopIteration
En fait, le StopIteration, c'est l'itérateur qui le lève quand il n'y à plus rien à itérer. Partant de là, il y a deux méthodes : soit on lui demande s'il a encore quelque chose à nous dire, soit on ne lui demande pas et on attend qu'il balance une exception /parce qu'on a tenté de lire un truc qui n'existe pas/ : on a donc fait une faute et il nous jette... faut pas se leurrer, c'est ça que ça veut dire.
Et, comme j'ai été formé à la vieille école, un for (un POUR) ne s'utilise que lorsque l'on connait à l'avance le nombre d'itérations. Sinon, c'est un TQ (0 à n) ou un REPETER (1 à n).
On aura compris que je préfère la première méthode : le mécanisme des exceptions, je le réserve aux situations que je ne peux pas prévoir, donc tester, et je peux toujours prévoir la fin d'une itération (on trouve le même genre de trucs avec EOF : je préfère tester l'EOF, certains s'en foutent et attendent de se prendre un EOFException ou équivalent...).
-- Eric Jacoboni, ne il y a 1448556957 secondes
Méta-MCI
Bonjour !
ne faites pas passer ce thread a mes collegues, je suis censce etre impermeable a l'objet ;-)
Je n'ai pas suivi le fil de cette discussion. Mais je tenais à dire que je comprend cette position. Je suis moi-même assez réservé sur la POO. Même si je l'utilise de temps en temps, j'apprécie beaucoup que Python laisse l'utilisateur libre, en offrant le choix du type de programmation.
Donc, je tique aussi sur le sous-entendu, reliant "convenable" et "objet".
@-salutations
Michel Claveau
Bonjour !
ne faites pas passer ce thread a mes collegues, je suis censce etre
impermeable a l'objet ;-)
Je n'ai pas suivi le fil de cette discussion. Mais je tenais à dire que je
comprend cette position. Je suis moi-même assez réservé sur la POO. Même si
je l'utilise de temps en temps, j'apprécie beaucoup que Python laisse
l'utilisateur libre, en offrant le choix du type de programmation.
Donc, je tique aussi sur le sous-entendu, reliant "convenable" et "objet".
ne faites pas passer ce thread a mes collegues, je suis censce etre impermeable a l'objet ;-)
Je n'ai pas suivi le fil de cette discussion. Mais je tenais à dire que je comprend cette position. Je suis moi-même assez réservé sur la POO. Même si je l'utilise de temps en temps, j'apprécie beaucoup que Python laisse l'utilisateur libre, en offrant le choix du type de programmation.
Donc, je tique aussi sur le sous-entendu, reliant "convenable" et "objet".
