IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Python 3.6 apporte des générateurs asynchrones
Ainsi qu'un protocole de chemin d'accès au système de fichiers

Le , par Stéphane le calme

71PARTAGES

8  0 
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
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
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
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
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
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
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
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de tyrtamos
Expert éminent https://www.developpez.com
Le 23/12/2016 à 17:42
Bonjour,

Citation Envoyé par ParseCoder Voir le message
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.
6  1 
Avatar de tyrtamos
Expert éminent https://www.developpez.com
Le 23/12/2016 à 18:21
Citation Envoyé par ParseCoder Voir le message
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.
5  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 23/12/2016 à 18:53
Citation Envoyé par ParseCoder Voir le message
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
3  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 26/12/2016 à 16:25
Salut,

Pour ceux que çà intéresse, il faut (re)lire ce que racontait John K. Ousterhout il y a presque 20 ans: Scripting: Higher Level Programming for the 21st Century.

- W
2  0 
Avatar de dlewin
Membre confirmé https://www.developpez.com
Le 16/12/2016 à 9:42
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
1  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 26/12/2016 à 15:08
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?
1  0 
Avatar de tyrtamos
Expert éminent https://www.developpez.com
Le 26/12/2016 à 15:56
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...
1  0 
Avatar de VinsS
Expert éminent https://www.developpez.com
Le 24/12/2016 à 0:26
Citation Envoyé par ParseCoder Voir le message
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.
0  0 
Avatar de dlewin
Membre confirmé https://www.developpez.com
Le 24/12/2016 à 11:00
Bon j'ai tout compris c'est une conspiration, faut juste scroller plus haut vers :
Citation Envoyé par tyrtamos Voir le message
Et le grand calme de ce forum Python certains jours commence à m'inquiéter.
pour avoir ensuite:

Citation Envoyé par deusyss Voir le message
Concernant le calme du forum, côté Python, j'y travaille.
Alors les gars j'ai faillit marcher dans votre hoax :

Citation Envoyé par ParseCoder Voir le message
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
Citation Envoyé par ParseCoder Voir le message
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
1  1 
Avatar de Heliogabale
Nouveau Candidat au Club https://www.developpez.com
Le 26/12/2016 à 10:16
Ca veut dire quoi "overkill" ?
0  0