Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Python ou Ruby ?
Je suis nouveau venu à Python, que je suis plus en train d'expérimenter que d'utiliser en production. J'y suis arrivé par le livre de M. Summerfield "Rapid GUI programming with Python & Qt". J'ai donc repris la configuration recommandée, en évitant Python 3.0 car il n'existe pas de version PyQt utilisant ce nouveau Python.
J'ai devant moi deux semaines de congés, que je vais mettre à profit pour approfondir ce langage, car pour le moment j'hésite encore sur le choix définitif: Python ou Ruby?
Je ne connais pas Ruby mais de ce que j'ai pu comprendre de différentes informations glannée de ci de là, ruby est serait purement orienté web (et donc réseau je suppose). Python, lui est également très utilisé pour du web ou du réseau, mais reste très ouvert pour une plus large gamme de soft (jeux, traitement de texte, scientifique etc...). La partie sur ruby est à confirmer, mais en me basant sur ce que j'ai cru comprendre de ce dernier donc, je dirais python, pour sa flexibilité (et accessoirement son gestionnaire d'exceptions, sa simplicité entre autres).
Python, mais sans PyQt, passe par wxPython, bien plus "mieux" foutu que PyQt (plsu dans la mentalité Python que PyQt).Envoyé par aandre2937
Non. Ruby on Rails est le gros framework web, mais Ruby != RoR.
Tout dépend ce que tu veux faire en réalité avec. Si c'est du scripting pur, les deux seront très bien. Pour le côté GUI, je ne connais pas Ruby, mais wxPython est très bien. Pour le côté scientifique, Python sans hésiter (les outils de Ruby ne sont pas aussi bien développés). Pour le côté Web, ça se défend, il y a de
quoi choisir des deux côtés. ...
Personnellement, je vais (re)passer a ruby ( + on rails) a la place de python/django, pour ces raisons suivantes :
- Je prefere la syntaxe de ruby, qui est BEAUCOUP plus flexible
- l'ORM de django est une merde (pas de connexions persistantes, pas de pools de connexion, pas de cache de requêtes, donc des requêtes qui se répètent a gogo dans la même page....)
- j’en ai marre que personne respecte les conventions de nommage de python, chez ruby c’est pas comme ca, j’ai rarement vu une api ne pas respecter les conventions
- rubygems
- JRuby est bien mieux maintenu que Jython qui lui est pratiquement a l'abandon
- Les API sont généralement plus sympa je trouve, par exemple Gruff, quand on vois l'horreur qu'est matplotlib a coté... (certe c'est plus complet, mais c'est une horreur de conception)
- J'en ai marre que personne respecte le PEP-008
Python a quand meme des avantages :
- Meilleur documentation
- Meilleur vitesse (enfin pas pour longtemps.. avec ruby2)
- l'admin automatique de django
Ah bon... Je travaille avec PyQt et je vais me faire sans difficulté une GUI évoluée. Le seul reproche que je ferais à PyQt est le manque d'exemples simples.
une API qui prefere utiliser les conventions de nommage de C++ plutot que celles de python j'appelle pas ca mentalité python....
Les conventions de nommage C++, ça n'existe pas. Il ya une convention pour le coeur de Python, mais ça n'est pas une obligation, tout comme en C++.
Maintenant, la manière de fonctionner me semble plus pythonistique, mais ce n'est que mon avis.
Moi c'est simple, si je trouve une API qui respecte pas ca, c'est que le créateur n'a aucun respect pour les langage et les programmeurs, donc poubelle
Mais il n'y a pas d'obligation pour Python, comme il n'y en a pas en C++, donc je ne vois pas quel est le problème.
pour la cohérence de l'API
Bonjour,
Personnellement tant que qu'on peut différencier les classes et le reste suivant que la première est une capitale ou pas, ça me va.
D'un côté c'est bien que tout le monde ait les mêmes conventions, d'un autre côté quand je fais de C# ou du Java ça me gave de me forcer à utiliser une convention que je n'aime pas.
De toute façon pour Python c'est mort vu que la bibliothèque standard elle-même ne supporte pas les conventions.
:wq
L'API wxPython est cohérente.
Un effort est fait pour rendre PEP8 les API des modules standard.
Je viens de me rendre compte que ce que je visais est en accord avec PEP 8 :
Je ne vois pas l'intérêt de préserver la compatibilité dans Python 3, mais bon...mixedCase is allowed [for functions] only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.
:wq
Lequel des 2 langages est le plus adapté à faire du multi-tâches? multi-threads? multi-process? multi-processeurs?
Car j'entendu dire que ces langages n'étaient pas adapté à la programmation parallèle?
C'est un amalgame, plutôt.
Les deux ont un lock au niveau de l'interpréteur (enfin, CPython, Jython et IronPython n'ont pas ce "problème") qui empêche que deux threads accèdent à l'interpréteur en même temps.
Maintenant, il y a des packages pour travailler en multi-processus, et en compilant le code avec Cython ou avec du code C/C++/Fortran, tu peux t'affranchir du verrou et donc aucun problème.
Je ne connais pas python et ruby, mais le but de la conccurence, c'est que justement que 2 threads ptyhon puissent accèder en "parallèle" de manière transparante à l'interpréteur, ou alors c'est justement ce que tu décrit?
que veux-tu dire par:
"en compilant le code avec Cython ou avec du code C/C++/Fortran" ???
Avec du code C/C++/Fortran ou Cython, il n'est plus forcément nécessaire de faire appel à l'API Python. Si tel est le cas, plusieurs threads pourront travailler en parallèle.
Python et Ruby ne permettent pas (ou plutôt les implémentations de référence) que deux threads accèdent en même temps à l'interpréteur.
Je n'ai pas essayé mais le PEP-0317 mentionne:
The processing package mimics the standard library threading
module functionality to provide a process-based approach to
threaded programming allowing end-users to dispatch multiple
tasks that effectively side-step the global interpreter lock.
et devrait être inclus dans 2.6n, 3.0n.
Cela permet à priori de distribuer la charge sur plusieurs CPU d'un multicore même si cela ne remet pas en cause l'architecture globale de l'interpréteur.
Ceci dit, tout dépend des utilisations qu'on fait de Python ou des autres langages interprétés: si on veut de la performance 'brute', il vaut mieux utiliser C/C++...
-W
D'où ce que j'ai dit, on peut passer des fonctions C/C++/Fortran aux threads, et à ce moment, aucun problème. Et ça sera bien plus rapidement créé qu'une application purement compilée dans 99% des cas.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager