nipdev

NipDev 22 – Holy Python

25 commentaires
Share

Podcast: Téléchargement

Après l’envolée des drones, nous revenons à du basique avec une présentation du langage Python réalisée par Sébastien Dupire, plus connu sous le nom de @kyoku57.

Références

Bibliothèques et outils

Administration système

Vérification du code

Web

Traitement d’image (et vidéo)

Application desktop et interfaces utilisateur

Calcul scientifique

Machine learning

CAO

Autres références :

Livres

Magazines

  • Linux Magazine / France HORS SERIE n°49
  • Linux Magazine / France HORS SERIE n°53
  • Linux Magazine / France HORS SERIE n°59 (Django)
  • Linux Magazine / France HORS SERIE n°65

25 réflexions sur « NipDev 22 – Holy Python »

  1. Bonjour,
    Tout d’abord bravo pour la qualité de vos podcasts !
    Dans l’interview vous parliez du choix du langage de programmation en tenant compte du cas d’usage.
    Connaissez-vous un site qui recense les principaux langage et leur cas d’usage ?
    Merci.

    Répondre

    1. J’avais ce lien en stock :
      http://hyperpolyglot.org/

      Il ne recense pas forcément les cas d’usage mais il permet de se faire une petite idée des points communs et des prédilections de certains langages.

      Par exemple, Scala a été pensé pour faire de la programmation fonctionnelle. Tu peux faire autre chose, mais ce sera pas forcément des plus utiles.

      Répondre

  3. pyc: « pré-compilé » en bytecode et non « compilé » 😉
    Une compilation c’est en langage « bas niveau » : si on compile pour de l’ARM ça ne fonctionnera pas sur de l’x86, alors qu’un bytecode, si on a l’interpreteur ça fonctionnera indépendamment sur x86/ARM/ppc.. (modulo les librairies utilisées bien sur)

    Non ruby il y a des fin d’accolades (def/end, while/end, for/end…) : l’indentation n’est pas critique du tout, c’est une vrai spécificité de python 😉

    Répondre

    2. En fait, la notion pré-compilation / compilation n’est pas forcément des plus clair. Nous allons dire que CPython va « compiler » ton code en bytecode, c’est à dire transformer tes instructions Python en autre chose. Après, le bytecode est « executé » sur la machine virtuelle CPython mais il n’y a plus de compilation derrière, uniquement de l’interprétation.

      Pour moi, la notion de précompilation signifierait qu’il y a une compilation après, ce qui n’est pas le cas. En C, la précompilation a du sens : elle prépare tes fichiers en une première passe avant de compiler en code machine près à être linké pour devenir executable. En Python, le bytecode pyc sera interprété mais il est déjà « compilé » pour la machine virtuelle CPython.

      La notion de compilation est simplement de transformer un langage dans un autre : http://fr.wikipedia.org/wiki/Compilation_%28informatique%29

      Après, le compilateur JIT comme l’implémente PyPy est différent : si un bout de bytecode est fréquent et identifiable, il va le « recompiler » en code machine directement, ce qui va rendre ton programme Python plus rapide. Là, tu auras effectivement, une précompilation du code en bytecode puis une recompilation des morceaux que PyPy juge possible d’optimiser en code machine.

      Répondre

  4. Pour la possibilité de changer à la volée une méthode c’est aussi intéressant qu’effrayant:
    Vous avez d’un coté des classes définis avec des paramètres et un type de sortie défini et documenté, mais vous pouvez avoir dans votre application une sortie tout autre car un développeur (ou vous même) avez redéfini son comportement à la volée 🙁
    Pas pratique à déboguer 🙁

    Le coup des paramètres « nommable », c’est bien pratique en effet: en php, soit on doit gérer des paramètres optionnelles (initialisé dans la définition) exple: function pourcentage($part,$total,$arrondi=false), soit on doit passer un tableau à la fonction 🙁

    Pour pypi, ça me fait penser à cpan en perl, ou pear en php, ou plus récemment composer en php 😉

    Répondre

    1. Cela peut-être effrayant, mais cela laisse au développeur le soin de faire ce qu’il veut car le langage lui permet. Python est un langage libre et il permet comme d’autres langages, de faire n’importe quoi. Comme tu le dis, ce ne serait pas pratique à déboguer donc à charge au développeur de ne pas faire ça.

      Python délègue beaucoup de responsabilité au développeur, ce qui est bien, je trouve. La même notion s’applique à la portée des variables : les variables protected n’existent pas en Python. C’est une convention avec le nom des variables qui indiquent au développeur « responsable » qu’il ne faut pas y toucher et faire n’importe quoi. Mais après, s’il a envie, il en a le pouvoir.

      Après comme disait l’oncle Ben « Un grand pouvoir implique de grandes responsabilités » 🙂

      Répondre

      1. Python à l’air en effet très flexible, mais j’ai encore quelques questions concernant la POO sur ce langage:
        Vous dites qu’il n’y a pas la notion de protection de variable et qu’il faut préfixer d’un underscore: mais comment différencier une propriété privée utilisée par la classe mère, d’une protected également accessible par la classe enfant ?
        Autre question: y a t’il la notion d’interface et de classe abstraite ?

        Cette liberté me fait penser aux arguments contre les langages « haut niveau » comme php,python,ruby…
        – absence de signature pour les méthodes
        – pas de typage fort

        Et c’est par le meurtre de son oncle que la jeune araignée comprend la signification de ses dernières paroles 😉

        Répondre

        1. Le soucis est que nous ne programmons pas en Python comme nous programmons en Java. Les règles connues dans la POO de C++ ou Java ne sont pas applicables à Python.

          Tu peux expérimenter en mode interactif :

          class Test:
          a = 3 #public
          _b = 4 #protected
          __c = 5 #private

          >>> obj=Test()
          >>> obj.a
          3
          >>> obj.b
          Traceback (most recent call last):
          File «  », line 1, in
          AttributeError: Test instance has no attribute ‘b’
          >>> obj._b
          4
          >>> obj.c
          Traceback (most recent call last):
          File «  », line 1, in
          AttributeError: Test instance has no attribute ‘c’
          >>> obj.__c
          Traceback (most recent call last):
          File «  », line 1, in
          AttributeError: Test instance has no attribute ‘__a’
          >>>

          Ta variable protected _b ne l’est pas. Elle est accessible directement. Le underscore n’est qu’une convention.

          Ta variable private __a ne l’est pas non plus. Elle n’est pas accessible directement. Le double underscore n’est qu’une convention … mais ! Si tu listes les attributs de l’objet obj.

          >>> dir(obj)
          [‘_Test__c’, ‘__doc__’, ‘__module__’, ‘_b’, ‘a’]

          On voit que le double underscore est un système de renommage de ta variable pour être moins accessible

          >>> obj._Test__c
          5

          Conclusion : toutes les données sont publiques 😉

          Concernant les classes abstraites, j’ai envie de dire : en Python, on ne fait que du concret 🙂

          Tu peux implémenter une pseudo classe abstraite :

          class TestAbstraite:

          def ma_fonction_abstraite(self):
          raise NotImplementedError(« pas dispo »)

          class TestFille(TestAbstraite):

          def ma_fonction_abstraite(self):
          print(« ok c’est bon »)

          Une fois que tu joues avec :

          >>> testMere=TestAbstraite()
          >>> testMere.ma_fonction_abstraite()
          Traceback (most recent call last):
          File «  », line 1, in
          File «  », line 3, in ma_fonction_abstraite
          NotImplementedError: pas dispo
          >>> testFille=TestFille()
          >>> testFille.ma_fonction_abstraite()
          ok c’est bon
          >>>

          Tu as le même résultat 😉

          Par contre, attention. Je suis d’accord que la signature des messages, c’est particulier car c’est dynamique (ce n’est pas qu’il n’y en a pas) mais le typage en python est justement très fort. Il n’est pas static mais il est très très fort en Python (tu ne peux pas ajouter des poires et des bananes … contrairement à Javascript qui a un typage faible. Toute opération entre type non compatible lève une exception en Python.

          Répondre

          2. C’est un peu du bricolage, mais bon. Et quand est il des interfaces ?
            C’est assez pratique je trouve par exemple pour checker/contraindre des plugins développés par des tiers dans un projet 😉
            Un peu comme un xsd 🙂

            Pour info je fais majoritairement du php (pas de java).
            La POO sous python me fait penser un peu à celle sous perl, dans le mauvais sens du terme: de la « POO light » 🙁

          3. Autre chose sur la notion du tout objet en python:
            Pourquoi ne peux-t-on pas faire
            a =2
            b= »toto »
            print a.toString() + b

            mais :
            print str(a) + b

            Tout objet mais pas jusqu’au bout ?

          4. @mikado : désolé, je n’ai pas le bouton « répondre » sous ton commentaire, du coup, je suis obligé de répondre ici :

            Pour les interfaces, tu as lâché le mot « checker/contraindre » : Python n’impose pas de contrainte .. donc pas d’interface. Le but du langage est d’offrir le maximum de liberté au développeur. Cela peut sembler effrayant mais personnellement, en Java, ça me frise les poils de voir qu’on se farçit une interface + une factory pour au final faire qu’une implémentation derrière. Si tu offres un système de plugins, tu t’attends à ce que les développeurs suivent les règles. Encore une fois, Python délègue beaucoup de contrôle aux développeurs et le langage ne doit pas « contraindre » l’utilisateur.

            Sinon, a.toString() == a.__str__() . Le str(a) est une convention afin d’appeler automatiquement a.__str__() . C’est pareil, avec len(a) qui appelle a.__len__(). Donc c’est bien objet 😉

          5. @Sébastien merci de prendre le temps de répondre 😉

            Personnellement je n’utilise pas les interfaces, mais si je souhaitais appliquer un « xsd » à des classes terses, ça me rassurerait de pouvoir vérifier leur compatibilité avec le reste du projet, tout comme le xsd permet de vérifier la conformité d’un xml avant de le parser ou de l’envoyer à un tiers.

            Pour le toString, merci de l’information, c’est dommage d’avoir créé un nom de méthode aussi « complexe »
            Si je comprends bien : les deux underscore du départ signifie (par convention) qu’elle est « private » ? Ce n’est pas logique vu qu’elle doit être appelé de « l’extérieur » de l’objet ..
            En tout cas ça confirme bien ce que vous disiez: c’est du tout objet.
            Dommage de ne pas avoir créé de méthodes plus simple pour garder cette logique/homogénéité objet lors de l’écriture 🙁

            note: je le répète, en objet je fais plutôt du php et non du java 😉
            Le php est également souvent critiqué pour sa POO jugée « incomplète »

            HS: J’avais pour projet de faire un portage de mon framework en python pour permettre de choisir son langage: peux-t-on faire un singleton en python ?

        2. @mikado, merci à toi d’être aussi curieux 😉

          J’avoue que pour le __add__() cela peut porter effectivement à confusion avec la portée d’une variable mais là, tu as les __ avant et après le nom … encore une convention :-D.

          Je suis fait la même réflexion que toi sur la complexité de « toString » en passant sur Python à l’époque, sauf que je me suis posé cette question sur len(). J’ai eu beaucoup de mal à me dire que pour avoir la taille d’une liste, je devais faire len(maliste) plutôt que maliste.size(). Ils ont du partir du principe que si une méthode était commune à plusieurs objets, il fallait mieux la sortir comme fonction du langage.

          Il doit y avoir une PEP à l’origine de cette décision et ça m’intéressait bien de connaître la raison exacte de cette convention ;-).

          On parle souvent d’une écriture Pythonique d’un programme et un vrai Pythonien n’a pas de mal à détecter ceux qui viennent d’un autre langage.

          Maintenant, tout n’est pas parfait en Python 3. Le langage évolue, après reste à voir si c’est en bien 🙂

          Répondre

  6. Concernant des exemples d’utilisation de Python, oui il y a des outils qu’on utilise tous les jours comme Youtube :

    * YouTube uses Python « to produce maintainable features in record times, with a minimum of developers »* « Google uses Python for many tasks including the backends of web apps such as Google Groups, Gmail, and Google Maps, as well as for some of its search-engine internals »
    * http://www.reddit.com/ le code source est même disponible https://github.com/reddit/reddit c’est en Pylons 1
    * Yahoo! Groups uses Python « to maintain its discussion groups »
    * http://en.wikipedia.org/wiki/Instagram
    * http://en.wikipedia.org/wiki/Pinterest
    * http://en.wikipedia.org/wiki/Disqus
    * http://en.wikipedia.org/wiki/EventBrite
    * http://en.wikipedia.org/wiki/Surveymonkey
    * https://bitbucket.org/
    * http://www.nytimes.com/
    * http://www.washingtonpost.com/
    * http://www.theguardian.com/uk
    * Anciennement OpenERP https://www.odoo.com/

    Je m’arrête là 🙂

    Répondre

Répondre à mikadoAnnuler la réponse.