Création d'un programme basique

Salut,

Citation:

---

Envoyé par Sve@r

Pour être honnête, le "égal" et "in" sont quasiment équivalents.

---

Déjà çà mesure le temps mis pour exécuter toute la fonction et ce qu'on cherche à mesurer (le test de casse) s'exécutera autant de fois qu'il y a de caractères dans la chaîne passées en argument.

Avec 4 caractères, si on noie le pouième qu'on cherche à mesurer dans l'overhead , il n'est pas anormal de trouver des temps semblables.

- W

Salut,

Citation:

---

Envoyé par Sve@r

Pour être honnête, le "égal" et "in" sont quasiment équivalents. Parfois c'est le "égal" qui devance, parfois c'est le "in". Mais le regex lui est carrément à la rue *10. C'est compréhensible, c'est un truc énorme le regex (mais peut-être j'ai pas pris la bonne méthode)...

---

Merci pour le test. Oui effectivement avec la regex c'est beaucoup plus long mais il y a peut-être des fonctions plus rapides, certaines fonctions font peut-être plus de choses (comme fournir les positions des éléments trouvés) que juste chercher ce qui expliquerait en partie qu'elles soient plus longues...

Enfin je ne connais pas les fonctions python je parle en général par rapport à d'autres langages.

Et aussi apparemment pour la regex, tu as utilisé une chaine de caractère mais je me demande si ce ne serait pas plus rapide avec un intervalle : [a-z]. La regex c'est une boite noire mais on peut penser que ce serait optimisé dans ce cas c'est-à-dire que cela se rapprocherait de la double comparaisons puisque là aussi on a les deux extrémités d'un intervalle.

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

Citation:

---

Envoyé par Sve@r

Il ne s'agit pour le processeur que de 2 tests d'égalité. L'opération "in" implique fatalement une boucle. Dans ce cas précis la boucle ne concerne que 26 éléments donc elle peut être rapide mais si on prend un cas plus général...

---

Oui il doit y avoir une boucle quelque part et du coup cela complique l'analyse car je suppose que la rapidité de la double comparaison doit être la même quelque soit la lettre testée alors qu'avec le in cela dépendra de la lettre : le plus rapide pour la lettre a et le plus lent pour la lettre z.

Citation:

---

Envoyé par Beginner.

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

---

C'est une bonne remarque. Indépendamment du langage, quand une même expression régulière est utilisée plusieurs fois, il vaut mieux la compiler une seule fois.

Comment Python gère-t-il la compilation des expression régulières ? Pour ceux que ça intéresse, il faut regarder le code source.
En haut de la documentation du module re, il y a un lien vers le code source du module.

La fonction re.search est définie ici :

Code:

---

1 2 3 4

def search(pattern, string, flags=0): """Scan through string looking for a match to the pattern, returning     a Match object, or None if no match was found.""" return _compile(pattern, flags).search(string)

---

_compile équivaut à re.compile :

Code:

---

1 2 3

def compile(pattern, flags=0): "Compile a regular expression pattern, returning a Pattern object." return _compile(pattern, flags)

---

Quand une même expression régulière est utilisée plusieurs fois, il vaut mieux appeler une seule fois re.compile.
Par exemple, de mon côté, quand une expression régulière est statiquement connue, je la compile au moment de l'import avec re.compile et je mets le résultat dans une variable globale.

Cela dit, en pratique, si on regarde le code source de _compile, on voit qu'il y a de la mémoïsation : jusqu'à 512 résultats de _compile sont gardés en mémoire, les plus récents étant prioritaires sur les plus anciens. Du coup, en vrai, si on appelle re.search en boucle avec la même expression régulière, même si la fonction _compile sera appelée inutilement en boucle, l'expression régulière ne sera pas compilée en boucle.

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

_cache = {} # ordered!   _MAXCACHE = 512 def _compile(pattern, flags): # internal: compile pattern if isinstance(flags, RegexFlag): flags = flags.value try: return _cache[type(pattern), pattern, flags] except KeyError: pass if isinstance(pattern, Pattern): if flags: raise ValueError( "cannot process flags argument with a compiled pattern") return pattern if not sre_compile.isstring(pattern): raise TypeError("first argument must be string or compiled pattern") p = sre_compile.compile(pattern, flags) if not (flags & DEBUG): if len(_cache) >= _MAXCACHE: # Drop the oldest item try: del _cache[next(iter(_cache))] except (StopIteration, RuntimeError, KeyError): pass _cache[type(pattern), pattern, flags] = p return p

---

Merci.

Citation:

---

Envoyé par Pyramidev

Comment Python gère-t-il la compilation des expression régulières ? Pour ceux que ça intéresse, il faut regarder le code source.
En haut de la documentation du module re, il y a un lien vers le code source du module.

---

Ah je ne savais pas qu'il y avait le code source...

Mais du coup je me demande si il existe des outils qui permettent de voir comment telle ou telle regex est exécutée. C'est-à-dire est-il possible de connaitre l'algorithme correspondant à une regex ? Cela permettrait de savoir comment optimiser l'écriture de notre regex.

Exemple concret, je me demande si il y a une différence entre [a-z] et [abcdefghijklmnopqrstuvwxyz] ? Ou entre [0-9] et [0123456789] ?

Un site comme regex101 permet de tester ses expressions régulières et de les optimiser.

Citation:

---

Envoyé par Beginner.

Et aussi apparemment pour la regex, tu as utilisé une chaine de caractère mais je me demande si ce ne serait pas plus rapide avec un intervalle : [a-z]. La regex c'est une boite noire mais on peut penser que ce serait optimisé dans ce cas c'est-à-dire que cela se rapprocherait de la double comparaisons puisque là aussi on a les deux extrémités d'un intervalle.

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

---

Ok, en avant pour la compilation
Petite modification du code donc...

Code:

---

1 2 3

comp=re.compile("[a-z]") def fct_re(l): for x in l: comp.search(x)

---

Résultat: on gagne un *2 par rapport aux premiers tests mais ça reste quand-même plus long *5 par rapport aux tests simples.

Citation:

---

Envoyé par Beginner.

Oui il doit y avoir une boucle quelque part et du coup cela complique l'analyse car je suppose que la rapidité de la double comparaison doit être la même quelque soit la lettre testée alors qu'avec le in cela dépendra de la lettre : le plus rapide pour la lettre a et le plus lent pour la lettre z.

---

Sans oublier quand la lettre n'y est pas (ie "0" dans mon test)...

Citation:

---

Envoyé par Arioch

Un site comme regex101 permet de tester ses expressions régulières et de les optimiser.

---

Joli :applo: lui je le mets dans mes favoris

Citation:

---

Envoyé par Sve@r

Ok, en avant pour la compilation
Petite modification du code donc...

Code:

---

1 2 3

comp=re.compile("[a-z]") def fct_re(l): for x in l: comp.search(x)

---

Résultat: on gagne un *2 par rapport aux premiers tests mais ça reste quand-même plus long *5 par rapport aux tests simples.

---

Ah quand même c'est un bon gain... Mais c'est vrai ça reste mauvais comparé aux autres méthodes...

Du coup je commence à me demander si la méthode sans les regex est plus performante même dans les autres types de recherche...

J'ai vu qu'il y avait des choses pour optimiser mais bon...

Citation:

---

Envoyé par Beginner.

Du coup je commence à me demander si la méthode sans les regex est plus performante même dans les autres types de recherche...

---

Ah personnellement la regex je ne m'en sers que si je ne peux pas faire autrement. Une recherche sur une string un peu exotique ou une substitution un peu complexe ok mais si la chaine à filtrer est une simple chaine lambda...

Attention avec la comparaison letter.upper() == letter.lower() pour déterminer si un caractère est une lettre ou pas. Si on prend l'eszett allemand, la version minuscule est ß, mais la version majuscule est soit ẞ, soit SS. Or si on teste le changement de casse sur la version minuscule, on obtient (Python 3.6.9):

Code:

---

1 2 3 4 5 6

>>> 'ß'.upper() 'SS' >>> 'ß'.lower() 'ß' >>> 'ß'.upper() == 'ß'.lower() False

---

D'autre part, il existe des lettres n'ayant pas de version majuscule ou de version minuscule.

https://www.unicode.org/reports/tr21/tr21-5.html

Bonjour,
Je suis etudiant et nous avons un cours de python, j'avoue que j'y vois du noir est ce que quelqu'un peut m'assister?

Citation:

---

Envoyé par Christianbash

Bonjour,
Je suis etudiant et nous avons un cours de python, j'avoue que j'y vois du noir est ce que quelqu'un peut m'assister?

---

Ben ouvre un ou plusieurs fil pour poser tes questions... Parce qu'ici tu seras hors-sujet...