Discussion :

[deusyss]

La première bêta de Python 3.6 est disponible
la version finale est prévue pour fin 2016

La première bêta de Python 3.6 a été mise à la disposition des développeurs cette semaine. Guido Van Rossum, créateur et leader du projet du langage de programmation Python, annonce déjà que cette nouvelle version va être l'occasion de migrer les sources du dépôt Mercurial vers un dépôt GitHub.

Comme l'indique la page dédiée, par rapport à Python 3.5, 9 PEP (propositions d'amélioration pour Python) supplémentaires ont été prises en compte. Outre cela, un certain nombre de correctifs sont également de la partie. Parmi les plus marquants, notons un module standard dédié à la cryptographie.

Concernant la feuille de route, cette dernière prévoit les prochaines bêta pour le 03 octobre, le 31 octobre et le 21 novembre, suivies d'une ou plusieurs releases candidates pour décembre, de même qu'une version finale.

La PSF (Python Software Foundation) encourage vivement les développeurs à tester leur code sur cette nouvelle version afin de s'assurer du bon fonctionnement.

Voir aussi :

Rubrique Python (Actualités, Forum, FAQ, Tutoriels, etc.)

[tyrtamos]

Bonjour,

Merci pour l'info!

Cependant, si j’apprécie que Python évolue, cette évolution est trop rapide! Certains éditeurs de modules externes ne suivent pas (ex: cx_freeze ne marche pas avec Python 3.5) et certaines modifications ont des conséquences importantes sur nos développements (ex: des ruptures de compatibilité entre les versions 5.5=>5.7 de PyQt5).

A titre d'exemple, mes tentatives de passage de Python v3.4 + PyQt5 v5.5 ==> Python v3.5 + PyQt5 v5.7 sous Windows ont été douloureuses: http://www.developpez.net/forums/d16...5/#post8738200, et je suis donc resté sous Python 3.4 pendant encore un bout de temps... Et on n'a pas le choix sous Windows: PyQt v5.7 n'existe pas avec Python v3.4 et PyQt v5.5 n'existe pas avec Python v3.5, ceci probablement à cause du changement de compilateur MS.

Quand je vois sur ce forum les problèmes que pose la poursuite des développements en Python v2 alors que Python v3 est sorti en 2008, je me dis que cette complexité peut freiner la diffusion du langage... Et le grand calme de ce forum Python certains jours commence à m'inquiéter.

[deusyss]

Bonjour Tyrtamos,

Il est vrai que côté PyQt, la V5 entraine son lot de modification, que j'ai également senti douloureusement (surtout quand on m'a demandé du code compatible Py2 et Py3, a la fois PyQt4 et PyQt5).

J'avoue être surpris par la vitesse de la feuille de route. Ce type de cycle court est à la fois une force et une faiblesse. Force, car les bugs peuvent être corrigés rapidement, mais faiblesse, car comme tu le dis, nombre de modules couramment utilisés ne suivent pas forcément.

Concernant le calme du forum, côté Python, j'y travaille.

[TiranusKBX]

Pour les problèmes de migration je me suis retrouvé avec un truc plutôt con
entre le passage de la 3.4 et la 3.5 il y a eus une modification de la lib asyncio associé et je me suis retrouvé avec plusieurs fonction et variables d'asyncio don le nom change(exemple async vs ensure_future ), m'obligeant à tester si l'ancien nom existe toujours et sinon j'utilise l'ancien vus que je fait tourner ça sur des linux qui n'on par forcément la même version de python3
Je parie que ça vas faire de même avec la 3.6

[wiztricks]

Salut,

Pour les problèmes de migration je me suis retrouvé avec un truc plutôt con
entre le passage de la 3.4 et la 3.5 il y a eus une modification de la lib asyncio associé et je me suis retrouvé avec plusieurs fonction et variables d'asyncio don le nom change(exemple async vs ensure_future ), m'obligeant à tester si l'ancien nom existe toujours et sinon j'utilise l'ancien vus que je fait tourner ça sur des linux qui n'on par forcément la même version de python3
Je parie que ça vas faire de même avec la 3.6

Hum... Pas facile de louper cette mention explicite:

Note

The asyncio package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the module) may occur if deemed necessary by the core developers.

dans la documentation du module.

Python 3.5 finalise le travail de fond commencé en 3.0 côté packaging avec "pip", le format "wheel", "importlib",...
Cela ouvre des opportunités de changements:
- le packaging de Qt séparant développement et run-time n'est pas une mauvaise idée. Elle aurait pu être prise plus tôt. PyQt5.6 annonçait déjà la couleur.
- cx_freeze: c'est un projet open source avec peu de développeurs qui ont aussi une autre vie. Ca fait des retards lorsque recompiler ne suffit pas, des utilisateurs qui râlent et d'autres développeurs qui "forkent".

Ceci dit, ces améliorations ont pour vocation (dans un futur lointain) de ne plus avoir à compter sur Gohlke pour avoir des packages prêt à l'emploi sur Windows, réduire la prolifération de tout-en-un comme PythonXY, Anaconda,... (ils existent surtout parce qu'installer c'est compliqué), faciliter un packaging multi-versions,...

Et ce que çà va trop vite?
Qt, PyQt, cx_freeze, Python,.... c'est autant d'équipes de développeurs qui ont leurs propres calendriers. Ils ne se concertent pas pour les changements et parfois ils s'accumulent... Ce qui peut être fort énervant.
Ceci dit, impossible d'être "à jour" dans les versions de tous les produits qu'on utilise, il faut travailler par plateforme i.e. des environnements stables construits avec un mix produits/versions mis à jour tous les ans ou tous les 2 ans (sauf gros bug..) Et on ne fait évoluer ses applications que lors de l'ajout de nouvelles fonctionnalités significatives.
note: çà ne veut pas dire qu'il ne faut pas explorer les nouveautés pour sa culture, pour savoir ce qu'on va figer plus tard, mais on peut essayer d'éviter que les applications qu'on développe ou que l'on maintient en dépendent trop tôt, trop vite.

J'ai aussi noté une baisse de la fréquentation du forum. Mais elle est aussi corrélée à une baisse de fréquentation de développez en général (il y a beaucoup plus de concurrents aujourd'hui qu'il y a 10 ans). Nous avons aussi une crise économique qui fait qu'on développe moins, qu'on privilégie plutôt tablettes et l'embarqué.

- W

[Stéphane le calme]

Python 3.6 apporte des générateurs asynchrones, une personnalisation simplifiée de la création de classe
ainsi qu'un protocole de chemin d'accès au système de fichiers

Mise à jour du 23 / 12 / 2016 : Python 3.6 est disponible en version stable

Comme convenu, la version finale de Python 3.6 est disponible en téléchargement. Il s’agit d’une évolution majeure du langage qui s’accompagne de nombreuses fonctionnalités et optimisations. Parmi les nouvelles fonctionnalités, notons les soulignements dans les littéraux numériques (pour en améliorer la lisibilité), une personnalisation simplifiée de la création de classe ou encore l’ajout d'un protocole de chemin d'accès au système de fichiers.

L’équipe donne quand même quelques avertissements :

• si vous êtes un utilisateur sur Windows, dans le cas où l’installation avec un compte ne disposant d’aucun privilège échoue, vous devrez peut-être passer à des privilèges d'administrateur pour installer une mise à jour dans vos bibliothèques d'exécution C.
• toujours pour les utilisateurs sur Windows, les binaires pour AMD64 vont également fonctionner sur des processeurs qui implémentent l'architecture Intel 64 (également connu sous le nom d'architecture "x64"). Toutefois, ils ne vont pas fonctionner pas sur les processeurs Intel Itanium (anciennement "IA-64").

Source : blog Python

En septembre 2016, Python 3.6 passait en version bêta. Depuis quelques heures, cette version est disponible en version stable. Voici quelques nouveautés qui l'accompagnent :

Littéraux de chaîne formatés :

Python 3.6 apporte un nouveau genre de littéral de chaîne : les f-strings ou encore littéraux de chaîne formatés. Ils ont pour préfixe “f” et sont similaires au format de chaînes accepté par str.format(). Ils contiennent des champs de remplacement entourés par des accolades. Pour rappel, les champs de remplacement sont des expressions, qui sont évaluées au moment de l'exécution, puis formatées à l'aide du protocole format().

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
>>> name = "Fred"
>>> f"He said his name is {name}."
'He said his name is Fred.'
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}"  # nested fields
'result:      12.35'

La syntaxe pour les variables d’annotation :

Cette version s’accompagne de la norme pour les annotations de type de paramètres de fonction. Elle apporte une syntaxe à Python pour l'annotation des types de variables, y compris les variables de classe et d'instance:

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
primes: List[int] = []
 
captain: str  # Note: no initial value!
 
class Starship:
    stats: Dict[str, int] = {}

Tout comme pour les annotations de fonctions, l'interpréteur Python n'attache aucune signification particulière aux annotations de variables et ne les stocke que dans l'attribut __annotations__ d'une classe ou d'un module.

Contrairement aux déclarations de variables dans les langages statiquement typés, l'objectif de la syntaxe d'annotation est de fournir un moyen simple de spécifier des métadonnées de type structuré pour les outils et bibliothèques tiers via l'arbre syntaxique abstrait et l'attribut __annotations__.

Soulignements dans les littéraux numériques :

Pour améliorer la lisibilité, il est possible de se servir de soulignements dans les littéraux numériques :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
>>> 1_000_000_000_000_000
1000000000000000
>>> 0x_FF_FF_FF_FF
4294967295

Les caractères de soulignement simples sont autorisés entre les chiffres et après tout spécificateur de base. À contrario, les soulignements multiples et les soulignements en début ne sont pas autorisés.

Le langage de mise en forme des chaînes est désormais compatible avec l'option '_' pour signaler l'utilisation d'un trait de soulignement pour un séparateur de milliers. Pour des entiers sous la forme 'b', 'o', 'x' et 'X', les caractères de soulignement seront insérés tous les 4 chiffres.

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
>>> '{:_}'.format(1000000)
'1_000_000'
>>> '{:_x}'.format(0xFFFFFFFF)
'ffff_ffff'

Générateurs asynchrones :

Avec Python 3.5 a débarquée le support de coroutines natives async / await dans la syntaxe du langage. L’une des limitations notables de cette implémentation dans Python 3.5 ? Il n’était pas possible d’utiliser dans le même corps de fonction await et yield. Dans Python 3.6, cette restriction a été levée, ce qui permet de définir des générateurs asynchrones.

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
async def ticker(delay, to):
    """Yield numbers from 0 to *to* every *delay* seconds."""
    for i in range(to):
        yield i
        await asyncio.sleep(delay)

Une personnalisation simplifiée de la création de classe :

Il est désormais possible de personnaliser la création de sous-classes sans utiliser de métaclasse. La nouvelle classe __init_subclass__sera appelée dans la classe de base chaque fois qu'une nouvelle sous-classe sera créée :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class PluginBase:
    subclasses = []
 
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        cls.subclasses.append(cls)
 
class Plugin1(PluginBase):
    pass
 
class Plugin2(PluginBase):
    pass

Pour permettre à l’appel de super() de l’argument zéro de fonctionner correctement à partir d'implémentations __init_subclass __ (), les métaclasses personnalisées doivent s'assurer que la nouvelle entrée d'espace de noms __classcell__ est propagée en type.__ new__.

L’ajout d'un protocole de chemin d'accès au système de fichiers :

Historiquement, les chemins du système de fichiers ont été représentés sous forme d'objets str ou bytes. Par conséquent, certains développeurs ont écrit du code qui opère sur les chemins de système de fichiers en supposant que ces objets étaient l’un ou l’autre de ces deux types. Malheureusement, cette hypothèse empêche les représentations d'objets alternatifs de chemins de système de fichiers, à l’instar de pathlib, de fonctionner avec du code préexistant, y compris la bibliothèque standard de Python.

Pour corriger cette situation, une nouvelle interface représentée par os.PathLike a été définie. En implémentant la méthode __fspath __ (), un objet signale qu'il représente un chemin. Un objet peut alors fournir une représentation de bas niveau d'un chemin du système de fichiers en tant qu'objet str ou byte. Cela signifie qu'un objet est considéré comme étant path-like s'il implémente os.PathLike ou est un objet str ou bytes qui représente un chemin d'accès au système de fichiers. Code peut utiliser os.fspath (), os.fsdecode () ou os.fsencode ()pour obtenir explicitement une représentation str et / ou bytes d'un objet path-like.

La fonction intégrée open() a été mise à jour pour accepter les objets os.PathLike, de même que toutes les fonctions pertinentes des modules os et os.path et de la plupart des autres fonctions et classes de la bibliothèque standard. La classe os.DirEntry et les classes pertinentes dans pathlib ont également été mises à jour pour implémenter os.PathLike.

L'objectif est que la mise à jour des fonctions fondamentales pour l'exploitation des chemins du système de fichiers pousse un code tiers à prendre en charge implicitement tous les objets ressemblant à des chemins sans aucun changement de code, ou du moins très minime (par exemple appelant os.fspath Début du code avant d'opérer sur un objet semblable à un chemin).

Voici quelques exemples de la façon dont la nouvelle interface permet à pathlib.Path d’être utilisé plus facilement et de manière transparente avec le code préexistant :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
>>> import pathlib
>>> with open(pathlib.Path("README")) as f:
...    contents = f.read()
...
>>> import os.path
>>> os.path.splitext(pathlib.Path("some_file.txt"))
('some_file', '.txt')
>>> os.path.join("/a/b", pathlib.Path("c"))
'/a/b/c'
>>> import os
>>> os.fspath(pathlib.Path("some_file.txt"))
'some_file.txt'

Source : note de version Python 3.6

[dlewin]

Voilà finalement une nouvelle sur Developpez. Moi qui desespérait depuis ces derniers temps de n'avoir que des sujet/questions trollesques. A me questionner sérieusement sur les évolutions de ce site depuis.

Donc finalement : merci, très intéressant, Python évolue dans un sens cohérent. Un langage vraiment surprenant

[ParseCoder]

Des coroutines dans un langage de script!?

C'est pas un peu "overkill"?

Je n'ai rien contre les langages de script tant qu'on les utilise seulement pour faire des ... scripts.

J'aimerais bien savoir quelle est l'utilité de faire de la programmation asynchrone dans des scripts!

[tyrtamos]

Bonjour,

Je n'ai rien contre les langages de script tant qu'on les utilise seulement pour faire des ... scripts.

Python peut faire des scripts mais aussi beaucoup d'autres choses! Je l'utilise pour ma part pour faire des programmes graphiques assez gros avec PyQt, et ça marche vraiment très bien. On peut faire aussi des calculs mathématiques complexes, y compris parallèles. Compte tenu de la grande quantité de modules, je ne vois pas beaucoup de limites pour l'instant, à part peut-être la programmation système comme avec le C.

Bref, il faut mettre à jour la catégorie: Python="langage de script" : ce n'est plus vrai maintenant.

[ParseCoder]

Python peut faire des scripts mais aussi beaucoup d'autres choses! Je l'utilise pour ma part pour faire des programmes graphiques assez gros avec PyQt, et ça marche vraiment très bien. On peut faire aussi des calculs mathématiques complexes, y compris parallèles. Compte tenu de la grande quantité de modules, je ne vois pas beaucoup de limites pour l'instant, à part peut-être la programmation système comme avec le C.

La question n'est pas de savoir si c'est possible, mais si c'est c'est adapté. Et là je ne suis pas d'accord. Les langages à la Python ne sont pas fait pour coder du "gros" soft, même si c'est possible.

[tyrtamos]

La question n'est pas de savoir si c'est possible, mais si c'est c'est adapté. Et là je ne suis pas d'accord. Les langages à la Python ne sont pas fait pour coder du "gros" soft, même si c'est possible.

Ça, c'est quelque chose que tu peux imposer à ton équipe de développement, mais pas au reste du monde... ;-)

Il y a déjà eu de nombreuses discussions sur ce forum concernant les applications professionnelles de Python, et j'ai rarement vu une telle restriction!

Mais c'est surtout dommage pour toi: en rentrant Python dans une catégorie restreinte, tu te prives de tous ses développements.

[wiztricks]

Des coroutines dans un langage de script!?

C'est pas un peu "overkill"?

Je n'ai rien contre les langages de script tant qu'on les utilise seulement pour faire des ... scripts.

J'aimerais bien savoir quelle est l'utilité de faire de la programmation asynchrone dans des scripts!

Les coroutines servent à remplacer (quand c'est possible) les threads.
Mais ce ne sont que des améliorations de fonctionnalités que Python supportait déjà depuis fort longtemps.

La vraie nouveauté qui devrait vous interpeller est plutôt côté "annotations".
Sûr que çà n'apporte rien à ceux qui utilisent Python comme langage de "scripts": ces codes faits à l'arrache pour dépanner.
Si c'est là, c'est surtout pour aider l'organisation de projets de développement composés de plusieurs personnes/équipes (et à la demande d'organisations qui se sont déjà lancées dans ce genre de projet).
Dans ce monde là, l'overkill est d'utiliser systématiquement un langage compilé (plus sérieux, plus performant,...) alors qu'on pourra coder plus vite avec un langage de scripting (quitte à compiler les parties critiques plus tard).

- W

[ParseCoder]

Ça, c'est quelque chose que tu peux imposer à ton équipe de développement, mais pas au reste du monde... ;-)

Si on parlait plutôt de ceux qui imposent aux autres d'assurer le support d'appli codées avec des outils inadaptés! Je n'impose rien à personne moi.

[VinsS]

Si on parlait plutôt de ceux qui imposent aux autres d'assurer le support d'appli codées avec des outils inadaptés!

Exemples ?

Des exemples de "grôôsses" applications en Python il y en a, par contre.

Je te laisse chercher, tes apriori ne m'invitent pas à t'aider.

[dlewin]

Bon j'ai tout compris c'est une conspiration, faut juste scroller plus haut vers :

Et le grand calme de ce forum Python certains jours commence à m'inquiéter.

pour avoir ensuite:

Concernant le calme du forum, côté Python, j'y travaille.

Alors les gars j'ai faillit marcher dans votre hoax :

Des coroutines dans un langage de script!?

C'est pas un peu "overkill"?

Je n'ai rien contre les langages de script tant qu'on les utilise seulement pour faire des ... scripts.

ou encore

Si on parlait plutôt de ceux qui imposent aux autres d'assurer le support d'appli codées avec des outils inadaptés! Je n'impose rien à personne moi.

On peut pas y croire, ça fait trop troll ça on voit bien que c'est vous qui avez rajouté ça pour faire venir du monde sur ce forum! roooo

[Heliogabale]

Ca veut dire quoi "overkill" ?

[wiztricks]

Ca veut dire quoi "overkill" ?

Ce qu'en dit wikipedia...

- W

[Heliogabale]

Ce qu'en dit wikipedia...

- W

Merci, fallait le dire tout de suite

[abriotde]

Je n'ai rien contre les langages de script tant qu'on les utilise seulement pour faire des ... scripts.

Python est un langage de script pour faire des scripts. On est d'accord. Mais il va plus loin que le bash qui se contente de lancer des programmes et d'en analyser le code de retour et les logs. Avec les extensions, Python récupère le retours des "programmes" comme des objets facilement manipulable. On fait donc un script Pyhton (Bien optimiser en performance par sa machine virtuel) mais qui utilise les extensions (wrapper de librairie pour les plus simple et standard) pour les performances (Qt comme cité plus haut). On a donc au final un programme complet écris en Python qui appel des extension binaires. Mais la partie critique n'est pas écrite en Python mais en C ou autre Pascal. la seul chose c'est que 98% des utilisateurs de Python ne vont jamais avoir besoin d'écrire leurs extensions. Pourquoi ré-inventer la roue?

[tyrtamos]

Bonjour,

Suite au message de abriotde:

Je ne sais pas s'il est courant qu'un "langage de script" puisse faire aussi de la POO comme Python, mais je suis plutôt d'accord avec cette façon de voir. Un développement facile et rapide avec Python, dont la partie interprétée passe rapidement la main à des modules puissants écrits en C ou en C++: on a ainsi le "meilleur des 2 mondes", et il serait dommage de s'en priver... La documentation de Python décrit d'ailleurs assez bien comment on peut lier des modules écrits en C ou en C++ pour qu'ils soient importés dans Python.

Dans d'autres temps, on aurait pu appeler cela "méthode de prototypage", mais en fait les besoins évoluent tellement vite que ça pourrait devenir une méthode normale de développement. Ça me fait penser à ce qui s'est passé avec la gestion des bases de données: dans la mesure où on a choisi des données stables dans le temps, on peut faire évoluer très vite leurs exploitations grâce à un langage de haut niveau comme SQL, y compris par l'utilisateur lui-même (ce que je fais couramment). Avec une exploitation complètement en C, le programme est à peine en production que les besoins ont déjà évolué. Or, la rapidité d'adaptation est plus que jamais un paramètre de survie...