Discussion :

[clavier12AZQSWX]

bonjour,


en python 2.4,

je souhaite tester si une variable string est convertible ou pas en int.
ça n'arrive que 1 fois sur 100

je n'ai comme solution (je crois) que ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
try:
n = int(s)
except ValueError:
print "attention erreur arrivée avec ",s

mais si je ne me trompe pas, le try..except prend bcp de temps au cpu non ?
et comme mon traitement est bouclée à au moins 10000 itérations toutes les 10min, ça m'embête de ralentir le serveur pour 1/100 qui pose un souci.

comment faire mieux (plus léger que le try...execpt) ?

[mont29]

Un bête isdigit() devrait faire l’affaire, non*?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if s.isdigit():
    n = int(s)

[wiztricks]

Un bête isdigit() devrait faire l’affaire, non*?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if s.isdigit():
    n = int(s)

non: "-123" est int alors que '-' n'est pas 'digit'.

mais si je ne me trompe pas, le try..except prend bcp de temps au cpu non ?

Cela se mesure avec des timeit, non?

et comme mon traitement est bouclée à au moins 10000 itérations toutes les 10min, ça m'embête de ralentir le serveur pour 1/100 qui pose un souci.

Si c'est un serveur, les données sont produites "ailleurs" dans un format (qu'on espère) "valide".
Le try...except de la conversion ne devrait jamais planter et n'est là qu'au cas où.
De plus, le cas échéant, il pourrait faire quoi sinon retourner une erreur sur tout le traitement?


- W

[fred1599]

Bonjour,

je n'ai comme solution (je crois) que ça :

De quoi avez-vous peur? Votre solution est un problème de conception de code, les try-except ont tendance à rendre un code moins lisible, mais si il faut le faire pour que le code soit fiable, alors faisons-le!

Il est évident que mettre du try-except sur toute la longueur du code va rendre votre code "illisible" et il faut savoir doser entre lisibilité et maintenabilité de votre code.

Je dirais en ce qui me concerne que trois choix s'offrent à vous

• Soit vous traiter tous les éléments, soit rien du tout et on stoppe le programme
• Soit vous traiter tous les éléments, et ce qui ne sont pas corrects on les modifie, on traite et on continue
• Soit vous traiter tous les éléments, et si il y a une erreur on l'ignore et on continue.

À vous de choisir lequel de ces choix est préférable, mais chacune des solutions va prendre plus ou moins de temps et chacune des solutions sera plus ou moins fiable par rapport à la demande du client.

Donc oui un try-except peut être plus long, mais tout dépendra de la conception demandée par le client, qui doit assumer par la suite le langage choisi pour faire son projet.

Vous avez aussi des solutions d'interfaçage entre python et des langages bas niveau comme le C par exemple (voir cython).

En espérant vous avoir aidé.

[Lujeni]

Je pense que ta question soulève surtout la question sur la manière et habitude de coder.

L'ajout d'un try n'affectera réellement en rien tes performances (dans ton contexte), le plus important est l'algo qui est derrière. 10 000 itérations toutes les 10mins, ca me parait quand même léger.

Si tu veux te faire ta propre opinion, monitor ta charge memory / cpu et regarde le temps d'execution.

Cela n'engage que moi, mais au contraire je trouve que l'ajout de try permet une meilleure lisibilité sur le code , si la repartition est faite en "block".

Vous avez aussi des solutions d'interfaçage entre python et des langages bas niveau comme le C par exemple (voir cython).

+1

[pfeuh]

Salut,

comment faire mieux (plus léger que le try...execpt)

Il suffit de faire quelques tests qui parlent d'eux mêmes. Ce n'est qu'une idée, c'est à toi de définir ce qui doit être accepté comme un int ou pas, mais on peut quand même dire que oui, try/except à un coût non négligeable. Sur ma machine j'ai les résultats suivants:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
>pythonw -u "dummy.py"         
A L L   T E S T S   P A S S E D !
INT : time for isint_1: 1.767
INT : time for isint_2: 3.513
NOT INT : time for isint_1: 1.706
NOT INT : time for isint_2: 11.677
>Exit code: 0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
39
40
41
42
43
44
45
 
def isint_1(text):
    if text[:1] =='-':
        return text[1:].isdigit()
    else:
        return text.isdigit()
 
def isint_2(text):
    try:
        int(text)
        return True
    except:
        return False
 
if __name__ == "__main__":
 
    import sys
    import time
 
    GOOD_INTS = ['1', '-1', '456789', '-123456', ]
    BAD_INTS = ['1-', '--1', '', 'text!']
 
    # unitary tests
    for text in GOOD_INTS:
        assert isint_1(text)
        assert isint_2(text)       
    for text in BAD_INTS:
        assert not isint_1(text)
        assert not isint_2(text)
    sys.stdout.write('A L L   T E S T S   P A S S E D !\n')
 
    # time computing
    LABELS = {isint_1:'isint_1', isint_2:'isint_2'}
    for function_under_test in [isint_1, isint_2]:
        start = time.time()
        for count in range(1000000):
            for text in GOOD_INTS:
                function_under_test(text)
        sys.stdout.write("INT : time for %s: %.03f\n"%(LABELS[function_under_test], time.time() - start))
    for function_under_test in [isint_1, isint_2]:
        start = time.time()
        for count in range(1000000):
            for text in BAD_INTS:
                function_under_test(text)
        sys.stdout.write("NOT INT : time for %s: %.03f\n"%(LABELS[function_under_test], time.time() - start))

A+

Pfeuh

[clavier12AZQSWX]

merci à tous de vos réponses.

Ce n'est qu'une idée, c'est à toi de définir ce qui doit être accepté comme un int ou pas, mais on peut quand même dire que oui, try/except à un coût non négligeable.

la valeur que je teste provient d'un prestataire externe c'est pour ça que dès fois elle n'arrive pas en int (pré-requis). Pas facile d'obliger un presta externe à formaliser correctement ses infos...

Bref, j'aimerai savoir si avec le Try...except si c'est le except qui prend plus de ressource ou la partie Try ?

Car comme dit plus, haut, l'exception n'arrive que rarement (mais arrive forcément et régulièrement hélas). Donc si c'est plus long pour le except et "à vitesse et ressource normale" pour la partie Try alors ça me va complètement !

J'espère que je ne me suis bien expliqué.

[fred1599]

La vitesse d'exécution semble vous poser des soucis, pourquoi python?

[pfeuh]

Bref, j'aimerai savoir si avec le Try...except si c'est le except qui prend plus de ressource ou la partie Try ?

Dans les test que j'ai fait plus haut, c'est clairement le except qui est pénalisant (NOT INT et fonction isint_2)

INT : time for isint_1: 1.767
INT : time for isint_2: 3.513
NOT INT : time for isint_1: 1.706
NOT INT : time for isint_2: 11.677

[afranck64]

Bref, j'aimerai savoir si avec le Try...except si c'est le except qui prend plus de ressource ou la partie Try ?

Contrairement à ce que je pensais, il semblerait que le bloc "except" prenne bien plus de temps que le "try".
pour 1000000 tours, j'ai...

>>>
Try without except: 0.682349618534 try, 0 except
Try with except: 0.494243102821 try, 2.53324953519 except

En ne comptant que le temps d'entrée dans try, et celui de try pour except.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import time
 
def bench(div=1, iterations=1000000):
    t_try=0
    t_except=0
    for i in range(iterations):
        c=b=a= time.clock()
        try:
            b = time.clock()
            1/div
        except:
            c = time.clock()
            t_except+=(c-b)
        t_try+=(b-a)
    return t_try, t_except
 
def get_scores():
    correct = bench()
    error = bench(0)
    print ("Try without except: {0} try, {1} except".format(*correct))
    print ("Try with except: {0} try, {1} except".format(*error))
 
get_scores()

.

Je crois que ca vous arrange...