Discussion :

[crashXpert]

Hello,

J'ai une différence de comportement entre Python 2.7 et Python 3.7.2 sur Windows 10 qui me pose un gros problème:

Python 2.7

Code :

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

1
2
3
4
5
>>> import os
>>> os.environ["abc_DE"]="tiTI"
>>> os.system("set")
 
abc_DE=tiTI

Python 3.7.2

Code :

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

1
2
3
4
5
>>> import os
>>> os.environ["abc_DE"]="tiTI"
>>> os.system("set")
 
ABC_DE=tiTI

La 'mixed-case' en python2.7 est respectée pour le nom de variable et sa valeur, et seulement pour sa valeur en python3.7.2
Mon problème est que j'appelle ensuite un code JAVA dont je ne maîtrise pas l'implémentation, et qui semble sensible à la case (quand le nom de la variable est passé en Upper-case, JAVA la voit comme non positionnée).

PS1 : Pour l'instant le by-pass trouvé consiste à faire un 'set abc_DE=tiTI' dans la console WINDOWS avant de lancer mon script python, mais ce n'est pas trop acceptable.
PS2 : Le script est voué à être déployé sur un parc de machine avec une configuration imposée. Donc je cherche une solution autre que passer en Python 2.X.

D'avance merci pour votre aide.

[tyrtamos]

Bonjour,

Essaie ça (Python 3.7):

Code :

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

1
2
3
os.putenv("abc_DE", "tiTI")
print(os.system("set"))
abc_DE=tiTI

[wiztricks]

Salut,

PS1 : Pour l'instant le by-pass trouvé consiste à faire un 'set abc_DE=tiTI' dans la console WINDOWS avant de lancer mon script python, mais ce n'est pas trop acceptable.

Le vrai soucis est que sur Windows, les variables d'environnements ne sont pas sensibles à la casse: ABC_DE écrasera abc_DE. De même, si vous faites echo dans un terminal vous allez récupérer la même valeur quelque soit la casse.
C'est ce que os.environ traduit en passant tout en uppercase.

PS2 : Le script est voué à être déployé sur un parc de machine avec une configuration imposée. Donc je cherche une solution autre que passer en Python 2.X.

La solution de Tyrtamos peut vous dépanner mais votre construction restera sensible aux mises à jour puisqu'elle repose sur une hypothèse (nom des variables sensibles à la casse sous Windows) qui n'est pas vraie.

- W

[crashXpert]

Hello,

Merci tyrtamos, ça fonctionne comme je veux maintenant

wiztricks, je ne suis pas sure d'avoir compris ton point. Effectivement le os.environ semble faire un UPCASE que je ne souhaite pas. Du coup le putenv correspond mieux. Mais tu semble dire qu'avec cette méthode je m'expose à des problèmes futurs ? Peux-tu m'expliquer ?

Encore merci pour votre aide et réactivité.

[wiztricks]

Salut,

wiztricks, je ne suis pas sure d'avoir compris ton point. Effectivement le os.environ semble faire un UPCASE que je ne souhaite pas. Du coup le putenv correspond mieux. Mais tu semble dire qu'avec cette méthode je m'expose à des problèmes futurs ? Peux-tu m'expliquer ?

Déjà vous corrigez côté Python un soucis dans le code Java qui devrait récupérer "abc_DE" quelque soit la casse.
Et dans les faits, le code Python passe des informations au code Java via un chemin (des variables d'environnements) dont la fiabilité dépend de la créativité des 3 mainteneurs: Java, Python, Windows à interpréter la règle Windows où c'est sensible à la casse (on peut définir des variables d'environnement mixed case - ainsi que les noms de fichiers) sans l'être vraiment ("abc_DE" devrait retourner la même chose que "ABC_DE").
Et cette créativité est ce qui s'exprime dans le passage Python2/Python3. Elle pourra aussi se manifester avec une mise à jour de Java ou de Windows. Comment? J'en sais rien: je dis juste que votre code n'est pas très robuste.

- W

[tyrtamos]

Bonjour,

Windows a toujours été ambigu sur la casse, et semble se comporter pour les variables d'environnement, comme pour les noms de fichier.

Une idée supplémentaire pour traiter les variables d'environnement: passer directement par l'api windows => installer le module pywin32.

Exemple de code:

Code :

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

1
2
3
4
5
6
7
8
9
from win32 import win32api
 
win32api.SetEnvironmentVariableW("abc_DE", "tiTI")
 
val = win32api.GetEnvironmentVariableW("abc_DE")
print(val)
 
val = win32api.GetEnvironmentVariableW("ABC_DE")
print(val)

Ce qui affiche:

tiTI
tiTI

On voit bien ce qui se passe: Windows a bien conservé le nom de variable avec sa casse ("abc_DE"), mais il accepte sa lecture avec une autre casse ("ABC_DE").

Ce serait mieux que java fasse pareil.

[crashXpert]

Hello,

Merci wiztricks pour cette précision. J'ai eu confirmation que le code JAVA fait une comparaison de chaine et ne passe pas par une API pour interroger l'ENV. J'ai fait une demande d'évolution, mais elle n'arrivera pas de suite, et en attendant je dois avancer 🙂 Mais je partage entièrement cette analyse.

Merci tyrtamos pour cette autre solution. Elle est un peu plus robuste, mais la première me plait bien pour son côté portable sur Linux s'il le faut.

Encore merci pour votre aide et ses infos.