- L'accélération du temps de démarrage ;
- La corrections de bugs de cPickle (implémentation en C de la bibliothèque de serialisation d'objets pickle) ;
- Cette version passe les tests de tous les outils et bibliothèques tiers qui servent à évaluer le projet. Ceci inclus tous les tests de non régression de Python, ainsi que plusieurs projets majeurs parmi lesquels Twisted, Django, NumPy et SWIG.
La consommation mémoire a été multipliée par dix, mais la baisse de consommation de ressources mémoire est un chantier pour la prochaine version (2009Q3).
Cette version n'est pas encore prête pour une utilisation en production, mais permet à chacun de voir la progression du projet.
Aller plus loin
- Annonce officielle (1 clic)
- Précédente annonce sur Linuxfr (1 clic)
- Page de tests du projet (0 clic)
# Un début !
Posté par ☂ Tramo . Évalué à 10.
Java va devoir faire face à un concurrent de plus en plus sérieux !
[^] # Re: Un début !
Posté par Maclag . Évalué à 9.
Ils ont dit que la prochaine version aura pour but de minimiser la consommation mémoire alors que celle-là a pour but de multiplier les perfs par 5.
La version 2009Q3 aura pour traits:
- Grâce au travail d'optimisation, la consommation mémoire a été divisée par 5 par rapport à la précédente version!
- En contrepartie, la vitesse d'exécution a été divisée par 10.
- L'amélioration de la vitesse d'exécution est en chantier pour la version 2009Q4.
- Et moi je sors: −−−−−−−−> [ ]
# Avantage
Posté par collinm (site web personnel) . Évalué à -7.
j'ai fait, du C, Java et python
et j'ai pas compris pourquoi certains vénère tant ce langage...
afin bon, si ça trouve son public
www.solutions-norenda.com
[^] # Re: Avantage
Posté par NOULARD Eric (site web personnel) . Évalué à 8.
- j'aime beaucoup Python
- j'en fait pas mal en ce moment
- j'ai programmé 5 ans ou +
(ou je programme encore) en C, C++, Java, Fortran, Perl, Shell etc...
A chaque fois que j'ai fait du Python (comme en ce moment) c'était pour prototyper rapidement et éventuellement garder une appli. qui ne nécessite pas de perfo démoniaque (sinon je fait du C/C++ voire Java).
Eh bien à chaque fois je n'ai pas été déçu et je suis quasiment certain que je n'aurais pas été plus vite en utilisant d'autres langages que je pratique pourtant plus souvent que Python (C, C++ et dans une moindre mesure Java).
Je pense que le seul truc qui pourrait me faire changer d'avis serait un autre langage interprété et dynamique comme Ruby ou peut-être Groovy [http://groovy.codehaus.org/] mais surement pas un langage compilé comme C/C++/Java
Le cycle de compilation+exécution est trop pénible et la dynamicité des langages compilés que je connais est trop faible pour faire des choses très dynamiques
(même avec l'introspection Java).
Par exemple DTest (Distributed Test) un petit outil qui permet de lancer des exécutables
sur différentes machines via une connexion SSH et coordonner [de façon sommaire] leur exécution et ainsi que ce qu'ils affichent sur leur sorties standard, une intro là:
[http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)]
Ca fait 1700 lignes de python (dont ~400 de commentaires) et ça m'a pris au total cumulé une quinzaine de jours.
J'aurai été incapable de faire ça aussi rapidement en C/C++/Java.
[^] # Re: Avantage
Posté par C. OB (site web personnel) . Évalué à 4.
Je me suis mis aussi au python (en venant du C) il y a quelques temps, et je dois dire que je trouve ça pas simple:
Certes on élimine la compilation, mais ce faisant on perd aussi toute l'habitude qu'on avais de l'environnement : Makefile, messages d'erreur du compilo,...
En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême. (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)
De plus les problèmes de version/lib sont toujours là ! J'ai passé un temps fou à trouver l'origine d'un message d'erreur obscur, pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé et que mon code ne faisait plus ce que je pensais.
Ce problème est commun a la plupart des langages interprétés, j'ai eu le même type de truc en ruby.
Et surtout, même si c'est qu'une question d'habitude, il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal.... bref, bien des fois je me suis dis qu'avec le temps que je perdais à faire ça, j'aurais déjà fini depuis longtemps en C.
Peut-être que ça payera un jour...
(Et pourtant, les bouquins le python pour les nul et les linux-mag dédiés au sujet traînent partout à la maison)
Par contre, il faut avouer que en terme de bibliothèque, le langage est bien fourni, les fonction de haut-niveau (comme les dessins ou le numérique) c'est autre chose que le C, c'est là ou je pense gagner du temps sur le long terme.
voilà, my 2c
[^] # Re: Avantage
Posté par Marc (site web personnel) . Évalué à 3.
pdb par exemple ?
Perso, quand il faut faire une appli, je passe beaucoup moins de temps à la faire en python qu'en C/C++. Le langage se fait moins sentir et je peux me concentrer sur ce que je veux faire et pas comment je vais pouvoir le faire avec le langage. C'est mon resenti perso.Mais par exemple, je voulais intéragir avec l'API de vimeo pour envoyer des vidéos. En 30min j'avais un premier trucs qui fonctionnait, fait à "la bite et au couteau", sans utiliser de module pour REST & cie. Ben en C, je sais que j'aurais mis plus de temps.
[^] # Re: Avantage
Posté par C. OB (site web personnel) . Évalué à 1.
Je suis bien d'accord que en python, les bibliothèques sont plus haut niveau qu'en C, qu'il y a moins de "fourbi inutile" pour parser les arguments, allouer la mémoire au préalable, vérifier l'environnement, ... etc
Comme c'est démontré dans un message en-dessous, récupérer le texte d'une page HTML en python se fait en une ligne, alors que même avec curl et libxml, en C.... ca fait plus d'une ligne, quoi.
Encore faut-il connaître ces librairies (qui n'est jamais tombé sur la lib idéale pour le script que l'on viens juste de terminer...), et s'habituer aux spécificités du langage, qui pour moi reste quand situé entre le C et le perl/bash en terme de simplicité et logique de la syntaxe.
(Mais mon point de vue est biaisé, car je connais bien le C et très peu le python).
J'ai tenté un moment le ruby, j'ai eu la même impression....
[^] # Re: Avantage
Posté par Bertrand Mathieu . Évalué à 5.
oui ça s'appelle pdb (c'est un module).
L'utilisation courante est d'insérer dans ton code une ligne:
import pdb; pdb.set_trace()
Sinon tu peux aussi le lancer avec une traceback (en post-mortem).
Il y des environnements qui font ça pour toi.
Dans les framework web (pylons, werkzeug, zope avec pdbdebugmode) c'est avec ça qu'est fait la console de debug en cas d'exception non interceptée.
en gros pour l'interception automatique ça revient à ça:
try:
my_func(...)
except SystemExit:
raise # Reraise the system exit exception
except Exception, error:
from sys import exc_info
import pdb
pdb.post_mortem(exc_info()[2])
raise
enfin avec un shell lancé depuis emacs, celui-ci peut reconnaitre l'arrivée sur une ligne pdb et affiche le code source de la frame en cours dans un autre panneau.
[^] # Re: Avantage
Posté par Victor STINNER (site web personnel) . Évalué à 5.
De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)
... pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé
Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)
il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal....
Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction. Exemples C => Python :
* open(), close() => os.open(), os.close()
* fopen(), fclose() => f=open(); f.close()
* sigaction(num, func, &oldfunc) => oldfunc = signal.signal(num, func)
* access(path, mode) => os.access(path, mode)
Et puis, la doc Python est plus agréable à lire que les manpages C je trouve. http://docs.python.org/library/
[^] # Re: Avantage
Posté par C. OB (site web personnel) . Évalué à 0.
Comparons ce qui est comparable...
En C , je trouve les messages *du compilateur* plus clairs.
En python, ya pas de compilation (ou du moins, pas à mon niveau de connaissance).
Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)
Voici le diff en question.
Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).
C'est vrais que c'est dans le module pyUnit.
- self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)
+ self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)._tests
def Build(self):
ret = True
[...]
- self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)
+ self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)._tests
def Build(self):
ret = True
print "Compilation of %s..." % self.name
Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction.
C'st exactement là-dessus que je perdais un temps fou, a tel point que je me suis fait un post-it avec les modules pour chaque fonction.
Et puis, la doc Python est plus agréable à lire que les manpages C je trouve.
Là pour le coup je ne suis pas du tout d'accord ! Pour moi rien de plus rapide de faire man 2 open et tu as , dans le terminal, le ou les .h qu'il faut inclure & la description des arguments.
La doc python elle est très bien, sauf que quand tu lance une recherche sur open ya 100 réponses ! Il faut déjà savoir quel module que tu cherche. Et c'est sur le net... si t'a pas le net c'est pas pratique (tu peux la télécharger, mais alors tu fait comment pour chercher ?)
Au final, moi je trouve qu'il y a du pour & du contre dans les 2 langages, et pour moi le python n'est pas l'eldorado de la programmation tel qu'il est parfois présenté...
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
Si ton code doit tourner sur python 2.3 alors il faut développer avec un 2.3!
C'est normal que les API évolue et il ne faut pas t'attendre à ce que tout ce que tu développe avec un 2.5 fonctionne sur un 2.3.
On a parfois le problème au boulot, avec java, on a forcément une version un peu récente par défaut sur nos machines avec d'autres versions à côté pour les développements qui doivent rester compatibles 1.4, mais parfois un des développeurs oublie sur quel JDK il est et on constate plus tard qu'on a des fonctions du 1.5 qui sont utilisées.
Heureusement maintenant on est passé à retrotranslator qui nous permet quand même d'utiliser les améliorations les plus fondamentales de l'API java 1.5.
[^] # Re: Avantage
Posté par NOULARD Eric (site web personnel) . Évalué à 2.
de démarrage j'ai trouvé celui de python acceptable.
Pour le debugger:
- python inclut le module pdb [http://docs.python.org/library/pdb.html]
- il existe aussi pydb [http://bashdb.sourceforge.net/pydb/] qui permet l'utilisation de DDD (à vérifier je ne suis pas utilisateur)
- comme python est interprété, l'interpréteur est déjà en lui-même un outil d'analyse très intéressant
Pour ce qui est du ré-apprentissage de l'API, ben évidemment ça peut prendre du temps, mais je trouve que ça va assez vite, car la doc de l'API est bonne.
Ensuite je pense qu'on gagne énormément de temps quand on utilise des API de haut niveau dont l'équivalent en C serait énormément plus verbeux. Par exemple récupérer un fichier sur un serveur en http:
import httplib
dlSavannah = httplib.HTTPConnection('download.savannah.gnu.org')
dlSavannah.request("GET","/releases-noredirect/tsp/dtest/what_is_dtest.pdf")
response = dlSavannah.getresponse()
f=open("what_is_dtest.pdf","w")
f.write(response.read())
f.close()
dlSavannah.close()
Il faudrait évidemment rajouter la gestion des erreurs, mais même comme ça
écrire l'équivalent en C, bon courage et même si tu prends la lib qui va bien
(curl [http://curl.haxx.se/libcurl/c/libcurl-tutorial.html] par exemple)
[^] # Re: Avantage
Posté par collinm (site web personnel) . Évalué à 1.
ton exemple de code n'aurait pas été vraiment plus long à coder en java, delphi...
www.solutions-norenda.com
[^] # Re: Avantage
Posté par Moonz . Évalué à 4.
Prouve le. Mon expérience me prouve le contraire (pour Delphi j’en sais rien, expérience insuffisante ;)).
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
java.io.InputStream is=new java.io.BufferedInputStream(new java.net.URL("http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
try{
java.io.OutputStream os=new java.io.BufferedOutputStream(new java.io.FileOutputStream("what_is_dtest.pdf"));
try{
int c;
while(c=is.read()>=0){os.write(c);}
os.flush();
}finally{fos.close();}
}finally{is.close();}
[^] # Re: Avantage
Posté par NOULARD Eric (site web personnel) . Évalué à 1.
On voit que Java et Python ont des librairies standards de
suffisamment haut niveau pour faire des choses rapidement mais....
On voit aussi que tu as un peu triché en essayant de dissimuler
le fait que Java est un langage compilé. Ce qui fait
que ton programme tel quel ne fonctionne pas alors
que tu peux copier/coller mon exemple python et tu verras que
ça marche.
Dans ton exemple il manque
- une classe englobante
<code class getIt { ...
}
au passage si j'appelle la classe d'un nom différent que le nom
de fichier ça me compliquera l'exécution....
- une méthode
public static void main(String[] args)pour cette classe qui permettra l'exécution du programme
- des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype
Je rajoutes à ça, qu'il faut:
a) compiler javac getIt.java
b) executer java getIt
Bref Java ET Python sont très expressifs et ont une librairie standard fourni, mais Python est un langage de script plus souple pour prototyper.
Résultat un fichier Java d'environ 27 lignes (pour que ça reste lisible)
que je dois compiler+exécuter contre un fichier de 10 lignes en python
que je peux exécuter tel quel et/ou copier coller dans l'interpréteur.
Je persiste, Java c'est très bien mais pour du prototypage ça vaut
pas un clou :-)
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
Mais je considère effectivement que java est plus adapté à des programmes de taille moyenne à grande bien architecturés, pas pour des petits programmes quick and dirty. Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)
- des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype
Non, soit tu intercepte les exceptions (et tu en fait quelque chose), soit tu déclare que ta méthode peut les lancer, en l'occurrence ton main.
[^] # Re: Avantage
Posté par NOULARD Eric (site web personnel) . Évalué à 1.
d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...
Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)
on est sur la même longueur d'onde je monte souvent a sed et shell afin d'arriver plus awk :-).
Mais bon, je dois avouer qu'un bon petit script python fait du bon boulot également, ceci avec le coté riche de Java et le côté Quick & Dirty du shell et ses amis scriptables.
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
> > mes try{}finally{} le rendent plus robuste
> d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...
Bien sur qu'on est obligé de les mettre, l'interpréteur/compilateur ne peut pas trouver de lui-même quelle est la façon intelligente de le faire. (Dans les cas simple comme ici ce serait possible, mais pas en général)
[^] # Re: Avantage
Posté par Moonz . Évalué à 3.
* créer un objet URL et un objet "BufferedInputStream". En python, je gère un seul objet, "session HTTP". "Buffer" ? "Stream" ? Concepts beaucoup trop bas niveau pour ce que je veux faire, morbleu !
* De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera. Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.
* Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…
Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.
Et comme l’ont fait remarqué d’autres plus bas, l’api que tu utilises en Java n’est pas du même niveau que celle en python, qui serait urllib2. L’équivalent du code python utiliserait plutôt WebRequest & co. Encore des classes en plus.
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
* De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera.
Non, tu n'es pas obligé, tu peux te contenter de l'InputStream de l'URL et du FileOutputStream, mais c'est plus efficace de bufferiser les IO.
Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.
L'OutputStream c'est juste parce que c'est la classe de base et que j'ai l'habitude ne ne pas utiliser les sous-classes quand je peux me contenter de la classe parente, tu peux écrire directement BufferedOutputStream si ça te dérange tant que ça d'avoir des noms de classe différents.
* Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…
Dans la méthode python cette boucle est sous-entendue. Au boulot dans un projet de relativement grosse taille on a une méthode utilitaire qui fait ça, on lui passe un InputStream et un OutputStream (ou directement des fichiers ou URLs, y a plusieurs variantes) et elle boucle pour copier l'un dans l'autre.
Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.
Mais donc dans ton exemple tu va charger tout le contenu de ton URL dans une chaîne de caractères pour pouvoir ensuite faire un remplace dessus et puis la réenregistrer, tu va utiliser beaucoup plus de mémoire que nécessaire par rapport à un fonctionnement en streaming.
Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.
[^] # Re: Avantage
Posté par wilk . Évalué à 2.
Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
[^] # Re: Avantage
Posté par wismerhill . Évalué à 1.
L'enrobage syntaxique à la C++ de java fait que des très petits programmes vont faire beaucoup de ligne pour pas grand chose (mais contrairement à python on peut tout mettre sur une seule ligne ;-) )
De plus, je préfère écrire quelques lignes de plus et que le code soit plus lisible plutôt que d'avoir un truc super compact qu'il faut relire cinq fois pour comprendre ce qu'il fait. Mais là je pense plutôt à perl.
Et python, qui impose syntaxiquement l'indentation m'empêche certaine mise en forme du code qui en améliore la lisibilité (séparer un long appel de fonction sur plusieurs lignes avec indentation variable pour bien identifier des groupes de paramètres par exemple)
Et si tu pense qu'on peut faire un projet de taille raisonnable en quick and dirty, je plains ceux qui devront reprendre ton code.
[^] # Re: Avantage
Posté par wilk . Évalué à 4.
Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)
query('select mon champ'
- - - - - - 'from matable'
- - - - - - 'where macondition'
- - - - - - 'order by montri',
- - - - - - - - - monparam1='cecicela',
- - - - - - - - - monparam2='etci')
Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
[^] # Re: Avantage
Posté par wismerhill . Évalué à 2.
Ah, ça je ne savais pas, merci.
(mon expérience de python date déjà de plusieurs années, je me suis concentré sur java pour raison professionnelle)
Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
Ça ce sont les programmeurs qui appliquent sans réfléchir les consignes qu'ils ont eu a l'école, et pas que pour les commentaires!
On en a eu un comme ça pendant un moment, c'est toujours un petit éclat de rire, suivit d'un long soupir, de devoir reprendre (réécrire) son code.
[^] # Re: Avantage
Posté par Victor STINNER (site web personnel) . Évalué à 4.
from urllib.request import urlopenAvec le temps, les programmes Python deviennent de plus en plus court :-) Enfin, de plus en plus haut niveau (urllib est un niveau au dessus d'httplib).url = 'http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
with urlopen(url) as dlSavannah, open("what_is_dtest.pdf","wb") as f:
...f.write(dlSavannah.read())
[^] # Re: Avantage
Posté par NOULARD Eric (site web personnel) . Évalué à 2.
à noter que ça existe aussi en Python 2.5 (peut-être même 2.3 à vérifier.
Et du coup on peut faire ça en 2 lignes!!
import urllib
urllib.urlretrieve('http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
[^] # Re: Avantage
Posté par wilk . Évalué à 4.
[^] # Re: Avantage
Posté par tylhdar . Évalué à 2.
J'utilise Eric4 qui se trouve dans les dépôts de toute les bonnes distributions; c'est un ide avec débogueur graphique qui permet de voire le contenu de toute les variables, entre autre.
[^] # Re: Avantage
Posté par Antoine . Évalué à 2.
Ah c'est vrai qu'il y a lieu de regretter les Makefile :-)
les messages d'erreurs que je trouve d'une confusion extrême
Du genre ?
pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé
Heu, quoi exactement ? La syntaxe ne change normalement pas, il y a seulement des ajouts.
# Ça me brule les lèvres...
Posté par Pol' uX (site web personnel) . Évalué à 6.
La compilation est elle destinée à rester sur le HD, dans l'arborescence de Python ?
Quels sont les gains de performance obtenus par rapport à la version stable de Python ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Ça me brule les lèvres...
Posté par wilk . Évalué à 2.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
# Psyco V2
Posté par wilk . Évalué à 3.
http://mail.python.org/pipermail/python-announce-list/2009-J(...)
[^] # Re: Psyco V2
Posté par Antoine . Évalué à 3.
[^] # Re: Psyco V2
Posté par wilk . Évalué à 2.
http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
# Décharger avaler
Posté par Pierre Tramonson . Évalué à 1.
En tout cas on peut leur dire "good job", pour rester dans le ton.
[^] # Re: Décharger avaler
Posté par Boa Treize (site web personnel) . Évalué à 4.
Et l'on ne comprend cette référence qu'en connaissant, bien sûr, les œuvres des Monty Python, dans le cas présent Sacré Graal.
Bridgekeeper: What... is the air-speed velocity of an unladen swallow?
King Arthur: What do you mean? An African or European swallow?
Bridgekeeper: Huh? I... I don't know that.
[he is thrown over]
Bridgekeeper: Auuuuuuuugh.
[^] # Re: Décharger avaler
Posté par tylhdar . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.