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 !

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

Le , par deusyss

62PARTAGES

11  1 
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.)

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

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
Modérateur 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
Modérateur 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 tyrtamos
Expert éminent https://www.developpez.com
Le 16/09/2016 à 8:24
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/d1601970/autres-langages/python-zope/gui/pyqt/qtdesigner-introuvable-malgre-installation-wheel-pyqt5/#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.
1  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 16/09/2016 à 9:33
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
1  0 
Avatar de wiztricks
Modérateur https://www.developpez.com
Le 16/09/2016 à 11:50
Salut,

Citation Envoyé par TiranusKBX Voir le message
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
1  0 
Avatar de dlewin
Membre averti 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 expérimenté 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