Discussion :

[PauseKawa]

Bonjour,

Soit les codes suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
#
#
try:
    import tkinter as Tk
except:
    import Tkinter as Tk
 
fenetre = Tk.Tk()
Tk.Label(fenetre, text='éèàù').pack()
Tk.Button(fenetre, text='Quitter', command=fenetre.quit).pack()
fenetre.mainloop()

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env python
# -*- coding: ISO8859-1 -*-
#
#
try:
    import tkinter as Tk
except:
    import Tkinter as Tk
 
fenetre = Tk.Tk()
Tk.Label(fenetre, text='éèàù').pack()
Tk.Button(fenetre, text='Quitter', command=fenetre.quit).pack()
fenetre.mainloop()

Quelle est la bonne pratique pour avoir du code compatible Python 2.x/3.x Et multi plateforme ?

Merci d'avance

[pfeuh]

Salut,

Code :

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

# -*- coding: ISO8859-1 -*-

Personnellement, comme il s'agit de ce qui est encodé dans le source lui-même si j'ai bien compris, je mets plutôt ça:

Code :

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

# -*- coding: latin1 -*-

Mais en fait, je suis comme toi, je vais attendre une réponse moins empirique.

A+

Pfeuh

[tyrtamos]

Bonjour,

En ce qui me concerne (Python 2.7 et développement multiplateforme Windows-Linux):

- toutes mes pages de code sont en utf-8. Cela implique pour Windows de trouve un éditeur qui travaille en utf-8. Pour Linux: les distributions récentes sont en utf-8 par défaut.

- pour les liaisons avec les disques: j'essaye d'utiliser latin1 ou, même, si je veux communiquer avec Excel, cp1252 (encodage par défaut de Windows). J'utilise dans ces cas le module codecs qui est très pratique.

- pour les saisies et les affichages en console, j'utilise sys.stdin.encoding et sys.stdout.encoding pour me dire comment je dois convertir les chaines avec encode et decode.

- et, en interne: c'est du 100% unicode!

Tyrtamos

[wiztricks]

Salut,
Je ne comprends pas la question.
Porte-t-elle sur:
- l'encoding?
- la gestion de noms de bibliothèques différents?
- la déclaration des littéraux "chaines de caractères"?

Concernant l'encoding
C'est d'abord un problème d'IDE: il faut qu'on voit ce qu'on tape. Mais pouvu que la déclaration -*- coding: XXXX -*- soit cohérente et dans les "codings" supportés par Python... Je ne vois pas trop de changements entre v2 et v3.

Les bibliothèques qui changent.
La portabilité se paie avec l'écriture d'un adaptateur - des modules entre l'application et les bibliothèques utilisées - qui épongeront les changements d'API... Et comme les changements sont spécifiques, la stratégie ne pourra qu'être ad hoc.
Un truc plus économique est un code "conditionnel" (en fonction de la version de Python). C'est ce que font implicitement les imports TKinter ou tkinter: le faire de façon explicite rendrait le code plus lisible - enfin lorsque quelqu'un essaiera de comprendre ce que fait le script dans quelques années.

litéraux.
L'instruction text = 'éèàù' n'a pas le même sens en v2 et en v3.
En V2, text sera une chaine de bytes dont les codes sont à interpréter en fonction du charset donnée dans "coding".
En V3, text sera un tableau de nombres Unicode construits en convertissant le litéral en fonction de...
La même chose en V2 serait text = u'éèàù'
Mais dans ce cas particulier, tout dépend de ce que Tk veut... et on est ramené à l'adaptateur précédent.

- W

[PauseKawa]

Bonjour wiztricks,

C'était une question de 'bonne pratique' dans le sens de la réponse de tyrtamos. Si ce n'est que je n'utilise pas les liaisons avec Windows c'est bien dans ce sens que je voyais les choses mais je m'étais demandé s'il n'y avais pas une conduite préconisée.
Pour ce qui est des bibliothèques (et tkinter n'était là que pour l'exemple) et des littéraux, et bien comme tu le dis : on s'adapte.

Bon code.