jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Sortie de la version 3.0a1 du langage Python

Posté par Weksteen Thiébaud (page perso, ). Modéré le 01 septembre 2007.
La PSF (Python Software Foundation) annonce aujourd'hui la sortie de Python 3.0 en version alpha 1.
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.

> Lire la dépêche (58 commentaires, moyenne: 2,3).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Cool...

Posté par Smarter () le 01/09/2007 à 19:27. (lien). Évalué à 4.

mais mettre un titre plus explicite ça serait sympa pour les lecteurs du flux rss ;)
(Au passage, si on clique sur le titre de l'article ça renvoit une erreur 404)

Grillay...

Posté par Moonz () le 01/09/2007 à 19:46. (lien). Évalué à 10.

Bon, j'étais en train de faire ma news mais j'ai été trop lent, donc je vais copier-coller ici mon brouillon contenant moult éléments non précisés dans cette news (c'est, en gros, une traduction et une précision des nouveautés)

* 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 :)

Optimisation

Posté par Victor STINNER (page perso, ) le 03/09/2007 à 11:02. (lien). Évalué à 7.

Personne n'a souligné que Python 3000 est 33% plus lent que Python 2.5 : « The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 33% slower than Python 2.5. ».

Plusieurs bémols

Posté par Thomas Hervé () le 05/09/2007 à 08:04. (lien). Évalué à 1.

Apparemment l'enthousiasme est de mise, mais j'ai du mal à ne pas voir tous les problèmes de cette version. Voir le point de Glyph Lefkowitz que je partage en grande partie: http://glyf.livejournal.com/72036.html.

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.

numpy integration?

Posté par Albert () le 06/09/2007 à 02:45. (lien). Évalué à 2.

quelqu'un sait si les PEP prepare par Travis Oliphant pour commencer a standardiser numpy ou du moins la base de numpy est pris en compte?

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1953s (dont 0.0184 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.