module de polyèdres [pb de docstring]

Salut les pythons scientifique,
J'ai développer un module de de calcule de polyèdre régulier qui renvoie l'aire, le volume, etc... d'un polyèdre régulier:
-Icosaèdre
-Dodécaèdre
-Octaèdre
-Hexaèdre
-Tétraèdre
Mais le module souffre d'un sérieux problème de docstring quand on s'en sert sous Windows car cet OS a du mal avec les caractères que j'utilise dans les docstring comme:
- le signe multiplier: × ( je peut utiliser un x à la place mais ca ne me plais pas)
- le signe au carré: ² ( je peut utiliser une formule à la place mais ca ne me plait pas non plus)
- j'ai confectionner un sign sqrt tenant sur trois lignes:

Code:

---

1 2 3 4

____ _ / \/

---

Dont Windows mets des caractères illisible à la place de ces caractères.
J'ai préciser l'encodage du fichier mais je ne sais si Windows prend en compte la ligne:

Code:

---

# -*- coding: utf-8 -*-

---

Mais je désire que mes docstrings soit le plus concises possible car ceux-ci affichent la formule utiliser par les méthodes pour renvoyer les valeurs.
Par ailleurs je n'ai uniquement tester le module qu'avec le IDLE fournis avec l'installation standart de python 2.7.3 et celui-ci n'affiche que la première ligne parfois amputer de la fin des docstrings... et il faut faire appel a la fonction help pour voir le gribouillage que ca donne.

Si vous ne pouvez m'aider je serai obliger de faire une version pour Windows et pour Linux avec lequel j'ai développer le module et qui affiche correctement les doctrings...

J'attends vos réponses avec impatience.

PS: je ne suis pas un anti-Windows mais je ne m'y connais pas avec cet OS (heureusement que python est vraiment bien portable).

Salut,

Par défaut, l'encoding de Windows sera plutôt "cp437" et non "utf-8".

Comme vous ne montrez pas de code et que Python2 est plutôt laxiste sur la représentation des bytes/unicode: ce qui pourrait "fonctionner" avec de l'Unicode marchera moyen avec des bytes.

Si vous voulez écrire un code portable, pourquoi ne pas créer une petite IHM avec Tk? Il devrait se débrouiller pour afficher l'Unicode qu'on lui envoie et gérer le paramétrage des "consoles" sous les différents OS.

A vous de voir.
- W

Merci pour la précision concernant l'encodage par défaut sous-windows, je le savais mais je n'y pas penser tout de suite car j'écris mes codes sous Linux et comme GUI j'utilise tkinter.
Et comme python et Tkinter sont bien portables je n'ai jamais eu de problèmes pour faire une version Windows d'un programme ou module écrit sous Linux.
Je vais essayer de mettre cp437 comme encodage, merci.
De toute façon je vais devoir faire une version pour chaque OS.

Citation:

---

Si vous voulez écrire un code portable, pourquoi ne pas créer une petite IHM avec Tk? Il devrait se débrouiller pour afficher l'Unicode qu'on lui envoie et gérer le paramétrage des "consoles" sous les différents OS.

---

c'est quoi une IHM ?
Et mon module n'est qu'un modeste module de calcule géometrique de polyèdres régulier, je vous ferai un liens quand j'aurai ,terminer.

Citation:

---

Comme vous ne montrez pas de code...

---

Le problème peut se représenter comme le code démonstratif du problème suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10

# -*- coding: utf-8 -*- # Est ce que Windows prend en charge la ligne du dessus ?   def dummy(side_length) '''return the area from an square      area= side_length²      area= side_length × side_length'''   return side_length * side_length

---

Copier simplement la fonction dans l'IDLE pour voir comment les signes:
- carrée ²
- multiplier × ( × != * )
sont représenter en tapant
help(dummy)
Et que l'IDLE n'affiche que le première ligne de docstring en appelant la fonction dummy dans l'interpréteur.

Merci pour vos réponses.

Salut,

Sous IDLE 3.2, çà fonctionne normalement.
Si vous êtes sous 2.x, le doctring devrait être écrit:

Code:

---

1 2 3 4

def dummy(side_length) u"""return the area from an square      area= side_length²      area= side_length × side_length"""

---

Citation:

---

c'est quoi une IHM ?

---

Demande a ton ami Google!

- W

La ligne

Code:

---

# -*- coding: utf-8 -*-

---

est bien comprise par Windows mais ne peut-être pas ce que tu attends : elle sert à spécifier l'encodage de ton fichier source mais ne spécifie pas l'encodage de ton flux de sortie.

Merci pour ces précisions,
je ne connaissait pas cette technique de docstring unicode merci du tuyau :

Code:

---

1 2 3 4 5

def dummy(side_length) u"""return the area from an square      area= side_length²      area= side_length × side_length"""

---

Et merci aussi pour la réponse concernant la ligne spécifiant l'encodage.

Salut,

Citation:

---

Envoyé par Luke spywoker

Et merci aussi pour la réponse concernant la ligne spécifiant l'encodage.

---

L'interpréteur Python utilisera cette information pour appliquer .encode au script chargé en mémoire avant de le compiler.
Le script est crée/modifié par un éditeur. C'est la fonction "save" qui devra faire le bon ".encode". La fonction Open/Create devant faire le bon ".decode".
La plupart des éditeurs ignorent cette ligne. En général, il faut configurer éditeur ou IDE autrement pour qu'il travaille dans l'encoding retenu.
Sur Linux l'encoding par défaut étant généralement "utf-8", çà ne pose pas de problème. Windows travaille avec d'autres défauts (latin-1) configurés par application. De plus, l'encoding "cp65001" est un "canada dry" d'utf-8.

- W