Réseau CPC BIENDEBUTER.NET Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
+ Reply to Thread
Page 205 of 205 FirstFirst ... 105 155 195 197 198 199 200 201 202 203 204 205
Results 6,121 to 6,146 of 6146
  1. #6121
    Ouais, je crois que c'était ça, un truc du MIT. Merci mec !
    (Ouais je vais me mettre à la programmation)
    It's the moped lads, they like to think they're bad
    It's the moped lads, if you hit 'em they'll tell their dads

  2. #6122
    Quote Originally Posted by Tramb View Post
    Ouais, je crois que c'était ça, un truc du MIT. Merci mec !
    (Ouais je vais me mettre à la programmation)
    Amuse toi bien ! Tu veux t'y mettre pour faire quoi comme projet ?
    Quote Originally Posted by SiGarret View Post
    Et merci aussi machiavel, j'ai bien reçu le bouquin "baise moi", accompagné d'un gentil mot. Très sympa.
    Quote Originally Posted by Harvester View Post
    Perso ce que je retiens c'est qu'Ookami est un enfoiré

  3. #6123
    Nan mais c'était une blague, c'est pour un enfant tiers :-)
    It's the moped lads, they like to think they're bad
    It's the moped lads, if you hit 'em they'll tell their dads

  4. #6124
    Quote Originally Posted by Tramb View Post
    Nan mais c'était une blague, c'est pour un enfant tiers :-)
    Tu as raison, laisse ça au petit et s'il te plait lache cette souris et éloigne toi doucement de l'écran :D
    Quote Originally Posted by SiGarret View Post
    Et merci aussi machiavel, j'ai bien reçu le bouquin "baise moi", accompagné d'un gentil mot. Très sympa.
    Quote Originally Posted by Harvester View Post
    Perso ce que je retiens c'est qu'Ookami est un enfoiré

  5. #6125
    Désolé pour cette remarque totalement primaire et débile, mais je trouve que les juges de l'IOCCC ont vraiment des têtes de juge de l'IOCCC

    Rust fanboy

  6. #6126
    Bon, on m'a collé sur un projet de fou furieux au taff.
    Une appli web qui est en évolution depuis 10 ans, en VB .Net, et qui utilise tous les outils MS que je ne connais pas : Reporting Service, SSIS et autres joyeusetés, versionné par Team Foundation et plein d'autres trucs.
    La solution comporte plus de 70 projets, et y'a 30 bases de données
    Et pour faire simple, il n'y a aucune requête dans le code, tout est en procédures stockées. Même des listes de fichiers qui remplissent des listes déroulantes (genre le truc où il te suffit de lister le répertoire), ben c'est stocké en bdd, et pour la sortir, faut passer par une procédure stockée.

    Je sens que je vais m'amuser

  7. #6127

  8. #6128
    Quote Originally Posted by Nattefrost View Post
    Bonne lecture du source, donc
    Putain, j'ai l'impression de lire la description de mon nouveau projet : 20 d'age , une pelletachiee de logique métier en procédure stockée, et un client lourd en eclipse RCP qui reçoit toute sa logique de fonctionnement (j'ai bien dit tout. Depuis le contenu des menus contextuels jusqu'au comportement a avoir sur les différents évènements) depuis une application serveur (sur un tomcat 4) via un protocol XML custom...
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  9. #6129
    Tiens y a un p'tit projet intéressant pour le dependency management en C++ : http://www.biicode.com/
    Si j'ai bien tout compris, leur programme analyse les "#include" de ton source code et télécharge automatiquement ce qu'il manque depuis un dépôt central.

    (dommage que dans mon coeur j'ai abandonné le C++ pour le rust)
    Rust fanboy

  10. #6130
    J'ai un petit problème en python, j'avais fais un script en python 3.4 pour parser une position GPS d'une page web. Il fonctionne bien. Par contre en passant le script en 2.7 ça marche pas. Le problème vient du caractère '°' dans l'expression régulière. Qui passait bien en 3.4 et là visiblement il bloque, car re.search me revoit none dès que je le met dans l'expression régulière. J'ai tenté de l'échapper \° sans résultat.

    J'ai vérifié qu'il n'y avait pas de problème d'encodage sur l'entrée. Du moins Pas dans le string en mode inspection dans PyCharm.
    HELP please.

  11. #6131
    Tu peux pas passer par le code du caractère ? ° ou ° ?

  12. #6132

  13. #6133
    Il ne considère pas ° codé en UTF-8 comme 2 caractères, par hasard ?

  14. #6134
    J'en sais rien du tout. Je sais que quand j'ai essayé de retirer le .decode("latin_1") il affichait des petits carré au lieu des °.
    J'ai reussi en mettant .? à la place du °. Mais c'est moins propre et moins claire à la lecture.

  15. #6135
    Essae d'ajouter u devant la chaine décrivant ton pattern, du genre u"\d\d°". Je pense que le souci viennent que par défaut une chaine de charactères est considéré comme unicode en Pthon 3, mais en Python 2. Et si ça suffit pas, colle ton script ici, qu'on puisse critiquercorriger
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  16. #6136
    On peut pas cumuler le u avec le r ?
    regex = ru"\d\d°"
    Du coup je dois passer par re.compile(u"\d\d°") ?

  17. #6137
    Et après on dit que le Python est plus simple que le C#

  18. #6138
    Ben si c'est un problème d'unicode c'est pareil qu'en C#, ici c'est simplement la compatibilité entre les deux branches qui fout la merde (on dirait).
    Quelqu'un qui s'y met aujourd'hui n'apprendra certainement pas python2, et puis arrivé en entreprise il tombera sur des kilotonnes de legacy code en python2

  19. #6139
    C'est un peu ce qui m'arrive, j'ai appris direct en v3, mais comme pygame n'est pas integré dans portable python 3 et que ça me lourde de faire une vrai install. Je me suis dit qu'il n'y aurai pas trop de différence entre la 2.7 et la 3.4. Finalement pour mon truc j'étais pas trop loin de la vérité. A cette broutille près.

  20. #6140
    Quote Originally Posted by moimadmax View Post
    On peut pas cumuler le u avec le r ?
    regex = ru"\d\d°"
    Du coup je dois passer par re.compile(u"\d\d°") ?
    J'aurais tendance a dire oui. Mais colle ton script, qu'on regarde. Ça fait longtemps que j'ai pas fait mumuse en python
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  21. #6141
    Quote Originally Posted by moimadmax View Post
    C'est un peu ce qui m'arrive, j'ai appris direct en v3, mais comme pygame n'est pas integré dans portable python 3 et que ça me lourde de faire une vrai install. Je me suis dit qu'il n'y aurai pas trop de différence entre la 2.7 et la 3.4. Finalement pour mon truc j'étais pas trop loin de la vérité. A cette broutille près.
    Le mec a la flemme de faire une install de python ! Encore de visualstudio ou un gros fatras je comprend mais python, 13 Mo.

    edit : d'ailleurs je connaissai pas portablepython, 64Mo le machin, bon avec 3 IDEs dans le package. A ce propos je suis récemment passé sur ninja-ide parce que j'en avai marre de switcher entre vim sous linux et geany sous windows (non parce que vim sous windows c'est nul à chier).
    Je préfère vim avec les plugins qui vont bien mais bon, ninja-ide me semble bien, pour ce que je fais avec du moins (principalement des petits programmes avec tkinter).

  22. #6142
    Quote Originally Posted by moimadmax View Post
    J'ai un petit problème en python, j'avais fais un script en python 3.4 pour parser une position GPS d'une page web. Il fonctionne bien. Par contre en passant le script en 2.7 ça marche pas. Le problème vient du caractère '°' dans l'expression régulière. Qui passait bien en 3.4 et là visiblement il bloque, car re.search me revoit none dès que je le met dans l'expression régulière. J'ai tenté de l'échapper \° sans résultat.

    J'ai vérifié qu'il n'y avait pas de problème d'encodage sur l'entrée. Du moins Pas dans le string en mode inspection dans PyCharm.
    HELP please.
    Tu as effectivement un problème d'encodage. Python3 a facilité beaucoup de choses de ce coté là.
    Si tu veux pas t'emmerder, TOUT tes fichiers .py doivent être sous la forme (pour l'en-tête):
    Code:
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    """
    TODO: écrire la documentation de ce module
    """
    from __future__ import unicode_literals, print_function, division
    Il faut aussi que tu t'assures que tes codes sources sont encodés en utf-8.
    Ainsi, toutes tes chaines de caractères "en dur" dans le code seront en unicode (un peu comme si il y avait la lettre u devant chaque string). Dont la regexp.
    Bien entendu, il faut AUSSI que tu t'assures que la chaine que tu envoies à matcher dans la regexp soit aussi en unicode. Unicode everywhere.

    En python2, c'est vicieux parce qu'il y a deux types de bases pour les chaines de caractères: les str et les unicode. Respectivement renommées en byte et str en python3. Les str en python2, c'est une suite d'octets, où un glyphe visuel est égal en réalité à un ou plusieurs caractères en mémoire suivant l'encodage. Les unicodes, c'est une "vraie" chaine de caractère, où chaque glyphe visuel est égal à un caractère en mémoire (je schématise).
    Si tu ne comprends pas, fais joujou avec l'interpréteur, il est là pour ça:
    Code:
    In [6]: import re
    
    In [7]: re.search('°', '::°::')  # Deux str avec le même encodage, ça match
    Out[7]: <_sre.SRE_Match at 0xb60a69c0>
    
    In [8]: re.search('°', u'::°::')  # Un str et un unicode, ça match pas
    
    In [10]: re.search(u'°', u'::°::')   # Deux unicode, ça match
    Out[10]: <_sre.SRE_Match at 0xb60a6b10>
    
    In [11]: re.search(u'°', u'::°::'.encode('latin-1'))  # un unicode et un str, ça match pas
    Out[11]: <_sre.SRE_Match at 0xb60dd678>                                                                                                                                             
    
    In [12]: re.search(u'°'.encode('utf-8'), u'::°::'.encode('latin-1'))  # deux str avec un encodage différent, ça match pas
    
    In [16]: u'°'  # Le signe unicode
    Out[16]: u'\xb0'
    
    In [17]: u'°'.encode('utf-8')  # On transforme en str utf-8. On voit qu'il y deux octets
    Out[17]: '\xc2\xb0'
    
    In [18]: u'°'.encode('latin-1')  # On transforme en str latin-1. Et on voit qu'il y a un octet
    Out[18]: '\xb0'
    Je pense que ça ne peut pas matcher parce que par défaut, python2 interprète ton code comme encodée en latin-1 (si y a rien dans l'en-tête). Et la chaine que tu envoies, c'est certainement soit de l'unicode, soit de l'utf-8. Et dans tous les cas != latin-1.

    Ou autre hypothèse (la plus probable), comme python2 interprète ton code en latin-1 si tu ne lui as rien précisé, mais que ton fichier source est en utf-8, ça va probablement foutre la merde, parce que `°` est sur deux octets en utf-8, et un seul en latin-1. Et il te lèvera pas d'erreurs d'encodage parce que les deux octets en utf-8 (correspondant à un glyphe visuel) sont correct en latin-1 (correspondant à deux glyphes visuels qui n'auront probablement aucun sens). Python ne va pas chercher à savoir si tes strings ont un sens, il va juste regarder si les trucs que t'as mis dedans sont valide d'un point de vue encodage. Ce qui est le cas.
    \o/ Bienvenue dans l'enfer de l'encodage et l'unicode. Prochaine étape, découvrir les cotés cool d'unicode

    En python3, le code est interprété par défaut en utf-8 et toutes les chaines de caractères sont de l'unicode.


    Les chaines raw (celle préfixé par un r), elles ne sont d'aucune utilité dans ce problème là. Elles servent à ne pas échapper le caractère antislash, et par habitude, on les utilises pour les regexps (et les chemins sous windows), vu qu'elles se servent des antislashs de manière récurrente.
    Et on peut très bien les coupler avec le signe `u` unicode. Ce qui donne ur"mon string".

    C'est un peu compliqué et indigeste, je le conçois. Faut vraiment faire joujou avec la console pour comprendre, et tester plein de trucs idiots.
    Tous les langages qui manipulent de l'unicode ET des bytes sont impactés par ce "problème" (qui n'en ai pas un en réalité).
    Last edited by Sekigo Le Magnifique; 30/10/2014 at 23h22.
    J'ai raison et vous avez tort.

  23. #6143
    De toute façon, pour l'encoding et Python, un seul article : http://sametmax.com/lencoding-en-pyt...is-pour-toute/. J'ai deja du le balancer une ou deux fois, en plus. Encore un ou deux fois, et ça pourra terminer dans l'OP
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  24. #6144
    Quote Originally Posted by Teocali View Post
    J'aurais tendance a dire oui. Mais colle ton script, qu'on regarde. Ça fait longtemps que j'ai pas fait mumuse en python
    J'ai honte c'est trop sâle. C'est en gros chantier et je suis débutant python (http://pastebin.com/bt8BAaYb)
    Quote Originally Posted by Nattefrost View Post
    Le mec a la flemme de faire une install de python ! Encore de visualstudio ou un gros fatras je comprend mais python, 13 Mo.
    J'ai pas la fleme, c'est pour pas pourrir le PC du taf avec ce projet qui tournera sur un raspberry après. Du coup la version portable me parait correct.

    Quote Originally Posted by Sekigo Le Magnifique View Post
    Tu as effectivement un problème d'encodage. Python3 a facilité beaucoup de choses de ce coté là.
    Si tu veux pas t'emmerder, TOUT tes fichiers .py doivent être sous la forme (pour l'en-tête):
    Code:
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    """
    TODO: écrire la documentation de ce module
    """
    from __future__ import unicode_literals, print_function, division
    Il faut aussi que tu t'assures que tes codes sources sont encodés en utf-8.
    Ainsi, toutes tes chaines de caractères "en dur" dans le code seront en unicode (un peu comme si il y avait la lettre u devant chaque string). Dont la regexp.
    Bien entendu, il faut AUSSI que tu t'assures que la chaine que tu envoies à matcher dans la regexp soit aussi en unicode. Unicode everywhere.

    En python2, c'est vicieux parce qu'il y a deux types de bases pour les chaines de caractères: les str et les unicode. Respectivement renommées en byte et str en python3. Les str en python2, c'est une suite d'octets, où un glyphe visuel est égal en réalité à un ou plusieurs caractères en mémoire suivant l'encodage. Les unicodes, c'est une "vraie" chaine de caractère, où chaque glyphe visuel est égal à un caractère en mémoire (je schématise).
    Si tu ne comprends pas, fais joujou avec l'interpréteur, il est là pour ça:
    Code:
    In [6]: import re
    
    In [7]: re.search('°', '::°::')  # Deux str avec le même encodage, ça match
    Out[7]: <_sre.SRE_Match at 0xb60a69c0>
    
    In [8]: re.search('°', u'::°::')  # Un str et un unicode, ça match pas
    
    In [10]: re.search(u'°', u'::°::')   # Deux unicode, ça match
    Out[10]: <_sre.SRE_Match at 0xb60a6b10>
    
    In [11]: re.search(u'°', u'::°::'.encode('latin-1'))  # un unicode et un str, ça match pas
    Out[11]: <_sre.SRE_Match at 0xb60dd678>                                                                                                                                             
    
    In [12]: re.search(u'°'.encode('utf-8'), u'::°::'.encode('latin-1'))  # deux str avec un encodage différent, ça match pas
    
    In [16]: u'°'  # Le signe unicode
    Out[16]: u'\xb0'
    
    In [17]: u'°'.encode('utf-8')  # On transforme en str utf-8. On voit qu'il y deux octets
    Out[17]: '\xc2\xb0'
    
    In [18]: u'°'.encode('latin-1')  # On transforme en str latin-1. Et on voit qu'il y a un octet
    Out[18]: '\xb0'
    Je pense que ça ne peut pas matcher parce que par défaut, python2 interprète ton code comme encodée en latin-1 (si y a rien dans l'en-tête). Et la chaine que tu envoies, c'est certainement soit de l'unicode, soit de l'utf-8. Et dans tous les cas != latin-1.

    Ou autre hypothèse (la plus probable), comme python2 interprète ton code en latin-1 si tu ne lui as rien précisé, mais que ton fichier source est en utf-8, ça va probablement foutre la merde, parce que `°` est sur deux octets en utf-8, et un seul en latin-1. Et il te lèvera pas d'erreurs d'encodage parce que les deux octets en utf-8 (correspondant à un glyphe visuel) sont correct en latin-1 (correspondant à deux glyphes visuels qui n'auront probablement aucun sens). Python ne va pas chercher à savoir si tes strings ont un sens, il va juste regarder si les trucs que t'as mis dedans sont valide d'un point de vue encodage. Ce qui est le cas.
    \o/ Bienvenue dans l'enfer de l'encodage et l'unicode. Prochaine étape, découvrir les cotés cool d'unicode

    En python3, le code est interprété par défaut en utf-8 et toutes les chaines de caractères sont de l'unicode.


    Les chaines raw (celle préfixé par un r), elles ne sont d'aucune utilité dans ce problème là. Elles servent à ne pas échapper le caractère antislash, et par habitude, on les utilises pour les regexps (et les chemins sous windows), vu qu'elles se servent des antislashs de manière récurrente.
    Et on peut très bien les coupler avec le signe `u` unicode. Ce qui donne ur"mon string".

    C'est un peu compliqué et indigeste, je le conçois. Faut vraiment faire joujou avec la console pour comprendre, et tester plein de trucs idiots.
    Tous les langages qui manipulent de l'unicode ET des bytes sont impactés par ce "problème" (qui n'en ai pas un en réalité).
    Merci pour ton explication, c'est plus claire et en effet le ur"Regex" fonctionne parfaitement.

    Quote Originally Posted by Teocali View Post
    De toute façon, pour l'encoding et Python, un seul article : http://sametmax.com/lencoding-en-pyt...is-pour-toute/. J'ai deja du le balancer une ou deux fois, en plus. Encore un ou deux fois, et ça pourra terminer dans l'OP
    Le pire c'est que je l'ai déjà lu et j'ai même pas pensé a y faire un tour quand je suis passé sur la V2.7

  25. #6145
    Quote Originally Posted by moimadmax View Post
    Le pire c'est que je l'ai déjà lu et j'ai même pas pensé a y faire un tour quand je suis passé sur la V2.7
    :gifd'unlapinquicolleunefessée:

    EDIT:
    dans l'instruction de retour de ta methode getpage(url), essaye return data.decode("latin_1").encode(utf-8)
    Last edited by Teocali; Yesterday at 11h00.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  26. #6146
    Quote Originally Posted by Sekigo Le Magnifique View Post
    Code:
    from __future__ import unicode_literals, print_function, division
    Python...



    Désolé mais ça faisait longtemps...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts