Si tu fais : f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345") f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire que l'objet fichier n'existe plus. Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en grève, ça n'arrive pas très souvent...
Bonne nuit
Michel Claveau
Bonsoir !
Si tu fais :
f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire
que l'objet fichier n'existe plus. Mais il y a forcément eu un objet
temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me
suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en
grève, ça n'arrive pas très souvent...
Si tu fais : f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345") f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire que l'objet fichier n'existe plus. Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en grève, ça n'arrive pas très souvent...
Bonne nuit
Michel Claveau
tiissa
Do Re Mi chel La Si Do wrote:
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure. Donc cet objet est donc bien créé mais est-il disponible pour être recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de nom, sera-t-il supprimé complètement à la fin de son utilisation (donc avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ? Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à cet objet (même fermé) jusqu'à la fin de sa portée, non ?
Do Re Mi chel La Si Do wrote:
Mais il y a forcément eu un objet
temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me
suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans
ce cas de figure.
Donc cet objet est donc bien créé mais est-il disponible pour être
recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de
nom, sera-t-il supprimé complètement à la fin de son utilisation (donc
avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à
cet objet (même fermé) jusqu'à la fin de sa portée, non ?
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure. Donc cet objet est donc bien créé mais est-il disponible pour être recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de nom, sera-t-il supprimé complètement à la fin de son utilisation (donc avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ? Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à cet objet (même fermé) jusqu'à la fin de sa portée, non ?
F. Petitjean
Bonsoir !
Si tu fais : f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345") f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire que l'objet fichier n'existe plus.
Non cela veut dire que 'f is None', c'est-à-dire que la méthode write() a eu la bonne idée de retourner (None) au lieu de provoquer une exception (ce qui aurait entraîné un débranchement ailleurs dans le programme)
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté. Là c'est effectivemebnt plus clair.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en grève, ça n'arrive pas très souvent...
D'accord. Le f.close() n'est pas un del f mais il remplit son rôle et est nettement plus explicite (et cela marche avec Jython ou IronPython ou autre xxthon à la mode).
Bonne nuit
Michel Claveau
Bonsoir !
Si tu fais :
f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345")
f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire
que l'objet fichier n'existe plus.
Non cela veut dire que 'f is None', c'est-à-dire que la méthode
write() a eu la bonne idée de retourner (None) au lieu de provoquer une
exception (ce qui aurait entraîné un débranchement ailleurs dans le
programme)
Mais il y a forcément eu un objet
temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me
suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
Là c'est effectivemebnt plus clair.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en
grève, ça n'arrive pas très souvent...
D'accord. Le f.close() n'est pas un del f mais il remplit son rôle et
est nettement plus explicite (et cela marche avec Jython ou IronPython
ou autre xxthon à la mode).
Si tu fais : f=open("tempsub.bat","w").write("SET AA«CDErnSET BB345") f.close()
Cela provoque une erreur (de NoneType) sur la seconde ligne. Cela veut dire que l'objet fichier n'existe plus.
Non cela veut dire que 'f is None', c'est-à-dire que la méthode write() a eu la bonne idée de retourner (None) au lieu de provoquer une exception (ce qui aurait entraîné un débranchement ailleurs dans le programme)
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté. Là c'est effectivemebnt plus clair.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant. Et, vu le nombre d'éboueurs en grève, ça n'arrive pas très souvent...
D'accord. Le f.close() n'est pas un del f mais il remplit son rôle et est nettement plus explicite (et cela marche avec Jython ou IronPython ou autre xxthon à la mode).
Bonne nuit
Michel Claveau
F. Petitjean
Do Re Mi chel La Si Do wrote:
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Donc cet objet est donc bien créé mais est-il disponible pour être recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de nom, sera-t-il supprimé complètement à la fin de son utilisation (donc avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à cet objet (même fermé) jusqu'à la fin de sa portée, non ?
Vous avez un objet python et une référence 'f' sur lui, l'objet python persiste tant que vous avez une référence (directe ou indirecte) et ce n'est certainement pas la mort, un objet de plus ou de moins.
et je ne vous conseille pas de faire gc.get_objects() à l'invite de commandes.
Cordialement.
Do Re Mi chel La Si Do wrote:
Mais il y a forcément eu un objet
temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me
suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans
ce cas de figure.
relisez le Zen import this
Donc cet objet est donc bien créé mais est-il disponible pour être
recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de
nom, sera-t-il supprimé complètement à la fin de son utilisation (donc
avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système
précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le
fichier ! Dommage qu'ils ont oublié de déposer un brevet )
Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à
cet objet (même fermé) jusqu'à la fin de sa portée, non ?
Vous avez un objet python et une référence 'f' sur lui, l'objet python
persiste tant que vous avez une référence (directe ou indirecte) et ce
n'est certainement pas la mort, un objet de plus ou de moins.
Mais il y a forcément eu un objet temporaire, qui n'a a jamais été affecté (associé) à une variable. Je me suis mal exprimé précédemment. L'objet a été créé, mais n'a pas été affecté.
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Donc cet objet est donc bien créé mais est-il disponible pour être recyclé quand le gc le jugera bon ou, du fait qu'il n'a jamais eu de nom, sera-t-il supprimé complètement à la fin de son utilisation (donc avant le prochain passage du gc) ?
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
Je pensais qu'un del était nécessaire car sinon le nom f reste affecté à cet objet (même fermé) jusqu'à la fin de sa portée, non ?
Vous avez un objet python et une référence 'f' sur lui, l'objet python persiste tant que vous avez une référence (directe ou indirecte) et ce n'est certainement pas la mort, un objet de plus ou de moins.
et je ne vous conseille pas de faire gc.get_objects() à l'invite de commandes.
Cordialement.
tiissa
F. Petitjean wrote:
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne sont pas des invariants prouvés ou encore moins des réponses à des questions précises (les mots 'simple', 'obvious', 'readbility',... le montrent). Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche mais ne savais pas que je l'avais à disposition directement.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est question ici (donc les sarcasmes tombent un peu à plat).
D'un autre côté, votre intervention est dans la continuité de cet échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
F. Petitjean wrote:
D'accord. J'avais cru qu'il y avait une optimisation particulière dans
ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne
sont pas des invariants prouvés ou encore moins des réponses à des
questions précises (les mots 'simple', 'obvious', 'readbility',... le
montrent).
Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche
mais ne savais pas que je l'avais à disposition directement.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système
précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le
fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est
question ici (donc les sarcasmes tombent un peu à plat).
D'un autre côté, votre intervention est dans la continuité de cet
échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse
à mes demandes de précision en comporte encore une (confirmée par votre
intervention) mais on va finir y arriver. ;)
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne sont pas des invariants prouvés ou encore moins des réponses à des questions précises (les mots 'simple', 'obvious', 'readbility',... le montrent). Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche mais ne savais pas que je l'avais à disposition directement.
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est question ici (donc les sarcasmes tombent un peu à plat).
D'un autre côté, votre intervention est dans la continuité de cet échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
F. Petitjean
F. Petitjean wrote:
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne sont pas des invariants prouvés ou encore moins des réponses à des questions précises (les mots 'simple', 'obvious', 'readbility',... le montrent).
Là c'était Special cases aren't special enough to break the rules. qui s'appliquait [1]
Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche mais ne savais pas que je l'avais à disposition directement.
Effectivement, après (ou avec) Type "help", "copyright", "credits" or "license" for more information. il devrait y avoir une allusion à 'import this'
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est question ici (donc les sarcasmes tombent un peu à plat).
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu de quilles et je m'en excuse )
D'un autre côté, votre intervention est dans la continuité de cet échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
Cordialement.
F. Petitjean wrote:
D'accord. J'avais cru qu'il y avait une optimisation particulière dans
ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne
sont pas des invariants prouvés ou encore moins des réponses à des
questions précises (les mots 'simple', 'obvious', 'readbility',... le
montrent).
Là c'était
Special cases aren't special enough to break the rules.
qui s'appliquait [1]
Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche
mais ne savais pas que je l'avais à disposition directement.
Effectivement, après (ou avec)
Type "help", "copyright", "credits" or "license" for more information.
il devrait y avoir une allusion à 'import this'
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas
complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais
seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système
précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le
fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est
question ici (donc les sarcasmes tombent un peu à plat).
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu
de quilles et je m'en excuse )
D'un autre côté, votre intervention est dans la continuité de cet
échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse
à mes demandes de précision en comporte encore une (confirmée par votre
intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
D'accord. J'avais cru qu'il y avait une optimisation particulière dans ce cas de figure.
relisez le Zen import this
Les grands principes servent à donner des directions générales. Ce ne sont pas des invariants prouvés ou encore moins des réponses à des questions précises (les mots 'simple', 'obvious', 'readbility',... le montrent).
Là c'était Special cases aren't special enough to break the rules. qui s'appliquait [1]
Mais c'est gentil quand même. Je l'avais lu sur net à droite à gauche mais ne savais pas que je l'avais à disposition directement.
Effectivement, après (ou avec) Type "help", "copyright", "credits" or "license" for more information. il devrait y avoir une allusion à 'import this'
Lorsque l'on décompose (l'autre écriture), le f.close() ne va pas complètement supprimer l'objet. Celui-ci sera effectivement supprimé, mais seulement lors du garbage collector suivant.
Vraiment ? Le close suffit ?
Le close suffit pour fermer le fichier et libérer une ressource système précieuse, et c'est l'essentiel. (trop fort Python f.close() ferme le fichier ! Dommage qu'ils ont oublié de déposer un brevet )
C'est peut-être l'essentiel à vos yeux mais ce n'est pas ce dont il est question ici (donc les sarcasmes tombent un peu à plat).
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu de quilles et je m'en excuse )
D'un autre côté, votre intervention est dans la continuité de cet échange qui porte principalement sur une non compréhension mutuelle. ;)
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
Cordialement.
tiissa
F. Petitjean wrote:
Là c'était Special cases aren't special enough to break the rules. qui s'appliquait [1]
Entre autres, merci. Comme tout le monde, quand je connais la réponse, je suis capable de la retrouver dans la plupart des principes qui s'y rapportent. Ca ne fait pas une réponse appropriée d'une liste de généralités.
La référence absente pointait-elle sur quelque chose d'utile ?
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu de quilles et je m'en excuse )
Ce fil est trouvable dans google [1] si ça vous intéresse.
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
Ah, l'habile humour ! Demander de la précision quand on n'amène que du flou et les références les moins précises. La drôlerie dans la subtilité. Merci. :)
Accessoirement, vous devriez simplement lire les fils dans lesquels vous répondez et poser des questions sur les points de la discussion que vous ne saisissez pas. Là, ne sachant pas ce que vous n'avez pas lu/compris, je ne pourrais rien ajouter que les messages déjà postés ne disent déjà.
[1] www.google.com ou groups.google.com par exemple.
F. Petitjean wrote:
Là c'était
Special cases aren't special enough to break the rules.
qui s'appliquait [1]
Entre autres, merci.
Comme tout le monde, quand je connais la réponse, je suis capable de la
retrouver dans la plupart des principes qui s'y rapportent. Ca ne fait
pas une réponse appropriée d'une liste de généralités.
La référence absente pointait-elle sur quelque chose d'utile ?
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu
de quilles et je m'en excuse )
Ce fil est trouvable dans google [1] si ça vous intéresse.
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse
à mes demandes de précision en comporte encore une (confirmée par votre
intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
Ah, l'habile humour !
Demander de la précision quand on n'amène que du flou et les références
les moins précises.
La drôlerie dans la subtilité. Merci. :)
Accessoirement, vous devriez simplement lire les fils dans lesquels vous
répondez et poser des questions sur les points de la discussion que vous
ne saisissez pas. Là, ne sachant pas ce que vous n'avez pas lu/compris,
je ne pourrais rien ajouter que les messages déjà postés ne disent déjà.
[1] www.google.com ou groups.google.com par exemple.
Là c'était Special cases aren't special enough to break the rules. qui s'appliquait [1]
Entre autres, merci. Comme tout le monde, quand je connais la réponse, je suis capable de la retrouver dans la plupart des principes qui s'y rapportent. Ca ne fait pas une réponse appropriée d'une liste de généralités.
La référence absente pointait-elle sur quelque chose d'utile ?
Quelle était la question ? (je suis arrivé là comme un chien dans un jeu de quilles et je m'en excuse )
Ce fil est trouvable dans google [1] si ça vous intéresse.
J'ai surinterprété une phrase légèrement imprécise de Michel. Sa réponse à mes demandes de précision en comporte encore une (confirmée par votre intervention) mais on va finir y arriver. ;)
Je l'espère aussi. Si vous pouviez être un tantinet plus précis ...
Ah, l'habile humour ! Demander de la précision quand on n'amène que du flou et les références les moins précises. La drôlerie dans la subtilité. Merci. :)
Accessoirement, vous devriez simplement lire les fils dans lesquels vous répondez et poser des questions sur les points de la discussion que vous ne saisissez pas. Là, ne sachant pas ce que vous n'avez pas lu/compris, je ne pourrais rien ajouter que les messages déjà postés ne disent déjà.
[1] www.google.com ou groups.google.com par exemple.
