J'aurais voulu savoir s'il existait, au delà des conventions de nommage,
un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu
comme dans Java avec le mot clé "private") rendre x accessible dans le
corps de la classe C via le classique self.x, mais rendre x inaccessible
en dehors, c'est-à-dire que obj.x lève une exception avec obj une
instance de la classe C.
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal intentionné veut quand même y accéder, il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Francois a écrit :
Bonjour à tous,
J'aurais voulu savoir s'il existait, au delà des conventions de nommage,
un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu
comme dans Java avec le mot clé "private") rendre x accessible dans le
corps de la classe C via le classique self.x, mais rendre x inaccessible
en dehors, c'est-à-dire que obj.x lève une exception avec obj une
instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé;
- précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal intentionné
veut quand même y accéder, il le pourra quand même (on paye ici le côté 'trop'
dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici
si je ne me trompe.
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal intentionné veut quand même y accéder, il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Francois
kib2 a écrit :
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal intentionné veut quand même y accéder,
Effectivement, c'est ce que j'entendais par "convention de nommage".
il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Pour moi, un utilisateur peut y accéder simplement avec le "." à condition de mettre le bon nom d'attribut. Par exemple, un attribut nommé __x dans la classe C sera accessible en dehors via obj._C__x. Je veux dire par là qu'il n'y a pas besoin de méthodes spéciales pour accéder à l'attribut (enfin il me semble).
Mais justement, ma question était de savoir si en "customisant" la classe C avec les méthodes spéciales ad hoc (genre __getattribute__ ou des choses comme ça), on pouvant simultanément :
1) définir dans une classe C un attribut x et le rendre accessible sans problème dans le corps de la classe via self.x 2) mais rendre x inaccessible en dehors du corps de la classe C, c'est-à-dire que "obj = C() ; obj.x" lève une exception 3) et faire 1) et 2) sans utiliser les conventions de nommage citées plus haut
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça pouvait peut-être réalisable ?
-- François
kib2 a écrit :
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé;
- précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal
intentionné veut quand même y accéder,
Effectivement, c'est ce que j'entendais par "convention de nommage".
il le pourra quand même (on paye
ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui
devrait faire l'affaire ici si je ne me trompe.
Pour moi, un utilisateur peut y accéder simplement avec le "." à
condition de mettre le bon nom d'attribut. Par exemple, un attribut
nommé __x dans la classe C sera accessible en dehors via obj._C__x. Je
veux dire par là qu'il n'y a pas besoin de méthodes spéciales pour
accéder à l'attribut (enfin il me semble).
Mais justement, ma question était de savoir si en "customisant" la
classe C avec les méthodes spéciales ad hoc (genre __getattribute__ ou
des choses comme ça), on pouvant simultanément :
1) définir dans une classe C un attribut x et le rendre accessible sans
problème dans le corps de la classe via self.x
2) mais rendre x inaccessible en dehors du corps de la classe C,
c'est-à-dire que "obj = C() ; obj.x" lève une exception
3) et faire 1) et 2) sans utiliser les conventions de nommage citées
plus haut
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça
pouvait peut-être réalisable ?
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Néanmoins, ce ne sont que des conventions; si un utilisateur mal intentionné veut quand même y accéder,
Effectivement, c'est ce que j'entendais par "convention de nommage".
il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Pour moi, un utilisateur peut y accéder simplement avec le "." à condition de mettre le bon nom d'attribut. Par exemple, un attribut nommé __x dans la classe C sera accessible en dehors via obj._C__x. Je veux dire par là qu'il n'y a pas besoin de méthodes spéciales pour accéder à l'attribut (enfin il me semble).
Mais justement, ma question était de savoir si en "customisant" la classe C avec les méthodes spéciales ad hoc (genre __getattribute__ ou des choses comme ça), on pouvant simultanément :
1) définir dans une classe C un attribut x et le rendre accessible sans problème dans le corps de la classe via self.x 2) mais rendre x inaccessible en dehors du corps de la classe C, c'est-à-dire que "obj = C() ; obj.x" lève une exception 3) et faire 1) et 2) sans utiliser les conventions de nommage citées plus haut
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça pouvait peut-être réalisable ?
-- François
Bruno Desthuilliers
kib2 a écrit :
Francois a écrit :
Bonjour à tous,
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Disons plutôt:
'_attrib' pour signaler que c'est un détail d'implémentation '__attrib' pour 'protéger' un attribut d'une surcharge accidentelle.
Néanmoins, ce ne sont que des conventions;
Dans le second cas, ça invoque quand même un mécanisme de 'name mangling', qui fait qu'en dehors de la classe, il faudra utiliser '_NomClasse__attrib' pour y accéder.
si un utilisateur mal intentionné
Pourquoi "mal intentionné" ? Qu'est-ce que tu sais des raisons qui poussent un "utilisateur" (qui est en l'occurrence, rappelons le, un programmeur) à vouloir accéder à cet attribut ? Aussi étrange que ça paraisse, en général, les développeurs (en tous cas les développeurs Python) n'essaient pas d'accéder aux détails d'implémentation sans une très bonne raison, et ne le font qu'en dernier recours. Bref, c'est le plus souvent soit pour contourner (temporairement) un bug, soit en raison d'un manque dans l'API.
veut quand même y accéder, il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Pas besoin de getattr.
kib2 a écrit :
Francois a écrit :
Bonjour à tous,
J'aurais voulu savoir s'il existait, au delà des conventions de nommage,
un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu
comme dans Java avec le mot clé "private") rendre x accessible dans le
corps de la classe C via le classique self.x, mais rendre x inaccessible
en dehors, c'est-à-dire que obj.x lève une exception avec obj une
instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé;
- précéder ton attribut par "_" pour le rendre protégé;
Disons plutôt:
'_attrib' pour signaler que c'est un détail d'implémentation
'__attrib' pour 'protéger' un attribut d'une surcharge accidentelle.
Néanmoins, ce ne sont que des conventions;
Dans le second cas, ça invoque quand même un mécanisme de 'name
mangling', qui fait qu'en dehors de la classe, il faudra utiliser
'_NomClasse__attrib' pour y accéder.
si un utilisateur mal
intentionné
Pourquoi "mal intentionné" ? Qu'est-ce que tu sais des raisons qui
poussent un "utilisateur" (qui est en l'occurrence, rappelons le, un
programmeur) à vouloir accéder à cet attribut ? Aussi étrange que ça
paraisse, en général, les développeurs (en tous cas les développeurs
Python) n'essaient pas d'accéder aux détails d'implémentation sans une
très bonne raison, et ne le font qu'en dernier recours. Bref, c'est le
plus souvent soit pour contourner (temporairement) un bug, soit en
raison d'un manque dans l'API.
veut quand même y accéder, il le pourra quand même (on paye
ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui
devrait faire l'affaire ici si je ne me trompe.
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Merci d'avance.
Il existe des conventions :
- précéder ton attribut par "__" pour le rendre privé; - précéder ton attribut par "_" pour le rendre protégé;
Disons plutôt:
'_attrib' pour signaler que c'est un détail d'implémentation '__attrib' pour 'protéger' un attribut d'une surcharge accidentelle.
Néanmoins, ce ne sont que des conventions;
Dans le second cas, ça invoque quand même un mécanisme de 'name mangling', qui fait qu'en dehors de la classe, il faudra utiliser '_NomClasse__attrib' pour y accéder.
si un utilisateur mal intentionné
Pourquoi "mal intentionné" ? Qu'est-ce que tu sais des raisons qui poussent un "utilisateur" (qui est en l'occurrence, rappelons le, un programmeur) à vouloir accéder à cet attribut ? Aussi étrange que ça paraisse, en général, les développeurs (en tous cas les développeurs Python) n'essaient pas d'accéder aux détails d'implémentation sans une très bonne raison, et ne le font qu'en dernier recours. Bref, c'est le plus souvent soit pour contourner (temporairement) un bug, soit en raison d'un manque dans l'API.
veut quand même y accéder, il le pourra quand même (on paye ici le côté 'trop' dynamique de Python) avec un petit "getattr" qui devrait faire l'affaire ici si je ne me trompe.
Pas besoin de getattr.
Bruno Desthuilliers
Francois a écrit :
Bonjour à tous,
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Bien que ce ne soit pas rigoureusement impossible, c'est très très lourd à mettre en place, très cher en matière de perfs, et toujours contournable.
Si ce n'est pas indiscret : pourquoi cette question ? quel intérêt vois-tu à la chose, quand l'expérience prouve qu'on vit aussi bien - si ce n'est mieux - sans ?
Francois a écrit :
Bonjour à tous,
J'aurais voulu savoir s'il existait, au delà des conventions de nommage,
un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu
comme dans Java avec le mot clé "private") rendre x accessible dans le
corps de la classe C via le classique self.x, mais rendre x inaccessible
en dehors, c'est-à-dire que obj.x lève une exception avec obj une
instance de la classe C.
Bien que ce ne soit pas rigoureusement impossible, c'est très très lourd
à mettre en place, très cher en matière de perfs, et toujours contournable.
Si ce n'est pas indiscret : pourquoi cette question ? quel intérêt
vois-tu à la chose, quand l'expérience prouve qu'on vit aussi bien - si
ce n'est mieux - sans ?
J'aurais voulu savoir s'il existait, au delà des conventions de nommage, un moyen canonique pour rendre un attribut x privé, c'est-à-dire (un peu comme dans Java avec le mot clé "private") rendre x accessible dans le corps de la classe C via le classique self.x, mais rendre x inaccessible en dehors, c'est-à-dire que obj.x lève une exception avec obj une instance de la classe C.
Bien que ce ne soit pas rigoureusement impossible, c'est très très lourd à mettre en place, très cher en matière de perfs, et toujours contournable.
Si ce n'est pas indiscret : pourquoi cette question ? quel intérêt vois-tu à la chose, quand l'expérience prouve qu'on vit aussi bien - si ce n'est mieux - sans ?
Bruno Desthuilliers
Francois a écrit :
Rakotomandimby (R12y) Mihamina a écrit :
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que Python laisse au programmeur. J'avais même lu (mais je ne sais plus où également) qu'un argument humoristique sur ce point disait : « on est entre adultes consentants ! »
Recherche "we're all consenting adults here" sur c.l.py - ça revient au moins une fois par mois depuis plusieurs années.
Francois a écrit :
Rakotomandimby (R12y) Mihamina a écrit :
En gros, Python ne souhaite pas "interdire". Il laisse le choix au
programmeur de faire des trucs "sales" si il insiste.
Si quelqu'un a des références officielles de ces "arguments" je suis
interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que
Python laisse au programmeur. J'avais même lu (mais je ne sais plus où
également) qu'un argument humoristique sur ce point disait : « on est
entre adultes consentants ! »
Recherche "we're all consenting adults here" sur c.l.py - ça revient au
moins une fois par mois depuis plusieurs années.
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que Python laisse au programmeur. J'avais même lu (mais je ne sais plus où également) qu'un argument humoristique sur ce point disait : « on est entre adultes consentants ! »
Recherche "we're all consenting adults here" sur c.l.py - ça revient au moins une fois par mois depuis plusieurs années.
Bruno Desthuilliers
kib2 a écrit :
Dingue ça,
BD a toujours réponse à tout et tout ce que les autres font ou expliquent, c'est toujours mal... bref, passons.
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au moins le courage de citer nommément le malfaisant que tu t'apprêtes a pourfendre. Surtout quand le vilain en question ne se donne même pas la peine d'utiliser un pseudonyme pour couvrir ses méfaits.
kib2 a écrit :
Dingue ça,
BD a toujours réponse à tout et tout ce que les autres font ou
expliquent, c'est toujours mal... bref, passons.
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au
moins le courage de citer nommément le malfaisant que tu t'apprêtes a
pourfendre. Surtout quand le vilain en question ne se donne même pas la
peine d'utiliser un pseudonyme pour couvrir ses méfaits.
BD a toujours réponse à tout et tout ce que les autres font ou expliquent, c'est toujours mal... bref, passons.
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au moins le courage de citer nommément le malfaisant que tu t'apprêtes a pourfendre. Surtout quand le vilain en question ne se donne même pas la peine d'utiliser un pseudonyme pour couvrir ses méfaits.
Rakotomandimby (R12y) Mihamina
Francois wrote:
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça pouvait peut-être réalisable ?
Je ne sais plus dans quel bouquin je l'ai lu, mais il me semble que c'est volontaire dans Python de ne pas mettre d'attributs privés. Je ne saurais retrouver la référence du passage, mais il y a de fortes chances que je l'ai lu dans le livre de Tarek Ziadé (Programmation Python). Je crois, mais ça fait longtemps que je l'ai lu, que ce "principe" et celui du "Duck Typing" sont des principes relativement importants en Python.
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça
pouvait peut-être réalisable ?
Je ne sais plus dans quel bouquin je l'ai lu, mais il me semble que
c'est volontaire dans Python de ne pas mettre d'attributs privés. Je ne
saurais retrouver la référence du passage, mais il y a de fortes chances
que je l'ai lu dans le livre de Tarek Ziadé (Programmation Python).
Je crois, mais ça fait longtemps que je l'ai lu, que ce "principe" et
celui du "Duck Typing" sont des principes relativement importants en Python.
En gros, Python ne souhaite pas "interdire". Il laisse le choix au
programmeur de faire des trucs "sales" si il insiste.
Si quelqu'un a des références officielles de ces "arguments" je suis
interessé car c'est bete, je ne les retrouve pas...
Je me disais qu'avec toute la flopée de méthodes spéciales (__truc__) ça pouvait peut-être réalisable ?
Je ne sais plus dans quel bouquin je l'ai lu, mais il me semble que c'est volontaire dans Python de ne pas mettre d'attributs privés. Je ne saurais retrouver la référence du passage, mais il y a de fortes chances que je l'ai lu dans le livre de Tarek Ziadé (Programmation Python). Je crois, mais ça fait longtemps que je l'ai lu, que ce "principe" et celui du "Duck Typing" sont des principes relativement importants en Python.
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que Python laisse au programmeur. J'avais même lu (mais je ne sais plus où également) qu'un argument humoristique sur ce point disait : « on est entre adultes consentants ! »
Donc ce n'est pas dans la philosophie de Python, nous sommes d'accord. Mais cela veut-il dire que c'est pour autant impossible à réaliser en Python ? C'est là ma question : peut-on faire un attribut "private" à la manière de Java ?
-- François
Rakotomandimby (R12y) Mihamina a écrit :
En gros, Python ne souhaite pas "interdire". Il laisse le choix au
programmeur de faire des trucs "sales" si il insiste.
Si quelqu'un a des références officielles de ces "arguments" je suis
interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que
Python laisse au programmeur. J'avais même lu (mais je ne sais plus où
également) qu'un argument humoristique sur ce point disait : « on est
entre adultes consentants ! »
Donc ce n'est pas dans la philosophie de Python, nous sommes d'accord.
Mais cela veut-il dire que c'est pour autant impossible à réaliser en
Python ? C'est là ma question : peut-on faire un attribut "private" à la
manière de Java ?
En gros, Python ne souhaite pas "interdire". Il laisse le choix au programmeur de faire des trucs "sales" si il insiste. Si quelqu'un a des références officielles de ces "arguments" je suis interessé car c'est bete, je ne les retrouve pas...
Oui, j'ai lu aussi des trucs là dessus, sur le principe de "liberté" que Python laisse au programmeur. J'avais même lu (mais je ne sais plus où également) qu'un argument humoristique sur ce point disait : « on est entre adultes consentants ! »
Donc ce n'est pas dans la philosophie de Python, nous sommes d'accord. Mais cela veut-il dire que c'est pour autant impossible à réaliser en Python ? C'est là ma question : peut-on faire un attribut "private" à la manière de Java ?
-- François
kib2
Dingue ça,
BD a toujours réponse à tout et tout ce que les autres font ou expliquent, c'est toujours mal...bref, passons.
Cette recette du cookbook pourra peut être aider (pas testé): http://code.activestate.com/recipes/573442/
Dingue ça,
BD a toujours réponse à tout et tout ce que les autres font ou expliquent,
c'est toujours mal...bref, passons.
Cette recette du cookbook pourra peut être aider (pas testé):
http://code.activestate.com/recipes/573442/
BD a toujours réponse à tout et tout ce que les autres font ou expliquent, c'est toujours mal...bref, passons.
Cette recette du cookbook pourra peut être aider (pas testé): http://code.activestate.com/recipes/573442/
Bruno Desthuilliers
kib2 a écrit :
Bruno Desthuilliers a écrit :
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au moins le courage de citer nommément le malfaisant que tu t'apprêtes a pourfendre. Surtout quand le vilain en question ne se donne même pas la peine d'utiliser un pseudonyme pour couvrir ses méfaits.
Si en outre il faut expliquer : qui possède des initiales "BD" ayant répondu à ce message ? A part toi Bruno, je ne vois pas.
Ne le prend pas pour une attaque perso,
Excuse moi si j'ai du mal à ne pas prendre une attaque perso pour une attaque perso, hein...
c'est seulement un constat : à chaque fois que j'ai lu récemment
récemment...
tes messages, c'était pour critiquer. Le dernier en date étant sur Windows.
Je regrettais effectivement le fait que les contribs de notre MCI national se limitent à des trucs tout à fait spécifiquement Windows. Et je l'ai effectivement formulé d'une manière aussi abrupte qu'inélégante - que Michel daigne m'en pardonner (Michel, si tu me lis...).
Mais bon, je doute que ce seul post suffise à justifier l'animosité dont tu fais preuve à mon égard...
Figure-toi qu'on est pas tous barbus comme Stallman,
Moi non plus
qu'on a pas tous un OS basé sur *nix,
Moi aussi !-)
Accessoirement, les unices gratuits ne manquent pas, donc rien ne t'empêche d'en installer un sur ta machine...
qu'on ne tape pas tous sur un clavier Dvorak,
Moi non plus.
et que néanmoins on peut vivre une vie tout à fait normale, même sans EMacs.
On peut même vivre une vie tout à fait normale sans ordinateur.
Voilà c'est tout; je te trouve simplement un peu hautain vis à vis de nous les humains qui de temps en temps essayons de comprendre les mécanismes sous jacents au Python.
Tu devrais peut-être relire les posts où j'essaie d'aider autant que je le peux (compte tenu de mon total manque de pédagogie). En essayant éventuellement de laisser (au moins momentanément) la forme de côté pour t'intéresser au fond.
kib2 a écrit :
Bruno Desthuilliers a écrit :
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au
moins le courage de citer nommément le malfaisant que tu t'apprêtes a
pourfendre. Surtout quand le vilain en question ne se donne même pas la
peine d'utiliser un pseudonyme pour couvrir ses méfaits.
Si en outre il faut expliquer : qui possède des initiales "BD" ayant
répondu à ce message ? A part toi Bruno, je ne vois pas.
Ne le prend pas pour une attaque perso,
Excuse moi si j'ai du mal à ne pas prendre une attaque perso pour une
attaque perso, hein...
c'est seulement un constat : à
chaque fois que j'ai lu récemment
récemment...
tes messages, c'était pour critiquer.
Le dernier en date étant sur Windows.
Je regrettais effectivement le fait que les contribs de notre MCI
national se limitent à des trucs tout à fait spécifiquement Windows. Et
je l'ai effectivement formulé d'une manière aussi abrupte qu'inélégante
- que Michel daigne m'en pardonner (Michel, si tu me lis...).
Mais bon, je doute que ce seul post suffise à justifier l'animosité dont
tu fais preuve à mon égard...
Figure-toi qu'on est pas tous barbus comme Stallman,
Moi non plus
qu'on a pas tous un
OS basé sur *nix,
Moi aussi !-)
Accessoirement, les unices gratuits ne manquent pas, donc rien ne
t'empêche d'en installer un sur ta machine...
qu'on ne tape pas tous sur un clavier Dvorak,
Moi non plus.
et que
néanmoins on peut vivre une vie tout à fait normale, même sans EMacs.
On peut même vivre une vie tout à fait normale sans ordinateur.
Voilà c'est tout; je te trouve simplement un peu hautain vis à vis de
nous les humains qui de temps en temps essayons de comprendre les
mécanismes sous jacents au Python.
Tu devrais peut-être relire les posts où j'essaie d'aider autant que je
le peux (compte tenu de mon total manque de pédagogie). En essayant
éventuellement de laisser (au moins momentanément) la forme de côté pour
t'intéresser au fond.
Si tu tiens à tout prix à te lancer dans les attaques persos, ait au moins le courage de citer nommément le malfaisant que tu t'apprêtes a pourfendre. Surtout quand le vilain en question ne se donne même pas la peine d'utiliser un pseudonyme pour couvrir ses méfaits.
Si en outre il faut expliquer : qui possède des initiales "BD" ayant répondu à ce message ? A part toi Bruno, je ne vois pas.
Ne le prend pas pour une attaque perso,
Excuse moi si j'ai du mal à ne pas prendre une attaque perso pour une attaque perso, hein...
c'est seulement un constat : à chaque fois que j'ai lu récemment
récemment...
tes messages, c'était pour critiquer. Le dernier en date étant sur Windows.
Je regrettais effectivement le fait que les contribs de notre MCI national se limitent à des trucs tout à fait spécifiquement Windows. Et je l'ai effectivement formulé d'une manière aussi abrupte qu'inélégante - que Michel daigne m'en pardonner (Michel, si tu me lis...).
Mais bon, je doute que ce seul post suffise à justifier l'animosité dont tu fais preuve à mon égard...
Figure-toi qu'on est pas tous barbus comme Stallman,
Moi non plus
qu'on a pas tous un OS basé sur *nix,
Moi aussi !-)
Accessoirement, les unices gratuits ne manquent pas, donc rien ne t'empêche d'en installer un sur ta machine...
qu'on ne tape pas tous sur un clavier Dvorak,
Moi non plus.
et que néanmoins on peut vivre une vie tout à fait normale, même sans EMacs.
On peut même vivre une vie tout à fait normale sans ordinateur.
Voilà c'est tout; je te trouve simplement un peu hautain vis à vis de nous les humains qui de temps en temps essayons de comprendre les mécanismes sous jacents au Python.
Tu devrais peut-être relire les posts où j'essaie d'aider autant que je le peux (compte tenu de mon total manque de pédagogie). En essayant éventuellement de laisser (au moins momentanément) la forme de côté pour t'intéresser au fond.
