Discussion :

[fanfouer]

Bonjour,

Je rencontre aujourd'hui des difficultés pour trouver un connecteur MySQL fonctionnel pour Python 3.3.1.
Prévoyant de déployer ma solution sur un serveur Red Hat, je souhaiterais pouvoir trouver les paquets (ou les rpm) qui vont avec.

On trouve de tout, et tous les avis qui vont avec et difficile de choisir quelque chose de fiable.

J'ai pu tester ceci : http://www.rpmfind.net/linux/rpm2htm...ysql-connector
Yum me demande d'installer la version de Python... alors que j'ai déjà fait :

# python3
Python 3.3.1 (default, May 14 2013, 15:38:01)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Détail de l'erreur :

Error: Package: mysql-connector-python3-1.0.9-1.fc18.noarch (/mysql-connector-python3-1.0.9-1.fc18.noarch)
Requires: python(abi) = 3.3
Installed: python-2.6.6-29.el6_2.2.x86_64 (@standard)
python(abi) = 2.6
Available: python-2.6.5-3.el6.i686 (standard)
python(abi) = 2.6
Available: python-2.6.5-3.el6_0.2.i686 (standard)
python(abi) = 2.6
Available: python-2.6.6-20.el6.x86_64 (standard)
python(abi) = 2.6
Available: python-2.6.6-29.el6_3.3.x86_64 (standard)
python(abi) = 2.6
Available: python-2.6.6-36.el6.x86_64 (standard)
python(abi) = 2.6

Est-ce que quelqu'un a déjà eu l'occasion de répondre à cette question ? (qui me semble un peu "évidente", en 2013).

Merci par avance.

[wiztricks]

Salut,
Vous voyez bien que le .rpm ne trouve pas comment satisfaire "Requires: python(abi) = 3.3". Ce qui pose question sur "comment" a été installé cette version de Python sur le serveur RHEL pour ne pas être "vue" par le gestionnaire de package.
- W

[fanfouer]

Bonjour,

Merci pour cette réponse.

Python 3 n'étant pas dispo sur le dépôt standard, je l'ai installé avec make install en effet
Selon un mode opératoire proche de ce qui est expliqué ici : http://stackoverflow.com/questions/8...ython3-on-rhel

Le rpm de python 3.3.1 disponible ici http://rpmfind.net/linux/rpm2html/se...?query=python3 me demandait systématiquement de multiples dépendances, assez gavant à faire à la main.

Visiblement je suis obligé d'installer le paquet pour que ça passe ?

[wiztricks]

La question pourrait être "comment dire" à l'installation du rpm du connecteur MySQL où trouver un Python 3.3 à priori non standard.
Par défaut, il devrait être accessible via un lien sur le path "/usr/bin/python3".
Où comment installer une version non standard de sorte à ce que çà plaise au gestionnaire de packages.

Il serait sage d'aller poser la question dans le forum linux ad hoc et/où espérer qu'un lecteur ait des idées.

Sinon, installer le connecteur Python from scratch pourrait être une "solution".
Les autres sujets sont:

• Pourquoi ne pas utiliser la version Python "standard"?
• Si on installe un serveur RHEL c'est pour avoir du "support", modifier l'OS de façon hasardeuse n'est peut être pas recommandé.

- W

[fanfouer]

C'est surement les bonnes questions.

Si il n'y a pas de moyens simple, je reviendrai sur Python 2.6 (version disponible dans RHEL6 il me semble).

Le tout est de savoir si cette version sera adapté à ce que je veux développer sachant que j'ai une certaine volonté à toujours utiliser quelque chose d'up-to-date plus que les vieilleries qui restent parfois dans les distrib.

Mon projet utilise massivement des threads ici, c'est surement l'élément le plus compliqué, en plus de la connexion à MySQL qui semble très abouti en Python 2 Avec MySQLdb.

Merci pour ces réponses.

[wiztricks]

Mon projet utilise massivement des threads ici, c'est surement l'élément le plus compliqué, en plus de la connexion à MySQL qui semble très abouti en Python 2 Avec MySQLdb.

Utiliser "massivement des threads" est une mauvaise idée en général: chaque thread crée coûte en CPU et on a intérêt à en réduire le nombre à quelque chose de proche du nombre de CPU disponibles.

Avec Python, le GIL réduit la quantité de CPU utilisée par le programme à 1 quelque soit le nombre de threads. L'intérêt est assez limité à avoir une "pré-emption" lorsqu'on ne sait pas découper le boulot en activités qui "coopèrent". Si c'est le cas, on vire les threads pour utiliser des coroutines.

C'est vous qui voyez.
- W

[fanfouer]

Utiliser "massivement des threads" est une mauvaise idée en général: chaque thread crée coûte en CPU et on a intérêt à en réduire le nombre à quelque chose de proche du nombre de CPU disponibles.

Ce qui est sur c'est que c'est un élément clé de mon cahier des charges et on est pas là pour le discuter.

Mais j'apprécie ton conseil et saurai en tenir compte à l'avenir.
Parce que de manière générale on est d'accord, mais ici le but principal des thread est de paralléliser des temps d'attente très long. Non pas les avoir en série, autant les avoir en parallèle comme ça on nivèle par le temps le plus long.

[wiztricks]

... mais ici le but principal des thread est de paralléliser des temps d'attente très long.

Comme je vois que vous avez tout compris sur l'intérêt des threads, je dirais "circulez, il n'y a rien à voir".
Bon courage!

- W