La communauté Python annonce la disponibilité générale de la version 3.6.2
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 :
:fleche: Rubrique Python (Actualités, Forum, FAQ, Tutoriels, etc.)
Python 3.6 apporte des générateurs asynchrones
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:
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:
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:
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:
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:
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:
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:
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
Trop gros, ça passera pas
Bon j'ai tout compris c'est une conspiration, faut juste scroller plus haut vers :
Citation:
Envoyé par
tyrtamos
Et le grand calme de ce forum Python certains jours commence à m'inquiéter.
pour avoir ensuite:
Citation:
Envoyé par
deusyss
Concernant le calme du forum, côté Python, j'y travaille. :wink:
Alors les gars j'ai faillit marcher dans votre hoax :
Citation:
Envoyé par
ParseCoder
Des coroutines dans un langage de script!? :weird:
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
Citation:
Envoyé par
ParseCoder
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. :wink:
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 :langue2:
Python : un langage de script... surpuissant
Citation:
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?
La communauté Python annonce la disponibilité générale de la version 3.6.2
La communauté Python annonce la disponibilité générale de la version 3.6.2
qui s'accompagne essentiellement de correctifs et d'améliorations
Quatre mois après la disponibilité générale de Python 3.6.1, la communauté Python a annoncé la disponibilité en téléchargement de Python 3.6.2 dans sa liste de diffusion. Cette mise à jour mineure apporte essentiellement des correctifs dont la plupart ont été proposés durant les RC.
Bibliothèque
Cette mouture a mis à jour la copie expat qui passe de la version 2.2.0 à 2.2.1 afin de corriger de multiples vulnérabilités de sécurité, parmi lesquelles :
- CVE-2017-9233 : DoS de boucle infinie d'entité externe ;
- CVE-2016-9063 : dépassement d'entiers ;
- CVE-2016 -0718 : correction des bogues régression ;
- CVE-2012-0876 : inondation de hachage de compteur avec SipHash.
Cette mouture corrige une situation de concurrence entre la livraison du signal et le descripteur du fichier de réveil. Pour rappel, une situation de concurrence est un défaut dans un système caractérisé par un résultat différent selon l'ordre dans lequel agissent les acteurs du système. Elle peut survenir dès que plusieurs acteurs tentent d'accéder au même moment à une ressource partagée (fichier, imprimante, etc.) et qu'au moins l'un d'entre eux est susceptible de modifier son état.
Cette situation de concurrence est également évitée dans le nettoyage multiprocessus.
Les plantages multiples dans ElementTree provoqués par les situations de concurrence et les mauvais types ont eux aussi été corrigés.
La fonctionnalité urllib.parse.splithost () a été corrigée et analyse désormais correctement les fragments. Par exemple, splithost ('// 127.0.0.1#@evil.com/') renvoie correctement l'hôte 127.0.0.1, au lieu de traiter @ evil.com comme hôte dans une authentification (login @ host).
L'API fonctionnelle pour les énumérations permet désormais de créer des enum vides.
La faille qui pouvait entraîner des fuites de sockets ssl lorsque la connexion est interrompue dans une implémentation asyncio / ssl a été colmatée.
Le problème empêchant logging.handlers.SysLogHandler de gérer les adresses IPv6 a été résolu.
Les fuites de mémoire dans la méthode replace() des objets datetime et time ont été corrigées.
Inspect.signature () prend maintenant en charge les callables avec des paramètres d'argument variable contenus dans partialmethod.
Core
La communauté a annoncé la correction de l’analyse de chaînes de caractères avec des backslashes dans f-strings.
Si un KeyboardInterrupt survient lorsque l'interpréteur est en train de reprendre une chaîne à partir d’appels "yield from" ou “await", il est maintenant correctement livré au frame qui est le plus profond.
Appliquer la méthode Sys.getsizeof () sur un objet code renvoie maintenant les tailles, ce qui comprend le code struct et la taille des objets dont il fait référence.
Source : annonce dans la liste de diffusion
