Quelques questions:
>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 reno . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. É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.