python vs perl

Henry de Monfreid · Le 15/12/2006, à 20:15

En conclusion: aucun langage n'est superieur aux autres, tout depend de de l'usage qu'on en fait, en l'occurance: Python est un bon compromis

#!/usr/bin/python
#This program is distrubued under GNU GPL
a = "Merci a tous pour vos precieux conseils!"
print a

PS: prevenez moi si vous trouvez un bug

kaworu · Le 15/12/2006, à 20:38

[détail]
perso je préfère

#!/usr/bin/env python

mais j'avoue que c'est une question de religion hein
[/détail]

manatlan · Le 15/12/2006, à 20:39

#!/usr/bin/python
# -*- coding: UTF-8 -*-

print """ de rien ... sinon c'est une bonne habitude que mettre l'encoding magic de python
en debut de programme ... ainsi que de faire ses scripts en UTF-8 (futur!)"""

voir le PEP : http://www.python.org/dev/peps/pep-0263/

tous les editeurs ne sont pas aware de ça
(Scite les comprends bien, eclipse aussi je pense ... ainsi que les editeurs python dédiés)

Henry de Monfreid · Le 15/12/2006, à 21:27

Des années que j'entends parler de:
-*- coding: UTF-8 -*-
ou pourrais-je trouver de la doc?

Dernière modification par pinballyoda (Le 15/12/2006, à 21:44)

Henry de Monfreid · Le 15/12/2006, à 21:28

au temps pour moi:
http://fr.wikipedia.org/wiki/UTF-8
merci google:)

aleph · Le 15/12/2006, à 21:33

Bonne remarque concernant l'encodage d'autant plus que Python 2.4 génère un "warning"

print 'éléphant'
sys:1: DeprecationWarning: Non-ASCII character '\xe9' in file a.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

alors que dans Python 2.5, c'est une "error" (enfin!)

SyntaxError: Non-ASCII character '\xe9' in file a.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Tout est expliqué dans Python Reference Manual, 2.1.4 Encoding declarations .

> manatlan
tous les editeurs ne sont pas aware de ça
(Scite les comprends bien, eclipse aussi je pense ... ainsi que les editeurs python dédiés)

Non, ce n'est pas juste. Les éditeurs n'ont rien à voir avec cela. L'information d'encodage que l'on défini en tête de fichier est une indication pour le moteur Python afin qu'il sache quel encodage d'entrée il devra utilisé.
De même il y a un encodage de sortie.
Il est fort possible de sauvegarder un fichier dans un encodage particulier et d'avoir une information d'encodage différente dans l'en-tête de ce fichier.

C'est un point que beaucoup de monde à de la peine à comprendre.

manatlan · Le 15/12/2006, à 21:52

aleph a écrit :

Non, ce n'est pas juste. Les éditeurs n'ont rien à voir avec cela. L'information d'encodage que l'on défini en tête de fichier est une indication pour le moteur Python afin qu'il sache quel encodage d'entrée il devra utilisé.
De même il y a un encodage de sortie.
Il est fort possible de sauvegarder un fichier dans un encodage particulier et d'avoir une information d'encodage différente dans l'en-tête de ce fichier.
C'est un point que beaucoup de monde à de la peine à comprendre.

Détrompes toi ...

Sous windows par exemple, tu prends un editeur de texte classique (textpad, ...), tu créés ton fichier texte/python ... tu mets "#-*- coding: UTF-8 -*-" en entete ... tu codes, tu sauvegardes ...

et ton fichier sera encodé en "windows" (encoding "mbcs" (subset de cp1252))
et python l'interpretera en UTF8 (a cause de l'entete), et t'aura des erreurs à l'execution ;-)

si tu le réouvres dans textpad, il s'en tapera de l'encoding dans l'entete, et ça restera du windows/MBCS
si tu le réouvres dans SciTE, il tentera de l'interprété en UTF-8 (car scite va lire cet entete pour definir l'encoding)
(sinon, en general, sous win, les editeurs enregistre le "code bom" en debut de fichier pour signaler aux editeurs que c de l'utf8 ... scite gere très bien les 2)

Il faut faire attention ...
l'idéal étant de regler ses éditeurs pour faire de l'utf8, et d'y coller l'entete systématiquement ...
(sous buntu, les editeurs font de l'utf8 en grande majorité ... mais sous des distrib en iso8859-15 : faut se méfier, au même titre que sous win)

mais avec python 3000 (v3), tout ça sera du passé, car tout sera full unicode (utf8)

JoelS · Le 15/12/2006, à 22:58

aleph a écrit :

Non, ce n'est pas juste. Les éditeurs n'ont rien à voir avec cela. L'information d'encodage que l'on défini en tête de fichier est une indication pour le moteur Python afin qu'il sache quel encodage d'entrée il devra utilisé.
De même il y a un encodage de sortie.
Il est fort possible de sauvegarder un fichier dans un encodage particulier et d'avoir une information d'encodage différente dans l'en-tête de ce fichier.

A ma connaissance, c'est Emacs/Xemacs qui a mis en place ça il y a déjà pas mal d'années. Ainsi je commence toujours mes scripts shell par:

#!/usr/bin/sh
# Hey (X)emacs, this is a -*- sh -*- file!

ce qui fait que même si le fichier n'a pas d'extension, Emacs le lit comme un fichier shell. On peut mettre plein de commande entre les -*-, comme le mode, les minor-modes, la tabulation, l'encodage, etc etc. Je pense que Vim a repris ça par la suite.

Donc si, ça viens bien des éditeurs de texte.

aleph · Le 15/12/2006, à 23:06

Non. Ce qui tu écris n'est que partiellement vrai et confirme ce que je disais.

Tu confonds les encodages de fichiers et l'information d'encodage d'entrée utilisée par Python. Ceux sont deux choses différentes bien que fortement liées.

Je peux écrire un fichier sous Windows, le sauvegarder en cp1252 y inclure une en-tête utf-8 et il peut très bien fonctionner. S'il y a des erreurs - ce qui est possible, si j'intègre des caractères dont les encodages sont différents dû aux conventions d'encodage - c'est parce que le moteur Python ne peut décoder l'entrée en non pas parce ce que le fichier est dans un encodage différent.
C'est un peu alambiqué, mais c'est comme cela.

Un problème analogue peut survenir lorsque les champs "texte" d'une base de données ne sont pas ceux attendus par le moteur Python avec son codage d'entrée. Dans ce cas, tu vois que le problème n'est pas lié à un encodage de fichiers.

Si tu as l'occasion de tester Python sous Windows, tu peux jouer avec Python sous DOS et sous de Windows, créer différents fichiers tests et tester. L'un utilise cp850 comme encodage d'entrée et l'autre cp1252.

Comme tu l'as justement dit, dans le monde Linux il faut faire attention aux distributions utf-8 et iso8859-15.

Il me semble que tu es intervenu assez souvent dans ce genre de dicussion. Tu devrais te souvenir que j'ai souvent proposé d'ouvrir une console Python et de jouer avec les différents encodages de "strings" (terme assez mal choisi).

Une petite remarque, Windows enregistre les fichiers texte avec un encodage par défaut cp1252. mbcs est l'encodage utilisé pas le système de fichier FAT32.

Je connais Python depuis le CNRI version 1.5.2 et collabore depuis 6-7 ans à une des ses extensions.

J'espère ne pas avoir été trop sec.

aleph · Le 15/12/2006, à 23:21

> JoelS

vim et emacs "savent" gérer l'encodage de Python. L'encodage d'entrée doit correspondre (match) à l'expression régulière suivante: coding[=:]\s*([-\w.]+)

A nouveau, ceci est expliqué dans Python Reference Manual, 2.1.4 Encoding declarations

manatlan · Le 15/12/2006, à 23:45

aleph a écrit :

Tu confonds les encodages de fichiers et l'information d'encodage d'entrée utilisée par Python. Ceux sont deux choses différentes bien que fortement liées.

non, je ne pense pas ...

aleph a écrit :

Je peux écrire un fichier sous Windows, le sauvegarder en cp1252 y inclure une en-tête utf-8 et il peut très bien fonctionner.

Evidemment ... si tu met pas de caractères accentués, tu restes dans la zone ascii (0-127) qui est, bien souvent, commune à différents encodage ... c'est évident ! dans ce cas là : python n'aura aucun prob !

mais je comprends que tu es mal interprété mes dires, j'aurai du dire : "tu codes, tu mets qques caractères bien renchis, et tu sauvegardes" (pour moi, ça me semblait evident, dans la mesure où les français écrivent en français ...)

aleph a écrit :

S'il y a des erreurs - ce qui est possible, si j'intègre des caractères dont les encodages sont différents dû aux conventions d'encodage[...]

je n'ai jamais dit le contraire ...

aleph a écrit :

Comme tu l'as justement dit, dans le monde Linux il faut faire attention aux distributions utf-8 et iso8859-15.

oui, pour les encodings français .. mais faut faire attention à tous les autres encodings aussi !
(ce pourquoi, il est préférable d'utiliser l'UTF-8 (qui, par nature, est lisible partout sur terre))

aleph a écrit :

Une petite remarque, Windows enregistre les fichiers texte avec un encodage par défaut cp1252. mbcs est l'encodage utilisé pas le système de fichier FAT32.

ça je ne savais pas ... la différence est subtile !

aleph a écrit :

J'espère ne pas avoir été trop sec.

non, du tout, mais je me bat aussi pas mal, un peu partout avec ces histoires d'encodings ... et j'essaie d'eduquer un peu ... (surtout contre les americains/anglophones qui ont l'impression que toute la terre utilise l'ascii)

no prob ...

aleph · Le 16/12/2006, à 00:11

> manatlan

Je crois qu'on est plus au moins sur la même longueur d'onde. Il est assez difficile d'utiliser les termes corrects dans ce genre de discussion.

> non, du tout, mais je me bat aussi pas mal, un peu partout avec ces histoires d'encodings ... et
>j'essaie d'eduquer un peu ... (surtout contre les americains/anglophones qui ont l'impression que
> toute la terre utilise l'ascii)

Le problème ici est dû à l'aspect élastique de l'encodage utf-8 d'unicode. Un byte pour pour les 128 premiers caractères, puis deux bytes pour les caractères accentués du monde latin-1. Les américains sont comme M. Jourdain, ils utilisent utf-8 en croyant que c'est de l'ascii ou inversément travaillent en ascii et prétendent que c'est de l'utf-8.

Un bon article pour les amateurs de Python et d'encodage, si tu ne connais pas :
http://www.pyzine.com/Issue008/Section_Articles/article_Encodings.html#bom-encoding-signatures

Henry de Monfreid · Le 16/12/2006, à 13:44

Je viens d'intaller ipoder.
Un petit soft tres sympa pour rapatrier des podcasts.
Il est ecrit en Python et Ô surprise il a des problèmes avec les accents.
Est-ce en rapport avec l' TUF-8?

manatlan · Le 16/12/2006, à 14:47

pinballyoda a écrit :

Je viens d'intaller ipoder.
Un petit soft tres sympa pour rapatrier des podcasts.
Il est ecrit en Python et Ô surprise il a des problèmes avec les accents.
Est-ce en rapport avec l' TUF-8?

Bon j'ai vaguement essayé ...
- soit c'est le cas typique d'un prog fait par des anglais/americain pas "très aware des autres encodings". Et du coup, ils croient que toute la terre utilise le même jeu de caractères ... ce qui peut poser prob pour nous frenchie (à nous alors de contribuer/eduquer ;-)
- mais dès qu'un prog utilise des RSS, pouvant provenir d'un peu partout sur terre, ce prog doit faire très attention, car bien fréquemment les fils rss(xml) générés ne déclarent pas le même encoding que celui du contenu. Et là, ça devient plus chaud. (il y a des libs python pour la detection des encodings, mais c jamais sure à 100%)

aleph · Le 16/12/2006, à 16:46

Flux xml ? Voilà un exemple de codage d'entrée.

J'ai jeté un rapide coup d'oeil sur le code. Il semble bien que les auteurs soient conscients de l'internationalisation, il y a des modules spécifiques aux langues (avec utf-8 dans l'en-tête).

Pour ma part, j'ai été confronté à un autre problème. L'utilisation de l'ancien "namespace" de wxPython.

manatlan · Le 16/12/2006, à 17:08

aleph a écrit :

Flux xml ? Voilà un exemple de codage d'entrée.

Dans les flux RSS, je crois que c'est le pire ...

Le nb de dev qui récupèrent un flux rss d'un site pour voir la structure, et le générer soit même, sans tenir compte des règles d'encodage xml ... (c'est encore pire que dans les page html, car c'est moins visible, et dépends du lecteur de rss ... et beaucoup ne sont pas stricts !)

aleph a écrit :

Pour ma part, j'ai été confronté à un autre problème. L'utilisation de l'ancien "namespace" de wxPython.

pareil ;-)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 15/12/2006, à 20:15

Re : python vs perl

#27 Le 15/12/2006, à 20:38

Re : python vs perl

#28 Le 15/12/2006, à 20:39

Re : python vs perl

#29 Le 15/12/2006, à 21:27

Re : python vs perl

#30 Le 15/12/2006, à 21:28

Re : python vs perl

#31 Le 15/12/2006, à 21:33

Re : python vs perl

#32 Le 15/12/2006, à 21:52

Re : python vs perl

#33 Le 15/12/2006, à 22:58

Re : python vs perl

#34 Le 15/12/2006, à 23:06

Re : python vs perl

#35 Le 15/12/2006, à 23:21

Re : python vs perl

#36 Le 15/12/2006, à 23:45

Re : python vs perl

#37 Le 16/12/2006, à 00:11

Re : python vs perl

#38 Le 16/12/2006, à 13:44

Re : python vs perl

#39 Le 16/12/2006, à 14:47

Re : python vs perl

#40 Le 16/12/2006, à 16:46

Re : python vs perl

#41 Le 16/12/2006, à 17:08

Re : python vs perl

Pied de page des forums