D'un autre coté red hat est un os pour "pro" (entendre, ceux qui paient le support sont avant tout des pros), n'ayant pas du tout la même base d'utilisateur que celle windows.
Je pense que ceux qui paient le support Windows sont aussi avant tout des pros...
si on accepte l'existence d'une communauté religieuse ou d'origine (armenienne, turque, etc.)
Excellent exemple. Si on "accepte l'existence" de ces communautés c'est parce que leurs membres entretiennent des relations serrées entre eux. On ne parle pas (ou plus), par exemple, de communauté belge ou italienne.
Mais il y a beaucoup de personnes d'ascendance turque ou arménienne qui vivent en-dehors de leurs communautés d'origine respectives, et qui n'ont font pas partie. De même pour les religions : ce n'est pas parce qu'on est juif, même pratiquant, qu'on fait partie de la communauté juive.
le rapport entre les membres de la communauté étant justement le logiciel libre.
Ce n'est pas suffisant, ou alors il y a une "communauté des mangeurs de petits pois" dont le point commun est simplement de manger des petits pois.
Il n'y a pas une communauté unifiée du logiciel libre, il y en a autant que de projets et de centres d'intérêt (et de LUGs, etc.).
Quand on voit qu'on a une culture commune sans jamais s'être vu on ne se pose plus la question de la communauté existe-t-elle ou pas
Une "communauté" telle qu'on l'entend implique d'être en interaction avec ses membres, pas simplement d'avoir des idées en commun. Or tu es peut-être en interaction avec les forumistes de Linuxfr, mais la majeure partie des communautés du libre t'est totalement étrangère.
D'ailleurs tu peux prendre du code BSD et le transformer en GPL
Ouhlala, non.
Une licence sert à préciser les droits accordés à l'utilisateur. Le truc, c'est que la licence BSD accorde en tous points plus de droits que la licence GPL. Donc, elle est compatible GPL, à savoir qu'on peut intégrer du code BSD dans du code GPL sans violer les conditions imposées par la GPL. Et on peut même dire, dans une simplification langagière, que l'ensemble du logiciel ainsi constitué est sous GPL (parce que, en pratique, tu peux l'utiliser aux conditions définies par la GPL).
Mais ça ne veut pas dire qu'on a le droit d'enlever le texte de la licence BSD pour le code couvert par cette licence, et le remplacer par la GPL. La licence BSD, comme à peu près toute licence logicielle, ne permet pas de la remplacer par une autre. Simplement, comme elle est très permissive et du coup compatible avec à peu près n'importe quelle autre licence (y compris propriétaire), les gens ont tendance à faire un pas de trop dans leur raisonnement et penser que c'est la même chose que de remplacer la licence par une autre.
Je pense d'ailleurs qu'il valait mieux être esclave professeur de philosophie qu'homme libre crêve-la-dalle ...
Ca dépend ce qu'on met dans le « mieux valoir » justement, et c'est ce qui fait l'intérêt de ce genre de maximes.
Sur un site où on trouve des gars qui installaient Linux sur leur machine perso en 1995 au lieu d'utiliser un truc ergonomique pépère, ça devrait pouvoir être compris (à défaut d'être forcément partagé).
C'est exactement comme le génie chimique, ou l'ingénierie des ponts, etc: c'est une étape obligée de l'évolution de l'ingénierie informatique.
Justement, non, c'est pas comme. Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
(*) ce qui ne veut pas dire que ce soit fait n'importe comment...
On pourrait rétorquer qu'avec XP/Scrum un logiciel comme le noyau Linux pourrait être écrit beaucoup plus vite, avec beaucoup moins de bugs ; j'attends la démonstration :-).
Je suis sûr que dans certains milieux, on trouve que "logiciel libre" et/ou "open source" sont des buzzwords, pourtant ils ont une signification précise.
L'appellation buzzword vise la façon dont un terme est utilisé, à savoir pour rameuter les foules et créer des « courants ». C'est indépendant de l'existence, ou non, d'une « signification précise ». Je me doute bien que tout cela a été codifié très précisément, d'autant plus précisément que cela donne l'illusion de la rigueur et permet de vendre des bouquins bien épais (et aussi d'expliquer, au type qui se plaindrait que pour lui ça ne marche pas, qu'il n'a probablement pas appliqué la méthodologie correctement).
La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
j'en suis venu à la conclusion que les informaticiens sont minoritaires ici.
Disons qu'à mon avis les gens parlent programmation au sein de leurs projets respectifs (pour ceux qui en font effectivement :-)).
"Récuperer" les erreurs (prévues et imprévues, que ce soit des bugs ou des attaques pourquoi pas) est un challenge qui a été posé plusieurs fois ces dernieres années
Je vais être méchant, mais écrire try/except (ou try/catch selon votre langage) est un challenge ?
Quant à récupérer une erreur non prévue, c'est un oxymore. Si on arrive à récupérer une erreur c'est qu'on avait prévu l'éventualité de son surgissement. On parle d'une machine de Turing déterministe, pas d'un organisme vivant.
Je crois que surtout que le verbiage à base de buzzwords, de sacro-saintes méthodologies accompagnées de leurs inséparables gourous et thuriféraires, de leurs schismes et de leurs querelles en religion (ainsi que d'une montagne de bouquins inutiles et redondants), les gens hors du monde merveilleux de l'entreprise s'en battent un peu le coquillard.
Les gens n'ont pas attendu le "XP", le "Scrum" et je ne sais quoi d'autre pour faire des tests unitaires et procéder par itérations fréquentes ("release often, release early", ça vient pas d'un gourou du XP/Agile/Wooloomooloo).
Maintenant si ça peut être une excuse pour s'amuser à coder sans vexer ses supérieurs, pourquoi pas.
Si je comprends bien, c'est SFR qui choisit ses conditions et vous jouez le rôle de bureau d'enregistrement ? Ou bien ?
(et l'AFNIC, Telecom Bretouille et Renater là-dedans, qu'est-ce qu'ils disent ? ils récupèrent des partenariats pour faire passer la pilule ?)
Tu fais référence à tous les nouveaux mot-clefs (as, with, mais aussi True et False...) ?
Ils ne sont pas nouveaux, c'est juste qu'avant ce n'étaient pas des mots réservés (on pouvait appeler une variable "as" ou "True" par exemple). En d'autres termes, le langage n'est pas devenu plus complexe de ce côté-là, mais il y a eu quelques ajustements dans l'implémentation.
Pour UCS-2, si un essaye de créer un caractère hors de [0; 65535], une exception est lancée.
Non, Python 3 décompose le caractère en deux codes :
Python 3.1a0 (py3k, Dec 7 2008, 21:13:32)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxunicode
65535
>>> s = chr(0x10000)
>>> len(s)
2
>>> s
'\U00010000'
>>> s.encode('utf-32le')
b'\x00\x00\x01\x00'
(le post initial parle de doubler, donc UTF-16 comme pour Java? Pas UCS-4 comme sous Linux?)
C'est une option à la compilation de Python. Les binaires officiels Windows sont compilés en UTF-16 (parce que ça rend la communication avec les API Windows plus efficace), quant aux version Linux ça dépend de la politique de la distribution (Debian compile en UTF-32, Mandriva en UTF-16).
En fait non. Si tu as vraiment besoin de calculs très rapides sur de grosses quantités de données, tu fais des sous-routines en C.
Python 3.0 est plus lent sur trois points :
- le calcul de petits entiers car tous les entiers sont maintenant de précision arbitraire ("infinie" si ce n'est bien sûr la mémoire virtuelle disponible pour le processus)
- les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)
- la couche IO qui a été réécrite, et pour l'instant en majorité en Python plutôt qu'en C
Les deux premiers points ne sont pas cruciaux, car les pertes ne sont pas énormes comparées au coût d'interprétation qui lui n'a pas vraiment changé. Le troisième point devra être corrigé dans Python 3.1.
Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ?
Je ne sais pas à quoi tu fais allusion mais il parlait certainement de l'accumulation de bricolages syntaxico-sémantiques qui mène à ce à quoi ressemblent Perl ou Javascript aujourd'hui. De ce côté-là Python 3 est effectivement une simplification.
À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).
Ce n'est pas forcément un problème, cela délègue juste la décision au niveau de l'userspace pour ce qui est de la façon d'interpréter les octets en question.
Bon, côté userspace on a les libc hackers et je ne suis pas sûr qu'ils soient plus compréhensifs :-)
Et c'est quoi la raison fondamentale pour que ce ne soit pas possible de mélanger les bytes et l'unicode à l'écriture ?
La même raison pour laquelle on n'a pas le droit de concaténer bytes et unicode : parce que sémantiquement ça ne veut rien dire. Si vraiment tu veux le faire, tu dois gérer l'encodage à la main et ça te force à réfléchir à ce que tu fais : explicit is better than implicit.
Une autre raison plus pragmatique est que lors du portage d'un programme de Python 2.x à Python 3.x, il y a forcément des endroits où l'on passe des bytes par erreur plutôt que de l'unicode. Du coup, avoir une API standard relativement stricte vis-à-vis de cela permet de détecter les erreurs plus tôt.
(dans le cas de Mercurial, j'imagine que vous ferez presque tout en bytes de toute façon)
---
Note : la solution que je t'ai donnée est sous-optimale car elle recrée un objet fichier. On peut plus simplement faire :
>>> f = sys.stdout.buffer
>>> f
<io.BufferedWriter object at 0xb7c78fec>
>>> f.write(b"abc")
abc3
on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait
Oui, parce qu'avant que Python n'autorise les identifiants non-ASCII les développeurs du monde entier parlaient tous parfaitement anglais et n'utilisaient jamais une autre langue. On n'avait jamais vu un programme utiliser des identifiants et des commentaires non anglais, et voilà que l'horrible Guido van Rossum ouvre la boîte de Pandore.
Le responsable d'un problème est donc celui qui tente d'y apporter une solution au lieu de le balayer sous le tapis en regardant ailleurs. Bientôt on saura que les bugs trackers sont les vrais responsables de l'existence des bugs.
on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...
La tour de Babel c'est pas très nouveau, ça date même d'avant l'informatique. Qu'est-ce que tu redécouvres au prochain message ?
Personnellement je trouve la décision d'autoriser les caractères non-ASCII dans les identifiants insupportables mais je dois reconnaitre que je vois poindre la de nouvelle possibilités pour troller !
En effet, c'est difficilement justifiable pour des langues faciles à translittérer (lorsqu'il s'agit juste de remplacer "ï" par "i" et "é" par "e" par exemple), ou pour des projets internationaux.
La demande, si je me souviens bien, vient d'utilisateurs japonais qui utilisent Python comme langage avec des utilisateurs peu anglophones qui veulent écrire des identifiants dans leur langue maternelle. Là ça change tout.
(il y a aussi le fait que Python est pas mal utilisé dans l'éducation)
[^] # Re: Un tantinet déçu...
Posté par Antoine . En réponse au journal Cherche ISO de Windows 7. Évalué à 1.
Je pense que ceux qui paient le support Windows sont aussi avant tout des pros...
[^] # Re: SSD
Posté par Antoine . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 7.
Linus Torvalds n'est pas d'accord :
« The only sane flash model is one where the hardware itself
does the block remapping.
And no, this is not about "most filesystems" or about any
majority voting. It's a simple technical fact.
The simple fact is that exposing the internal flash
model to any external software is simply insane. [...] »
http://realworldtech.com/forums/index.cfm?action=detail&(...)
[^] # Re: Pour quoi faire ?
Posté par Antoine . En réponse au journal Cherche ISO de Windows 7. Évalué à 4.
[^] # Re: Journal très pertinent
Posté par Antoine . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 5.
En tout cas ce serait plus amusant que de programmer en Java.
[^] # Re: Quelle communauté ?
Posté par Antoine . En réponse à la dépêche Neuf mauvaises pratiques du logiciel libre. Évalué à 2.
Excellent exemple. Si on "accepte l'existence" de ces communautés c'est parce que leurs membres entretiennent des relations serrées entre eux. On ne parle pas (ou plus), par exemple, de communauté belge ou italienne.
Mais il y a beaucoup de personnes d'ascendance turque ou arménienne qui vivent en-dehors de leurs communautés d'origine respectives, et qui n'ont font pas partie. De même pour les religions : ce n'est pas parce qu'on est juif, même pratiquant, qu'on fait partie de la communauté juive.
le rapport entre les membres de la communauté étant justement le logiciel libre.
Ce n'est pas suffisant, ou alors il y a une "communauté des mangeurs de petits pois" dont le point commun est simplement de manger des petits pois.
[^] # Re: Quelle communauté ?
Posté par Antoine . En réponse à la dépêche Neuf mauvaises pratiques du logiciel libre. Évalué à 2.
Que tu n'es pas en "communauté" avec des groupes avec lesquels tu n'as aucune relation, voilà, c'est pas dur à comprendre, si ?
[^] # Re: Quelle communauté ?
Posté par Antoine . En réponse à la dépêche Neuf mauvaises pratiques du logiciel libre. Évalué à 2.
Quand on voit qu'on a une culture commune sans jamais s'être vu on ne se pose plus la question de la communauté existe-t-elle ou pas
Une "communauté" telle qu'on l'entend implique d'être en interaction avec ses membres, pas simplement d'avoir des idées en commun. Or tu es peut-être en interaction avec les forumistes de Linuxfr, mais la majeure partie des communautés du libre t'est totalement étrangère.
[^] # Re: ah la poésie ...
Posté par Antoine . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 3.
C'est sûr, si tu veux de la poésie absolue, il va falloir passer à un langage parfait et sans pertes.
(c'était la minute de méta-absurdie)
[^] # Re: les free-tarded on se réveille
Posté par Antoine . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 6.
Ouhlala, non.
Une licence sert à préciser les droits accordés à l'utilisateur. Le truc, c'est que la licence BSD accorde en tous points plus de droits que la licence GPL. Donc, elle est compatible GPL, à savoir qu'on peut intégrer du code BSD dans du code GPL sans violer les conditions imposées par la GPL. Et on peut même dire, dans une simplification langagière, que l'ensemble du logiciel ainsi constitué est sous GPL (parce que, en pratique, tu peux l'utiliser aux conditions définies par la GPL).
Mais ça ne veut pas dire qu'on a le droit d'enlever le texte de la licence BSD pour le code couvert par cette licence, et le remplacer par la GPL. La licence BSD, comme à peu près toute licence logicielle, ne permet pas de la remplacer par une autre. Simplement, comme elle est très permissive et du coup compatible avec à peu près n'importe quelle autre licence (y compris propriétaire), les gens ont tendance à faire un pas de trop dans leur raisonnement et penser que c'est la même chose que de remplacer la licence par une autre.
[^] # Re: les free-tarded on se réveille
Posté par Antoine . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 1.
Ca dépend ce qu'on met dans le « mieux valoir » justement, et c'est ce qui fait l'intérêt de ce genre de maximes.
Sur un site où on trouve des gars qui installaient Linux sur leur machine perso en 1995 au lieu d'utiliser un truc ergonomique pépère, ça devrait pouvoir être compris (à défaut d'être forcément partagé).
[^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode
Posté par Antoine . En réponse à la dépêche Coding Dojo à Grenoble. Évalué à 3.
Justement, non, c'est pas comme. Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
(*) ce qui ne veut pas dire que ce soit fait n'importe comment...
On pourrait rétorquer qu'avec XP/Scrum un logiciel comme le noyau Linux pourrait être écrit beaucoup plus vite, avec beaucoup moins de bugs ; j'attends la démonstration :-).
Je suis sûr que dans certains milieux, on trouve que "logiciel libre" et/ou "open source" sont des buzzwords, pourtant ils ont une signification précise.
L'appellation buzzword vise la façon dont un terme est utilisé, à savoir pour rameuter les foules et créer des « courants ». C'est indépendant de l'existence, ou non, d'une « signification précise ». Je me doute bien que tout cela a été codifié très précisément, d'autant plus précisément que cela donne l'illusion de la rigueur et permet de vendre des bouquins bien épais (et aussi d'expliquer, au type qui se plaindrait que pour lui ça ne marche pas, qu'il n'a probablement pas appliqué la méthodologie correctement).
La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
j'en suis venu à la conclusion que les informaticiens sont minoritaires ici.
Disons qu'à mon avis les gens parlent programmation au sein de leurs projets respectifs (pour ceux qui en font effectivement :-)).
[^] # Re: Gestion d'erreur ou de bugs ?
Posté par Antoine . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 3.
Je vais être méchant, mais écrire try/except (ou try/catch selon votre langage) est un challenge ?
Quant à récupérer une erreur non prévue, c'est un oxymore. Si on arrive à récupérer une erreur c'est qu'on avait prévu l'éventualité de son surgissement. On parle d'une machine de Turing déterministe, pas d'un organisme vivant.
[^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode
Posté par Antoine . En réponse à la dépêche Coding Dojo à Grenoble. Évalué à 2.
Les gens n'ont pas attendu le "XP", le "Scrum" et je ne sais quoi d'autre pour faire des tests unitaires et procéder par itérations fréquentes ("release often, release early", ça vient pas d'un gourou du XP/Agile/Wooloomooloo).
Maintenant si ça peut être une excuse pour s'amuser à coder sans vexer ses supérieurs, pourquoi pas.
[^] # Re: De l'exploitation pure et simple?
Posté par Antoine . En réponse à la dépêche Concours d'applications innovantes sur IPv6. Évalué à 3.
(et l'AFNIC, Telecom Bretouille et Renater là-dedans, qu'est-ce qu'ils disent ? ils récupèrent des partenariats pour faire passer la pilule ?)
[^] # Re: Parts de marché ?
Posté par Antoine . En réponse à la dépêche Faire part de naissance : SPIP 2.0. Évalué à 3.
Le Tigre !
http://www.le-tigre.net/
(et la version papier est réalisée avec Scribus)
[^] # Re: Trollons peu trollons bien
Posté par Antoine . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 3.
Ils ne sont pas nouveaux, c'est juste qu'avant ce n'étaient pas des mots réservés (on pouvait appeler une variable "as" ou "True" par exemple). En d'autres termes, le langage n'est pas devenu plus complexe de ce côté-là, mais il y a eu quelques ajustements dans l'implémentation.
[^] # Re: Trollons peu trollons bien
Posté par Antoine . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 5.
Non, Python 3 décompose le caractère en deux codes :
Python 3.1a0 (py3k, Dec 7 2008, 21:13:32)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxunicode
65535
>>> s = chr(0x10000)
>>> len(s)
2
>>> s
'\U00010000'
>>> s.encode('utf-32le')
b'\x00\x00\x01\x00'
(sous un build UCS-4, len(s) retournerait 1)
[^] # Re: Trollons peu trollons bien
Posté par Antoine . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 3.
C'est une option à la compilation de Python. Les binaires officiels Windows sont compilés en UTF-16 (parce que ça rend la communication avec les API Windows plus efficace), quant aux version Linux ça dépend de la politique de la distribution (Debian compile en UTF-32, Mandriva en UTF-16).
[^] # Re: Trollons peu trollons bien
Posté par Antoine . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 2.
En fait non. Si tu as vraiment besoin de calculs très rapides sur de grosses quantités de données, tu fais des sous-routines en C.
Python 3.0 est plus lent sur trois points :
- le calcul de petits entiers car tous les entiers sont maintenant de précision arbitraire ("infinie" si ce n'est bien sûr la mémoire virtuelle disponible pour le processus)
- les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)
- la couche IO qui a été réécrite, et pour l'instant en majorité en Python plutôt qu'en C
Les deux premiers points ne sont pas cruciaux, car les pertes ne sont pas énormes comparées au coût d'interprétation qui lui n'a pas vraiment changé. Le troisième point devra être corrigé dans Python 3.1.
Il y a des comparaisons de performance entre Python 2.5 / 2.6 / 3.0 ici (mais attention, versions beta, pas versions finales, il y a eu quelques corrections entre temps) :
http://mail.python.org/pipermail/python-dev/2008-August/0819(...)
Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ?
Je ne sais pas à quoi tu fais allusion mais il parlait certainement de l'accumulation de bricolages syntaxico-sémantiques qui mène à ce à quoi ressemblent Perl ou Javascript aujourd'hui. De ce côté-là Python 3 est effectivement une simplification.
[^] # Re: Tout les bugs ? vraiment ?
Posté par Antoine . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 5.
Ce n'est pas forcément un problème, cela délègue juste la décision au niveau de l'userspace pour ce qui est de la façon d'interpréter les octets en question.
Bon, côté userspace on a les libc hackers et je ne suis pas sûr qu'ils soient plus compréhensifs :-)
[^] # Re: Mercurial 2.0
Posté par Antoine . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.
Et une mailing-list spécifique a été créée : http://mail.python.org/mailman/listinfo/python-porting
[^] # Re: Mercurial 2.0
Posté par Antoine . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 3.
La même raison pour laquelle on n'a pas le droit de concaténer bytes et unicode : parce que sémantiquement ça ne veut rien dire. Si vraiment tu veux le faire, tu dois gérer l'encodage à la main et ça te force à réfléchir à ce que tu fais : explicit is better than implicit.
Une autre raison plus pragmatique est que lors du portage d'un programme de Python 2.x à Python 3.x, il y a forcément des endroits où l'on passe des bytes par erreur plutôt que de l'unicode. Du coup, avoir une API standard relativement stricte vis-à-vis de cela permet de détecter les erreurs plus tôt.
(dans le cas de Mercurial, j'imagine que vous ferez presque tout en bytes de toute façon)
---
Note : la solution que je t'ai donnée est sous-optimale car elle recrée un objet fichier. On peut plus simplement faire :
>>> f = sys.stdout.buffer
>>> f
<io.BufferedWriter object at 0xb7c78fec>
>>> f.write(b"abc")
abc3
[^] # Re: Mercurial 2.0
Posté par Antoine . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
>>> import sys
>>> f = open(sys.stdout.fileno(), "wb", buffering=0)
>>> f.write(b"abc")
abc3
(le "3" étant la valeur de retour de f.write(), affichée par l'interpréteur interactif)
[^] # Re: Ajout d'un nouveau troll
Posté par Antoine . En réponse au journal Python 3000 est sorti. Évalué à 4.
Oui, parce qu'avant que Python n'autorise les identifiants non-ASCII les développeurs du monde entier parlaient tous parfaitement anglais et n'utilisaient jamais une autre langue. On n'avait jamais vu un programme utiliser des identifiants et des commentaires non anglais, et voilà que l'horrible Guido van Rossum ouvre la boîte de Pandore.
Le responsable d'un problème est donc celui qui tente d'y apporter une solution au lieu de le balayer sous le tapis en regardant ailleurs. Bientôt on saura que les bugs trackers sont les vrais responsables de l'existence des bugs.
on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...
La tour de Babel c'est pas très nouveau, ça date même d'avant l'informatique. Qu'est-ce que tu redécouvres au prochain message ?
[^] # Re: Ajout d'un nouveau troll
Posté par Antoine . En réponse au journal Python 3000 est sorti. Évalué à 2.
En effet, c'est difficilement justifiable pour des langues faciles à translittérer (lorsqu'il s'agit juste de remplacer "ï" par "i" et "é" par "e" par exemple), ou pour des projets internationaux.
La demande, si je me souviens bien, vient d'utilisateurs japonais qui utilisent Python comme langage avec des utilisateurs peu anglophones qui veulent écrire des identifiants dans leur langue maternelle. Là ça change tout.
(il y a aussi le fait que Python est pas mal utilisé dans l'éducation)