Proposition : x.( ...?.... ) équivalent à ( ...x.... )
2 réponses
daniel delay
Bonjour à tous
(ps: j'ai également posté ce message sur comp.lang.python)
Je me demandais s'il pouvait être pertinent d'introduire la syntaxe
suivante dans python (ou même dans n'importe quel langage orient objet):
x.( ? ) pourrait être équivalent à ( x )
Ainsi, une expression telle que :
(1) html.stringtohtml(''.join(a.strip().split('/n')[:-1])).lower()
pourrait ainsi être remplacée par :
(2) a.strip().split('/n')[:-1].(''.join(?)).(html.stringtohtml(?)).lower()
Les avantages d'une telle notation :
- L'ordre des opérations se fait toujours dans le même sens, de gauche à
droite. (alors que dans la formulation (1) on a un mélange d'écritures
de gauche à droite et de droite à gauche)
- Le niveau d'imbrications - limité à 2 niveaux de parenthèses -
n'augmente pas avec le nombre d'opérations (alors que cela pose
rapidement un problème avec la formulation (1))
Il en découle les autres avantages suivants :
- L'augmentation de la complexité de la formulation (1) conduit
rapidement à écrire des calculs intermédiaires qui introduisent des
variables intermédiaires inutiles (ne servant qu'une seule fois).
b = a.strip().split('/n')[:-1]
c = ''.join(b)
d = html.stringtohtml(c).lower()
On a du introduire 3 variables supplémentaires pour augmenter la
lisibilité, mais ce sont 3 sources potentielles d'erreurs : il faut
vérifier que b, c et d ne sont pas utilisées ailleurs dans le code.
Au contraire, avec la notation (2), on minimise le recours à des
variables intermédiaires.
- Les classes builtins n'ont pas besoin d'être très riches en fonctions
membres. Par exemple, bien que la classe string ne contienne pas de
fonction membre "tohtml" permettant la facilite d'ecriture s.tohtml()
on se console très rapidement si l'on peut utiliser
s.(html.texttohtml(?)) ou même simplement s.(texttohtml(?)) si on a
fait import html.texttohtml
Quand je construis des expressions en Python, je me retrouve souvent
confronté à un seuil ou la lisibilité devient difficile à cause des
imbrications successives. C'est alors à contre-coeur que je "casse" mes
expression en écrivant des calculs intermédiaires plus lisible, mais qui
introduisent des variables supplémentaires : je trouve ça très moche.
J'ai l'impression que le fait d'introduire ces sortes de modificateurs
successifs x.(...?....).(...?....).(...?....).etc... pourrait résoudre
ce genre de problème, et maintenir un code à la fois lisible et compact.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
F. Petitjean
Bonjour à tous
(ps: j'ai également posté ce message sur comp.lang.python) Voir à la fin de cette réponse (2)
Je me demandais s'il pouvait être pertinent d'introduire la syntaxe suivante dans python (ou même dans n'importe quel langage orient objet):
x.( ? ) pourrait être équivalent à ( x )
Ainsi, une expression telle que : (1) html.stringtohtml(''.join(a.strip().split('/n')[:-1])).lower()
pourrait ainsi être remplacée par : (2) a.strip().split('/n')[:-1].(''.join(?)).(html.stringtohtml(?)).lower()
Votre présentation est un peu rapide et succincte en écrivanr
directement une expression un peu « complexe ». Il me semble qu'une démarche plus progressive serait mieux accueillie par un lecteur, qui à priori n'en a jamais entendu parler. Pour reprendre votre exemple, dans le cadre d'un traitement d'un tampon a, on est amené à considérer : lines = q.strip().split('n') # je suppose que c'est 'n' et non '/n' puis : toutes les lignes sauf la dernière : lines[:-1] puis considérer la chaîne obtenue en concaténant ces lignes (sans fin de lignes, une garnde chaîne seulement !) ''.join(lines[:-1]) ) la grande chaîne obtenue nous voulons appliquer un taitement html.stringtohtml(..) qui donne une nouvelle cahîne sur laquelle on applique .lower(). (ouf!)
Je ne vous apprendrai rien si je vous parle de notation préfixée, postfixée ou infixée. Ainsi c = a + b utilise un opérateur + en notation infixée, cette même opératio d'addition va s'écrire en Forth ou PostScript en notation postfixée : a b add (PostScript) et les gourous de Lisp/Scheme/... vous donneront la seule « vraie » notation préfixée (ce qui vous obligera à utiliser des parenthèses).
Vous remarquez que si je veux écrire (a+b) fois (c+d) avec un opérateur de multification (fois ou mul) j'ai droit à au mois deux jeux de paraenthèses dans la notation infixée utilisée par Python : res = (a+b) * (c+d) un nombre supérieur en Lisp (que je ne sais pas écrire) et zéro parenthèse en notation postfixée : a b add c d add mul # PostScript (exercice : écrire l'état de la pile avant et après l'opérateur divmod.)
Autrement dit : si vous avez envie d'écrire des expressions complexes sans vous embêter à trouver des noms pour les résultats intermédiaores ou à mettre des parenthèses passez à un langage à pile comme Forth ou PostScript, et c'est très facile pour peu que vous ayez jadis utilisé une calculette comme la HP 48 ou autre qui utilise la notation polonaise inverse (RPN). Naturellemnt, une fois que vous avez trouvé les bins mots-clé (*), vous pouvez nous concocter un langage à pile ( à la Forth ) qui a une syntaxe décente, une sémantique précise et qui respecte un peu mieux les princopes définis dans le Zen de Python (import this). Par exemple, nous pouvons écrire c = a + b, c = a.__add__(b) ou même faire preuve de réativité c = b.__radd__(a). Dans le nouveau langage il n'y aurait à priori qu'une manière d'écrire : a b add et b a add remplace la notation ésotérique b.__radd__(a).
Les avantages d'une telle notation :
- L'ordre des opérations se fait toujours dans le même sens, de gauche à droite. (alors que dans la formulation (1) on a un mélange d'écritures de gauche à droite et de droite à gauche) Une pile est une pile
- Le niveau d'imbrications - limité à 2 niveaux de parenthèses - n'augmente pas avec le nombre d'opérations (alors que cela pose rapidement un problème avec la formulation (1)) Une pile est une pile. Les parenthèses connait pas. (en Forth c'est pour
les commentaires, autrement dit pour les pas bons qui ont besoin d'indications sur ce que fait ke code :-) )
Il en découle les autres avantages suivants :
- L'augmentation de la complexité de la formulation (1) conduit rapidement à écrire des calculs intermédiaires qui introduisent des variables intermédiaires inutiles (ne servant qu'une seule fois). b = a.strip().split('/n')[:-1] c = ''.join(b) d = html.stringtohtml(c).lower() Une pile est une pile
On a du introduire 3 variables supplémentaires pour augmenter la lisibilité, mais ce sont 3 sources potentielles d'erreurs : il faut vérifier que b, c et d ne sont pas utilisées ailleurs dans le code. Au contraire, avec la notation (2), on minimise le recours à des variables intermédiaires. Une pile est une pile
Voilà que je radote ;-) Vous avez redécouvert les avantages ingérents à une pile contenant des résultats intermédiaires ou tout ce qu'on a pu y mettre qui n'a pas été consommé/utilisé.
Les avantages que vous citez sont réels mais accessibles seulement à ceux qui ont bien compris le mécanisme sous-jacent à une pile LIFO. Mais tout espoir n'est pas perdu, si vous faites preuvent de pédagogie et demandez par exemple de résoudre un problème simple, concret : Toto est un gentil garçcon qui veut aider sa maman en essuyant la vaisselle. Il y a, pour chacun des membres de la famille (papa, maman et Toto) une assiette plate et une assiette creuse (pour la soupe, car Toto mange sa soupe). Comment va-t-il s'y prendre pour ranger les assiettes de telle sorte que les assiettes creuses sont toutes au-dessus des assiettes plates ? (on ne mélange pas les torchons et les serviettes dans la famille de Toto). Le jour suivant vous embrayez sur les tours de Hanoï et vous vous félicitez d'avoir fait comprendre un principe très important en algorithmique : la récursivité. Naturellement vous donnez la réponse au problème en langage de tous les jours te dans le langage informatique que vous avez conçu, en montrant comme il est facile de passer de l'un à l'autre.
- Les classes builtins n'ont pas besoin d'être très riches en fonctions membres. Par exemple, bien que la classe string ne contienne pas de fonction membre "tohtml" permettant la facilite d'ecriture s.tohtml() on se console très rapidement si l'on peut utiliser s.(html.texttohtml(?)) ou même simplement s.(texttohtml(?)) si on a fait import html.texttohtml
Quand je construis des expressions en Python, je me retrouve souvent confronté à un seuil ou la lisibilité devient difficile à cause des imbrications successives. C'est alors à contre-coeur que je "casse" mes expression en écrivant des calculs intermédiaires plus lisible, mais qui introduisent des variables supplémentaires : je trouve ça très moche.
J'ai l'impression que le fait d'introduire ces sortes de modificateurs successifs x.(...?....).(...?....).(...?....).etc... pourrait résoudre ce genre de problème, et maintenir un code à la fois lisible et compact.
Qu'en pensez-vous ?
Daniel Delay
Notes: (*) j'ai un doute sur l'orthographe de « mot-clé » au pluriel. Si une âme charitable et compétente en orthographe pouvait relire ce message et envoyer un corrigé, elle est la bienvenue.
(2) Il se trouve qu'il y a pas mal de temps j'avais imaginé un langage mixant PostScipt et python (disons psython) avec par exemple pour une fonction telle que sum qui prend un nombre variable d'arguments : () 1 2 3 sum # 6 sur la pile () est la marque de fin d'arguments en python on aurait écrit sum(3, 2, 1)
Pour les définitions (dans un module) /nom valeur def (inspiré de PostScropt) avec souvent calcul laissant un résultat sur la pile et /nom exch def. Vous pouvez être encore plus intransigeant en exigeant que les fonctions soient obligatoirement définies avec un doc-string et donc que ce doc-string soit présent sur la pile au moment du def (les varaibles sont alors aussi documentées) ...
Bref, il faudrait que je retrouve mes notes. Et j'ai constaté récemment qu'on est à 6 mois du poisson d'avril et donc qu'un message sur comp.lang.python pour proposer psython serait le bienvenu.
Bonjour à tous
(ps: j'ai également posté ce message sur comp.lang.python)
Voir à la fin de cette réponse (2)
Je me demandais s'il pouvait être pertinent d'introduire la syntaxe
suivante dans python (ou même dans n'importe quel langage orient objet):
x.( ? ) pourrait être équivalent à ( x )
Ainsi, une expression telle que :
(1) html.stringtohtml(''.join(a.strip().split('/n')[:-1])).lower()
pourrait ainsi être remplacée par :
(2) a.strip().split('/n')[:-1].(''.join(?)).(html.stringtohtml(?)).lower()
Votre présentation est un peu rapide et succincte en écrivanr
directement une expression un peu « complexe ». Il me semble qu'une
démarche plus progressive serait mieux accueillie par un lecteur, qui à
priori n'en a jamais entendu parler.
Pour reprendre votre exemple, dans le cadre d'un traitement d'un
tampon a, on est amené à considérer :
lines = q.strip().split('n') # je suppose que c'est 'n' et non '/n'
puis : toutes les lignes sauf la dernière : lines[:-1]
puis considérer la chaîne obtenue en concaténant ces lignes (sans fin
de lignes, une garnde chaîne seulement !) ''.join(lines[:-1])
) la grande chaîne obtenue nous voulons appliquer un taitement
html.stringtohtml(..) qui donne une nouvelle cahîne sur laquelle on
applique .lower(). (ouf!)
Je ne vous apprendrai rien si je vous parle de notation préfixée,
postfixée ou infixée. Ainsi c = a + b utilise un opérateur + en notation
infixée, cette même opératio d'addition va s'écrire en Forth ou
PostScript en notation postfixée : a b add (PostScript) et les
gourous de Lisp/Scheme/... vous donneront la seule « vraie » notation
préfixée (ce qui vous obligera à utiliser des parenthèses).
Vous remarquez que si je veux écrire (a+b) fois (c+d) avec un
opérateur de multification (fois ou mul) j'ai droit à au mois deux jeux
de paraenthèses dans la notation infixée utilisée par Python :
res = (a+b) * (c+d)
un nombre supérieur en Lisp (que je ne sais pas écrire)
et zéro parenthèse en notation postfixée :
a b add c d add mul # PostScript
(exercice : écrire l'état de la pile avant et après l'opérateur divmod.)
Autrement dit : si vous avez envie d'écrire des expressions complexes
sans vous embêter à trouver des noms pour les résultats intermédiaores
ou à mettre des parenthèses passez à un langage à pile comme Forth ou
PostScript, et c'est très facile pour peu que vous ayez jadis utilisé
une calculette comme la HP 48 ou autre qui utilise la notation polonaise
inverse (RPN). Naturellemnt, une fois que vous avez trouvé les bins
mots-clé (*), vous pouvez nous concocter un langage à pile ( à la Forth
) qui a une syntaxe décente, une sémantique précise et qui respecte un
peu mieux les princopes définis dans le Zen de Python (import this). Par
exemple, nous pouvons écrire c = a + b, c = a.__add__(b) ou même faire
preuve de réativité c = b.__radd__(a). Dans le nouveau langage il n'y
aurait à priori qu'une manière d'écrire : a b add et b a add remplace
la notation ésotérique b.__radd__(a).
Les avantages d'une telle notation :
- L'ordre des opérations se fait toujours dans le même sens, de gauche à
droite. (alors que dans la formulation (1) on a un mélange d'écritures
de gauche à droite et de droite à gauche)
Une pile est une pile
- Le niveau d'imbrications - limité à 2 niveaux de parenthèses -
n'augmente pas avec le nombre d'opérations (alors que cela pose
rapidement un problème avec la formulation (1))
Une pile est une pile. Les parenthèses connait pas. (en Forth c'est pour
les commentaires, autrement dit pour les pas bons qui ont besoin
d'indications sur ce que fait ke code :-) )
Il en découle les autres avantages suivants :
- L'augmentation de la complexité de la formulation (1) conduit
rapidement à écrire des calculs intermédiaires qui introduisent des
variables intermédiaires inutiles (ne servant qu'une seule fois).
b = a.strip().split('/n')[:-1]
c = ''.join(b)
d = html.stringtohtml(c).lower()
Une pile est une pile
On a du introduire 3 variables supplémentaires pour augmenter la
lisibilité, mais ce sont 3 sources potentielles d'erreurs : il faut
vérifier que b, c et d ne sont pas utilisées ailleurs dans le code.
Au contraire, avec la notation (2), on minimise le recours à des
variables intermédiaires.
Une pile est une pile
Voilà que je radote ;-) Vous avez redécouvert les avantages ingérents à
une pile contenant des résultats intermédiaires ou tout ce qu'on a pu y
mettre qui n'a pas été consommé/utilisé.
Les avantages que vous citez sont réels mais accessibles seulement à
ceux qui ont bien compris le mécanisme sous-jacent à une pile LIFO. Mais
tout espoir n'est pas perdu, si vous faites preuvent de pédagogie et
demandez par exemple de résoudre un problème simple, concret :
Toto est un gentil garçcon qui veut aider sa maman en essuyant la
vaisselle. Il y a, pour chacun des membres de la famille (papa, maman et
Toto) une assiette plate et une assiette creuse (pour la soupe, car Toto
mange sa soupe). Comment va-t-il s'y prendre pour ranger les assiettes
de telle sorte que les assiettes creuses sont toutes au-dessus des
assiettes plates ? (on ne mélange pas les torchons et les serviettes
dans la famille de Toto).
Le jour suivant vous embrayez sur les tours de Hanoï et vous vous
félicitez d'avoir fait comprendre un principe très important en
algorithmique : la récursivité. Naturellement vous donnez la réponse au
problème en langage de tous les jours te dans le langage informatique
que vous avez conçu, en montrant comme il est facile de passer de l'un à
l'autre.
- Les classes builtins n'ont pas besoin d'être très riches en fonctions
membres. Par exemple, bien que la classe string ne contienne pas de
fonction membre "tohtml" permettant la facilite d'ecriture s.tohtml()
on se console très rapidement si l'on peut utiliser
s.(html.texttohtml(?)) ou même simplement s.(texttohtml(?)) si on a
fait import html.texttohtml
Quand je construis des expressions en Python, je me retrouve souvent
confronté à un seuil ou la lisibilité devient difficile à cause des
imbrications successives. C'est alors à contre-coeur que je "casse" mes
expression en écrivant des calculs intermédiaires plus lisible, mais qui
introduisent des variables supplémentaires : je trouve ça très moche.
J'ai l'impression que le fait d'introduire ces sortes de modificateurs
successifs x.(...?....).(...?....).(...?....).etc... pourrait résoudre
ce genre de problème, et maintenir un code à la fois lisible et compact.
Qu'en pensez-vous ?
Daniel Delay
Notes:
(*) j'ai un doute sur l'orthographe de « mot-clé » au pluriel. Si une âme
charitable et compétente en orthographe pouvait relire ce message et
envoyer un corrigé, elle est la bienvenue.
(2) Il se trouve qu'il y a pas mal de temps j'avais imaginé un langage
mixant PostScipt et python (disons psython) avec par exemple pour une
fonction telle que sum qui prend un nombre variable d'arguments :
() 1 2 3 sum # 6 sur la pile () est la marque de fin d'arguments
en python on aurait écrit sum(3, 2, 1)
Pour les définitions (dans un module) /nom valeur def (inspiré de
PostScropt) avec souvent calcul laissant un résultat sur la pile et
/nom exch def. Vous pouvez être encore plus intransigeant en exigeant
que les fonctions soient obligatoirement définies avec un doc-string
et donc que ce doc-string soit présent sur la pile au moment du def
(les varaibles sont alors aussi documentées) ...
Bref, il faudrait que je retrouve mes notes.
Et j'ai constaté récemment qu'on est à 6 mois du poisson d'avril et
donc qu'un message sur comp.lang.python pour proposer psython serait
le bienvenu.
(ps: j'ai également posté ce message sur comp.lang.python) Voir à la fin de cette réponse (2)
Je me demandais s'il pouvait être pertinent d'introduire la syntaxe suivante dans python (ou même dans n'importe quel langage orient objet):
x.( ? ) pourrait être équivalent à ( x )
Ainsi, une expression telle que : (1) html.stringtohtml(''.join(a.strip().split('/n')[:-1])).lower()
pourrait ainsi être remplacée par : (2) a.strip().split('/n')[:-1].(''.join(?)).(html.stringtohtml(?)).lower()
Votre présentation est un peu rapide et succincte en écrivanr
directement une expression un peu « complexe ». Il me semble qu'une démarche plus progressive serait mieux accueillie par un lecteur, qui à priori n'en a jamais entendu parler. Pour reprendre votre exemple, dans le cadre d'un traitement d'un tampon a, on est amené à considérer : lines = q.strip().split('n') # je suppose que c'est 'n' et non '/n' puis : toutes les lignes sauf la dernière : lines[:-1] puis considérer la chaîne obtenue en concaténant ces lignes (sans fin de lignes, une garnde chaîne seulement !) ''.join(lines[:-1]) ) la grande chaîne obtenue nous voulons appliquer un taitement html.stringtohtml(..) qui donne une nouvelle cahîne sur laquelle on applique .lower(). (ouf!)
Je ne vous apprendrai rien si je vous parle de notation préfixée, postfixée ou infixée. Ainsi c = a + b utilise un opérateur + en notation infixée, cette même opératio d'addition va s'écrire en Forth ou PostScript en notation postfixée : a b add (PostScript) et les gourous de Lisp/Scheme/... vous donneront la seule « vraie » notation préfixée (ce qui vous obligera à utiliser des parenthèses).
Vous remarquez que si je veux écrire (a+b) fois (c+d) avec un opérateur de multification (fois ou mul) j'ai droit à au mois deux jeux de paraenthèses dans la notation infixée utilisée par Python : res = (a+b) * (c+d) un nombre supérieur en Lisp (que je ne sais pas écrire) et zéro parenthèse en notation postfixée : a b add c d add mul # PostScript (exercice : écrire l'état de la pile avant et après l'opérateur divmod.)
Autrement dit : si vous avez envie d'écrire des expressions complexes sans vous embêter à trouver des noms pour les résultats intermédiaores ou à mettre des parenthèses passez à un langage à pile comme Forth ou PostScript, et c'est très facile pour peu que vous ayez jadis utilisé une calculette comme la HP 48 ou autre qui utilise la notation polonaise inverse (RPN). Naturellemnt, une fois que vous avez trouvé les bins mots-clé (*), vous pouvez nous concocter un langage à pile ( à la Forth ) qui a une syntaxe décente, une sémantique précise et qui respecte un peu mieux les princopes définis dans le Zen de Python (import this). Par exemple, nous pouvons écrire c = a + b, c = a.__add__(b) ou même faire preuve de réativité c = b.__radd__(a). Dans le nouveau langage il n'y aurait à priori qu'une manière d'écrire : a b add et b a add remplace la notation ésotérique b.__radd__(a).
Les avantages d'une telle notation :
- L'ordre des opérations se fait toujours dans le même sens, de gauche à droite. (alors que dans la formulation (1) on a un mélange d'écritures de gauche à droite et de droite à gauche) Une pile est une pile
- Le niveau d'imbrications - limité à 2 niveaux de parenthèses - n'augmente pas avec le nombre d'opérations (alors que cela pose rapidement un problème avec la formulation (1)) Une pile est une pile. Les parenthèses connait pas. (en Forth c'est pour
les commentaires, autrement dit pour les pas bons qui ont besoin d'indications sur ce que fait ke code :-) )
Il en découle les autres avantages suivants :
- L'augmentation de la complexité de la formulation (1) conduit rapidement à écrire des calculs intermédiaires qui introduisent des variables intermédiaires inutiles (ne servant qu'une seule fois). b = a.strip().split('/n')[:-1] c = ''.join(b) d = html.stringtohtml(c).lower() Une pile est une pile
On a du introduire 3 variables supplémentaires pour augmenter la lisibilité, mais ce sont 3 sources potentielles d'erreurs : il faut vérifier que b, c et d ne sont pas utilisées ailleurs dans le code. Au contraire, avec la notation (2), on minimise le recours à des variables intermédiaires. Une pile est une pile
Voilà que je radote ;-) Vous avez redécouvert les avantages ingérents à une pile contenant des résultats intermédiaires ou tout ce qu'on a pu y mettre qui n'a pas été consommé/utilisé.
Les avantages que vous citez sont réels mais accessibles seulement à ceux qui ont bien compris le mécanisme sous-jacent à une pile LIFO. Mais tout espoir n'est pas perdu, si vous faites preuvent de pédagogie et demandez par exemple de résoudre un problème simple, concret : Toto est un gentil garçcon qui veut aider sa maman en essuyant la vaisselle. Il y a, pour chacun des membres de la famille (papa, maman et Toto) une assiette plate et une assiette creuse (pour la soupe, car Toto mange sa soupe). Comment va-t-il s'y prendre pour ranger les assiettes de telle sorte que les assiettes creuses sont toutes au-dessus des assiettes plates ? (on ne mélange pas les torchons et les serviettes dans la famille de Toto). Le jour suivant vous embrayez sur les tours de Hanoï et vous vous félicitez d'avoir fait comprendre un principe très important en algorithmique : la récursivité. Naturellement vous donnez la réponse au problème en langage de tous les jours te dans le langage informatique que vous avez conçu, en montrant comme il est facile de passer de l'un à l'autre.
- Les classes builtins n'ont pas besoin d'être très riches en fonctions membres. Par exemple, bien que la classe string ne contienne pas de fonction membre "tohtml" permettant la facilite d'ecriture s.tohtml() on se console très rapidement si l'on peut utiliser s.(html.texttohtml(?)) ou même simplement s.(texttohtml(?)) si on a fait import html.texttohtml
Quand je construis des expressions en Python, je me retrouve souvent confronté à un seuil ou la lisibilité devient difficile à cause des imbrications successives. C'est alors à contre-coeur que je "casse" mes expression en écrivant des calculs intermédiaires plus lisible, mais qui introduisent des variables supplémentaires : je trouve ça très moche.
J'ai l'impression que le fait d'introduire ces sortes de modificateurs successifs x.(...?....).(...?....).(...?....).etc... pourrait résoudre ce genre de problème, et maintenir un code à la fois lisible et compact.
Qu'en pensez-vous ?
Daniel Delay
Notes: (*) j'ai un doute sur l'orthographe de « mot-clé » au pluriel. Si une âme charitable et compétente en orthographe pouvait relire ce message et envoyer un corrigé, elle est la bienvenue.
(2) Il se trouve qu'il y a pas mal de temps j'avais imaginé un langage mixant PostScipt et python (disons psython) avec par exemple pour une fonction telle que sum qui prend un nombre variable d'arguments : () 1 2 3 sum # 6 sur la pile () est la marque de fin d'arguments en python on aurait écrit sum(3, 2, 1)
Pour les définitions (dans un module) /nom valeur def (inspiré de PostScropt) avec souvent calcul laissant un résultat sur la pile et /nom exch def. Vous pouvez être encore plus intransigeant en exigeant que les fonctions soient obligatoirement définies avec un doc-string et donc que ce doc-string soit présent sur la pile au moment du def (les varaibles sont alors aussi documentées) ...
Bref, il faudrait que je retrouve mes notes. Et j'ai constaté récemment qu'on est à 6 mois du poisson d'avril et donc qu'un message sur comp.lang.python pour proposer psython serait le bienvenu.
Do Re Mi chel La Si Do
Bonsoir !
Juste pour amener ma pierre, à la question sur l'orthographe du pluriel de "mot-clef".
Il me semble que la réforme de l'orthographe de 2003 conseille d'accoler les mots composés (suppression du trait d'union), et propose de leur appliquer les règles générales du pluriel.
En conséquence, on peut écrire "un motclef", et "des motclefs".
J'ai noté que la réforme accepte l'utilisation des anciennes orthographes. Mais, la nouvelle étant plus simple, je ne tiens pas à prendre le risque de me ridiculiser sur ce point...
@-salutations
Michel Claveau
Bonsoir !
Juste pour amener ma pierre, à la question sur l'orthographe du pluriel de
"mot-clef".
Il me semble que la réforme de l'orthographe de 2003 conseille d'accoler les
mots composés (suppression du trait d'union), et propose de leur appliquer
les règles générales du pluriel.
En conséquence, on peut écrire "un motclef", et "des motclefs".
J'ai noté que la réforme accepte l'utilisation des anciennes orthographes.
Mais, la nouvelle étant plus simple, je ne tiens pas à prendre le risque de
me ridiculiser sur ce point...
Juste pour amener ma pierre, à la question sur l'orthographe du pluriel de "mot-clef".
Il me semble que la réforme de l'orthographe de 2003 conseille d'accoler les mots composés (suppression du trait d'union), et propose de leur appliquer les règles générales du pluriel.
En conséquence, on peut écrire "un motclef", et "des motclefs".
J'ai noté que la réforme accepte l'utilisation des anciennes orthographes. Mais, la nouvelle étant plus simple, je ne tiens pas à prendre le risque de me ridiculiser sur ce point...
