"map() and filter() return iterators. If you really need a list, a quick fix is e.g. list(map(...)), but a better fix is often to use a list comprehension (especially when the original code uses lambda), or rewriting the code so it doesn’t need a list at all. Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful)".
- "Removed: apply(). Instead of apply(f, args) use f(*args)." - "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable".
"map() and filter() return iterators. If you really need a list, a quick
fix is e.g. list(map(...)), but a better fix is often to use a list
comprehension (especially when the original code uses lambda), or
rewriting the code so it doesn’t need a list at all. Particularly tricky
is map() invoked for the side effects of the function; the correct
transformation is to use a regular for loop (since creating a list would
just be wasteful)".
- "Removed: apply(). Instead of apply(f, args) use f(*args)."
- "Removed reduce(). Use functools.reduce() if you really need it;
however, 99 percent of the time an explicit for loop is more readable".
"map() and filter() return iterators. If you really need a list, a quick fix is e.g. list(map(...)), but a better fix is often to use a list comprehension (especially when the original code uses lambda), or rewriting the code so it doesn’t need a list at all. Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful)".
- "Removed: apply(). Instead of apply(f, args) use f(*args)." - "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable".
À mon avis, on peut apprendre pas mal de langages sans connaître grand chose aux concepts de la programmation. Comme on peut apprendre pas mal de langues sans rien connaître aux notions de syntaxe, de grammaire, de sémantique et autres...
C'est absolument mon avis [et je ne suis pas sûr qu'il soit si répandu dans le milieu des enseignants d'informatique]. Le corollaire étant que l'apprentissage d'un langage de programmation ne doit pas être réservé aux gens du sérail et que les documentations des dits langages doivent donc être écrites en conséquence. Reste à savoir si c'est possible, moi je pense que oui, y compris pour utiliser des notions avancées, le tout étant qu'on en ait besoin (nécessité souvent fait sens).
Paul Gaborit a écrit :
À mon avis, on peut apprendre pas mal de langages sans connaître grand
chose aux concepts de la programmation. Comme on peut apprendre pas
mal de langues sans rien connaître aux notions de syntaxe, de
grammaire, de sémantique et autres...
C'est absolument mon avis [et je ne suis pas sûr qu'il soit si répandu dans le
milieu des enseignants d'informatique]. Le corollaire étant que l'apprentissage
d'un langage de programmation ne doit pas être réservé aux gens du sérail et que
les documentations des dits langages doivent donc être écrites en conséquence.
Reste à savoir si c'est possible, moi je pense que oui, y compris pour utiliser
des notions avancées, le tout étant qu'on en ait besoin (nécessité souvent fait
sens).
À mon avis, on peut apprendre pas mal de langages sans connaître grand chose aux concepts de la programmation. Comme on peut apprendre pas mal de langues sans rien connaître aux notions de syntaxe, de grammaire, de sémantique et autres...
C'est absolument mon avis [et je ne suis pas sûr qu'il soit si répandu dans le milieu des enseignants d'informatique]. Le corollaire étant que l'apprentissage d'un langage de programmation ne doit pas être réservé aux gens du sérail et que les documentations des dits langages doivent donc être écrites en conséquence. Reste à savoir si c'est possible, moi je pense que oui, y compris pour utiliser des notions avancées, le tout étant qu'on en ait besoin (nécessité souvent fait sens).
candide
kael a écrit :
- "Lambda had originally been scheduled for removal but has been retained, and in its original form."
J'ignorais ce point lequel n'est d'ailleurs même pas évoqué dans les livres (par exemple Lutz ou Martelli pour les plus connus).
- "Removed: apply(). Instead of apply(f, args) use f(*args)." - "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable".
OK merci de toutes ces références précises.
On se demande pourquoi ces informations ne figurent pas en toutes lettres dans la doc de Python 2.6. Faut dire que ce ne sont pas les aberrations qui manquent. Dans le manuel de référence, on peut lire par exemple ceci :
======================= 8< ========================== While this manual aims to provide comprehensive coverage of Python’s class mechanics, it may still be lacking in some areas when it comes to its coverage of new-style classes. Please see http://www.python.org/doc/newstyle/ for sources of additional information. ======================= >8 ==========================
Le manuel de RÉFÉRENCE de la version de 2.6 (donc en fait qui précède la version 3.0) n'est pas capable d'incorporer des possibilités offertes par le langage dès la version 2.2 qui date de fin 2001 !!!! On croit rêver.
kael a écrit :
- "Lambda had originally been scheduled for removal but has been
retained, and in its original form."
J'ignorais ce point lequel n'est d'ailleurs même pas évoqué dans les livres
(par exemple Lutz ou Martelli pour les plus connus).
- "Removed: apply(). Instead of apply(f, args) use f(*args)."
- "Removed reduce(). Use functools.reduce() if you really need it;
however, 99 percent of the time an explicit for loop is more readable".
OK merci de toutes ces références précises.
On se demande pourquoi ces informations ne figurent pas en toutes lettres dans
la doc de Python 2.6. Faut dire que ce ne sont pas les aberrations qui manquent.
Dans le manuel de référence, on peut lire par exemple ceci :
======================= 8< ========================== While this manual aims to provide comprehensive coverage of Python’s class
mechanics, it may still be lacking in some areas when it comes to its coverage
of new-style classes. Please see http://www.python.org/doc/newstyle/
for sources of additional information.
======================= >8 ==========================
Le manuel de RÉFÉRENCE de la version de 2.6 (donc en fait qui précède la version
3.0) n'est pas capable d'incorporer des possibilités offertes par le langage dès
la version 2.2 qui date de fin 2001 !!!! On croit rêver.
- "Lambda had originally been scheduled for removal but has been retained, and in its original form."
J'ignorais ce point lequel n'est d'ailleurs même pas évoqué dans les livres (par exemple Lutz ou Martelli pour les plus connus).
- "Removed: apply(). Instead of apply(f, args) use f(*args)." - "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable".
OK merci de toutes ces références précises.
On se demande pourquoi ces informations ne figurent pas en toutes lettres dans la doc de Python 2.6. Faut dire que ce ne sont pas les aberrations qui manquent. Dans le manuel de référence, on peut lire par exemple ceci :
======================= 8< ========================== While this manual aims to provide comprehensive coverage of Python’s class mechanics, it may still be lacking in some areas when it comes to its coverage of new-style classes. Please see http://www.python.org/doc/newstyle/ for sources of additional information. ======================= >8 ==========================
Le manuel de RÉFÉRENCE de la version de 2.6 (donc en fait qui précède la version 3.0) n'est pas capable d'incorporer des possibilités offertes par le langage dès la version 2.2 qui date de fin 2001 !!!! On croit rêver.
Antoine Pitrou
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système d'exceptions et ses types de données riches et haut niveau, C est beaucoup plus « tolérant envers l'incompétence » que cet assembleur portable qu'est Python. D'ailleurs il est recommandé de tout coder en C, et de ne recoder en Python que si c'est vraiment nécessaire, tant les risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très tolérant envers l'incompétence).
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers
l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système
d'exceptions et ses types de données riches et haut niveau, C est
beaucoup plus « tolérant envers l'incompétence » que cet assembleur
portable qu'est Python. D'ailleurs il est recommandé de tout coder en C,
et de ne recoder en Python que si c'est vraiment nécessaire, tant les
risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très
tolérant envers l'incompétence).
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système d'exceptions et ses types de données riches et haut niveau, C est beaucoup plus « tolérant envers l'incompétence » que cet assembleur portable qu'est Python. D'ailleurs il est recommandé de tout coder en C, et de ne recoder en Python que si c'est vraiment nécessaire, tant les risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très tolérant envers l'incompétence).
William Dode
On 08-07-2009, Antoine Pitrou wrote:
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système d'exceptions et ses types de données riches et haut niveau, C est beaucoup plus « tolérant envers l'incompétence » que cet assembleur portable qu'est Python. D'ailleurs il est recommandé de tout coder en C, et de ne recoder en Python que si c'est vraiment nécessaire, tant les risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très tolérant envers l'incompétence).
Et en terme d'incompétence tu t'y connais.
Pour ceux qui ne passent pas leurs dimanches pluvieux à lire la liste python-dev, regardez un peu ce que d'autres font de leur temps libre http://docs.python.org/3.1/whatsnew/2.7.html#optimizations que même les mecs d'unladen se demandent s'ils vont arriver à suivre ;-)
Pour Antoine, hip hip hip ! hourra !
-- William Dodé - http://flibuste.net Informaticien Indépendant
On 08-07-2009, Antoine Pitrou wrote:
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers
l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système
d'exceptions et ses types de données riches et haut niveau, C est
beaucoup plus « tolérant envers l'incompétence » que cet assembleur
portable qu'est Python. D'ailleurs il est recommandé de tout coder en C,
et de ne recoder en Python que si c'est vraiment nécessaire, tant les
risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très
tolérant envers l'incompétence).
Et en terme d'incompétence tu t'y connais.
Pour ceux qui ne passent pas leurs dimanches pluvieux à lire la liste
python-dev, regardez un peu ce que d'autres font de leur temps libre
http://docs.python.org/3.1/whatsnew/2.7.html#optimizations que même les
mecs d'unladen se demandent s'ils vont arriver à suivre ;-)
Pour Antoine, hip hip hip ! hourra !
--
William Dodé - http://flibuste.net
Informaticien Indépendant
On Mon, 29 Jun 2009 00:51:41 +0200, candide wrote:
Le problème est que le C est beaucoup moins intolérant que Python envers l'incompétence
C'est vrai qu'avec sa gestion mémoire automatique, son système d'exceptions et ses types de données riches et haut niveau, C est beaucoup plus « tolérant envers l'incompétence » que cet assembleur portable qu'est Python. D'ailleurs il est recommandé de tout coder en C, et de ne recoder en Python que si c'est vraiment nécessaire, tant les risques de plantage intempestifs sont grands en Python.
Adieu donc, et bonnes aventures en C (ou PHP, un autre langage très tolérant envers l'incompétence).
Et en terme d'incompétence tu t'y connais.
Pour ceux qui ne passent pas leurs dimanches pluvieux à lire la liste python-dev, regardez un peu ce que d'autres font de leur temps libre http://docs.python.org/3.1/whatsnew/2.7.html#optimizations que même les mecs d'unladen se demandent s'ils vont arriver à suivre ;-)
Pour Antoine, hip hip hip ! hourra !
-- William Dodé - http://flibuste.net Informaticien Indépendant
