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'>
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Pyth on "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"
Il était pourtant difficile de placer plus de guillemets dans une mêm e phrase...
Je pense effectivement qu'il est plus intéressant d'utiliser Python pou r ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets. C'est une force de Python mais c'est aussi, a mon avis, passer à coté du langage. N'est-ce pas un peu dommage d'utilise r Python et se limiter à une écriture sémantique similaire à BASIC ou PHP ? D'ailleurs ses deux derniers langages ont évolués en intégrant le s mêmes concepts d'exceptions.
Je ne vois pas en quoi, comme j'ai pu le lire, la clause try/except est moins "propre" ou moins "clean" qu'une clause if/then pour un test de typage d'objet, puisqu'au final c'est de ça qu'il s'agit. Mais comme j'ai pu aussi très justement le lire, le choix est finalement conceptuel. Python est un langage OO, j'y adhère.
Par exemple, l'équivalent strict écrit avec if/then ne saura pas profiter du trans-typage dynamique.
Stéphane.
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 Pyth on
"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"
Il était pourtant difficile de placer plus de guillemets dans une mêm e
phrase...
Je pense effectivement qu'il est plus intéressant d'utiliser Python pou r
ce qu'il sait faire et apporte telle que la POO. Il est bien sur
possible de faire du code Python sans se soucier de savoir que l'on
manipule des objets. C'est une force de Python mais c'est aussi, a mon
avis, passer à coté du langage. N'est-ce pas un peu dommage d'utilise r
Python et se limiter à une écriture sémantique similaire à BASIC ou PHP
? D'ailleurs ses deux derniers langages ont évolués en intégrant le s
mêmes concepts d'exceptions.
Je ne vois pas en quoi, comme j'ai pu le lire, la clause try/except est
moins "propre" ou moins "clean" qu'une clause if/then pour un test de
typage d'objet, puisqu'au final c'est de ça qu'il s'agit. Mais comme
j'ai pu aussi très justement le lire, le choix est finalement
conceptuel. Python est un langage OO, j'y adhère.
D'un point de vu fonctionnel je dirais que dans votre cas les deux solutions sont similaires. En revanche pour qui souhaite faire du Pyth on "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"
Il était pourtant difficile de placer plus de guillemets dans une mêm e phrase...
Je pense effectivement qu'il est plus intéressant d'utiliser Python pou r ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets. C'est une force de Python mais c'est aussi, a mon avis, passer à coté du langage. N'est-ce pas un peu dommage d'utilise r Python et se limiter à une écriture sémantique similaire à BASIC ou PHP ? D'ailleurs ses deux derniers langages ont évolués en intégrant le s mêmes concepts d'exceptions.
Je ne vois pas en quoi, comme j'ai pu le lire, la clause try/except est moins "propre" ou moins "clean" qu'une clause if/then pour un test de typage d'objet, puisqu'au final c'est de ça qu'il s'agit. Mais comme j'ai pu aussi très justement le lire, le choix est finalement conceptuel. Python est un langage OO, j'y adhère.
Par exemple, l'équivalent strict écrit avec if/then ne saura pas profiter du trans-typage dynamique.
Stéphane.
Méta-MCI
Bonjour !
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec la "Programmation Orientée Objet" (POO).
Lorsque, dans Python, on programme en procédural, et sans faire de POO, on manipule aussi des objets.
Python a une bonne (excellente ?) structure-objets. Mais on peut très bien en profiter, sans utiliser la POO. Ceci dit, on peut, bien sûr, en profiter avec de la POO.
Et, ce que j'ai dit pour la programmation procédurale pourrait aussi bien s'appliquer à la programmation fonctionnelle, ou à d'autres styles (par contrat, orienté-aspect, objets à prototype, etc.)
@-salutations -- Michel Claveau
Bonjour !
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour
ce qu'il sait faire et apporte telle que la POO. Il est bien sur
possible de faire du code Python sans se soucier de savoir que l'on
manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec la
"Programmation Orientée Objet" (POO).
Lorsque, dans Python, on programme en procédural, et sans faire de POO, on
manipule aussi des objets.
Python a une bonne (excellente ?) structure-objets. Mais on peut très bien
en profiter, sans utiliser la POO.
Ceci dit, on peut, bien sûr, en profiter avec de la POO.
Et, ce que j'ai dit pour la programmation procédurale pourrait aussi bien
s'appliquer à la programmation fonctionnelle, ou à d'autres styles (par
contrat, orienté-aspect, objets à prototype, etc.)
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec la "Programmation Orientée Objet" (POO).
Lorsque, dans Python, on programme en procédural, et sans faire de POO, on manipule aussi des objets.
Python a une bonne (excellente ?) structure-objets. Mais on peut très bien en profiter, sans utiliser la POO. Ceci dit, on peut, bien sûr, en profiter avec de la POO.
Et, ce que j'ai dit pour la programmation procédurale pourrait aussi bien s'appliquer à la programmation fonctionnelle, ou à d'autres styles (par contrat, orienté-aspect, objets à prototype, etc.)
@-salutations -- Michel Claveau
stephane
Bonjour !
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec l a "Programmation Orientée Objet" (POO).
Qu'entendez vous par "structure objet' ? Parlez-vous du formalisme, de la syntaxe, ou encore de la sémantique du langage ?
Lorsque, dans Python, on programme en procédural, et sans faire de PO O, on manipule aussi des objets.
Python n'est pas un langage procédural au sens propre. Il vous le laiss e croire de part un formalisme idoine. C'est ce que j'entendais en précisant qu'il est possible "d'oublier" que l'on manipule, in fine, de s objets. C'est d'ailleurs ce qui rend Python très accessible. Mais c'est aussi, a mon sens, regarder ce fabuleux langage par le petit bout de la lorgnette.
Comparez l'écriture :
r = [ x**2 for x in echantillon ]
Avec :
r = [] for x in echantillon : r = r + [ x**2 ]
d'obédience fonctionnel qui plus est.
(...)
Cordialement,
Stéphane.
Bonjour !
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour
ce qu'il sait faire et apporte telle que la POO. Il est bien sur
possible de faire du code Python sans se soucier de savoir que l'on
manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec l a
"Programmation Orientée Objet" (POO).
Qu'entendez vous par "structure objet' ? Parlez-vous du formalisme, de
la syntaxe, ou encore de la sémantique du langage ?
Lorsque, dans Python, on programme en procédural, et sans faire de PO O, on
manipule aussi des objets.
Python n'est pas un langage procédural au sens propre. Il vous le laiss e
croire de part un formalisme idoine. C'est ce que j'entendais en
précisant qu'il est possible "d'oublier" que l'on manipule, in fine, de s
objets. C'est d'ailleurs ce qui rend Python très accessible. Mais c'est
aussi, a mon sens, regarder ce fabuleux langage par le petit bout de la
lorgnette.
Je pense effectivement qu'il est plus intéressant d'utiliser Python pour ce qu'il sait faire et apporte telle que la POO. Il est bien sur possible de faire du code Python sans se soucier de savoir que l'on manipule des objets.
Python est un langage OO
Attention, à ne pas confondre la "structure objet" du langage, avec l a "Programmation Orientée Objet" (POO).
Qu'entendez vous par "structure objet' ? Parlez-vous du formalisme, de la syntaxe, ou encore de la sémantique du langage ?
Lorsque, dans Python, on programme en procédural, et sans faire de PO O, on manipule aussi des objets.
Python n'est pas un langage procédural au sens propre. Il vous le laiss e croire de part un formalisme idoine. C'est ce que j'entendais en précisant qu'il est possible "d'oublier" que l'on manipule, in fine, de s objets. C'est d'ailleurs ce qui rend Python très accessible. Mais c'est aussi, a mon sens, regarder ce fabuleux langage par le petit bout de la lorgnette.
Par exemple, l'équivalent strict écrit avec if/then ne saura pas profiter du trans-typage dynamique.
En réalité, dans de telles situations, ce qui m'intéresse, moi, c'est que arg1 se comporte comme un int, arg2 se comporte comme un str et arg3 se comporte comme un float. Je n'ai donc que très rarement le besoin de transtyper. Là, ton code, on dirait du Java.
Par exemple, l'équivalent strict écrit avec if/then ne saura pas
profiter du trans-typage dynamique.
En réalité, dans de telles situations, ce qui m'intéresse, moi, c'est
que arg1 se comporte comme un int, arg2 se comporte comme un str et
arg3 se comporte comme un float. Je n'ai donc que très rarement le
besoin de transtyper. Là, ton code, on dirait du Java.
Par exemple, l'équivalent strict écrit avec if/then ne saura pas profiter du trans-typage dynamique.
En réalité, dans de telles situations, ce qui m'intéresse, moi, c'est que arg1 se comporte comme un int, arg2 se comporte comme un str et arg3 se comporte comme un float. Je n'ai donc que très rarement le besoin de transtyper. Là, ton code, on dirait du Java.
-- Eric Jacoboni, ne il y a 1448638416 secondes
Méta-MCI
Bonsoir !
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'est pas un langage procédural ; mais c'est un langage qui permet la programmation procédurale.
Par exemple : def addition(a,b): return(a+b) print addition(3+4)
C'est de la programmation procédurale. Qu'il y ait ou non présence/utilisation d'objets ne changera pas ce fait. Que cela soit en Python, ou dans un autre langage ne joue pas non plus.
Mais, lorsque complète avec : def ef(func,*args): return apply(func,(args))
fdition print ef(f,33,44)
On manipule de l'objet, sans faire de POO (Programmation Orientée Objet). Et, ça, pouvoir manipuler des objets, sans faire de POO, c'est un des avantages de Python.
De même qu'un des atouts de Python, c'est qu'il permet de programmer en POO, en procédural, un peu en fonctionnel (et d'autres styles aussi), sans obliger le programmeur. Et en pouvant mixer le tout.
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'est, c'est que Python permet AUSSI la POO.
@-salutations -- Michel Claveau
Bonsoir !
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'est pas un
langage procédural ; mais c'est un langage qui permet la programmation
procédurale.
Par exemple :
def addition(a,b):
return(a+b)
print addition(3+4)
C'est de la programmation procédurale. Qu'il y ait ou non
présence/utilisation d'objets ne changera pas ce fait. Que cela soit en
Python, ou dans un autre langage ne joue pas non plus.
Mais, lorsque complète avec :
def ef(func,*args):
return apply(func,(args))
fdition
print ef(f,33,44)
On manipule de l'objet, sans faire de POO (Programmation Orientée Objet).
Et, ça, pouvoir manipuler des objets, sans faire de POO, c'est un des
avantages de Python.
De même qu'un des atouts de Python, c'est qu'il permet de programmer en POO,
en procédural, un peu en fonctionnel (et d'autres styles aussi), sans
obliger le programmeur. Et en pouvant mixer le tout.
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'est,
c'est que Python permet AUSSI la POO.
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'est pas un langage procédural ; mais c'est un langage qui permet la programmation procédurale.
Par exemple : def addition(a,b): return(a+b) print addition(3+4)
C'est de la programmation procédurale. Qu'il y ait ou non présence/utilisation d'objets ne changera pas ce fait. Que cela soit en Python, ou dans un autre langage ne joue pas non plus.
Mais, lorsque complète avec : def ef(func,*args): return apply(func,(args))
fdition print ef(f,33,44)
On manipule de l'objet, sans faire de POO (Programmation Orientée Objet). Et, ça, pouvoir manipuler des objets, sans faire de POO, c'est un des avantages de Python.
De même qu'un des atouts de Python, c'est qu'il permet de programmer en POO, en procédural, un peu en fonctionnel (et d'autres styles aussi), sans obliger le programmeur. Et en pouvant mixer le tout.
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'est, c'est que Python permet AUSSI la POO.
@-salutations -- Michel Claveau
Eric Jacoboni
"Méta-MCI" writes:
AMHA, il faut quasiment créer autant de méthodes que de types d'arguments utilisés.
A confirmer, toutefois.
En fait non : il suffit de créer une seule méthode avec des paramètres de type Object. Vu que Object est la classe de base de toutes les autres, on peut donc passer des instances de n'importe quelle classe.
C'est ensuite, dans le corps de la méthode, que ça se gâte et c'était un peu le but de mon petit troll car le code Python avec les transtypages me faisait penser à ce que l'on voit souvent en Java lorsqu'il s'agit de traiter un Object : il faut le transtyper pour faire du downcasting et c'est pas beau (mais on a du mal à y couper en Java alors que je reste persuadé qu'on doit pouvoir s'en passer avec un langage dynamique).
Mais j'avoue que je ne suis ni un grand expert de Java, et encore moins de Python... Ma réflexion portait plus sur le principe : je reste un adepte de l'utilisation parcimonieuse des exceptions, comme je l'ai expliqué, et je préfère tester le comportement d'un objet plutôt que son appartenance à un type (le premier permettant notamment de s'affranchir des contraintes de l'héritage).
AMHA, il
faut quasiment créer autant de méthodes que de types d'arguments utilisés.
A confirmer, toutefois.
En fait non : il suffit de créer une seule méthode avec des paramètres
de type Object. Vu que Object est la classe de base de toutes les
autres, on peut donc passer des instances de n'importe quelle
classe.
C'est ensuite, dans le corps de la méthode, que ça se gâte et
c'était un peu le but de mon petit troll car le code Python avec les
transtypages me faisait penser à ce que l'on voit souvent en Java
lorsqu'il s'agit de traiter un Object : il faut le transtyper pour
faire du downcasting et c'est pas beau (mais on a du mal à y couper en
Java alors que je reste persuadé qu'on doit pouvoir s'en passer avec
un langage dynamique).
Mais j'avoue que je ne suis ni un grand expert de Java, et encore
moins de Python... Ma réflexion portait plus sur le principe : je
reste un adepte de l'utilisation parcimonieuse des exceptions, comme
je l'ai expliqué, et je préfère tester le comportement d'un objet
plutôt que son appartenance à un type (le premier permettant notamment
de s'affranchir des contraintes de l'héritage).
AMHA, il faut quasiment créer autant de méthodes que de types d'arguments utilisés.
A confirmer, toutefois.
En fait non : il suffit de créer une seule méthode avec des paramètres de type Object. Vu que Object est la classe de base de toutes les autres, on peut donc passer des instances de n'importe quelle classe.
C'est ensuite, dans le corps de la méthode, que ça se gâte et c'était un peu le but de mon petit troll car le code Python avec les transtypages me faisait penser à ce que l'on voit souvent en Java lorsqu'il s'agit de traiter un Object : il faut le transtyper pour faire du downcasting et c'est pas beau (mais on a du mal à y couper en Java alors que je reste persuadé qu'on doit pouvoir s'en passer avec un langage dynamique).
Mais j'avoue que je ne suis ni un grand expert de Java, et encore moins de Python... Ma réflexion portait plus sur le principe : je reste un adepte de l'utilisation parcimonieuse des exceptions, comme je l'ai expliqué, et je préfère tester le comportement d'un objet plutôt que son appartenance à un type (le premier permettant notamment de s'affranchir des contraintes de l'héritage).
-- Eric Jacoboni, ne il y a 1448669856 secondes
stephane
Bonsoir !
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'e st pas un langage procédural ; mais c'est un langage qui permet la programmatio n procédurale.
Pardonnez moi, mais c'est la seconde fois que vous ne faite que reprendre ce que je dis en coupant soigneusement mes phrases ! Est-ce que je m'exprime mal ?
(...)
C'est de la programmation procédurale. Qu'il y ait ou non présence/utilisation d'objets ne changera pas ce fait. Que cela soit en Python, ou dans un autre langage ne joue pas non plus.
Il est intéressant de lire que la "programmation procédurale" est indépendante du langage !!!
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'es t, c'est que Python permet AUSSI la POO.
"Même si le coq ne chante pas le soleil se lève" (Proverbe chinois)
Cordialement,
Stéphane.
Bonsoir !
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'e st pas un
langage procédural ; mais c'est un langage qui permet la programmatio n
procédurale.
Pardonnez moi, mais c'est la seconde fois que vous ne faite que
reprendre ce que je dis en coupant soigneusement mes phrases ! Est-ce
que je m'exprime mal ?
(...)
C'est de la programmation procédurale. Qu'il y ait ou non
présence/utilisation d'objets ne changera pas ce fait. Que cela soit en
Python, ou dans un autre langage ne joue pas non plus.
Il est intéressant de lire que la "programmation procédurale" est
indépendante du langage !!!
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'es t,
c'est que Python permet AUSSI la POO.
"Même si le coq ne chante pas le soleil se lève"
(Proverbe chinois)
Python n'est pas un langage procédural au sens propre
ça n'a pas de rapport avec la programmation procédurale. Python n'e st pas un langage procédural ; mais c'est un langage qui permet la programmatio n procédurale.
Pardonnez moi, mais c'est la seconde fois que vous ne faite que reprendre ce que je dis en coupant soigneusement mes phrases ! Est-ce que je m'exprime mal ?
(...)
C'est de la programmation procédurale. Qu'il y ait ou non présence/utilisation d'objets ne changera pas ce fait. Que cela soit en Python, ou dans un autre langage ne joue pas non plus.
Il est intéressant de lire que la "programmation procédurale" est indépendante du langage !!!
Autrement dit la POO n'est pas un avantage de Python. Mais, ce qui l'es t, c'est que Python permet AUSSI la POO.
"Même si le coq ne chante pas le soleil se lève" (Proverbe chinois)
Cordialement,
Stéphane.
Eric Deveaud
Eric Jacoboni wrote:
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... :-)
oops en effet j'aurai du me relire plus attentivement^W^W tout court
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 a du user nos culottes sur les mêmes bancs. j'essaye de faire entrer dnas la caboche de certains de mes étudiants que 90% de leur code doit servir à controler et virifier les 10% qui font vraiement des choses.
il se trouve que nous sommes en gros du même avis, prevoir plutôt que guérir, i et contrôler ce que l'on vient d'obtenir avant de continuer à la nuance que je ne diabolise (non que je t'accuse de le faire) pas le mécanisme des exceptions.
ça apporte AMHA un degré de flexibilité et une clarté du code que ne permet pas une batterie de test. mais il ne faut pas se leurrer c'est une délégation à un autre bout de code ;-)
c'est UN des choix fait par les auteurs de python.
Eric -- tenir à bout de bras un câble ethernet qui traverse une salle de restau pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en infrarouge, c'est bien la vraie vie, n'est-ce pas ? -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
Eric Jacoboni wrote:
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... :-)
oops en effet j'aurai du me relire plus attentivement^W^W tout court
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 a du user nos culottes sur les mêmes bancs.
j'essaye de faire entrer dnas la caboche de certains de mes étudiants que 90%
de leur code doit servir à controler et virifier les 10% qui font vraiement des
choses.
il se trouve que nous sommes en gros du même avis, prevoir plutôt que guérir, i
et contrôler ce que l'on vient d'obtenir avant de continuer à la nuance que je
ne diabolise (non que je t'accuse de le faire) pas le mécanisme des exceptions.
ça apporte AMHA un degré de flexibilité et une clarté du code que ne permet pas
une batterie de test. mais il ne faut pas se leurrer c'est une délégation à un
autre bout de code ;-)
c'est UN des choix fait par les auteurs de python.
Eric
--
tenir à bout de bras un câble ethernet qui traverse une salle de restau
pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en
infrarouge, c'est bien la vraie vie, n'est-ce pas ?
-+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
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... :-)
oops en effet j'aurai du me relire plus attentivement^W^W tout court
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 a du user nos culottes sur les mêmes bancs. j'essaye de faire entrer dnas la caboche de certains de mes étudiants que 90% de leur code doit servir à controler et virifier les 10% qui font vraiement des choses.
il se trouve que nous sommes en gros du même avis, prevoir plutôt que guérir, i et contrôler ce que l'on vient d'obtenir avant de continuer à la nuance que je ne diabolise (non que je t'accuse de le faire) pas le mécanisme des exceptions.
ça apporte AMHA un degré de flexibilité et une clarté du code que ne permet pas une batterie de test. mais il ne faut pas se leurrer c'est une délégation à un autre bout de code ;-)
c'est UN des choix fait par les auteurs de python.
Eric -- tenir à bout de bras un câble ethernet qui traverse une salle de restau pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en infrarouge, c'est bien la vraie vie, n'est-ce pas ? -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
Eric Deveaud
Eric Jacoboni wrote:
je préfère tester le comportement d'un objet plutôt que son appartenance à un type (le premier permettant notamment de s'affranchir des contraintes de l'héritage).
nous sommes donc fondamentalement d'accord.
Eric
-- tenir à bout de bras un câble ethernet qui traverse une salle de restau pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en infrarouge, c'est bien la vraie vie, n'est-ce pas ? -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
Eric Jacoboni wrote:
je préfère tester le comportement d'un objet plutôt que son appartenance à
un type (le premier permettant notamment de s'affranchir des contraintes de
l'héritage).
nous sommes donc fondamentalement d'accord.
Eric
--
tenir à bout de bras un câble ethernet qui traverse une salle de restau
pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en
infrarouge, c'est bien la vraie vie, n'est-ce pas ?
-+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
je préfère tester le comportement d'un objet plutôt que son appartenance à un type (le premier permettant notamment de s'affranchir des contraintes de l'héritage).
nous sommes donc fondamentalement d'accord.
Eric
-- tenir à bout de bras un câble ethernet qui traverse une salle de restau pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en infrarouge, c'est bien la vraie vie, n'est-ce pas ? -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-
Eric Jacoboni
Boris Borcic writes:
Mphhh, c'est une vision qui finalement interdit d'utiliser le protocole d'itérateur, puisque celui-ci ne prévoit pas d'autre interface pour épuiser la source que de demander à répétition l'élément suivant jusqu'à StopIteration; en particulier, il n'y a pas (d'autre) moyen de savoir le nombre d'éléments.
Qu'en interne l'itérateur utilise StopIteration n'est pas mon problème (ou, plutôt, si je n'ai pas envie de le savoir, c'est mon choix).
Moi, je préfère écrire :
for var in coll: faire_qque_chose_avec(var)
que :
_iter_temp = iter(coll) while True: try: var = _iter_temp.next() except StopIteration: break faire_qque_chose_avec(var)
La première forme est strictement équivalente à la seconde... Fais ton choix, camarade.
franchement, il faut être maso pour ne pas utiliser par ex :
for line in open("/foo/bar") : do_something(line)
lorsqu'on a un traitement ligne à ligne à faire dans un fichier.
Euh, oui... c'est bien ce que je dis... où il y a t'il un traitement d'exception _de ma part_, là-dedans ?
J'en ai rien à faire, qu'en interne, ce for utilise une exception ou un test d'EOF pour savoir qu'il doit se terminer : je parcours ligne à ligne un fichier (donc nombre d'itération bornée), point barre. Si je devais parcourir ce fichier sans être sûr du nombre d'itération, je prendrais un while (qui testerait aussi EOF, c'est le minimum en algo, hein...).
J'ai l'impression que pas mal de Pythoniens confondent un peu l'abstraction des structures de contrôle et leur implémentation interne et qu'ils se font un malin plaisir de les ressortir à tout bout de champ.
La possibilité qu'offre Python d'intervenir dans le fonctionnement interne peut être une bonne chose, _dans certains cas_, l'utiliser systématiquement, je ne trouve pas ça productif, loin de là. -- Eric Jacoboni, ne il y a 1448829933 secondes
Boris Borcic <bborcic@gmail.com> writes:
Mphhh, c'est une vision qui finalement interdit d'utiliser le
protocole d'itérateur, puisque celui-ci ne prévoit pas d'autre
interface pour épuiser la source que de demander à répétition
l'élément suivant jusqu'à StopIteration; en particulier, il n'y a pas
(d'autre) moyen de savoir le nombre d'éléments.
Qu'en interne l'itérateur utilise StopIteration n'est pas mon
problème (ou, plutôt, si je n'ai pas envie de le savoir, c'est mon
choix).
Moi, je préfère écrire :
for var in coll:
faire_qque_chose_avec(var)
que :
_iter_temp = iter(coll)
while True:
try: var = _iter_temp.next()
except StopIteration: break
faire_qque_chose_avec(var)
La première forme est strictement équivalente à la seconde... Fais ton
choix, camarade.
franchement, il faut être maso pour ne pas utiliser par ex :
for line in open("/foo/bar") :
do_something(line)
lorsqu'on a un traitement ligne à ligne à faire dans un fichier.
Euh, oui... c'est bien ce que je dis... où il y a t'il un traitement
d'exception _de ma part_, là-dedans ?
J'en ai rien à faire, qu'en interne, ce for utilise une exception ou
un test d'EOF pour savoir qu'il doit se terminer : je parcours ligne à
ligne un fichier (donc nombre d'itération bornée), point barre. Si je
devais parcourir ce fichier sans être sûr du nombre d'itération, je
prendrais un while (qui testerait aussi EOF, c'est le minimum en algo,
hein...).
J'ai l'impression que pas mal de Pythoniens confondent un peu
l'abstraction des structures de contrôle et leur implémentation
interne et qu'ils se font un malin plaisir de les ressortir à tout
bout de champ.
La possibilité qu'offre Python d'intervenir dans le fonctionnement
interne peut être une bonne chose, _dans certains cas_, l'utiliser
systématiquement, je ne trouve pas ça productif, loin de là.
--
Eric Jacoboni, ne il y a 1448829933 secondes
Mphhh, c'est une vision qui finalement interdit d'utiliser le protocole d'itérateur, puisque celui-ci ne prévoit pas d'autre interface pour épuiser la source que de demander à répétition l'élément suivant jusqu'à StopIteration; en particulier, il n'y a pas (d'autre) moyen de savoir le nombre d'éléments.
Qu'en interne l'itérateur utilise StopIteration n'est pas mon problème (ou, plutôt, si je n'ai pas envie de le savoir, c'est mon choix).
Moi, je préfère écrire :
for var in coll: faire_qque_chose_avec(var)
que :
_iter_temp = iter(coll) while True: try: var = _iter_temp.next() except StopIteration: break faire_qque_chose_avec(var)
La première forme est strictement équivalente à la seconde... Fais ton choix, camarade.
franchement, il faut être maso pour ne pas utiliser par ex :
for line in open("/foo/bar") : do_something(line)
lorsqu'on a un traitement ligne à ligne à faire dans un fichier.
Euh, oui... c'est bien ce que je dis... où il y a t'il un traitement d'exception _de ma part_, là-dedans ?
J'en ai rien à faire, qu'en interne, ce for utilise une exception ou un test d'EOF pour savoir qu'il doit se terminer : je parcours ligne à ligne un fichier (donc nombre d'itération bornée), point barre. Si je devais parcourir ce fichier sans être sûr du nombre d'itération, je prendrais un while (qui testerait aussi EOF, c'est le minimum en algo, hein...).
J'ai l'impression que pas mal de Pythoniens confondent un peu l'abstraction des structures de contrôle et leur implémentation interne et qu'ils se font un malin plaisir de les ressortir à tout bout de champ.
La possibilité qu'offre Python d'intervenir dans le fonctionnement interne peut être une bonne chose, _dans certains cas_, l'utiliser systématiquement, je ne trouve pas ça productif, loin de là. -- Eric Jacoboni, ne il y a 1448829933 secondes
