import

Au moins 9 fois sur 10, quand tu es tenté d'utiliser exec ou eval, dis
toi qu'il y a une meilleure solution !-)

Salut Bruno,

Je veux bien, mais en interne il est quasiment certain que imp les
utilise.

C'est assez facile à vérifier, non ?

Donc pourquoi s'en priver ?

Il ne s'agit pas s'en priver, mais de ne pas les utiliser n'importe
comment - et donc de ne pas les utiliser quand le langage propose une
solution spécifique au problème.

Après tout exec et eval font partie intégrante de Python, je ne vois pas
ce qu'il ya de sâle à les utiliser.

Il y a des risques évidents à utiliser ces fonctionnalités, et tu peux
être sûr que les fonctions builtin ou de la stdlib qui le font le font
avec beaucoup de précautions.

Concernant la 'saleté' de la chose, qu'est-ce qui est à ton avis le plus
lisible et le plus facile à debugger ?

val = gettattr(obj, attrname)
setattr(obj, attrname, 42)

ou

val = eval("obj.%s" % attrname)
exec("obj.%s=%s" % (attrname, 42))


J'utilise Python depuis la fin du millénaire précédent, et à peu près
99% des fois où j'ai été tenté d'utiliser exec ou eval, il y avait une
solution plus appropriée, pas bien plus coûteuse à mettre en oeuvre et
*infiniment* moins coûteuse à maintenir.

Maintenant, tu fais comme tu veux, hein, c'est pas moi qui maintient ton
code...

C'est assez facile à vérifier, non ?

Sans doute pour quelqu'un de talentueux, mais ça me dépasse.

Donc pourquoi s'en priver ?

Il ne s'agit pas s'en priver, mais de ne pas les utiliser n'importe
comment - et donc de ne pas les utiliser quand le langage propose une
solution spécifique au problème.

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Du reste, utiliser un module pour une ligne de code me fait souvent
envisager une nouvelle solution.

Après tout exec et eval font partie intégrante de Python, je ne vois
pas ce qu'il ya de sâle à les utiliser.

Il y a des risques évidents à utiliser ces fonctionnalités, et tu peux
être sûr que les fonctions builtin ou de la stdlib qui le font le font
avec beaucoup de précautions.

Mais alors dans ce cas à quoi servent-elles exactement ? Si tu ouvres
n'importe quel bouquin sur Python, tu vas trouver ce genre de petits
exemples en 2-3 lignes.

Je veux bien en apprendre plus sur le sujet, mais reconnaissons que la
littérature actuelle ne nous y aide pas.

Concernant la 'saleté' de la chose, qu'est-ce qui est à ton avis le plus
lisible et le plus facile à debugger ?

val = gettattr(obj, attrname)
setattr(obj, attrname, 42)

ou

val = eval("obj.%s" % attrname)
exec("obj.%s=%s" % (attrname, 42))

Sûr, je choisis la première solution.

J'utilise Python depuis la fin du millénaire précédent, et à peu près
99% des fois où j'ai été tenté d'utiliser exec ou eval, il y avait une
solution plus appropriée, pas bien plus coûteuse à mettre en oeuvre et
*infiniment* moins coûteuse à maintenir.

Là encore, je veux bien te croire. Mais pour le commun des utilisateurs,
c'est une perte de temps à la recherche pour un résultat identique.

@+

Je veux bien, mais en interne il est quasiment certain que imp les
utilise.

C'est assez facile à vérifier, non ?

Sans doute pour quelqu'un de talentueux, mais ça me dépasse.

Alors comment peut-tu affirmer que c'est quasiment certain ?-)

Bon, pour info, imp est un module builtin - donc codé en C, donc les
chances que ce code précis utilise exec est relativement faible.

Donc pourquoi s'en priver ?

Il ne s'agit pas s'en priver, mais de ne pas les utiliser n'importe
comment - et donc de ne pas les utiliser quand le langage propose une
solution spécifique au problème.

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Ah bon ? C'est très particulier, comme approche, là. Je veux dire, il y
a dans les builtins tout le nécessaire pour gérer très exactement ce
genre de problème, mais ce n'est pas une solution ??? J'avoue ne pas
suivre ton raisonnement...

Du reste, utiliser un module pour une ligne de code me fait souvent
envisager une nouvelle solution.

Pas moi, surtout quand c'est dans la stdlib, et a fortiori quand c'est
dans les builtins.

Après tout exec et eval font partie intégrante de Python, je ne vois
pas ce qu'il ya de sâle à les utiliser.

Il y a des risques évidents à utiliser ces fonctionnalités, et tu peux
être sûr que les fonctions builtin ou de la stdlib qui le font le font
avec beaucoup de précautions.

Mais alors dans ce cas à quoi servent-elles exactement ?

A solutionner certains problèmes pour lequels il n'y a pas de meilleure
solution.

Si tu ouvres
n'importe quel bouquin sur Python, tu vas trouver ce genre de petits
exemples en 2-3 lignes.

Hélas. Même si le niveau moyen des bouquins sur Python n'est pas trop
catastrophique (si tu savis ce qu'on peut voir comme horreur dans les
bouquins sur le C...), on y retrouve certains travers communs à la
littérature informatique.

Je veux bien en apprendre plus sur le sujet, mais reconnaissons que la
littérature actuelle ne nous y aide pas.

Un des problèmes est qu'entre le coût de fabrication d'un ouvrage de ce
genre, son espérance de vie (le temps qu'il soit écrit / corrigé /
imprimé / distribué, tu peux être sûr qu'une ou deux versions de Python
seront passées...) et le nombre de ventes potentielles, ça n'encourage
pas forcément les éditeurs à faire mieux.

Ceci étant, même pour des langages plus stables (je veux dire : qui sont
plus standardisés et évoluent moins vite) et plus connus, l'essentiel de
la littérature est à mettre à la poubelle. J'ai bien plus appris sur le
langage C et les bonnes pratiques le concernant en suivant c.l.c et
f.c.l.c qu'avec les bouquins.

Concernant la 'saleté' de la chose, qu'est-ce qui est à ton avis le
plus lisible et le plus facile à debugger ?

val = gettattr(obj, attrname)
setattr(obj, attrname, 42)

ou

val = eval("obj.%s" % attrname)
exec("obj.%s=%s" % (attrname, 42))

Sûr, je choisis la première solution.

Alors quel est ton problème avec imp et/ou __import__ ? On est
exactement dans le même cas de figure.

J'utilise Python depuis la fin du millénaire précédent, et à peu près
99% des fois où j'ai été tenté d'utiliser exec ou eval, il y avait une
solution plus appropriée, pas bien plus coûteuse à mettre en oeuvre et
*infiniment* moins coûteuse à maintenir.

Là encore, je veux bien te croire. Mais pour le commun des utilisateurs,
c'est une perte de temps à la recherche pour un résultat identique.

J'ai une fois passé 2 (longs) jours à implémenter un module (pourri et
buggé) de parsing pour des fichiers csv. Avant de prendre les 10 minutes
nécessaires à consulter l'index de la stdlib, parcourir la doc du module
csv, et faire les trois essais nécessaires pour comprendre son
utilisation. Perte de temps, disais-tu ?

Et encore, je te fais grâce du temps que j'ai perdu l'année dernière à
réécrire les trois quart d'une appli pas tout à fait triviale pondue par
un gougnafier qui considérait manifestement qu'apprendre à utiliser le
langage et le framework utilisés était une "perte de temps". La perte de
temps finale a été de plusieurs mois/homme (perte sèche pour la boite,
sans compter les problèmes avec le client...). Alors excuse moi si ton
argumentation ne me convaint pas franchement.

Bonjour !

il est quasiment certain que imp utilise exec

C'est assez facile à vérifier, non ?

En fait, c'est assez dur. imp est un module C_BUILTIN ; il faut donc se
plonger dans les sources en langage C de Python.
Autrement, il faut se plonger dans le c...ambouis. Et, d'abord,
apprendre le C. Très peu pour moi.

Toujours est-il qu'il m'étonnerait que imp utilise l' exec de Python,
mais plutôt une fonction C intégrée dans(de) Python.

Concernant la 'saleté' de la chose, qu'est-ce qui est à ton avis le
plus lisible et le plus facile à debugger ?

J'utilise beaucoup exec et eval. J'apprécie ces instructions. Et je suis
d'accord avec ton argument sur la difficulté à déboguer. Je considère
cet argument beaucoup plus valable que les mauvais arguments parlant de
la sécurité.

Mais, cet aspect (difficulté à déboguer) pourrait s'étendre à
l'importation d'un module par son nom, aux surcharges multiples, ou
simplement aux héritages (multiples ou en cascade).

Perso, comme j'ai hérité, de la soirée d'hier, une vilaine fatigue, je
vais instancier une mini-sieste...

@-salutations

Michel Claveau

Sans doute pour quelqu'un de talentueux, mais ça me dépasse.

Alors comment peut-tu affirmer que c'est quasiment certain ?-)

Parce que je pensais (à tord apparement) que comme beaucoup de modules,
il était codé en C.

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Ah bon ? C'est très particulier, comme approche, là. Je veux dire, il y
a dans les builtins tout le nécessaire pour gérer très exactement ce
genre de problème, mais ce n'est pas une solution ??? J'avoue ne pas
suivre ton raisonnement...

Le raisonnement n'est tout du tout en cause ici, c'est mon hypothèse qui
était vérollée : pourquoi ne pas avoir dit de suite qu'il était écrit en
C. Prendre les gens de haut en se contentant de "c'est facile à
vérifier..." n'apporte pas grand chose à l'édifice. Tout le monde n'a
pas les mêmes connaissances, et en l'occurence je n'ai en fait jamais
utilisé imp après 2 ans de Python.

Du reste, utiliser un module pour une ligne de code me fait souvent
envisager une nouvelle solution.

Pas moi, surtout quand c'est dans la stdlib, et a fortiori quand c'est
dans les builtins.

Question de style, mais je comprends ton point de vue.

A solutionner certains problèmes pour lequels il n'y a pas de meilleure
solution.

Cetes, ça reste pour moi toujours aussi flou...quels sont ces types de
problèmes justement ?

Si tu ouvres n'importe quel bouquin sur Python, tu vas trouver ce
genre de petits exemples en 2-3 lignes.

Hélas. Même si le niveau moyen des bouquins sur Python n'est pas trop
catastrophique (si tu savis ce qu'on peut voir comme horreur dans les
bouquins sur le C...), on y retrouve certains travers communs à la
littérature informatique.

Je ne prononcerai pas là-dessus, je n'ai qu'un bouquin sur le C
(Delannoy je crois me souvenir), et ça me donne des boutons.

Je veux bien en apprendre plus sur le sujet, mais reconnaissons que la
littérature actuelle ne nous y aide pas.

Un des problèmes est qu'entre le coût de fabrication d'un ouvrage de ce
genre, son espérance de vie (le temps qu'il soit écrit / corrigé /
imprimé / distribué, tu peux être sûr qu'une ou deux versions de Python
seront passées...) et le nombre de ventes potentielles, ça n'encourage
pas forcément les éditeurs à faire mieux.

Ca n'empêche pas certains bouquins d'être à jour, comme les 2 tomes de
"Au coeur de Python" qui traitent la version 2.5 et parlent même un peu
du futur.

D'autres sont même complètement obsolètes sur la version utilisée, mais
toujours utiles au sens du contenu qu'ils apportent, je pense par
exemple à "Text Procressing In Python".

Ceci étant, même pour des langages plus stables (je veux dire : qui sont
plus standardisés et évoluent moins vite) et plus connus, l'essentiel de
la littérature est à mettre à la poubelle. J'ai bien plus appris sur le
langage C et les bonnes pratiques le concernant en suivant c.l.c et
f.c.l.c qu'avec les bouquins.

Rien n'est meilleure que la pratique, mais il faut un minimum pour
débuter, et sur certains langages c'est plutôt difficile. J'en fais
actuelement l'expérience avec Haskell : pas de bouquin en Français, une
littérature Anglo-Saxonne jugée difficile (au bout de 30 pages on
commence par la théorie des compilateurs). Heureusement, IRC et les
newsgroups sont parfois là pour nous sauver comme tu le dis.

Alors quel est ton problème avec imp et/ou __import__ ? On est
exactement dans le même cas de figure.

Je n'ai pas de problème, j'ai simplement tenté de répondre à une
question posée (et avec ce que je connaissais, donc pas d'imp) et
applaudi Jean-Baptiste pour sa solution que je trouvais élégante.

J'ai une fois passé 2 (longs) jours à implémenter un module (pourri et
buggé) de parsing pour des fichiers csv. Avant de prendre les 10 minutes
nécessaires à consulter l'index de la stdlib, parcourir la doc du module
csv, et faire les trois essais nécessaires pour comprendre son
utilisation. Perte de temps, disais-tu ?

On est bien d'accord sur le fond : on perd du temps à chercher dans la
doc pour en gagner par la suite, malheureusement en pratique c'est
plutot la solution de facilité qui vient à l'esprit : on voit ça dans
pas mal de sources. Une ou deux lignes de code un peu louche avec un
commentaire '# this part seems weird, but it works'

Et encore, je te fais grâce du temps que j'ai perdu l'année dernière à
réécrire les trois quart d'une appli pas tout à fait triviale pondue par
un gougnafier qui considérait manifestement qu'apprendre à utiliser le
langage et le framework utilisés était une "perte de temps". La perte de
temps finale a été de plusieurs mois/homme (perte sèche pour la boite,
sans compter les problèmes avec le client...). Alors excuse moi si ton
argumentation ne me convaint pas franchement.

C'est parce qu'on en a tout simplement pas la même utilisation. Tu codes
pour une boite, je le fais pour mon plaisir, et ça change vraiment pas
mal de choses car personne ne m'impose quoi que ce soit. C'est sûr, les
"bonnes pratiques" vont être imposées dans une boite (et heureusement),
mais tu ne peux exiger cette rigueur de la part d'un amateur qui n'y
passe que quelques heures dans la semaine.

En outre, je n'ai jamais prétendu ne pas vouloir utiliser les
fonctionnalités du language, mais simplement éviter au maximum les
dépendances externes (sauf la stdlib, mais elle est assez grosse pour ne
pas tout maîtriser, la preuve avec imp).

Juste une faute dans mon dernier message, première phrase lire :

"Parce que je pensais (à tord apparement) que comme beaucoup de modules,
il était codé en **Python**."

Sans doute pour quelqu'un de talentueux, mais ça me dépasse.

Alors comment peut-tu affirmer que c'est quasiment certain ?-)

Parce que je pensais (à tord apparement) que comme beaucoup de modules,
il était codé en C.

<fix, cf post suivant de kib>
Parce que je pensais (à tord apparement) que comme beaucoup de modules,
il était codé en Python.
</fix>

Si un module est codé en Python, il n'est pas besoin d'être spécialement
talentueux pour vérifier s'il emploie exec ou non, tu sais - une simple
recherche dans le texte suffit !-)

Bon, je te taquine un peu, mais l'expérience m'a appris à me méfier des
idées préconçues dans ce domaine.

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Ah bon ? C'est très particulier, comme approche, là. Je veux dire, il
y a dans les builtins tout le nécessaire pour gérer très exactement ce
genre de problème, mais ce n'est pas une solution ??? J'avoue ne pas
suivre ton raisonnement...

Le raisonnement n'est tout du tout en cause ici, c'est mon hypothèse qui
était vérollée : pourquoi ne pas avoir dit de suite qu'il était écrit en
C.

Parce que j'ai vérifié après, tout simplement.

Prendre les gens de haut en se contentant de "c'est facile à
vérifier..." n'apporte pas grand chose à l'édifice.

Désolé si ma formulation t'a vexé, ce n'était pas mon intention. Ce que
je voulais dire en l'occurrence est qu'il est facile de savoir si un
module est implémenté en C ou en Python, et dans le second cas d'aller
consulter le code - ce qui constitue souvent une expérience intéressante
d'ailleurs (dans un sens ou dans un autre pour ce que ça vaut : dès
fois, ça décomplexifie très nettement !)).

Tout le monde n'a
pas les mêmes connaissances, et en l'occurence je n'ai en fait jamais
utilisé imp après 2 ans de Python.

Honnêtement, j'en ai très peu eu l'usage moi-même.

Du reste, utiliser un module pour une ligne de code me fait souvent
envisager une nouvelle solution.

Pas moi, surtout quand c'est dans la stdlib, et a fortiori quand c'est
dans les builtins.

Question de style,

Pas uniquement. Question d'éviter de réinventer la roue carrée, surtout.
Je fais bien plus confiance à un code écrit par des développeurs très
probablement plus doués que moi et validé par plusieurs années
d'utilisation et de débuggage que dans ce que je peux pondre moi-même.
Question auss, accessoirement, de lisibilité : quand je tombe, dans un
code que je n'ai pas écrit, sur une duplication apparente d'une
fonctionnalité "de base" du langage (ou de sa bibliothèque standard),
j'ai tendance a supposer qu'il y a une raison technique majeure à cela,
et je cherche donc cette raison. Quand il s'avère, après X dizaines de
minutes d'étude attentive du code en question que cette duplication est
inutile, je constate que j'ai perdu ces X minutes à me prendre la tête
pour rien.

mais je comprends ton point de vue.

A solutionner certains problèmes pour lequels il n'y a pas de
meilleure solution.

Cetes, ça reste pour moi toujours aussi flou...quels sont ces types de
problèmes justement ?

Pour le moment, les seuls cas que j'ai vu (où l'usage de exec était
justifié) concernait l'utilisation de Python comme langage de scripting
d'une autre application (codée en Python et/ou en C ou C++).

Si tu ouvres n'importe quel bouquin sur Python, tu vas trouver ce
genre de petits exemples en 2-3 lignes.

Hélas. Même si le niveau moyen des bouquins sur Python n'est pas trop
catastrophique (si tu savis ce qu'on peut voir comme horreur dans les
bouquins sur le C...), on y retrouve certains travers communs à la
littérature informatique.>

Je ne prononcerai pas là-dessus, je n'ai qu'un bouquin sur le C
(Delannoy je crois me souvenir), et ça me donne des boutons.

Je veux bien en apprendre plus sur le sujet, mais reconnaissons que
la littérature actuelle ne nous y aide pas.

Un des problèmes est qu'entre le coût de fabrication d'un ouvrage de
ce genre, son espérance de vie (le temps qu'il soit écrit / corrigé /
imprimé / distribué, tu peux être sûr qu'une ou deux versions de
Python seront passées...) et le nombre de ventes potentielles, ça
n'encourage pas forcément les éditeurs à faire mieux.

Ca n'empêche pas certains bouquins d'être à jour, comme les 2 tomes de
"Au coeur de Python" qui traitent la version 2.5 et parlent même un peu
du futur.

D'autres sont même complètement obsolètes sur la version utilisée, mais
toujours utiles au sens du contenu qu'ils apportent, je pense par
exemple à "Text Procressing In Python".

Certes. Je ne dis pas que *tous* les bouquins d'informatique sont
mauvais ou inutiles, juste que même envers les meilleurs, il faut savoir
user de sens critique.

Ceci étant, même pour des langages plus stables (je veux dire : qui
sont plus standardisés et évoluent moins vite) et plus connus,
l'essentiel de la littérature est à mettre à la poubelle. J'ai bien
plus appris sur le langage C et les bonnes pratiques le concernant en
suivant c.l.c et f.c.l.c qu'avec les bouquins.

Rien n'est meilleure que la pratique, mais il faut un minimum pour

débuter, et sur certains langages c'est plutôt difficile. J'en fais
actuelement l'expérience avec Haskell : pas de bouquin en Français, une
littérature Anglo-Saxonne jugée difficile (au bout de 30 pages on
commence par la théorie des compilateurs).

<HS>
Oui, c'est un des problèmes avec les langages fonctionnels : la
communauté est souvent composée avant tout de "grosses têtes", et la
littérature associée s'en ressent. C'est dommage d'ailleurs parce qu'il
serait intéressant que ces langages se répandent davantage...
</HS>

Heureusement, IRC et les
newsgroups sont parfois là pour nous sauver comme tu le dis.

Alors quel est ton problème avec imp et/ou __import__ ? On est
exactement dans le même cas de figure.

Je n'ai pas de problème, j'ai simplement tenté de répondre à une
question posée (et avec ce que je connaissais, donc pas d'imp)

Jusque là, j'avais suivi :-)

Non, je parlais de ton commentaire selon lequel avec l'utilisation de
imp, je cite : "on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp."

J'ai une fois passé 2 (longs) jours à implémenter un module (pourri et
buggé) de parsing pour des fichiers csv. Avant de prendre les 10
minutes nécessaires à consulter l'index de la stdlib, parcourir la doc
du module csv, et faire les trois essais nécessaires pour comprendre
son utilisation. Perte de temps, disais-tu ?>

On est bien d'accord sur le fond : on perd du temps à chercher dans la
doc pour en gagner par la suite, malheureusement en pratique c'est
plutot la solution de facilité qui vient à l'esprit : on voit ça dans
pas mal de sources. Une ou deux lignes de code un peu louche avec un
commentaire '# this part seems weird, but it works'

Attention, ça ne veut pas forcément dire que c'est une solution de
facilité - simplement que contrairement à ce qui pourrait sembler à
première vue, ce n'est pas un WTF mais une solution appropriée au contexte.

Et encore, je te fais grâce du temps que j'ai perdu l'année dernière à
réécrire les trois quart d'une appli pas tout à fait triviale pondue
par un gougnafier qui considérait manifestement qu'apprendre à
utiliser le langage et le framework utilisés était une "perte de
temps". La perte de temps finale a été de plusieurs mois/homme (perte
sèche pour la boite, sans compter les problèmes avec le client...).
Alors excuse moi si ton argumentation ne me convaint pas franchement.

C'est parce qu'on en a tout simplement pas la même utilisation. Tu codes
pour une boite, je le fais pour mon plaisir,

Aussi étrange que ça puisse paraître, l'un n'empêche pas l'autre !-)

et ça change vraiment pas
mal de choses car personne ne m'impose quoi que ce soit. C'est sûr, les
"bonnes pratiques" vont être imposées dans une boite

Dans la plupart de celles où je suis passé, la notion même de "bonne
pratique" était lettre morte. Dans celles où je suis resté (!-), c'est
qu'au moins une autre personne partageais mes convictions à ce propos.

(et heureusement),

Dans un monde idéal peut-être. Pas dans ce monde ci, j'en ai peur :(

mais tu ne peux exiger cette rigueur de la part d'un amateur qui n'y
passe que quelques heures dans la semaine.

Je n'exige rien de toi, rassure-toi !-)

Par contre, dans la mesure où tu n'es pas, loin s'en faut, le seul
lecteur de ce thread, et qu'il se peut que j'ai un jour à repasser sur
le code d'un des dits lecteurs, j'aimerais autant faire en sorte que le
code soit le plus propre possible - ce qui est une motivation certes
très égoïste, mais néanmoins légitime.

En outre, je n'ai jamais prétendu ne pas vouloir utiliser les
fonctionnalités du language, mais simplement éviter au maximum les
dépendances externes

Il y a des cas où ça se justifie, effectivement. Il y a d'autres cas où
réinventer la roue n'est pas forcément la meilleure idée non plus.
Question à régler au cas par cas en fonction du problème concret, du
contexte, et probablement aussi de la phase de la lune...

(sauf la stdlib, mais elle est assez grosse pour ne
pas tout maîtriser, la preuve avec imp).

Ce n'est pas moi qui dirais le contraire - la preuve, mon module csv à
deux balles. Par contre, l'expérience m'a appris à éviter de me ruer sur
mon clavier pour ce qui, à la réflexion, n'est probablement pas un
problème nouveau. Et encore plus quand la solution envisagée implique
exec ou eval !-)

Bonjour !

il est quasiment certain que imp utilise exec

C'est assez facile à vérifier, non ?

En fait, c'est assez dur. imp est un module C_BUILTIN ;

Ce qui suffit a écarter l'hypothèse de l'utilisation de exec !-)

(snip)

Concernant la 'saleté' de la chose, qu'est-ce qui est à ton avis le
plus lisible et le plus facile à debugger ?

J'utilise beaucoup exec et eval. J'apprécie ces instructions. Et je suis
d'accord avec ton argument sur la difficulté à déboguer. Je considère
cet argument beaucoup plus valable que les mauvais arguments parlant de
la sécurité.

Etant donné le dynamisme de Python, je ne pense pas que les arguments
concernant la sécurité soient à prendre à la légère.

Mais, cet aspect (difficulté à déboguer) pourrait s'étendre à
l'importation d'un module par son nom, aux surcharges multiples, ou
simplement aux héritages (multiples ou en cascade).

Il y a quand même une différence fondamentale : tu ne peux pas
simplement tracer (dans pdb) un code généré par exec. Tu ne sais même
pas quel appel à exec a généré le code posant problème. Alors que tous
le reste (et même les décorateurs, les applications partielles, les
metaclasses etc) peux se tracer d'une façon ou d'une autre.

Si un module est codé en Python, il n'est pas besoin d'être spécialement
talentueux pour vérifier s'il emploie exec ou non, tu sais - une simple
recherche dans le texte suffit !-)

C'est vrai, tu entends par là que je suis flemmard :) ?

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Ah bon ? C'est très particulier, comme approche, là. Je veux dire, il
y a dans les builtins tout le nécessaire pour gérer très exactement
ce genre de problème, mais ce n'est pas une solution ??? J'avoue ne
pas suivre ton raisonnement...

Le raisonnement n'est tout du tout en cause ici, c'est mon hypothèse
qui était vérollée : pourquoi ne pas avoir dit de suite qu'il était
écrit en C.

Parce que j'ai vérifié après, tout simplement.

Prendre les gens de haut en se contentant de "c'est facile à
vérifier..." n'apporte pas grand chose à l'édifice.

Désolé si ma formulation t'a vexé, ce n'était pas mon intention. Ce que
je voulais dire en l'occurrence est qu'il est facile de savoir si un
module est implémenté en C ou en Python, et dans le second cas d'aller
consulter le code - ce qui constitue souvent une expérience intéressante
d'ailleurs (dans un sens ou dans un autre pour ce que ça vaut : dès
fois, ça décomplexifie très nettement !)).

Ne t'inquiète pas, je ne l'ai pas mal pris. On a le droit de discuter
quand même. Je retiens néanmoins ton conseil.

Cetes, ça reste pour moi toujours aussi flou...quels sont ces types de
problèmes justement ?

Pour le moment, les seuls cas que j'ai vu (où l'usage de exec était
justifié) concernait l'utilisation de Python comme langage de scripting
d'une autre application (codée en Python et/ou en C ou C++).

C'est plus clair, merci.

D'autres sont même complètement obsolètes sur la version utilisée,
mais toujours utiles au sens du contenu qu'ils apportent, je pense par
exemple à "Text Procressing In Python".

Certes. Je ne dis pas que *tous* les bouquins d'informatique sont
mauvais ou inutiles, juste que même envers les meilleurs, il faut savoir
user de sens critique.

Oui, mais ce n'est jamais facile d'être critique lorsque l'on débute un
language. Pour critiquer il faut toujours connaître un peu, et on entre
ainsi dans spirale infernale (un "while True" quoi :)).

<HS>
Oui, c'est un des problèmes avec les langages fonctionnels : la
communauté est souvent composée avant tout de "grosses têtes", et la
littérature associée s'en ressent. C'est dommage d'ailleurs parce qu'il
serait intéressant que ces langages se répandent davantage...
</HS>

Je ne peux qu'approuver.

Dans la plupart de celles où je suis passé, la notion même de "bonne
pratique" était lettre morte. Dans celles où je suis resté (!-), c'est
qu'au moins une autre personne partageais mes convictions à ce propos.

Ca fait peur...c'est vérolé à ce point ?

Par contre, dans la mesure où tu n'es pas, loin s'en faut, le seul
lecteur de ce thread, et qu'il se peut que j'ai un jour à repasser sur
le code d'un des dits lecteurs, j'aimerais autant faire en sorte que le
code soit le plus propre possible - ce qui est une motivation certes
très égoïste, mais néanmoins légitime.

Ok, en l'occurence il a été vite corrigé (mais il fonctionnait tout de me!).

Il y a des cas où ça se justifie, effectivement. Il y a d'autres cas où
réinventer la roue n'est pas forcément la meilleure idée non plus.
Question à régler au cas par cas en fonction du problème concret, du
contexte, et probablement aussi de la phase de la lune...

...et tu oublis les marées non ?!

(sauf la stdlib, mais elle est assez grosse pour ne pas tout
maîtriser, la preuve avec imp).

Ce n'est pas moi qui dirais le contraire - la preuve, mon module csv à
deux balles. Par contre, l'expérience m'a appris à éviter de me ruer sur
mon clavier pour ce qui, à la réflexion, n'est probablement pas un
problème nouveau. Et encore plus quand la solution envisagée implique
exec ou eval !-)

Heureusement, on nous concocte de nouvelles docs toutes jolies, ça va
être un bon prétexte pour les potasser.

A ce propos, voici une astuce que j'ai trouvée, je n'ai pas encore eû le
temps de la poster sur mon pseudo blog :

Il est possible via Mozilla Firefox de se constituer des mots-cles à
exécuter dans votre barre de navigation de façon à ne pas aller/venir
dans vos favoris.

Nous allons voir ici comment accéder à la nouvelle doc Python 2.6
totalement refondue. Allez sur la page [Oui, la page donne une erreur et
c'est totalement volontaire.]:

http://docs.python.org/dev/library/%s.html et placez-là dans vos favoris
sous le nom de "PyDoc".

Ensuite allez dans 'favoris', choisissez "PyDoc" un et faites un
clic-droit, puis 'Propriétés'. Dans mot-clef, entrez "pydoc".

C'est fait ?
Bon, alors on va tester ça : entrez maintenant "pydoc math"
suivi de Entréé dans votre barre de navigation.

Ca marche ? Tant mieux.

@+

Bonsoir !

Certes, je ne sais pas d'où vient l'appel de l'exec (je n'ai, en fait,
jamais cherché).
Par contre, j'arrive très bien à tracer, faire du pas à pas, suivre des
valeurs, pour du code lancé avec exec.

@+

Michel Claveau