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 :

Python, un langage plaisant mais inefficace pour la plupart des projets professionnels


Sujet :

Python

  1. #21
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 474
    Points : 6 119
    Points
    6 119
    Par défaut
    Citation Envoyé par binarygirl Voir le message
    C'est l'éternel débat langage compilé/interprété.
    Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
    Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

    Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
    Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.
    Si un développeur a beaucoup de lacunes dans les fondamentaux et qu'on lui demande de coder un programme complexe avec un langage compilé et statiquement typé habituel, alors le code n'aura pas de tests automatisés, il y aura des copiés-collés dans tous les sens et, malgré le typage, les entrées et sorties des opérations ne seront pas claires, car il y aura des variables globales muables (ou d'autres patterns similaires) dans tous les sens. Il y aura aussi plusieurs centaines d'avertissements du compilateur, tous ignorés. Bon, par contre, les paramètres des fonctions seront typés, donc il y aura quand même quelques indices qui traîneront dans tout ce bazar pour la future victime qui reprendra le code plus tard.

    Si tu prends le même genre de développeur et que tu lui donnes un langage dynamiquement typé, il te pondras un code qui atteindra des niveaux de catastrophe qu'on ne connaît pas dans le monde des langages statiquement typés. Non seulement il y a encore plus de bogues car il n'y a toujours pas de tests automatisés et car le compilateur ne rattrape plus les erreurs les plus grotesques, mais ce n'est pas tout : quand on lit une fonction quelconque dans le code, on ne sait pas ce qu'elle prend en entrée, on ne sait pas ce qu'elle retourne en sortie et on ne sait même pas toujours quel code est appelé à l'intérieur : objet.methode_dont_le_nom_existe_dans_plein_de_classes(lol). Mais je ne sais pas à quelle(s) classe(s) cet objet peut appartenir !

    Les deux exemples précédents, je les ai vus en entreprise.

    Avec un mauvais développeur, le code sera mauvais quel que soit le langage. Mais, plus le langage lui permettra d'aller loin dans le mauvais code dès le début de l'apprentissage du langage, plus il ira loin dans l'immaintenabilité.

    Citation Envoyé par defZero Voir le message
    C, C++ = langage compilé (AoT), faiblement & statiquement typé (proche de la machine quoi).
    C++, ce n'est pas le même langage que C. Concernant le typage, on n'est pas du tout au même niveau.

    En C, dès qu'on veut faire un peu d'abstraction au runtime, on se retrouve avec des void* qu'il faut convertir de manière un peu sauvage. En outre, en langage C, tout pointeur est nullable, alors que C++ supporte des alternatives aux pointeurs comme les références et std::reference_wrapper.

    Sur certains aspects, le C++ est même un peu plus fortement typé que Java. Par exemple, en Java, comme toute classe dérive de Object qui possède une méthode equals, on peut comparer tout objet avec n'importe quel autre objet, même quand ça n'a pas de sens. En C++, par contre, si on écrit objet1 == objet2 sans avoir surchargé l'opérateur == sur le ou les types correspondants, cela provoque une erreur de compilation.

    Par contre, pour la gestion de la mémoire, il est vrai que C++ est périlleux si on le compare à Java et Rust.

    Citation Envoyé par nhugodot Voir le message
    De toutes façons d'ici la fin de l'année les GitHub CoPilot/GPT5 et autre Google Bard vont certainement être capables de traduire tout langage en un autre et coder eux-mêmes en comprenant nos besoins , spécifications ou même codes (donc un Linux recodé de C à Rust, idem pour Windows depuis son C++, je ne vois pas pourquoi ce serait impossible..?)...
    D'ici la fin de l'année ?! En plus, on est déjà en août ! Non, on n'en est pas à ce stade là.

  2. #22
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 691
    Points : 30 988
    Points
    30 988
    Billets dans le blog
    1
    Par défaut
    Bonjour
    Citation Envoyé par Bruno Voir le message
    L'analyse de Jos Visser est-elle pertinente ?
    Pas vraiment. Parce que tout ce qu'il dit en réalité c'est que Python est un bien beau langage mais il a ses faiblesses et si ces faiblesses sont critiques vis à vis d'un projet X alors il ne faut pas l'utiliser. Ce qui est parfaitement vrai. Mais c'est vrai pour tout langage. Donc cette analyse qui dit en simplifié "un truc qui n'est pas adapté n'est pas adapté" est peut-être exacte mais n'apporte rien de vraiment pertinent.
    De plus commencer son argumentation par "j'ai vu des codes pourris tourner sans avoir été testés" ben oui je veux bien mais est-ce la faute de Python ?

    Citation Envoyé par Bruno Voir le message
    Comment Jos Visser explique-t-il la popularité continue de Python malgré ses supposés défauts ?
    Parce que Python a été pensé pour être assez central. Son crédo de base est "je ne peux pas tout faire très bien donc je fais tout au mieux et je vous laisse ensuite déléguer à d'autres outils plus adéquats les trucs plus spécifiques". C'est un peu comme demander "pourquoi le béton est-il si apprécié dans la construction alors qu'il est moche?" réponse : parce que le béton n'est que le support solide et la beauté est faite avec d'autres matériaux.

    Citation Envoyé par Bruno Voir le message
    Quels sont les avantages et les inconvénients de Python par rapport à des langages compilés et sûrs du point de vue du type, comme C++, Java ou Go ?
    Avantage: il n'a pas été conçu pour les mêmes buts
    Inconvénient: il n'a pas été conçu pour les mêmes buts
    C'est comme demander "quels sont les avantages et inconvénients de l'avion par rapport à l'hélicoptère"...

    Donc voilà, un bien beau discours mais qui ne fait en réalité que brasser du vent
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  3. #23
    Membre éclairé
    Inscrit en
    Mai 2003
    Messages
    271
    Détails du profil
    Informations personnelles :
    Âge : 43

    Informations forums :
    Inscription : Mai 2003
    Messages : 271
    Points : 717
    Points
    717
    Par défaut
    Citation Envoyé par binarygirl Voir le message
    Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
    Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

    Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
    Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

    On pourrait certes argumenter que les langages comme PHP, Python etc sont abordables pour les débutants, et donc il est courant de trouver du code de mauvaise qualité, ce qui explique le mauvais retour d'expérience dans le cas présent.


    Si on parle du type hinting, des annotations, il me semble que ça ne change pas le fait que Python reste dynamiquement typé et alors ce n'est pas du vrai typage statique au sens où ça existe dans d'autres langages. Mais on peut quand même utiliser des outils comme MyPy pour tester la cohérence du code. Et un bon IDE devrait déjà attirer l'attention sur certains problèmes.

    Pour ce qui est des fuites mémoire, on peut utiliser un outil comme Valgrind. Idéalement, toutes ces batteries de tests devraient être mises en place dans une chaîne CI/CD, ce qui prend du temps.
    +1 sur les tests.
    pour pas mal bosser en Python, Go, C# en milieu professionnel, je vois passer bcp d erreurs de code en Python qui n apparaissent qu'au Runtime alors que VS aurait déjà évité certaines en C#/.NET.

    La flexibilité de Python doit s accompagner de plus de tests qu un équivalent en C# ou Go, et c est souvent là que cela pèche: Python est choisi pour son côté "proto" mais trop de dev se refusent à écrire tout les unit tests nécessaires pour rendre le code "professionnel grade / production ready".


    Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".
    J'ai vu trop de fois j ai vu du code style

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    str(len(project["propA"]["subPropB"]))
    sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    if project and "propA" in project and "subPropB" in project["propA"]:
    (En C# ou Go, l erreur serait la même, mais VS émet qques warning ici il me semble)

  4. #24
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 691
    Points : 30 988
    Points
    30 988
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Eric80 Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    str(len(project["propA"]["subPropB"]))
    sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    if project and "propA" in project and "subPropB" in project["propA"]:
    Pardon mais là je suis pas trop d'accord. Si j'écris traite dico["xxx"] c'est que je me sens à priori assez hardi dans le fait que quelque part plus haut j'ai écrit dico["xxx"]=valeur_à_traiter.
    Et si je ne suis pas confiant dans mon Alzheimer, je peux toujours écrire traite dico.get("xxx", "valeur_sinon").

    Parce que c'est bien joli d'écrire if project and "propA" in project and "subPropB" in project["propA"] style "je pense à tout" mais il faut alors vraiment penser à tout et donc aussi réfléchir à ce qui se passe dans le "else"...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  5. #25
    Membre éclairé
    Inscrit en
    Mai 2003
    Messages
    271
    Détails du profil
    Informations personnelles :
    Âge : 43

    Informations forums :
    Inscription : Mai 2003
    Messages : 271
    Points : 717
    Points
    717
    Par défaut
    ds mon exemple, il s'agit de lire des valeurs d un fichier json transformée en dictionnaire avec les noeuds json. (d un json.load). J aurais du le préciser pour éviter toute incompréhension.
    Donc aucune garantie que les valeurs existent. Et si elles n existent pas, il faut simplement ignorer le noeud parent. D'où le if and in proposé.

    Si python propose une façon simple et puissante de charger un json, je préfère ce que je fait généralement en C# avec une approche 100% objet et une flopée de classes générées, avec un deserialize<myRootNodeClass>(jsonString) comme décrit dans la doc MS. Alors oui c est bcp plus long et verbeux mais AMHA plus facile à débugger et tester.

    Dans tout les cas, je trouve que c est un bon ex de la puissance de Python. Ma critique va d'abord aux développeurs qui n ont pas tjs conscience des effets de bords possible...

  6. #26
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 474
    Points : 6 119
    Points
    6 119
    Par défaut
    Citation Envoyé par Eric80 Voir le message
    ds mon exemple, il s'agit de lire des valeurs d un fichier json transformée en dictionnaire avec les noeuds json. (d un json.load). J aurais du le préciser pour éviter toute incompréhension.
    Donc aucune garantie que les valeurs existent. Et si elles n existent pas, il faut simplement ignorer le noeud parent. D'où le if and in proposé.
    Dans ce cas, je conseille d'utiliser un package Python qui va valider le JSON et le transformer en objet plus fortement typé. Je pense que le plus connu est Pydantic (qui est utilisé par FastAPI). Aujourd'hui, je viens de tester un peu msgspec (qui est utilisé par Litestar), mais je n'ai pas encore vérifié si Mypy le gère bien.

    Voici un script de démo que je viens d'écrire :

    Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    #!/usr/bin/env python
     
    PYTHON_VERSION = "3.11.4"
    DEPENDENCIES = ["msgspec==0.17.0"]
    VENV_DIR_NAME = ".venv"
     
    def run():
        from typing import Annotated
     
        import msgspec
        from msgspec import Struct, Meta
     
        PlayerName = Annotated[str, Meta(min_length=1, pattern="^[A-Z][a-z]*$")]
     
        class Player(Struct, forbid_unknown_fields=True):
            name: PlayerName
            score: Annotated[int, Meta(ge=0, le=10)]
     
        class Game(Struct, forbid_unknown_fields=True):
            players: Annotated[list[Player], Meta(min_length=1)]
            winner: PlayerName
     
        game = msgspec.json.decode(
            b'{"players":[{"name":"Alan","score":2},{"name":"Bob","score":7}],"winner":"Bob"}',
            type=Game,
        )
        print(game)
        print(game.players[0].name)
        try:
            msgspec.json.decode(b'{"players":[{"name":"Bob","score":7}]}', type=Game)
        except Exception as exc:
            print(f"Error when the winner is missing: {exc}")
        try:
            msgspec.json.decode(b'{"players":[],"winner":"Bob"}', type=Game)
        except Exception as exc:
            print(f"Error when the player list is empty: {exc}")
        try:
            msgspec.json.decode(b'{"players":[{"name":"Bob","score":"7"}],"winner":"Bob"}', type=Game)
        except Exception as exc:
            print(f"Error when the score is not an integer: {exc}")
     
     
    def main():
        import sys
        from pathlib import Path
     
        if Path(sys.executable).parent.parent.name == VENV_DIR_NAME:
            run()
        else:
            create_venv_if_needed_and_run_script_from_it()
     
     
    def create_venv_if_needed_and_run_script_from_it():
        import shlex
        from pathlib import Path
        from subprocess import check_call, check_output
     
        def print_and_execute(command):
            print("------ " + shlex.join(str(x) for x in command))
            check_call(command)
     
        venv_python = Path(VENV_DIR_NAME) / "bin/python"
        if not Path(VENV_DIR_NAME).is_dir():
            pyenv_root = Path(check_output(("pyenv", "root")).decode("utf-8").strip())
            pyenv_python_dir = pyenv_root / f"versions/{PYTHON_VERSION}"
            if not pyenv_python_dir.is_dir():
                print_and_execute(("pyenv", "install", PYTHON_VERSION))
            pyenv_python = pyenv_python_dir / "bin/python"
            print_and_execute((pyenv_python, "-m", "venv", VENV_DIR_NAME))
            print_and_execute((venv_python, "-m", "pip", "install", "--upgrade", "pip"))
            for dependency in DEPENDENCIES:
                print_and_execute((venv_python, "-m", "pip", "install", dependency))
            print("-"*80)
        check_call((venv_python, Path(__file__).resolve()))
     
     
    if __name__ == "__main__":
        main()
    Sortie :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Game(players=[Player(name='Alan', score=2), Player(name='Bob', score=7)], winner='Bob')
    Alan
    Error when the winner is missing: Object missing required field `winner`
    Error when the player list is empty: Expected `array` of length >= 1 - at `$.players`
    Error when the score is not an integer: Expected `int`, got `str` - at `$.players[0].score`
    La partie qui concerne msgspec est dans ma fonction run. Le reste du script est un bricolage de ma part pour créer à la volée un environnement virtuel avec la version désirée de Python (elle-même installée à la volée via pyenv si besoin), avant de relancer le script depuis cet environnement virtuel.

    Remarque : dans la doc de msgspec, il y a un exemple concret de parsing d'un pyproject.toml : https://jcristharif.com/msgspec/exam...ject-toml.html

  7. #27
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 474
    Points : 6 119
    Points
    6 119
    Par défaut
    À première vue, Mypy sait gérer msgspec.

    Je viens d'apprendre à utiliser Scriptisto. Voici une nouvelle version améliorée du code qui tient aussi en un seul fichier et qui lance des linters avant l'exécution du code :

    Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    #!/usr/bin/env scriptisto
     
    from typing import Annotated
     
    import msgspec
    from msgspec import Meta, Struct
     
    PlayerName = Annotated[str, Meta(min_length=1, pattern="^[A-Z][a-z]*$")]
     
    class Player(Struct, forbid_unknown_fields=True):
        name: PlayerName
        score: Annotated[int, Meta(ge=0, le=10)]
     
    class Game(Struct, forbid_unknown_fields=True):
        players: Annotated[list[Player], Meta(min_length=1)]
        winner: PlayerName
     
    game = msgspec.json.decode(
        b'{"players":[{"name":"Alan","score":2},{"name":"Bob","score":7}],"winner":"Bob"}',
        type=Game,
    )
    print(game)
    print(game.players[0].name)
    try:
        msgspec.json.decode(b'{"players":[{"name":"Bob","score":7}]}', type=Game)
    except Exception as exc:
        print(f"Error when the winner is missing: {exc}")
    try:
        msgspec.json.decode(b'{"players":[],"winner":"Bob"}', type=Game)
    except Exception as exc:
        print(f"Error when the player list is empty: {exc}")
    try:
        msgspec.json.decode(
            b'{"players":[{"name":"Bob","score":"7"}],"winner":"Bob"}',
            type=Game,
        )
    except Exception as exc:
        print(f"Error when the score is not an integer: {exc}")
     
    """
    scriptisto-begin
    script_src: me.py
    build_once_cmd: python build_venv.py && chmod +x script
    build_cmd: ./venv/bin/mypy me.py && ./venv/bin/ruff check me.py
    files:
    - path: requirements.txt
      content: |
        msgspec==0.17.0
        mypy==1.4.1
        ruff==0.0.284
    - path: build_venv.py
      content: |
        from pathlib import Path
        from subprocess import check_call, check_output
        python_version = "3.11.4"
        pyenv_root = Path(check_output(("pyenv", "root")).decode("utf-8").strip())
        pyenv_python_dir = pyenv_root / f"versions/{python_version}"
        if not pyenv_python_dir.is_dir():
            check_call(("pyenv", "install", python_version))
        check_call((pyenv_python_dir / "bin/python", "-m", "venv", "venv"))
        check_call(("venv/bin/python", "-m", "pip", "install", "--upgrade", "pip"))
        check_call(("venv/bin/python", "-m", "pip", "install", "-r", "requirements.txt"))
    - path: script
      content: |
        #!/bin/sh
        DIR="$(cd "$(dirname "$0")" && pwd)"
        exec "$DIR/venv/bin/python" "$DIR/me.py" "$@"
    scriptisto-end
    """
    Quand on lance Scriptisto sur ce fichier, cela fait les opérations suivantes :
    • Initialiser un dossier de cache quelque part dans $HOME/.cache/scriptisto/bin et y exécuter build_venv.py :
      • Installer Python 3.11.4 avec pyenv s'il n'est pas déjà installé.
      • Créer l'environnement virtuel et y installer msgspec, Mypy et Ruff.
    • Depuis cet environnement virtuel :
      • Vérifier le typage avec Mypy.
      • Si c'est OK, vérifier le code avec Ruff.
      • Si c'est OK, exécuter le script.

    Après avoir édité le code, Scriptisto ne réexécutera pas build_venv.py, sauf si on détruit le cache associé au script, par exemple via la commande scriptisto cache clean ./nom_du_fichier.py.

    Cela fait quand même beaucoup de tours de passe-passe juste pour faire tenir tout ça en un seul fichier…

  8. #28
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 287
    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 287
    Points : 36 776
    Points
    36 776
    Par défaut
    Citation Envoyé par Eric80 Voir le message
    Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".
    Faut-il blâmer les développeurs ou ceux qui les emploient (et qui laissent faire)?
    De toutes façons, il n'est pas facile de devenir "bon". On peut avoir une formation initiale raisonnable, mais si on n'a pas l'opportunité de bosser dans des équipes pour apprendre des plus anciens, difficile de s'améliorer seul dans son coin.
    Tout l'intérêt de la qualité d'un développement est dans la compréhension d'un travail d'équipe. On écrit du code qui devra pouvoir être relu/maintenu par d'autres.
    Et pour des applications critiques, on préférera faire faire le contrôle qualité par une autre entité que celle qui développe (on évite les conflits d'intérêt qui pourraient fermer les yeux sur certains défauts).

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

  9. #29
    Membre chevronné
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    721
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2006
    Messages : 721
    Points : 1 876
    Points
    1 876
    Par défaut
    Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
    Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.

    Je déteste aussi la tabulation qui peut causer des erreurs de logique si on ne fait pas attention. Mais c'est ce qui arrive à ceux qui pondent du long code avec des if imbriqués, ce qui n'est pas un bon pattern dans l'absolu. D'ailleurs, je pense que ça m'a ouvert les yeux.
    Depuis que je fais du Python, j'ai appris à rédiger des fonctions plus succinctes et mieux modulariser le code.

  10. #30
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 474
    Points : 6 119
    Points
    6 119
    Par défaut
    Citation Envoyé par binarygirl Voir le message
    Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
    Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.
    Depuis Python 3.8, typing.Final permet de signaler à l'analyseur statique de type qu'une variable ne peut pas être réassignée. Si de plus la variable pointe vers un objet immuable, on a alors une constante.

  11. #31
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 691
    Points : 30 988
    Points
    30 988
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par binarygirl Voir le message
    Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
    Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.
    En dehors d'un aspect lié au langage en lui-même (pouvoir écrire var=123 puis plus tard var="autre chose" parce que les variables doivent pouvoir être réaffectées), il y a une notion philosophique. Est-ce que la notion de "variable invariable" a un sens? Si "var" ne doit pas changer de valeur "123", pourquoi alors utiliser "var" et ne pas utiliser directement "123" ? Pour des questions de lisibilité me répondras-tu (à mon avis). Effectivement c'est plus lisible d'utiliser une variable "avogadro" qu'une valeur "6.02214076e+23". Dans ce cas, le consensus c'est de la mettre en majuscules (comme les #define du C). Mais ça ne reste qu'un consensus (comme les "_" pour les attributs publics, nécessaire pour être connus des objets hérités, mais ne devant pas être utilisés depuis l'extérieur).

    En bash (en fait ça date même du Bourne Shell originel de 1970) c'est pour une question de sécurité. Par exemple la variable "EUID" (Exec User Identifiant) sert à identifier l'utilisateur qui demande une action. Il est évidemment impensable (enfin si on tient à garder un système multi-utilisateurs intègre) d'autoriser n'importe qui à modifier cette valeur et à la mette par exemple à 0

    Citation Envoyé par binarygirl Voir le message
    Je déteste aussi la tabulation qui peut causer des erreurs de logique si on ne fait pas attention.
    Personnellement je ferme toujours mes blocs par un commentaire équivalent au mot clef qui a ouvert le bloc (sauf si le bloc ne contient qu'une ligne)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    def toto():
    	for truc in machin:
    		if chose:
    			actionX
    	# for
    # toto()
    Mais effectivement moi aussi j'ai réduit mes imbrications. C'était peut-être le but voulu en définitive...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  12. #32
    Membre chevronné
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    721
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2006
    Messages : 721
    Points : 1 876
    Points
    1 876
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Depuis Python 3.8, typing.Final permet de signaler à l'analyseur statique de type qu'une variable ne peut pas être réassignée. Si de plus la variable pointe vers un objet immuable, on a alors une constante.
    Oui, mais ça reste une déclaration d'intention au niveau du code, tout comme le typage qui reste dynamique même quand on assigne un type à la variable au départ, mais on peut quand même faire ce qu'on veut de cette variable.
    L'interpréteur ne fait aucun "enforcement". Pour protéger des variables/objets on peut seulement s'appuyer sur les conventions de nommage (uppercase) et éventuellement des outils comme Flake et les tests unitaires.

    Mais merci du rappel, je vais quand même m'habituer à utiliser typing.Final pour enfoncer le clou même si ça ne sert pas à grand-chose dans l'absolu...

  13. #33
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 287
    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 287
    Points : 36 776
    Points
    36 776
    Par défaut
    Citation Envoyé par binarygirl Voir le message
    L'interpréteur ne fait aucun "enforcement". Pour protéger des variables/objets on peut seulement s'appuyer sur les conventions de nommage (uppercase) et éventuellement des outils comme Flake et les tests unitaires.
    Le typing sera utilisé par un analyseur de code statique comme mypy.
    C'est un outil qui permettra de vérifier qu'on n'écrase pas une variable déclarée typing.Final... Et plus généralement du respect du type des objets qui amenés à transiter via les différentes interfaces.
    Comme je le disais plus haut, c'est le genre d'outil qui permet de réduire quelque peu la couverture fonctionnelle des tests et du nombre de boulettes qu'on ne pourrait découvrir qu'en production.

    Si on veut fabriquer un logiciel de quelque importance, il faut faire travailler plein de monde et avoir des gardes fous pour assurer la qualité de ce qui sera produit. Le typing est un des outils qui peut faire passer Python de l'artisanat à une production plus industrielle (c'est pour ça que ça intéresse les grosses boites).

    Ceci dit, un (gros) logiciel fabriqué en usine ne sera jamais parfait.

    C'est pour ça qu'on va faire des alpha/beta tests en plus de toutes une batterie de tests automatiques.

    Dans les faits, on arbitrera sa mise en production/sortie en fonction du nombre de bugs résiduels et de leur gravité/impact estimé côté utilisateurs. Parfois on se trompe (sur la gravité ou sur ce qui a été effectivement testé).

    Et on se prend un tollé côté utilisateurs.

    D'où les réticences de certains à se jeter dans une version .0 et préférer attendre une version .1 ou .2 et/ou de ne pas se jeter sur la dernière mouture disponible mais de patienter en .n-1 ou .n-2.

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

  14. #34
    Membre habitué

    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Novembre 2008
    Messages
    65
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur d'études

    Informations forums :
    Inscription : Novembre 2008
    Messages : 65
    Points : 156
    Points
    156
    Par défaut
    "Python inefficace pour la plupart des projets pro", certains peut-être, mais apparemment pas la plupart. Par exemple dans le traitement data et calcul scientifique il est au top. Pour indice voir aussi l'index Tiobe, en 10 ans d'évolution... Je l'invente pas ça non plus

  15. #35
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2010
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2010
    Messages : 28
    Points : 52
    Points
    52
    Par défaut Grosse pub pour rust... encore.
    "n'est pas vérifié avant l'exécution et qu'il peut produire des erreurs ou des exceptions selon les données qu'il reçoit"... J'utilise beaucoup de C++, et les erreurs à l'exécution existe aussi, croire que le typage va tout résoudre est un peu naïf.
    "Il donne l'exemple d'une application qui lançait du code qui n'avait jamais été testé ni exécuté auparavant"... Et avec n'importe quel langage on obtiendra le même résultat, pas testé donc pas valide, le travail n'est clairement pas terminé, pareil pour ceux qui ne documente pas leur code et le fond faire par des prestataires (les tests aussi mais là c'est une hérésie mais c'est bien réel malheureusement).

    Le peu que j'ai vu de rust ne m'a pas du tout convaincu d'y passer, pour moi il est encore plus que prématuré de s'y lancer professionnellement, à moins d'être kamikaze. Quand à python, cela reste un excellent langage, avec des défauts, et des qualités, et des domaines où il est mieux adapté qu'ailleurs. Et c'est comme tout, un excellent langage dans les mains des mauvaises personnes, produira toujours un résultat imprévisible. Imposer rust à une équipe qui ne le connais pas et je parie que le résultat ne sera pas merveilleux.

    Et puis, on se focalise souvent sur le langage, mais à la base pour réussir une application, c'est avant tout un travail de réflection, conception, test, le langage n'est qu'un outils. Dans ma jeunesse on m'avait interdit d'utiliser du C++, j'ai conçu tout une bibliothèque avec des classes, héritage, polymorphisme en langage C, c'était certes bien plus lourd mais pas infaisable, dans ce cas le langage C++ m'aurait aider, mais au final cela ne m'a pas manqué, car j'ai pu concevoir ce que je voulais faire.

  16. #36
    Expert confirmé
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    Mars 2005
    Messages
    2 679
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 2 679
    Points : 5 264
    Points
    5 264
    Par défaut
    Citation Envoyé par defZero Voir le message
    Phrase d'accroche :

    "Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
    selon Jos Visser, ingénieur principal chez Amazon"

    vs Conclusion :

    "En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels."

    La divergence de la conclusion par rapport à l'énoncé de départ me dérange .
    C'est parce que c'est dérangeant.
    l faut lire les articles originaux pour démêler cette traduction approximative.
    L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.

  17. #37
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 691
    Points : 30 988
    Points
    30 988
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par popo Voir le message
    C'est parce que c'est dérangeant.
    Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde

    Citation Envoyé par popo Voir le message
    L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.
    Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  18. #38
    Expert confirmé
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    Mars 2005
    Messages
    2 679
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 2 679
    Points : 5 264
    Points
    5 264
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde
    Dans mon commentaire "C'est" faisait référence à "La divergence de la conclusion par rapport à l'énoncé de départ".
    Ce qui est, effectivement, dérangeant.

    Citation Envoyé par Sve@r Voir le message
    Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...
    Là aussi, tu n'a pas compris mes propos.
    Alors tu les déformes et tu les tournes en ridicule.

    Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
    Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).

    Noter que mon objectif n'était pas d'émettre un avis sur Python (qui soit positif ou négatif).
    Mon objectif était d'expliquer pourquoi on a cette divergence de la conclusion par rapport à l'énoncé de départ.

  19. #39
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 691
    Points : 30 988
    Points
    30 988
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par popo Voir le message
    Là aussi, tu n'a pas compris mes propos.
    Alors tu les déformes et tu les tournes en ridicule.
    Pas les tiens, les siens !!! Ce sont les siens que tu as expliqué !!!
    Tu me connais non, on a déjà parlé ensemble, je me suis jamais moqué de toi. Un peu d'humour oui sur "dérange/dérangeant" mais bon si ça te... dérange...

    Citation Envoyé par popo Voir le message
    Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
    Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).
    Exactement ce que je dis. Jos Visser a des propos négatifs sur les avions parce que Karun Thankachan encense la choucroute (ou tout autre plat typiquement délicieux que la consonnance de son nom laisse suggérer) et qu'on n'en sert pas dans les avions. Comme quoi
    1. j'avais parfaitement compris tes propos
    2. c'est toi qui n'a pas compris les miens
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

Discussions similaires

  1. Réponses: 0
    Dernier message: 14/02/2020, 11h00
  2. Réponses: 3
    Dernier message: 26/08/2018, 19h23
  3. Conception d'un MCD pour la gestion des projets
    Par abderazaqtr dans le forum Merise
    Réponses: 23
    Dernier message: 05/09/2016, 15h31
  4. [Recrutement] recrutement d'un infographiste pour un ou des projet en loire Atlantique
    Par watsky44 dans le forum Projets
    Réponses: 4
    Dernier message: 03/12/2012, 23h25
  5. Réponses: 0
    Dernier message: 13/03/2008, 10h32

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