Python est langage de programmation interprété qui connaît un succès grandissant du fait de sa syntaxe intuitive et il est massivement utilisé dans le monde du libre.
Cette nouvelle version ajoute un lot considérable de nouveautés comme l'utilisation de l'Unicode pour chaque chaine de caractère ou encore une approche basée sur les itérateurs pour les fonctions map et filter. Cependant, le revers de la médaille est l'incompatibilité avec les versions antérieures. (La PSF nous promet cependant un outils d'aide à la conversion du code ancien).
Un tutorial complet de Python 3 est disponible en ligne pour se familiariser avec l'utilisation ce langage.
Cette version alpha marque le début d'un marathon pour les développeurs. Celui-ci nous mènera jusqu'en août 2008, date à laquelle la version finale devrait être disponible.
Aller plus loin
- Annonce sur python.org (1 clic)
- Les nouveautés (1 clic)
- Le blog de Guido van Rossum (1 clic)
# Cool...
Posté par Smarter . Évalué à 4.
(Au passage, si on clique sur le titre de l'article ça renvoit une erreur 404)
[^] # Re: Cool...
Posté par jmny . Évalué à 0.
[^] # Re: Cool...
Posté par carlo . Évalué à 1.
d'ailleurs, j'ai remarqué ce problème si je clique sur les titres de mes contenus surveillés également
[^] # Re: Cool...
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
# Grillay...
Posté par Moonz . Évalué à 10.
* Les "petits" changements
Les opérateurs <> (équivalent à !=) et `x` (équilavent à repr(x)) sont supprimés du langage.
Disparaissent également dict.has_key(), apply(), callable(), coerce(), execfile(), file(), reduce() et reload()
cPickle a été supprimé, utilisez pickle. Une version optimisée sera utilisée de manière transparente dans le futur.
raw_input() a été renommé en input(). input() doit donc être remplacé par eval(input()).
long a été renommé en int afin qu'il n'y ait plus qu'un type pour représenter les entiers. Bien qu'il s'appelle int, il se comporte comme le long de Python 2.x
.next() renommé en .__next__()
xrange() renommé en range()
string.letters renommé en string.ascii_letters (de même pour string.lowercase et string.uppercase)
1/2 retourne maintenant 0.5 (pour avoir 0, utilisez 1//2). Notez que ce comportement existe déjà depuis Python 2.2 en utilisant from __future__ import division
Les opérateurs de comparaison ne renvoient plus un résultat pseudo-aléatoire pour deux types incompatibles ; à la place, ils lèvent une exception TypeError.
__getslice__, __delslice__ et __setslice__ ont été supprimés. Les méthodes __getitem__, __delitem__ et __setitem__ sont appelés à la place avec un argument de type slice
exec et print deviennent des fonctions (et non plus des mots clefs). Cela signifie entre autres que que print ('a', 1) affichera "a 1" au lieu de "('a', 1)" et que print seul ne fera rien du tout (au lieu d'afficher une nouvelle ligne).
def spam(a, (b, c)) est maintenant invalide. À la place, utilisez def spam(a, b_c): b, c = b_c
0666 est maintenant une erreur syntaxique, la syntaxe correcte est 0o666. Apparition de 0b..., équivalent à int(..., 2).
La syntaxe des nombres variables d'arguments à été étendue au décompactage d'itérables. Par exemple:
a, *b = (1, 2, 3) donnera a = 1 et b = [2, 3] (b sera une liste)
*a, b = (1, 2, 3) donnera a = [1, 2] et b = 3
super() peut maintenant être invoqué sans arguments et choisira automatiquement la bonne classe. Avec arguments, il n'y a aucun changement.
Les décorateurs peuvent maintenant être appliqués aux classes.
Les identifieurs (variables,...) ne sont plus limités aux caractères ascii
Une nouvelle alternative à l'opérateur '%' a faite son apparition, str.format().
map, filter et zip renvoient maintenant des itérateurs à la place de listes.
* Changement dans les fonctions à nombre variable d'arguments
Il est possible d'imposer que certains arguments soient passés par leur nom. Pour cela, il suffit de les placer après *args. De plus, le caractère * seul (sans nom) peut être utilisé pour indiquer qu'une fonction n'accepte pas de nombre variable d'arguments.
Comme un bon exemple vaut mieux qu'un long discours:
>>> def spam(*args, egg): print(len(args), egg)
>>> spam(4, 2)
Traceback (most recent call last):
File "", line 1, in
TypeError: spam() needs keyword-only argument egg
>>> spam(4, egg = 2)
1 2
>>> def spam(*, egg): print(egg)
>>> spam(4, egg=2)
Traceback (most recent call last):
File "", line 1, in
TypeError: spam() takes exactly 0 non-keyword positional arguments (1 given)
>>> spam(egg=2)
2
* Apparition de nonlocal
qui signifie qu'une variable est accessible à un niveau supérieur (mais pas au niveau global). Exemple:
>>> def spam():
... ... a = 2
... ... def egg():
... ... ... nonlocal a
... ... ... a = 5
... ... egg()
... ... print(a)
>>> spam()
5
(sans nonlocal, cela aurait affiché 2)
* str, unicode et bytes
unicode est maintenant le seul type "chaine de caractères" et a pris le nom de str. Le type bytes a fait son apparition ; il a pour vocation de remplacer str pour certaines opération d'I/O (par exemple, les fichiers binaires) ou les sockets. Ce sont deux types bien distincts qui ne peuvent être comparés (b"foo" == "foo" lèvera une exception TypeError) ni implicitement convertis (str(b"foo") échouera). La convertion doit se faire via str.encode() ou bytes.decode(). En pratique:
- Un fichier ouvert en mode texte (open('test', 'r')) travaillera sur des "str" dont l'encodage est défini à l'ouverture (par défaut, utf-8) via l'argument encoding (pour ouvrir "test" encodé en iso-8859-1, on utilisera open('test', encoding = 'iso-8859-1')).
- Un fichier ouvert en mode binaire (open('test', 'rb')) travaillera sur des "bytes".
- socket travaille avec des bytes
- cStringIO et stringIO sont remplacés par io.StringIO et io.BytesIO
- bytes ne peut pas être utilisé comme index d'un dictionnaire.
* Annotation de fonctions
On peut associer une valeur aux arguments d'une fonction et à une fonction, par exemple pour de la documentation (mais pas seulement, puisque n'importe quelle valeur Python peut être associée)
>>> def repeat(a: "This will be printed", n: "Times to repeat") -> "Nothing.": print(str(a) * n)
>>> print(repeat.__annotations__)
{'a': 'This will be printed', 'return': 'Nothing.', 'n': 'Times to repeat'}
* Les exceptions
Les exceptions doivent maintenant toutes dériver de BaseException (il n'est plus possible par exemple de faire raise "Panic !"). De plus, la syntaxe raise Exception, 42 a été supprimée (faisait doublon avec raise Exception(42)). Il est également possible d'enchainer les exceptions (pour par exemple notifier "Une exception IOError a été levée lors du traitement d'une exception MyError"). L'attribut message a été supprimé.
* .keys(), .values() et .items() revus
.keys(), .values() et .items() renvoient maintenant un objet qui référence ces éléments et ayant le même comportement qu'un set. Il est d'ailleurs garanti que set(a.values()) == a.values(). En pratique:
- for x in a.itervalues() s'écrit maintenant for x in a.values()
- a.values() s'écrit maintenant list(a.values())
Et comme c'est un commentaire et non une news, je peux donner mes réactions à chaud non vérifiées:
* Faire de print une fonction a beau être une bonne idée pour la cohérence du langage, c'est ch*ant au possible dans l'interpréteur :p
* L'introduction de bytes semble avec carrément cassé les modules officiels (chez moi, httplib ne marche plus). Je vais voir ça de plus près plus tard.
* J'applaudis de mes quatres pieds gauches la refonte du système d'exceptions
* J'ai pas encore vraiment testé, mais le nouveau mot clef "make" me semble vraiment puissant :). En plus il sera intégré dans Python 2.6 \o/
* Grâce à la nouvelle division, python fait maintenant office de super-calculatrice de poche
* Les identifieurs non-ascii, ça me semble une idée plus que douteuse, m'enfin...
* Les itérateurs ont le beau rôle. C'est une très bonne idée AMHA :)
[^] # Re: Grillay...
Posté par reno . Évalué à 2.
>long a été renommé en int
Pour les non-pythoniens, il faut préciser: en Python un int est un long C et un long est un 'big int', utiliser par défaut des 'big int' dans un langage de script me parait une bonne idée, mais d'après ce que tu dis >qu'un type pour représenter les entiers< il n'y a pas de raw_int ou équivalent qui remplace int, ce que je trouve curieux: j'aurais tendance a penser que les 'big int' sont plus lents et/ou utilisent plus de mémoire que les 'raw int' et que pour des raisons d'optimisations, garder l'accès au 'raw int' serait intéréssant..
>1/2 retourne maintenant 0.5
Une bonne idée. Dans des langages type C ou ce n'est pas vraiment faisable (quel type flottant utilisé? il y en plusieurs) AMHA on devrait remplacer le '/' entier par 'div' ou 'idiv' cela éviterait des confusions.
>def spam(a, (b, c)) est maintenant invalide. À la place, utilisez def spam(a, b_c): b, c = b_c
Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!
>0666 est maintenant une erreur syntaxique, la syntaxe correcte est 0o666
Pas trop tôt! Cette hérésie devrait déja avoir disparue des langages depuis longtemps..
>nonlocal
Bin oui quand il y a déclaration implicites des variables, on se retrouve a devoir faire des bidouilles comme ça, beurk.
En Limbo, pour déclarer une variable, c'est un/1 caractére(!), le deux-points ':', par exemple "a := 10" déclare et initialise a.
Ce qui montre bien qu'on peut faire des déclarations explicites sans que le résultat soit lourd a lire.
Ce que je trouve dommage, c'est que:
1) l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
2) pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.
[^] # Re: Grillay...
Posté par micha_mosk . Évalué à 2.
Ce n'est pas comme ça que je l'ai compris. Pour moi, cela signifie qu'on ne peut plus faire de déballage de tuples dans les arguments d'une fonction, mais qu'on est maintenant obligé de le faire dans le corps de la fonction. "b_c" est juste le nom de la variable, qui pourrait être n'importe quoi d'autre.
[^] # Re: Grillay...
Posté par reno . Évalué à 1.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 4.
> pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.
Pas d'accord. Le mélange des deux est une mauvaise idées, mais beaucoup indentent avec des tabulations, ce qui est moult pratique ! Il n'y a guère que quelques éditeurs dinosaures (je ne citerai pas de nom) qui font ch*er à mal gérer les tabulations.
Les tabulations ont l'ÉNORME avantage de faire plaisir à tout monde: certain préfèrent avoir une indentation à deux espaces (moi), d'autres à 4 espaces (beaucoup, parmis les pythnoeux), d'autres à 6 (j'en ai pas vu beaucoup, mais j'en ai vus), d'autres à 8 (beaucoup parmis les codeurs PHP). La solution pour mettre tout le monde d'accord est d'utiliser les tabulations et de laisser l'éditeur choisir par combien d'espaces représenter une tabulation. Avec les espaces, tu imposes ton style aux autres, c'est chiant au possible.
Sans compter que dans le cas de l'indentation par espaces, à moins d'ajouter des * vim: je sais pas quoi: * ou des *emacs: xxx* qui polluent le code, tu es obligé de changer la configuration de ton éditeur dès que tu contribues à un proet différent. C'est vraiment lourd. (encore que moi, je suis pas trp dérangé, scite detecte automatiquement le style utilisé)
Selon moi, c'est plutot l'indentation par espaces qui devrait gicler...
> Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!
Non.
Avant, tu écrivais def spam(a, (b, c)) et tu pouvais faire my_tuple = (4,2); spam(a, my_tuple). C'est à dire que le décompactage du tuple se faisait implicitement. Maintenant, tu dois le faire explicitement, mais tu aurais aussi pu faire
def spam(a, my_bc_tuple): b, c = my_bc_tuple
En fait, je connaissais mêmepas la syntaxe def spam(a, (b,c))
> l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
C'est a un énorme point positif: ça évite les variables "magiques" et c'est après tout un argument comme un autre (self peut être passé à travers *args ou **kwargs par exemple). Ça évite les comportements plus que surprenants provenant du fait que ce soit un "machin spécial" (je n'ai jamais réussi à utiliser correctement "this" en JavaScript...)
[^] # Re: Grillay...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
> l'éditeur choisir par combien d'espaces représenter une tabulation.
Ça, c'est le meilleur moyen d'être sûr que ton code sera illisible partout ailleurs que dans ton éditeur.
Si tu règle ta tabulation à 2, essayes par exemple
$ cat ton-fichier.py
$ a2ps ton-fichier.py
...
Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
Après, il y a des trucs un peu plus subtils, du genre
SSune ligne
TTune autre ligne
(avec "S" = espace, et "TT" = une tab de largeur 2), qui s'affichera aligné chez toi, et pas chez n'importe qui ayant une configuration décente. Ou encore
TTif (une-condition-un-peu-longue &&
TTTTTTune-autre-condition) {
qui s'affichera correctement chez toi, mais nulle part ailleurs.
Bon, je m'arrête là.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 2.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
2. Le rendu dépend aussi de la police utilisée (au moins monospace ou pas). Tout le monde ne code pas dans un terminal ! A coté de ça, le "problème" des tabulations est vraiment mineur...
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ? Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle et de laisser l'éditeur s'occuper de cette dernière selon les préférences de l'utilisateur...
> SSune ligne
> TTune autre ligne
Tu sais, si seules les tabulations sont autorisées c'est plus un problème :)
Mais sans aler si loin (je suis d'accord que ce serait exagéréà le problème n'est pas les tabulations mais le mix tabulations/espaces (et ça, tout le monde est d'accord pour dire que ça pue)
> TTif (une-condition-un-peu-longue &&
> TTTTTTune-autre-condition) {
cf. les 80 caractères.
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
T[sendSomeLongMessage: arg1
TSSSwithManyArguments: arg2
TSSandAnotherArgument: arg3
TSSSSSSSSmoreArgument: arg4
TSSScontinueArguments: arg5]
Mais à part cette situation, je fais tout en tabulations dès que j'en ai l'occasion sans rencontrer aucun problème...
[^] # Re: Grillay...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Bah, moi, j'ai pas envie de m'emmerder à utiliser sed parce qu'un autre développeur a décidé d'utiliser une largeur de tab non-standard. D'autant que ça m'oblige à deviner la largeur de tab pour laquelle le code a été écrit (je parle d'expérience, et tous les enseignants qui ont déjà corrigé des TPs d'étudiants qui jouent avec leur largeur de tab comprennent de quoi je parle).
> 2. Le rendu dépend aussi de la police utilisée (au moins monospace ou pas).
> Tout le monde ne code pas dans un terminal ! A coté de ça, le "problème" des
> tabulations est vraiment mineur...
Tout le monde ne code pas dans un terminal, mais faut vraiment en vouloir pour coder avec une police à chasse variable.
>> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
> À tout hasard, dépasser les 80 colonnes
Ce qui confirme mon affirmation de départ : ton code sera illisible ailleurs que chez toi : du code qui tiens sur 80 colonnes chez toi va probablement dépasser chez n'importe qui n'ayant pas trifoullié sa config.
> Tu sais, si seules les tabulations sont autorisées c'est plus un problème :)
[...]
> la seule situation ou je m'autorise le mix tab/espaces
Bah, ça a l'air d'être un beau bordel, tes directives de codage.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 1.
c'est quoi une largeur de tab non-standard ?
mais comme je l'ai dit plus bas, si tu veux imprimer et avoir le code dans ton style préféré, indent est ton ami :)
> Ce qui confirme mon affirmation de départ : ton code sera illisible ailleurs que chez toi : du code qui tiens sur 80 colonnes chez toi va probablement dépasser chez n'importe qui n'ayant pas trifoullié sa config.
Heu... et alors ? Le monde n'est plus limité à 80 colonnes et 24 lignes depuis bien longtemps :p (même dans un terminal, d'ailleurs...). C'est une limite tout a fait arbitraire aujourd'hui...
> Bah, ça a l'air d'être un beau bordel, tes directives de codage.
Je ne marcherai pas dedans, je ne marcherai pas dedans...
Ho et puis zut, c'est le dernier jour où je peux troller, autant en profiter :)
Moins que celles de GNU :p
[^] # Re: Grillay...
Posté par TeXitoi (site web personnel) . Évalué à 1.
C'est pas un hasard ces 80 colonnes, ca permet à l'oeil de bien se repéré. Plus de 80 colonnes, et tu as du mal à voir les alignements...
[^] # Re: Grillay...
Posté par Gniarf . Évalué à 3.
effectivement, ça vient des cartes perforées et on a gardé ça pour qu'elles tiennent à l'écran.
pas exactement des critères d'ergonomie, donc.
[^] # Re: Grillay...
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Si mes souvenirs sont bons, les études en ergonomie ont placé l'optimum pour la lisibilité (de texte en langue naturelle) plutôt autour de 60 à 70 colonnes.
D'ailleurs, si tu prends à peu près n'importe quel truc sur lequel il y a quelque chose d'écrit, il y a ce genre de limite. Soit on fait des pages petites, soit on fait des gros caractères, soit on coupe en plusieurs colonnes.
[^] # Re: Grillay...
Posté par Sebastien (site web personnel) . Évalué à 1.
Ça, c'est une super bonne excuse quand on bosse tout seul dans son coin. Par contre, quand on utilise une gestion de version partagée entre plusieurs développeurs, si chacun passe un coups d'indent à son style préféré avant de faire ses modifs et committer, on n'est pas sorti de l'auberge.
Après, on peut faire un indent spécifique pour remettre dans le dépôt partagé, mais ça veut dire que pour visualier les diffs et l'historique, soit il faut avoir un soft spécifique (qui va 1/ récupérer les 2 versions 2/ les indenter à notre goût), soit s'adapter au style d'indentation -- mais dans ce cas, autant s'adapter autant en lecture qu'en écriture.
Enfin, pour ma part, je ne mets pas de caractères tab. Par contre, j'appuie sur la touche tab et mon éditeur fait ce qu'il a à faire et c'est tout.
[^] # Re: Grillay...
Posté par Gniarf . Évalué à 1.
[^] # Re: Grillay...
Posté par Gniarf . Évalué à 2.
> Bah, moi, j'ai pas envie de m'emmerder à utiliser sed parce qu'un autre développeur a décidé d'utiliser une largeur de tab non-standard.
quelle ouverture d'esprit. tu es mûr pour bosser chez Microsoft, vraiment.
> tous les enseignants qui ont déjà corrigé des TPs d'étudiants qui jouent avec leur largeur de tab comprennent de quoi je parle
bah si ils imposent pas une largeur de tabulation, c'est leur problème. ils imposent bien un langage de programmation pour leurs TP quand même ?
et si ça leur prend plus de quelques secondes à ajuster la tabulation pour les élèves qui s'en foutent de se prendre -5 ou 0 à leur TP, bah je crois qu'ils feraient mieux de changer de métier.
[^] # Re: Grillay...
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
>
>quelle ouverture d'esprit. tu es mûr pour bosser chez Microsoft, vraiment.
En général, ce qu'on reproche à Microsoft, c'est justement pas d'être trop près des standards, ni de permettre aux gens de bosser sans être forcés à utiliser des outils spécifiques pour résoudre des non-problèmes.
> bah si ils imposent pas une largeur de tabulation, c'est leur problème.
Ouais, c'est ça, on va préciser dans les sujets que les tabs font 8.
On va ajouter aussi que le caractère de fin de ligne doit être interprêté comme un retour à la ligne suivante, dire qu'on attends un code en ASCII et non en EBCDIC. On sait jamais.
Et on ajoutera aussi qu'il faut écrire le programme sur plusieurs lignes.
Et on interdira explicitement les identificateurs de plus de 1024 caractères, au cas où.
Une tab, c'est 8 caractères, point. C'est le défaut sur toutes les applications que je connaisse, et c'est pas du tout réglable sur toutes les applications que je connaisse par contre.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . Évalué à 2.
--
Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
2. Le rendu dépend aussi de la police utilisée
C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?
Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle
C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes.
http://www.ioccc.org/
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :
T[sendSomeLongMessage: arg1
TSSSwithManyArguments: arg2
TSSandAnotherArgument: arg3
TSSSSSSSSmoreArgument: arg4
TSSScontinueArguments: arg5]
Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.
Mais à part cette situation,
C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 3.
En même temps, il s'agit ici d'un cas spécial vraiment rare. Tu imprimes tous les jours des codes sources toi ? Je vois pas où est le problème d'utiliser sed pour ça, c'est pas comme si c'était une tache quotidienne. D'autant plus que j'aurais tendance à d'abord passer par highlight pour ça, soit dit en passant.
> C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
Le rapport est que même sans tabulations, si tu présentes ton code au caractère près tu risques (fotement) d'avoir des soucis à l'impression. C'est normal. Un code source n'est pas fait pour être imprimé.
> Car le mode "wrap" est souvent pénible à utiliser.
Pourquoi donc ?
> Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible [...] . Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Là, je suis d'accord, mais ça n'a rien à voir avec la choucroute (tu dis que normalement ce problème ne se pose pas vu qu'on ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas. Si le problème se pose as, aucune raison d'en discuter :D)
> En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define)
Oui, enfin, il y a une utilité pratique indéniable aux retours à la ligne: ça marche mieux avec diff et patch, au delà de toute considération esthétique :)
> Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Ben justement... non, elle reste la même.
Ce qui est un peu le but, quand même. Je suis pas stupide à ce point, si changer la taille des tabulations brisait la présentation, ça ferait longtemps que je n'utiliserais plus les tabulations :p
> Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
C'est un cas VRAIMENT spécial ou ni les espaces ni les tabulations ni le mélange des deux ne brisent la présentation. Le généraliser pour dire "les tabulations, sainul", ça manque un peu de rigueur mathématique ;)
> C'est pourtant exactement pour cette situation (pourtant très courante)
Heu... non, pas courante du tout. C'est la seule fois ou j'ai besoin de mélanger, et comme je l'ai dit, ça passe comme un charme (et oui, j'ai essayé dans différentes configurations)...
> Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN
Mais NON, NON et re-re-NON !!! (j'insiste)
le but est JUSTEMENT que quelle que soit la configuration de l'éditeur, le code source reste autant lisible en s'accordant aux gouts du lecteur ! Le but est justement de ne RIEN imposer comme style (taille de l'indentation, wrap ou pas wrap, wrap en début de ligne ou au même niveau que la ligne précédent ou à un niveau supérieur...). Avec la solution espace, ça passe effectivement partout, mais tu impose ton style au lecteur/contributeur. TOUS mes codes sources passent très bien partout (et je vais me répéter, mais j'ai essayé). Éventuellement, il arrive parfois que la configuration de l'éditeur m'insupporte (genre 8 espaces pour une tabulation, je déteste ça) quand je suis pas chez moi, mais c'est le pire qui puisse arriver.
Toutes, TOUTES les critiques "valides" que j'ai lues concernant les tabulations jusqu'ici proviennent d'éditeurs foireux (genre "oui, mais mon éditeur change les tabulations par 4 espaces en dur et du coup ça pollue les patchs"). Moi aussi je peux faire pareil: j'ai vu certains codes sources indentés à 3 espaces (parce que son auteur aime les espaces) où 8 espaces étaient remplacés par une tabulation (configuration foireuse), ce qui donnait un truc hideux du genre
SSSSSSif(foo)
TSbar();
(d'ailleurs, si mes souvenirs sont bons c'et le cas dans GNUstep - mais pas à 3 espaces - ce qui a été une raison suffisante pour que je m'arrête de plonger dans le code de GNUstep)
conclusion: les espaces, c'est de la merde en sac, si l'auteur avait utilisé des tabulations dès le début ça aurait fait chier personne
Mais comme j'aime pas être de mauvaise foi, je n'utiliserai pas ça comme un argument :p
[^] # Re: Grillay...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
C'est si rare que ça de passer par autre chose que ton éditeur de texte pour regarder du code ? T'utilises jamais "less" ? Tu envoies jamais un patch par email ? J'ai donné a2ps et cat comme exemples (pour cat, en fait, c'est le xterm qui décide de la présentation des tabs), mais il y a des tonnes de cas où la tab, c'est 8 espaces, et à peu près impossible à changer.
Si tu veux indenter à 2, met deux espaces, et ça passera partout. Si tu met des tabs, tu vas te retrouver avec une expansion x4 de ton indentation, et il y a de bonnes chances pour que tu te retrouves avec un truc illisible car il dépasse d'une fenêtre normalement dimensionnée.
D'ailleurs, puisque c'est un truc qui n'arrive jamais, pourquoi avoir suggéré sed ?
>> Car le mode "wrap" est souvent pénible à utiliser.
> Pourquoi donc ?
Là, tu me fais vraiment peur sur la lisibilité du code que tu écris.
Tu ne vois vraiment pas pourquoi c'est plus lisible d'avoir du code bien aligné plutôt que d'avoir des lignes de 500 caractères découpées arbitrairement par ton éditeur de texte ?
> ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas.
Tu ne nous a toujours pas expliqué comment tu comptais le nombre de caractères que prends une ligne, si tu considère que la tab peut faire autre chose que 8 caractères.
Le problème avec les tabs, c'est pas tellement les tabs en soi, mais c'est les gens qui jouent avec la configuration de leur éditeur et qui du coup, indentent n'importe comment.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 4.
Non, ce n'est pas rare, mais c'est pour regarder vite fait, et tant pis si les tabulations n'ont pas le mon nombre préféré d'espace puisque ce n'est pas censé casser la présentation (c'est fait pour...).
> Tu envoies jamais un patch par email ?
Heu... si. Mais quel rapport ? Un patch, ça s'envoie en pièce jointe...
> normalement dimensionnée.
Mais quel est ce "normalement dimensionnée" ? Personnellement, même en terminal je suis rarement en 80 colonnes que ce soit avec un xterm en plein écran ou sous une console avec framebuffer.
> mais il y a des tonnes de cas où la tab, c'est 8 espaces, et à peu près impossible à changer.
Je n'en doute pas. Mais un cas bloquant qui ne se règle pas en deux coups de cuillère à pot, je n'en ai jamais eu vent...
> D'ailleurs, puisque c'est un truc qui n'arrive jamais, pourquoi avoir suggéré sed ?
rarement != jamais -_-
Ce que je voulais dire, c'est que le cas "normal", c'est coder dans un éditeur. Pour les cas spéciaux, hé bien... outils spéciaux...
> Tu ne vois vraiment pas pourquoi c'est plus lisible d'avoir du code bien aligné plutôt que d'avoir des lignes de 500 caractères découpées arbitrairement par ton éditeur de texte ?
Mais non d'une pipe, si ton éditeur fait portnawak, c'est sa faute et ton problème !
Peux tu comprendre que le wrap peut se faite de différentes manières et que chacun à ses préférences ? Que du coup, laisser faire l'éditeur est le seul moyen de mettre tout le monde d'accord ? Que c'est le même problème avec l'indentation ?
J'ai l'impression que tu subis ton éditeur. Ce n'est pas normal. Si tu trouves qu'il wrappe ou indente comme un goret, configure le correctement. Pense que ce que tu trouves "wrappé comme un goret" peut être apprécié par certains, et vice versa !
> Tu ne nous a toujours pas expliqué comment tu comptais le nombre de caractères que prends une ligne, si tu considère que la tab peut faire autre chose que 8 caractères.
Je considère tout simplement la ligne sans son indentation...
Note que je ne suis pas au caractère près, vu que pour moi la règle des 80 caractères n'est pas "on doit wrapper au 80ème caractère selon des règles totalement arbitraires" mais "une ligne de plus de ~80 caractères est probablement trop complexe et devrait être simplifiée..." (en fait, je commence plutôt à me poser des questions vers 90-100, mais comme le nombre 80 semble "magique" pour toi...)
> Si tu veux indenter à 2, met deux espaces, et ça passera partout.
Oui, mais si quelqu'un qui bosse avec moi préfère 4, on fait quoi ? On tire à la courte paille ? On choisit la moyenne, 3 ? Un des deux IMPOSE sa préférence à l'autre ? Ou tout simplement on utilise des tabulations et chacun configure son éditeur comme il l'entend ?
Je te laisse devenir ce qu'on a décidé...
> mais c'est les gens qui jouent avec la configuration de leur éditeur et qui du coup, indentent n'importe comment.
À moins de le faire volontairement, il est tout aussi difficile de casser une indentation par tabulations que de casser une indentation par espaces. Ce qui est extrèmement facile de casser, c'est le mélange des deux ala GNUstep...
Tu peux configurer ton éditeur comme tu l'entends, du moins que tu utilises des tabulations tu ne casseras probablement rien. Et c'est justement l'avantage :)
[^] # Re: Grillay...
Posté par benoar . Évalué à 3.
Exemple :
fooTbar
fooooooTbar
Ici, les deux "bar" apparaîteront alignés si on a des tabulations à 8 ou plus. Mais pas si elles font moins.
Bref, changer la largeur des tabulations, c'est intelligent uniquement si on ne met pas de tabulations en milieu de ligne, ce que je trouve quand même pas très pratique : j'aime bien aligner des choses autres que le début de la ligne.
Bref, les tabulations font 8, un point c'est tout : si vous voulez moins d'espacement, vous pouvez utiliser un mix tab/espace, même si ça devient vite le bordel si vous avez un éditeur pas adapté (en gros, pour mes développement persos ça me va puisque mon vim gère ça merveilleusement bien), soit mettre uniquement des espaces : c'est lourd mais ça passe partout. Soit encore, écouter Linus qui dit que de toutes façons, si vous avez besoin de tabulations plus petites, c'est que votre fonction a un niveau d'indentation trop profond et qu'il faut la diviser en plusieurs sous-fonctions...
[^] # Re: Grillay...
Posté par Moonz . Évalué à 2.
En même temps, je n'ai jamais jusqu'ici rencontré de tabulations en milieu de lignes (personnellement, si je veux aligner en milieu de ligne, j'utilise des espaces...)
[^] # Re: Grillay...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sinon, je bannis les tabulations.
Pour être dans le troll, c'est quand que dans un Makefile, un '->' en début de ligne sera équivalent à une tabulation !
[^] # Re: Grillay...
Posté par Mildred (site web personnel) . Évalué à 1.
Je trouve dommage d'ailleurs qu'il n'y ait pas un mode qui indente avec:
- des tabulations lorsqu'il n'y a rien en début de ligne
- des espaces lorsqu'on est en milieu ou fin de ligne
Mais kate ne sait pas faire ça :(
[^] # Re: Grillay...
Posté par benoar . Évalué à 2.
(dans le :help tabstop)
Par contre, je ne suis pas franchement un partisan des espaces seulement, je suis plutôt à faire un mix tab/espaces, avec des tab à 8. Vim gère ça très bien.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Les identifieurs (variables,...) ne sont plus limités aux caractères ascii
Certains vont tomber de leur chaise en lisant ça : « Mais... mais... comment je vais faire pour utiliser une bibliothèque écrite en tibétain, vietnamien ou encore coréen ? mon clavier est frappé d'un coq et n'a que quelques lettres accentuées ! ». La réponse est simple : c'est à l'auteur de choisir d'utiliser des noms ASCII (a-z, A-Z, 0-9, _) ou bien des noms unicode (dans leur langue). C'est l'auteur de la bibliothèque qui décide si d'autres pourront le relire ou non. Quelqu'un qui écrit du logiciel libre et veut des contributeurs écrira forcément en anglais avec des noms ASCII.
Une nouvelle alternative à l'opérateur '%' a faite son apparition, str.format().
format() a l'air surpuissant ! Pour l'internationalisation d'un programme, on peut aisément changer l'ordre des arguments dans la chaîne de formatage car les arguments sont numérotés (ex: "{0} {1}!".format('Hello', 'World')). En fait, c'était déjà plus au moins possible avec printf() mais beaucoup plus tordu. format() est très personalisable au niveau des rêgles de formatage. Lire la PEP pour les détails.
bytes ne peut pas être utilisé comme index d'un dictionnaire.
Pour ceux qui parlent le Python, on dit que le type mutable est mutable. C'est-à-dire qu'on peut le modifier : « x=b"abc"; x[0]=42 » ce qui n'était pas possible avec le type str de Python2. Conséquence : le type bytes n'est pas hashable, or la clé d'un dictionnaire doit être hashable. J'ai posé la question de comment faire pour avoir un bytes non modifiable mais je n'ai pas bien compris la réponse. On m'a parlé du l'outil « buffer » ou du type batard « str8 » (qui est en fait l'ancien type str mais ce dernier ma disparaitre). Pour des raisons de compatibilités avec Python2 ou pour pouvoir utiliser bytes comme clé de dictionnaire, ça serait bien d'avoir un frozen_bytes.
Annotation de fonctions
Un des objectifs est de permettre d'annoter les types des arguments et type de retour pour permettre aux outils tels que pychecker de vérifier les erreurs de typage.
Faire de print une fonction a beau être une bonne idée pour la cohérence du langage,
C'est surtout pour permettre de remplacer la fonction par du code perso. On peut très bien écrire « print = logging.info » pour transférer la sortie dans le système de logging !
Haypo
[^] # Re: Grillay...
Posté par Gniarf . Évalué à 7.
rien n'est moins sûr. en particulier nos amis japonais vivent un peu dans leur bulle et restent entre japonais (Ruby, des jeux pour D), l'anglais alors parfois utilisé est souvent de l'anglais de cuisine, une sorte de seconde main, une arrière-pensée.
en France on aura des accents ici et là, et en allemand en plus on aura des ß. même si ce qui est produit est libre, le fait que ça ne soit pas utilisable hors de leur milieu est presque un détail pour eux. le russe est marrant aussi.
mais tout cela est un faux problème pour du code libre, si quelque chose a de la valeur il sera vite adapté. le frein c'est souvent plutôt les pages web décrivant le bousin quand elles sont en pas-anglais.
[^] # Re: Grillay...
Posté par reno . Évalué à 3.
Beurk et rebeurk:numéroté les arguments c'est super-pénible et c'est une source d'erreur.
Une chaîne de format qui contient le nom des variables est bien meilleur, j'ai fait une librairie en D(assez moche) qui comprend ce genre de format:
"Bonjour %{prenom} votre age est %03d{age}"
Comparé a "Bonjour {0} votre age est {1}", je crois qu'il n'y a pas de doute sur ce qui est le plus lisible, surtout si les chaines sont stockées dans un fichier séparé..
[^] # Re: Grillay...
Posté par Moonz . Évalué à 3.
"Bonjour {prenom} votre age est {0}".format("42", prenom="monde")
Les argument numériques, c'est 'achement pratique quand t'en as deux ou trois. Au delà, c'est sur que par nom est pus lisible. À chaque cas son utilisation.
[^] # Re: Grillay...
Posté par benoar . Évalué à 2.
La notation "%" a un équivalent aux substitutions "nommées" depuis un bout de temps dans python 2 :
Je l'utilise déjà depuis un certains temps. Mais effectivement, mettre le "s" comme dans "%s" après la parenthèse, c'est un peu bizarre.
[^] # Re: Grillay...
Posté par Moonz . Évalué à 4.
[^] # Re: Grillay...
Posté par benoar . Évalué à 2.
[^] # Re: Grillay...
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Et je suis d'accord, on ne peut que se réjouir de la tendance à mettre des itérateurs là où il y a des copies de liste actuellement.
[^] # Re: Grillay...
Posté par lolop (site web personnel) . Évalué à 3.
Va-t-on avoir qq chose comme un std.xxx pour les batteries livrées avec Python (histoire d'avoir moins de chance de masquer un module standard par un module à soi) ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Grillay...
Posté par Moonz . Évalué à 3.
Mais pour ton problème, il y a la PEP 328 [http://www.python.org/dev/peps/pep-0328/], disponible depuis Python 2.5 avec from __future__ import absolute_import et par défaut dans Python 2.7
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Certians vont disparaitre et d'autres vont maigrir. Il doit y avoir une PEP qui détaille ça, disons :
http://www.python.org/dev/peps/pep-3001/
Ce travail n'est pas encore fait mais le sera avant août 2008.
[^] # Re: Grillay...
Posté par gallenza . Évalué à 1.
Je suis 100% d'accord avec toi, sur ce coup là je pense que Guido l'a joué trop dogmatique et pas assez pragmatique...
# Optimisation
Posté par Victor STINNER (site web personnel) . Évalué à 7.
[^] # Re: Optimisation
Posté par Sébastien B. . Évalué à 4.
non ?
(ca avait fait un chtit troll hier sur irc)
[^] # Re: Optimisation
Posté par Victor STINNER (site web personnel) . Évalué à 3.
# Plusieurs bémols
Posté par Thomas Hervé . Évalué à 1.
Pour moi, cette version ne devrait même pas avoir de version officielle. Une des forces de Python est sa stabilité, et son évolution pas à pas. Casser toute la compatibilité d'un coup n'a aucun sens. Rien dans les nouvelles fonctionnalités ne nécessitaient de ne pas passer par la case habituelle "PendingDeprecation/Depreaction/Deletion". La preuve? Beaucoup de ces nouvelles fonctionnalités vont être portées dans Python 2.6.
En tout cas, cette version s'annonce comme un mal de tête énorme pour tous les créateurs de bibliothèques, qui devront pendant une période de temps importante (python 2.3 est encore utilisé énormément, voir 2.2) fournir 2 versions de leur code... Quand on voit le mal que les core développeurs ont à porter les bibliothèques internes (cf email), il y a de quoi s'inquiéter.
Bref, un bel objectif, mais incompatible avec une véritable utilisation selon moi.
[^] # Re: Plusieurs bémols
Posté par z a . Évalué à 3.
De plus ce genre de choses n'a pas l'air monnaie courante dans l'histoire de Python, nettoyer de temps en temps ne fait certainement pas de mal...
[^] # Re: Plusieurs bémols
Posté par Thomas Hervé . Évalué à -1.
Comme je le dis dans le commentaire, Python a toujours su utiliser les DeprecationWarning pour prévoir une migration de ces utilisateurs. Et je cherche encore un point dans Python 3.0 qui ne pouvait pas passer par cette case.
[^] # Re: Plusieurs bémols
Posté par Gniarf . Évalué à 2.
et on aura surement des versions mineures 2.6 ou 2.7 ou plus d'ici là : c'est à elles d'utiliser des DeprecationWarning pour prévenir tout le monde, pas à la génération suivante.
[^] # Re: Plusieurs bémols
Posté par Thomas Hervé . Évalué à 0.
Python 3.0 est un bon objectif. Cependant il faut mettre en garde les gens de ne pas s'en servir pour écrire de vrais programmes, et attendre justement les transitions offerts par les version 2.6 et suivantes.
[^] # Re: Plusieurs bémols
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Comme je l'ai déjà expliqué ça et là, les changements brisant la compatibilité est d'éviter les erreurs de programmation.
Exemple 1
Mélanger des octets (str) et caractères (unicode) est source de bugs difficile à corriger. Python2 autorise la comparaison entre un octet et un caractère, ce qui conceptuellement n'a aucun sens. Python3 lance une erreur TypeError (can't compare bytes and str).
Exemple 2
0666 est lu comme 438 par Python2, sauf que ça peut dérouter les débutants qui saisissent 001, 002, (...), 008 => SyntaxError. Python3 exige le préfixe « 0o » (zéro, lettre O) : 0o666.
Exemple 3
Les méthodes values() et items() d'un dictionnaire sont des itérateurs. Ceci évite que « for key, valeur in data.items(): ... » ne crée une liste temporaire qui peut peser lourd en mémoire, prend de temps à être créée. En plus, si ça se trouve la boucle va être interrompue à la 2e itération ! On pourra toujours obtenir une liste mais avec la syntaxe générique « items = list(data.items()) ».
Exemple 4
De nombreux ajouts visent à durcir les contrôles du typage. L'annotation des fonctions permettra d'indiquer le protoype d'une fonction et les classes abstraites peuvent servir d'interface.
[^] # Re: Plusieurs bémols
Posté par Thomas Hervé . Évalué à 1.
Je ne conteste pas les changements en soi. La plupart me semble sensé (sauf les ABC peut-être, mais bon...). Mais il faut offrir un moyen aux utilisateurs de faire tourner leur code sur 2.x et sur 3.0, avec des future import par exemple.
Pour l'instant rien n'est foutu, mais il y a un gros enjeu pour 2.6 d'offrir une migration aisée.
[^] # Re: Plusieurs bémols
Posté par Gniarf . Évalué à 1.
les distributions fourniront python 3.0 et python 2.6 - comme elles se trainent déjà un lourd passif de python 2.2 python 2.3 python 2.4 python 2.5 : je ne vois pas le problème pour des utilisateurs normaux (non-codeurs)
maintenant pour tes utilisateurs-en-fait-codeurs tu crains qu'ils aient deux fois plus de boulot à faire, deux versions incompatibles à se trainer, s'ils décident de viser en même temps les branches 2 et 3 de python ?
bah oui. maintenant tu es parfaitement libre d'ignorer l'une des deux branches ou de demander de l'aide, hein. ça se fait.
[^] # Re: Plusieurs bémols
Posté par Thomas Hervé . Évalué à 0.
Ca c'est de la métaphore... J'ai du mal à voir le rapport.
les distributions fourniront python 3.0 et python 2.6 - comme elles se trainent déjà un lourd passif de python 2.2 python 2.3 python 2.4 python 2.5 : je ne vois pas le problème pour des utilisateurs normaux (non-codeurs)
maintenant pour tes utilisateurs-en-fait-codeurs tu crains qu'ils aient deux fois plus de boulot à faire, deux versions incompatibles à se trainer, s'ils décident de viser en même temps les branches 2 et 3 de python ?
bah oui. maintenant tu es parfaitement libre d'ignorer l'une des deux branches ou de demander de l'aide, hein. ça se fait.
Un projet opensource demande déjà beaucoup d'effort en temps normal pour essayer de minimiser les gros travaux de ce type. De l'aide, un projet en a toujours besoin, même sans une migration aussi importante.
Pour en revenir à ce que tu dis, les utilisateurs seront forcément impacté, car les bibliothèques n'existeront pas pour Python 3.0. Le travail des distributions, qui se limitait dans beaucoup de cas à recompiler la même version de la bibliothèque pour plusieurs version de Python, sera lui aussi doublée: besoin de compiler 2 versions différents des projets.
[^] # Re: Plusieurs bémols
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Pour les modules écrits entièrement en Python, l'outil 2to3 s'occupe de convertir automatiquement tout le code. Il n'y a rien à faire. Pour les modules écrit en C, je ne sais pas. Je pense que d'avec des #ifdef, on doit pouvoir s'en sortir.
Quand on voit le mal que les core développeurs ont à porter les bibliothèques internes (cf email), il y a de quoi s'inquiéter.
J'ai aidé à porter le module email. Son gros défaut est qu'il mélangeait allègrement octet et caractère, chose totalement fausse d'un point de vue conceptuel. Disons que ça marche (en Python2), mais que le comportement est parfois inattendu...
Un gros travail a été fait sur le module et il a été intégré de justesse à la version alpha 1.
Porter un module pour Python3 implique de recadrer certaines choses, et ça va dans le bon sens.
[^] # Re: Plusieurs bémols
Posté par Thomas Hervé . Évalué à 0.
Ca, c'est une belle illusion. 2to3 arrivera peut-être à convertir des projets simples, mais a peu de chances de convertir un projet plus complexe. J'attend de voir ce que ca peut donner sur SQLalchemy ou Genshi par example.
[^] # Re: Plusieurs bémols
Posté par Philippe F (site web personnel) . Évalué à 0.
A un moment, si tu veux évoluer, il faut casser la compatibilité pour introduire des nouvelles fonctionnalités. C'est le cas pour Qt, KDE1 -> KDE2 et KDE3 -> KDE4, Gnome 1 -> Gnome 2 , apache1 -> apache2.
Repousser le passage ne fait que compliquer la tâche.
Mais voila, un programmeur aime faire évoluer son logiciel. Python 2.6 ne va pas disparaitre par ailleurs, donc des milliers d'applications continueront a fonctionner correctement. Ca, c'est la bonne nouvelle.
# numpy integration?
Posté par abramov_MS . Évalué à 2.
[^] # Re: numpy integration?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
http://www.python.org/dev/peps/pep-0209/ -- Multi-dimensional Arrays
http://www.python.org/dev/peps/pep-3141/ -- A Type Hierarchy for Numbers
http://www.python.org/dev/peps/pep-0357/ -- Allowing Any Object to be Used for Slicing
http://www.python.org/dev/peps/pep-3118/ -- Revising the buffer protocol
La PEP 209 a été rejettée si j'ai bien compris.
Le PEP 357 a été implementée dans Python 2.5.
La PEP 3118 a eu sa branche Subversion : « py3k-buffer ». Travis a fini son travail et a mergé avec trunk mi-août (2007, ça fait donc parti de Python 3.0a1).
La PEP 3141 dépendait de la PEP 3119 (classe abstraite) qui a été implémentée. J'ai vu passer plusieurs patch pour cette PEP mais elle ne semble pas encore implémentée, ça avance doucemennt.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.