Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

Pourquoi pas des string literals regexp en Python ? Ex: re".*"

+1 vote

L'idée serai d'intégrer un peu plus les regexp au langage, un peu comme en Perl où le surcoût à l'utilisation d'une regexp est faible… Là on pourrait faire :

>>> import re
>>> if re".k" in 'ok':
    ... print "ok"
ok
>>> 

Vu qu'on a déjà les : u" ", r" ", b" ", br" ", …

demandé 23-Mar par Siltaar (112 points)

3 Réponses

+1 vote

Je pense que cela irait mieux sur le reddit de s&m
https://www.reddit.com/r/sametmax/

répondu 24-Mar par ptank (278 points)
+1 vote

Si la suggestion te semble assez intéressante pour être porté à la communauté, tu as la mailing-list python-ideas qui est dédié aux suggestions de nouvelles features.

Après je suis pas convaincu que la syntaxe que tu propose soit possible (ça rentrerai directement en syntax error), il faudrait que le

re""

soit un built-in?
Mais je me plante peut-être.

répondu 24-Mar par Poisson (256 points)

Ma proposition est bien d'ajouter re" " comme built-in.

+1 vote

Ca inciterait les gens à utiliser plus les regexs, et pour des raisons de lisibilité et performance ce n'est pas à encourager.

Mais avec in, strip(), replace(), split(), startswith() et endswith() on peut déjà éliminer 80% des cas d'usage des regexs en perl/javascript. Ils sont plus rapides et plus lisibles et il faut les privilégier.

Pour les rares cas qui restent, importer re n'est pas la mort.

J'adore les regex, je les connais très bien, et pourtant je dois en écrire une par mois grand max en Python. Un import par mois ne justifie pas un builtin.

Pourtant j'avoues, j'ai voulu ce poney aussi. C'est juste que comme les impôts, je comprends qu'il faut privilégier l'interêt général.

répondu 30-Mar par Sam (4,952 points)

Sur Python-ideas il a été soulevé que re"" c'était deux lettres, sans être un assemblage de deux fonctionnalités, les autres string-litterals de ce type ayant une lettre par fonctionnalité (bon, il suffirait de choisir une seule lettre pour les regexp, comme m"" pour match, ou k"" pour Kleene, ou /""…).

Ensuite, on m'a avancé qu'il y a plusieurs lib de regexp en Python et qu'en privilégier une ne serait pas bon (alors qu'il y en a déjà une par défaut).

J'admet que les fonctions "lib-static" comme : mo = re.search(r'.k', mystring) ; sont moins pénibles à utiliser que celles prévues pour être compilées (comme en Ada, ou en partie en Python).

L'argument de la performance, je l'avais en tête en commençant cette démarche vu que c'est l'argument des Lua-istes pour ne pas avoir de re dans leur stdlib. Mais il n'a pas été clairement ré-exposés sur Python-ideas, merci donc d'avoir complété. Toutefois, mon point de vue sur la question est que bricoler des trucs fragiles (.startswith…) alors qu'il existe un outil prévu pour, ça ne me semble toujours pas une bonne idée. Tu perds plein de temps à te dire que ton traitement doit pouvoir rentrer dans une forme de cas particulier, et faut recommancer quand il apparait clairement que non.

Ensuite, sur Python-ideas le débat dérive vers les VerbalExpressions, un sous ensemble d'expression régulières, voulues plus faciles à maintenir :
- https://github.com/VerbalExpressions/implementation/wiki/List-of-methods-to-implement

Certaines de mes objections n'ont pas encore de réponses, mais je dois reconnaître que j'ai été bien accueilli sur la liste, et que chacun s'applique à détacher les arguments des opinions. Il est rassurant pour l'avenir de Python de trouver cette qualité de débat sur Python-ideas.


Bon par contre, j'ai encore codé un petit script de tri de courriels en Python cette semaine, et :
- l'UTF-8 strict par défaut de Python3 est pénible face à la réalité du monde (où tu croises des bouts de mails mal encodés, en on-ne-sais quel encodage) ;
- la version Python2.7 est 20% plus performante que la version Python3.4.

D'ailleurs je trouve déloyal de dire que Python3 devient plus performant dans sa version 3.6, si la seule raison c'est que les nouvelles améliorations générales ne sont plus backportées dans Python2… Est-ce que cela appelle à un fork de Python2.7 pour le garder à jour ? Genre : Cobra, 20% plus rapide que Python3.X !

UTF-8 est un standard qui n'arrange que les américains en faisant reposer la complexité et les lenteurs sur les autres, c'est déloyal et c'est donc un mauvais encoding. UTF32 pour tout le monde, et parlons Esperanto ! (d'ici quelques générations, on pourrait revenir à du ASCII du coup, si on parle tous en Espéranto… ou un petit encoding Ad-Hoc)


PS : reCAPCHAT, c'est pas super fiable… le précédent croisé sur IndexError ne s'est juste jamais chargé. Et après, me dire que je bosse gratuitement pour Google, c'est démoralisant :p

...