Grouper les mots clés du langage Python par catégories

Bonjour,
pour améliorer la coloration syntaxique des codes, je me suis dit qu'il fallait regrouper les mots clés par catégories. Pour le langage Python, je suis arrivé à ce qui suit. Le but est de produire assez de catégories mais pas trop non plus...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Test, boucle & co if,elif,else, is,not,and,or, for,in,while, assert,try,except,finally   Action (des choses qui font quelque chose) from,import,as, global,class, def,del, exec,lambda, print, range, return,yield, with,access,raise, continue,pass,break,   Constant True,False

---

Qu'en pensez-vous ? Y-a-t-il des incohérences ? Des oublis ? Des catégories à ajouter ?

Bonjour rambc,

je crois qu'il n'y aura toujours une part d'arbitraire dans un partitionnement de ce genre, chacun aura des goûts différents. Et puis pour juger il faudrait voir un code coloré...

Certains mots-clés ont plusieurs utilisations distinctes, et je vois que tu as été prudent en regroupant les catégories auxquels ils appartiennent. Comme in, qui s'utilise avec for ainsi que comme opérateur au même niveau que is, and, or, etc. Si tu les avais mis dans des catégories différents, il faudrait colorer in différemment en fonction du contexte, mais cela serait sans doute trop compliqué vu qu'il faudrait une analyse syntaxique... Idem pour as, qui s'utilise avec import et avec with.

range n'est pas un mot-clé, mais un built-in; je crois qu'il vaut mieux le retirer de cette liste. Et access, ça existe ? Je ne connais pas ce mot-clé.

Citation:

---

Envoyé par dividee

range n'est pas un mot-clé, mais un built-in; je crois qu'il vaut mieux le retirer de cette liste.

---

Hum... Peux-tu préciser un peu ?

Citation:

---

Envoyé par dividee

Et access, ça existe ? Je ne connais pas ce mot-clé.

---

J'en sais rien... :mouarf: En fait, il est apparu dans un package LaTeX que je souhaite améliorer un peu. Va falloir mener l'enquête...

Bonjour dividee et merci (on n'est pas des sauvages...).

Citation:

---

Envoyé par rambc

Hum... Peux-tu préciser un peu ?

---

Euh... Ben un mot-clé a un statut particulier dans le langage, il est reconnu par l'analyseur syntaxe comme tel, et ne peut pas être redéfini. Ce n'est pas le cas de range, qui est seulement un built-in, c'est à dire une fonction standard qu'il ne faut pas importer (tout comme list, open, len, ...).

Code:

---

1 2 3 4 5 6 7

>>> in = 2 Traceback ( File "<interactive input>", line 1 in = 2 ^ SyntaxError: invalid syntax >>> range = 2 >>> # pas d'erreur

---

En fait si range n'était pas fourni, il pourrait être écrit sans trop de difficultés.

Et le cas de True et False est un peu particulier également. En Python 2.x, ce ne sont pas des mots-clés mais des built-ins. En Python 3, ils sont devenu des mots-clés. Mais dans ce cas, je dirais: autant prendre les devants et les considérer, pour la coloration syntaxique, comme des mots-clés, même en Python 2.x.

Il y a aussi None, qui, je pense, doit-être considéré comme un mot-clé.

Salut,
La liste des mots clés python est dans documentée dans "The Python Language Reference" et pour la version 3.2, ici
On y trouve:

Code:

---

1 2 3 4 5 6 7

False class finally is return None continue for lambda try True def from nonlocal while and del global not with as elif if or yield assert else import pass break except in raise

---

Pour les builtins, il y a des fonctions et des constantes.
Dans les constantes, nous y retrouvons False, True, None.
Elles ont, de ce fait, un statut assez particulier puisqu'on ne peut pas les redéfinir.
Mais Emacs colore les builtins comment les mots clés, ce qui n'est pas une mauvaise chose.
- W

Bonsoir wiztricks et merci pour les liens.

L'idéal serait de ne plus colorer range dès que l'on tombe sur quelque chose comme range = 2 par exemple.

Tout ceci m'amène donc à ajouter deux catégories : l'une pour les fonctions modifiables, et une autre pour les constantes modifiables. Va falloir que j'étudie ce qu'il se passe pour d'autres langages... J'arrive donc à ce qui suit.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Test, boucle & co if,elif,else, is,not,and,or, for,in,while, assert,try,except,finally   Action (des choses qui font quelque chose) from,import,as, global,nonlocal, class,def, del, lambda, return,yield, with,access,raise, continue,pass,break,   Constante True,False, None   Action modifiable abs,dict,help,min,setattr, all,dir,hex,next,slice, any,divmod,id,object,sorted, ascii,enumerate,input,oct,staticmethod, bin,eval,int,open,str, bool,exec,isinstance,ord,sum, bytearray,filter,issubclass,pow,super, bytes,float,iter,print,tuple, callable,format,len,property,type, chr,frozenset,list,range,vars, classmethod,getattr,locals,repr,zip, compile,globals,map,reversed,__import__, complex,hasattr,max,round, delattr,hash,memoryview,set   Constante modifiable NotImplemented,Ellipsis,__debug__

---

Bonsoir rambc,

Citation:

---

Envoyé par rambc

Code:

---

1 2 3 4 5

Test, boucle & co if,elif,else, is,not,and,or, for,in,while, assert,try,except,finally

---

---

Juste pour dire que j'ai du mal a associer boucle et test.

@+

Bonsoir PauseKawa,
utiliser deux couleurs différentes pour les tests et les boucles n'apporteraient rien de plus que d'augmenter inutilement le nombre de couleurs. Avoir trop de couleurs seraient contre productifs. C'est pour cette raison que j'ai regroupé ces deux types d'actions.

Salut,

Citation:

---

Envoyé par rambc

L'idéal serait de ne plus colorer range dès que l'on tombe sur quelque chose comme range = 2 par exemple.

---

Si c'est ce que vous avez compris j'aurais mieux fait de me taire :oops:
A mon sens le but de la coloration est d'éviter les ennuis i.e. me signaler que je suis peut être en train de faire une bêtise...
Si on ne me montre plus la chose après que... snif.
Enfin c'était mon idée, maintenant c'est vous qui tenez le pinceau.
Cordialement,
- W

Très bon argument, je signe tout de suite ! :ccool: En plus ceci va me faciliter la tâche.

Citation:

---

Envoyé par rambc

Bonsoir PauseKawa,
utiliser deux couleurs différentes pour les tests et les boucles n'apporteraient rien de plus que d'augmenter inutilement le nombre de couleurs. Avoir trop de couleurs seraient contre productifs. C'est pour cette raison que j'ai regroupé ces deux types d'actions.

---

Bonjour!
Les test boucles and co ne sont-ils pas ce qu'on appelle parfois des structures de contrôle?

Peur-être... Je parlerais plutôt de flux.