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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

La communauté Python annonce la disponibilité générale de la version 3.6.2


Sujet :

Python

  1. #1
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    Mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 659
    Points : 8 442
    Points
    8 442
    Par défaut 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 :

    Rubrique Python (Actualités, Forum, FAQ, Tutoriels, etc.)
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  2. #2
    Expert éminent
    Avatar de tyrtamos
    Homme Profil pro
    Retraité
    Inscrit en
    Décembre 2007
    Messages
    4 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2007
    Messages : 4 461
    Points : 9 248
    Points
    9 248
    Billets dans le blog
    6
    Par défaut
    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.
    Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
    Mes recettes python: http://www.jpvweb.com

  3. #3
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    Mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 659
    Points : 8 442
    Points
    8 442
    Par défaut
    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.
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  4. #4
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    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
    Rien, je n'ai plus rien de pertinent à ajouter

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 235
    Points : 36 684
    Points
    36 684
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  6. #6
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 382
    Points : 196 416
    Points
    196 416
    Par défaut 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 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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  7. #7
    Membre confirmé

    Inscrit en
    Février 2007
    Messages
    202
    Détails du profil
    Informations forums :
    Inscription : Février 2007
    Messages : 202
    Points : 450
    Points
    450
    Billets dans le blog
    1
    Par défaut Intéressant
    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

  8. #8
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 138
    Points : 406
    Points
    406
    Par défaut
    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!

  9. #9
    Expert éminent
    Avatar de tyrtamos
    Homme Profil pro
    Retraité
    Inscrit en
    Décembre 2007
    Messages
    4 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2007
    Messages : 4 461
    Points : 9 248
    Points
    9 248
    Billets dans le blog
    6
    Par défaut
    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.
    Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
    Mes recettes python: http://www.jpvweb.com

  10. #10
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 138
    Points : 406
    Points
    406
    Par défaut
    Citation Envoyé par tyrtamos Voir le message
    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.

  11. #11
    Expert éminent
    Avatar de tyrtamos
    Homme Profil pro
    Retraité
    Inscrit en
    Décembre 2007
    Messages
    4 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2007
    Messages : 4 461
    Points : 9 248
    Points
    9 248
    Billets dans le blog
    6
    Par défaut
    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.
    Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
    Mes recettes python: http://www.jpvweb.com

  12. #12
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 235
    Points : 36 684
    Points
    36 684
    Par défaut
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  13. #13
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 138
    Points : 406
    Points
    406
    Par défaut
    Citation Envoyé par tyrtamos Voir le message
    Ç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.

  14. #14
    Expert éminent

    Homme Profil pro
    Inscrit en
    Octobre 2008
    Messages
    4 298
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2008
    Messages : 4 298
    Points : 6 778
    Points
    6 778
    Par défaut
    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.

  15. #15
    Membre confirmé

    Inscrit en
    Février 2007
    Messages
    202
    Détails du profil
    Informations forums :
    Inscription : Février 2007
    Messages : 202
    Points : 450
    Points
    450
    Billets dans le blog
    1
    Par défaut Trop gros, ça passera pas
    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

  16. #16
    Nouveau Candidat au Club Avatar de Heliogabale
    Profil pro
    Inscrit en
    Mai 2008
    Messages
    54
    Détails du profil
    Informations personnelles :
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2008
    Messages : 54
    Points : 1
    Points
    1
    Par défaut @ParseCoder
    Ca veut dire quoi "overkill" ?

  17. #17
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 235
    Points : 36 684
    Points
    36 684
    Par défaut
    Citation Envoyé par Heliogabale Voir le message
    Ca veut dire quoi "overkill" ?
    Ce qu'en dit wikipedia...

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  18. #18
    Nouveau Candidat au Club Avatar de Heliogabale
    Profil pro
    Inscrit en
    Mai 2008
    Messages
    54
    Détails du profil
    Informations personnelles :
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2008
    Messages : 54
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Ce qu'en dit wikipedia...

    - W
    Merci, fallait le dire tout de suite

  19. #19
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut Python : un langage de script... surpuissant
    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?
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  20. #20
    Expert éminent
    Avatar de tyrtamos
    Homme Profil pro
    Retraité
    Inscrit en
    Décembre 2007
    Messages
    4 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2007
    Messages : 4 461
    Points : 9 248
    Points
    9 248
    Billets dans le blog
    6
    Par défaut
    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...
    Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
    Mes recettes python: http://www.jpvweb.com

Discussions similaires

  1. Réponses: 7
    Dernier message: 06/12/2015, 03h45
  2. [LibreOffice] La première Beta de LibreOffice 4.0 est disponible
    Par troumad dans le forum OpenOffice & LibreOffice
    Réponses: 5
    Dernier message: 31/01/2013, 15h23
  3. La beta du Feature Pack est disponible pour Team Foundation Server 2010
    Par Hinault Romaric dans le forum Visual Studio Team System
    Réponses: 0
    Dernier message: 08/12/2010, 19h45
  4. Réponses: 13
    Dernier message: 06/11/2008, 02h18
  5. [Continuum] La 1.1-beta-1 est disponible
    Par evenisse dans le forum Intégration Continue
    Réponses: 5
    Dernier message: 26/07/2007, 12h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo