Perl 5.36.0 est sorti

Posté par  . Édité par contra-sh, Patrick Trauquesègues, tisaac, Bruno Ethvignot, Ellendhel, Gil Cot ✔ et palm123. Modéré par bobble bubble. Licence CC By‑SA.
Étiquettes :
35
28
sept.
2022
Perl

La toute dernière version de Perl, la 5.36.0, est sortie le 28 mai 2022. Vous la retrouverez bientôt dans votre distribution préférée.

Perl est un langage généraliste créé en 1987 par Larry Wall. Il est distribué sous une double licence : Artistic Licence et GPL v1+. La plupart des modules du CPAN, dépôt de référence pour des modules tiers, suivent également ce même traitement. Perl est inclus dans la quasi-totalité des distributions GNU/Linux.

Tout d’abord un petit lien vers la précédente dépêche sur la sortie de Perl 5.32.0 ainsi que vers la dépêche annonçant la sortie de Perl 5.30.0.

Sommaire

Améliorations de base

Comme toujours, use v5.36; active les fonctionnalités pour cette version de Perl. Le bundle 5.36 permet la fonctionnalité « signatures ». Introduite dans la version 5.20.0 de Perl et modifiée plusieurs fois depuis, la fonctionnalité de « signatures » de sous-programmes n’est désormais plus considérée comme expérimentale. Elle est considérée comme une fonctionnalité de langage stable et n’affiche plus d’avertissement.

use v5.36;

sub add ($x, $y) {
  return $x + $y;
}

Malgré cela, certains éléments des sous-programmes signés restent expérimentaux ; voir ci-dessous.

Le bundle 5.36 active aussi la fonctionnalité isa. Introduite dans la version 5.32.0 de Perl, cet opérateur est resté inchangé depuis. L’opérateur est désormais considéré comme une fonctionnalité de langage stable. Pour plus de détails, vous pouvez lire la documentation de l’opérateur.

Le bundle 5.36 désactive la fonctionnalité « indirect »

L’utilisation d’appels de méthode « indirects » est très puissante et permet d’émuler des constructions comme $x = new Class;.

D’un autre côté, cette possibilité complique le travail de l’interpréteur en rendant de nombreuses erreurs détectable uniquement à l’exécution. C’est ce qui fait de la désactivation de cette fonctionnalité un « mal pour un bien » et donc une amélioration.

Le bundle 5.36 désactive la fonctionnalité « multidimensional »

L’utilisation d’une expression de liste comme clé de hachage pour simuler des tableaux multidimensionnels clairsemé

Les détails de ces changements peuvent être trouvés dans la documentation de Perl-5.36.0 mais la version courte est : c’est un peu comme avoir use strict; activé, les fonctionnalités qui causent plus de problèmes que de solutions sont désactivées. De plus, ajouter use 5.36; dans votre code activera également les avertissements comme si vous aviez écrit use warnings;

Enfin, avec cette version, la fonctionnalité expérimentale switch, présente dans chaque bundle de fonctionnalités depuis leur introduction dans la v5.10, a été supprimée du bundle v5.36. Si vous souhaitez l’utiliser (contre l’avis des développeurs du langage), vous devrez l’activer explicitement.

Ricardo Signes a annoncé le 28 mai 2022 des exceptions avec des blocs finally, des blocs defer, des boucles for avec plusieurs variables d’itération, Unicode 14 et une nouvelle classe de fonctions d’assistance importées via le pragma 'builtin'.

L’argument de ligne de commande -g

Un nouvel argument de ligne de commande, -g, est disponible. C’est un alias plus simple pour -0777.

Cet argument est utile pour les “one-liners” car il permet de lire un fichier en entier plutôt que ligne par ligne.

Par exemple un fichier data:

foo
bar
baz

Pourra être lu en une seule fois avec -0777 ou -g:

$ cat data | perl -g -e 'while (<>) { chop; print "[$_]"; }'
[foo
bar
baz]

Attention, cet argument change également le comportement d’autres fonctionnalités (comme chomp).

Prise en charge d’Unicode 14.0

Comme toujours, cette version de Perl améliore le support d’Unicode. Vous pouvez lire Unicode® 14.0.0 pour plus de détails. On pourra par exemple utiliser l’émoji “troll” et ce, même si on n’est pas vendredi.

Les ensembles de regex ne sont plus considérés comme expérimentaux

Avant cette version, la fonctionnalité des ensembles de regex (officiellement appelée “Extended Bracketed Character Classes”) était considérée comme expérimentale. Introduite dans la version 5.18.0 de Perl et modifié plusieurs fois depuis, elle est désormais considérée comme une fonctionnalité stable du langage et son utilisation n’affiche plus d’avertissement. Les personnes intéressées pourront lire la documentation de la fonctionnalité.

Le lookbehind de longueur variable n’est généralement plus considéré comme expérimental

Avant cette version, toute forme de lookbehind de longueur variable était considérée comme expérimentale. Avec cette version, le statut expérimental a été réduit pour ne couvrir que le lookbehind qui contient des parenthèses de capture. En effet, il n’est pas clair si “aaz”=~/(?=z)(?<=(a|aa))/ doit correspondre et laisser $1 égal à “a” ou “aa”. Actuellement, il correspondra à l’alternative la plus longue possible, “aa”. Bien que nous soyons convaincus que la construction globale ne correspondra désormais que lorsqu’elle le devrait, nous ne sommes pas sûrs de conserver le comportement actuel de “correspondance la plus longue”.

SIGFPE n’est plus différé

Les exceptions à virgule flottante sont maintenant livrées immédiatement, de la même manière que les autres “défauts” -comme les signaux tels que SIGSEGV. Cela signifie que l’on a au moins une chance d’attraper un tel signal avec un gestionnaire $SIG{FPE}, par exemple pour que la fonction die puisse signaler la ligne en perl qui l’a déclenché.

Suivi de booléen stable

Les valeurs booléennes “true” et “false”, souvent accessibles par des constructions comme !!0 et !!1 (idiomatique n’est-ce pas?), en plus d’être renvoyées par de nombreuses fonctions et opérateurs de base, se souviennent désormais de leur nature booléenne même via l’affectation à des variables. La nouvelle fonction is_bool() vient rejoindre les builtins et peut servir à vérifier si une valeur est de nature booléenne. Cela est susceptible d’être utile lors de l’interopérabilité avec d’autres langages ou de la sérialisation de type de données, entre autres.

Itération sur plusieurs valeurs à la fois (expérimental)

Vous pouvez désormais itérer sur plusieurs valeurs à la fois en spécifiant une liste de lexiques entre parenthèses. Par exemple:

for my ($key, $value) (%hash) { ... }
for my ($left, $right, $gripping) (@moties) { ... }

Avant Perl v5.36, essayer de spécifier une liste après for my donnait une erreur de syntaxe. Cette fonctionnalité est actuellement expérimentale et entraînera un avertissement de catégorie experimental::for_list. Pour plus de détails, voyez-la documentation associée.

Aller plus loin

  • # Qui code en perl ?

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 29 septembre 2022 à 07:29.

    Ne prenez pas mon titre comme une provocation, c'est une question légitime. Je ne connais pas beaucoup d'outils codés en Perl encore actuellement. Sur ma machine, perl est installé pour cloc et irssi.

    Qui utilise encore Perl par choix et pour quoi, quel domaine ?

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 10. Dernière modification le 29 septembre 2022 à 08:56.

      Proxmox VE et Request Tracker sont en perl.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Qui code en perl ?

      Posté par  (site web personnel) . Évalué à 5.

      Je ne connais pas beaucoup d'outils codés en Perl encore actuellement

      Tu peux essayer :

      cd /bin
file * | grep -i perl
file * | grep -ic perl # j'obtiens 206...

      puis revenir vers nous :-) (pas besoin de regarder dans /usr/bin c'est pareil grâce à Lennart :D)

      sur Mageia, tu as historiquement tous les outils du centre de contrôle (drak*) et de gestion de paquets (urpm*).

      • [^] # Re: Qui code en perl ?

        Posté par  (site web personnel) . Évalué à 3.

        "sur Mageia : file * | grep -ic perl # j'obtiens 206…"

        On vient bien les préférences de chaque distribution Linux :-) Sous Fedora, c'est plutôt Python qui prédomine :-)

        $ file /usr/bin/* | grep -ic perl
        22
        $ file /usr/bin/* | grep -ic python
        150

        • [^] # Re: Qui code en perl ?

          Posté par  (site web personnel) . Évalué à 3.

          ah bah

          file /bin/* | grep  -ic python # donne 222 sur Mageia

          comme quoi :-)

          • [^] # Re: Qui code en perl ?

            Posté par  (site web personnel) . Évalué à 5.

            et pour être plus complet sur la répartition (script bash à la râche, j'aurais pu tout faire en gawk… l'équivalent en perl étant laissé à titre d'exercice :p) :

            file /bin/* | awk -F ":" '{gsub(/^[ \t]+/,"",$2) ; print $2 }' \
| grep -vE "symbolic|setuid|setgid|^ELF"  |sort -u \
| while read vfiletype ; do \
     echo  `file /bin/* |grep -c "$vfiletype"` ":" $vfiletype ; \
  done|sort -nr

670 : ASCII text
405 : a /usr/bin/sh script, ASCII text executable
200 : Perl script text executable
187 : Python script, ASCII text executable
56 : Bourne-Again shell script, ASCII text executable
15 : Python script, Unicode text, UTF-8 text executable
10 : a /usr/bin/sh script, Unicode text, UTF-8 text executable
5 : a /usr/bin/sh -e script, ASCII text executable
4 : POSIX shell script, ASCII text executable
4 : directory
4 : a /usr/bin/sh script, ASCII text executable, with escape sequences
3 : a /usr/bin/sh - script, ASCII text executable
2 : a /usr/bin/sh script, ISO-8859 text executable
2 : a /usr/bin/sh -f script, ASCII text executable
1 : Python script, ISO-8859 text executable
1 : Python script, ASCII text executable, with very long lines (402)
1 : Python script, ASCII text executable, with escape sequences
1 : gzip compressed data, max compression, from Unix, original size modulo 2^32 4545904
1 : C source, ASCII text
1 : Bourne-Again shell script, Unicode text, UTF-8 text executable
1 : Bourne-Again shell script, Non-ISO extended-ASCII text executable
1 : Bourne-Again shell script, ASCII text executable, with very long lines (702)
1 : Bourne-Again shell script, ASCII text executable, with very long lines (363)
1 : a /usr/bin/wish script, ASCII text executable
1 : a /usr/bin/tclsh script, ASCII text executable
1 : a /usr/bin/sh script, ISO-8859 text executable, with CR, LF line terminators
1 : a /usr/bin/sh script, ASCII text executable, with very long lines (626)
1 : a /usr/bin/sh script, ASCII text executable, with very long lines (1242)
1 : a /usr/bin/sh script, ASCII text executable, with overstriking
1 : a /usr/bin/sh -e script, ASCII text executable, with CR, LF line terminators
1 : a /usr/bin/guile -s script, ASCII text executable
1 : a /usr/bin/gjs script, ASCII text executable
1 : a /usr/bin/env python3 script executable (binary data)

            ça permet aussi de voir le franc succès d'UTF-8 /o\ (hint: spa gagné :p)

            • [^] # Re: Qui code en perl ?

              Posté par  (site web personnel) . Évalué à 5.

              UTF-8 englobe ASCII. Un fichier ASCII peut être décode par UTF-8. Mais les outils préfèrent dire ASCII qui est plus précis. Pour du code source, ASCII est suffisant dans la grande majorité des cas.

              • [^] # Re: Qui code en perl ?

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Oui, quand il dit ASCII c'est qu'il n'y a pas de caractères étendus/accentués (utilisant 8 bits) ni de BOM…

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Qui code en perl ?

        Posté par  (site web personnel) . Évalué à 2.

        Challenge accepted!

        ~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -ic perl
15
~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -i perl 
/usr/bin/callgrind_annotate:                   Perl script text executable
/usr/bin/callgrind_control:                    Perl script text executable
/usr/bin/cg_annotate:                          Perl script text executable
/usr/bin/cg_diff:                              Perl script text executable
/usr/bin/cloc:                                 Perl script text executable
/usr/bin/ms_print:                             Perl script text executable
/usr/bin/perl:                                 ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perl5.34.1:                           ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perldoc:                              Perl script text executable
/usr/bin/pod2html:                             Perl script text executable
/usr/bin/pod2man:                              Perl script text executable
/usr/bin/pod2text:                             Perl script text executable
/usr/bin/pod2usage:                            Perl script text executable
/usr/bin/podchecker:                           Perl script text executable
/usr/bin/streamzip:                            Perl script text executable

        Par contre tous les pod* ne comptent pas puisqu'ils viennent depuis perl directement. Donc en realité sur ma machine il n'y a que cloc, valgrind et git-send-email qui sont codés en perl visiblement.

        ~ $ apk info -r perl
perl-5.34.1-r0 is required by:
perl-sub-quote-2.006006-r1
perl-error-0.17029-r1
cloc-1.92-r0
perl-role-tiny-2.002004-r1
perl-regexp-common-2017060201-r2
perl-class-method-modifiers-2.13-r2
perl-algorithm-diff-1.201-r0
git-perl-2.36.1-r0
perl-moo-2.005004-r1
perl-parallel-forkmanager-2.02-r3

        git is great because linus did it, mercurial is better because he didn't

        • [^] # Re: Qui code en perl ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Comparé au message initial, tu n'as pas installé irsii et tu découvres qu'en plus de cloc il y a deux autres au moins (en ne comptant pas streamzip et ms_print) qui l'ont en dépendance. Valgrind et Git étant d'assez gros projets, on ne peut pas dire ça reste un usage de niche …bien que peu visible en général.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Qui code en perl ?

            Posté par  . Évalué à 0.

            git-perl est une interface pour utiliser Git depuis perl, pas une dépendance de git

      • [^] # Re: Qui code en perl ?

        Posté par  . Évalué à 1.

        Utiliser find quand on ignore le nombre d'arguments

        find /usr/bin/ -type f -exec file {} + | grep -ic perl

        (Sur ma distrib, /bin donne 0.)

    • [^] # Re: Qui code en perl ?

      Posté par  (site web personnel) . Évalué à 6. Dernière modification le 29 septembre 2022 à 10:11.

      Parmi les (gros) logiciels que j'utilise : amavis, spamassassin, webmin.
      Tous mes projets opensource sont en perl : afick, webminstats, rpmorphan, rpmrestore, rpmerizor … (disponibles sur sourceforge)

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 7. Dernière modification le 29 septembre 2022 à 11:18.

      Deux outils excellents que j'utilise tous les jours (en plus de ceux déjà cités) : BackupPC et Lemonldap::NG. Sinon perso, je trouve perl très adapté pour des petits scripts vite fait (monitoring, traitement de données one-shot etc.)

      • [^] # Re: Qui code en perl ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 29 septembre 2022 à 14:20.

        Traitement de données one-shot (et one-liner) : je fais habituellement du AWK et de la glue shell avec les autres filtres. Mais dès que le traitement est conséquent ou complexe :
        les dinosaures comme moi dégainent PERL (toujours présent),
        les poussins iront automatiquement vers Python (maintenant présent par défaut) ou autre nouveauté

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 8.

      En plus de ceux déjà évoqués, il y a GNU Parallel et, surtout, Asciiquarium !

    • [^] # Re: Qui code en perl ? -> Shutter

      Posté par  . Évalué à 6.

      J'ai découvert que Shutter est écrit en Perl. https://github.com/shutter-project/shutter

      Excellent utilitaire de capture d'écran.

    • [^] # Re: Qui code en perl ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Zonemaster est en Perl (et activement développé).

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 4.

      C'est vrai que la confusion autour de Perl 6 a fait chuter la popularité de ce langage assez vite. Toutefois, à la fin des années 1990 et au début des 2000, c'était très utilisé, y compris pour du CGI. Et autant dire que pendant cette période chaotique (la folie des dotcom), beaucoup de code a été écrit, et je ne serais pas surpris qu'il en reste un bon paquet.

      Dans l'infrastructure dont j'ai hérité au boulot, et je pense que c'est le cas dans beaucoup d'entreprises un peu anciennes (pour mon cas, créée en 1983), il y a toujours quelques scripts d'admin en Perl qui traînent, et qui continuent de fonctionner modulo 2-3 ajustements.

      De temps en temps, je me sers de Perl comme filtre sur la ligne de commande, à la place de awk ou sed, parce que je connais mieux la syntaxe et que c'est plus lisible (c'est dire !).

      Sur Archlinux, Perl n'a pas l'air très essentiel, j'ai fait un sudo pacman -R perl, et rien de bien méchant n'est sorti. Ceci dit, peut-être que les paquets dépendent des libs plutôt que de l'interpréteur directement (flemme de vérifier).

      Ah, tiens, le code de Slashdot (slashcode) est en Perl aussi. Mais, oui, c'est ancien.

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 7.

      Qui utilise encore Perl par choix et pour quoi, quel domaine ?

      L'un des grands usages de perl reste le code glue où il est en concurrence avec le shell. C'est un domaine où il excelle d'une part le pas entre les outils POSIX et lui est simple, mais la gestion des processus est aussi simple comme en shell. Ça en fait l'outil idéal quand tu veut faire du shell/grep/sed/awk/… mais en ayant tout dans un même langage et la possibilité d'utiliser des bibliothèques pour faire du réseau ou parser du json/yaml/etc.

      Pour faire la même chose python sera plus rébarbatif au profit d'une certaine lisibilité (pas de variables autodéclarées, pas d'identifiant de variable d'un seul caractère non alphanumérique, mais plus de construction comme re.search() qu'il faut importer pour utiliser une expression régulière, pas non plus de os.system subprocess pour lancer des commandes,…).

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Qui code en perl ?

        Posté par  . Évalué à 2.

        Pour faire ça avec python il y a les shells comme xonsh, pas performant du tout, ou ipython.

        • [^] # Re: Qui code en perl ?

          Posté par  . Évalué à 3.

          Ils ne sont pas dans l'installation de base des distributions. Ça n'aide pas à leur adoption.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Qui code en perl ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          ipython-likes and alikes aren't meant as shell…

          sinon, on a similairement à xonsh, psh…

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Qui code en perl ?

            Posté par  . Évalué à 2.

            mais encore ? ça sort de quelque part et j’ai pas la ref ?

            • [^] # Re: Qui code en perl ?

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              C'est dans leur tableau : https://xon.sh/contents.html#comparison
              Peut-être un lien avec ceci (dont commandes non disponible sans manips supplémentaires) https://ipython.readthedocs.io/en/stable/interactive/shell.html#overview ?
              Ou juste parce-que c'est surtout un environnement de débogage et de test avant tout https://www.ics.uci.edu/~dock/manuals/IPython/node7.html ?

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: Qui code en perl ?

                Posté par  . Évalué à 4.

                C'est dans leur tableau : https://xon.sh/contents.html#comparison

                Je comprends pas la moitié du tableau :

                • c'est quoi un langage pratique ?
                • native cross-plateform support → oui/non ? C'est le genre de question ou on donne la liste de ce qui est supportée
                • Typed variables → je connais pas plumbum, mais il y en a en bash et zsh
                • Syntax highlighting → ça existe en zsh, ce n'est pas en standard, mais c'est un paquet et une ligne de commande dans ma distribution (debian pas un truc très spécifique) et c'est de base dans mon ipython sans jupyter
                • Pun in name → fish ça en est pas un ?

                Le Easily scriptable n'a pas de sens pour ipython qui n'est pas un langage, son langage c'est python. Donc c'est peut être vrai (je ne sais pas quels sont les difficultés qui se passent quand on essaie d'utiliser ipython comme sheban), mais c'est un moyen assez facile de retirer une coche à une alternative.

                Du coup je vois pas quoi tirer de ce tableau.

                Ou juste parce-que c'est surtout un environnement de débogage et de test avant tout https://www.ics.uci.edu/~dock/manuals/IPython/node7.html ?

                On parle de ce qui est la base de jupyter. C'est bien plus qu'un environnement de debogage. C'est un shell python qui permet de se servir de python de manière interactive (chose que perl a mis du temps à avoir). Le fait qu'il puisse aider au debuggage (c'est ce qu'on doit comprendre de ton lien ?) n'indique pas du tout que c'est "surtout" à ça qu'il sert.

                Si on prend la plus vielle version de la page du projet qu'on peut trouver dans waybback machine : https://web.archive.org/web/20110721132832/https://ipython.org/

                The goal of IPython is to create a comprehensive environment for interactive and exploratory computing.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Qui code en perl ?

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  On fait son marketing comme on peut :-D Le tableau est pour donner envie aux gens qui ne connaissent pas bien/vraiment quelque autre alternative ou les gens qui sont déjà convaincus. Dès que tu maîtrises un peu une des alternative, t'as envie de jeter le tout pour cause de malhonnêteté (coloration syntaxique certes pas native mais existant pour zsh comme pour bash et d'autres, typage de variables et même richesse de l'historique —les critiques concernent le comportement par défaut, mais on peut faire la même chose excepté le diff— etc.)
                  Quoi tirer du tableau ? Je ne sais pas trop non plus et j'espère que la discussion va éclairer. (oui, j'ai juste lancé un pavé dans la marre.)

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: Qui code en perl ?

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  Pour la seconde partie, l'aspect débogage versus shell, il y a deux notions qui se chevauchent ici.

                  La première, c'est d'avoir un interpréteur interactif (comme les dinosaures l'ont connu avec les BASIC de leur micro 8-bits.) Pour un langage interprété, c'est juste un REPL et c'est ça que j'appelle de façon impropre « environnement de débogage » : il faut comprendre débogage comme « exploration » (surtout essais ou prototypage pas à pas…) ; et c'est un peu comme ça que je comprends aussi « a comprehensive environment for interactive and exploratory computing. »
                  PERL, comme d'autres, n'a jamais jugé utile d'intégrer cela dans son cœur (coucou PHP) ou de fournir une implémentation officielle (genre iperl) mais a laissé la communauté fournir plusieurs modules qui correspondent à autant de besoins et de visions qu'un seul truc central n'aurait pu combler (j'ai mentionné Perl::Shell et PerlConsole/console.pl mais il y aussi Reply et Devel::REPL/re.pl par exemple). Mais son mode débogage de base était assez puissant déjà :

                  perl -de1

                  La seconde notion (CLI) est toujours d'interpréter des commandes, mais cette fois-ci plus précisément de lancer les utilitaires/programmes (surtout en consoles/terminales pour simplifier) installés avec le système… d'exploitation. Ce programme fait aussi la police (s'assurer du respect des droits d'accès) et le chef d'orchestre (octroyer les entrées-sorties et faire les redirections.)
                  Et là, justement j'ai par exemple l'utilitaire ls pour lister le contenu du répertoire courant. Avec IPython, je dois littéralement écrire mon programme pour faire la même chose

                  from pathlib import Path

for child in Path('.').iterdir():
    if child.is_file():
        print(f"{child.name}:\n{child.read_text()}\n")

                  …par exemple, ou alors

                  import os

path = "."
obj = os.scandir()

print("Files and Directories in '% s':" % path)
for entry in obj:
    if entry.is_dir() or entry.is_file():
        print(entry.name)

                  …je ne peux pas juste appeler ma commande, même si dans le cas présent on peut se permettre de faire de manière crade :

                  import os

os.system('ls')

                  …mais en terme de nombre de lignes et caractères tapés ce n'est pas vraiment ça !

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                  • [^] # Re: Qui code en perl ?

                    Posté par  . Évalué à 3.

                    ipython est loin de ce que tu décris. Bon d'une part au cas où, ce n'est pas fourni par les mainteneurs de python. Cpython peut être lancé en repl. Ipython n'est d'ailleurs pas le seul interpréteur python interactif. L'alternative la plus connue est probablement bpython.

                    Je ne sais pas d'où vient la dichotomie que tu fais, mais elle oublie au moins un autre cas : utiliser un interpréteur interactif en tant que tel. C'est ce que tu fais avec R ou octave ou matlab (voir bc si on veut aller par là) par exemple. Aujourd'hui on les décris plus comme des notebook et ce n'est pas pour rien que jupyter a été fais par le même projet. Il ne s'agit pas d'un outil qui t'aide à écrire ton code, mais d'un environnement qui te permet de manipuler via le langage python tout ce que tu veux. Tout comme R tu peux envisager de t'en servir comme remplaçant d'un tableur par exemple.

                    Il n'a pas été conçu pour devenir un login shell personne ne dit le contraire même si pour simplifier la vie il a des raccourcis pour lancer des commandes avec un !. Il n'a pas était conçu pour être un debugger, mais quite à être un très bon interpréteur interactif autant simplifier la vie à ceux qui ont cet usage. Et si python n'est pas vraiment un excellent langage pour lancer et gérer des processus, il a pour lui un écosystème de bibliothèques assez dingue.

                    Et j'aime perl d'amour, mais comparer perl -de1 à ipython c'est vraiment très très différent.

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: Qui code en perl ?

                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                      Au temps pour moi si Ipython n'est écrit par les mainteneurs de Python, et tant mieux s'il existe d'autres alternatives aussi.

                      La dichotomie que je fais est exactement la même que tu décris.

                      c'est ça que j'appelle de façon impropre « environnement de débogage » : il faut comprendre débogage comme « exploration »

                      J'ai initialement employé le mot débogage parce-que je m'en sers pour explorer pas à pas des idées d'algorithme avant d'en faire un script, ou de tester des bibliothèques/extensions avant de les inclure dans un autre code, et surtout quand j'ai commencé ça m'aidait à comprendre d'autres codes (en redéroulant pas à pas et en examinant les effets de certaines fonctions/méthodes sur les variables en cours.)

                      ipython-likes and alikes aren't meant as shell…

                      Il n'a pas été conçu pour devenir un login shell personne ne dit le contraire

                      Voilà, c'était ça le propos : c'est un shell au sens d'outil d'exploration interactive du langage ; ce n'est pas un shell au sens de login shell (d'où ne pas mettre sur le plan Ipython et Xonsh)

                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                      • [^] # Re: Qui code en perl ?

                        Posté par  . Évalué à 4.

                        Comprends qu'en disant que c'est "surtout un environement de débogage et de test", que tu pointe partie de la documentation traitant le debuggage pas à pas, que tu le compare à perl -de1,… Tu insiste tout de même lourdement sur un aspect existant mais loin de décrire complètement l'outil. C'est presque comme présenter emacs en disant que c'est surtout un debugger lisp très pratique. C'est pas faux, mais on passe à côté de beaucoup en disant ça.

                        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 5.

      Le serveur d'Open Food Facts est en perl :-)
      https://github.com/openfoodfacts/openfoodfacts-server/

    • [^] # Re: Qui code en perl ?

      Posté par  . Évalué à 6. Dernière modification le 04 octobre 2022 à 17:27.

      Debian, avec ce sources.list:

      deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian-debug bullseye-debug main contrib non-free

deb http://dl.winehq.org/wine-builds/debian bullseye main

deb http://deb.debian.org/debian buster main 
deb http://deb.debian.org/debian bullseye-backports main

      Donne:

      • perl: installés: 17 non-installés: 4648
      • python: installés: 36 non-installés: 8172

      sur mon système.
      Côté debtags (implemented-in):

      • perl: 4728
      • python: 2097
      • TODO: 220 Bien sûr, je pense qu'il y a pas mal de choses non taguées, mais je donne les chiffres.

      Les trucs qui requièrent python installé, et qui sont gérés par ma distro:

      • hplip
      • linux-perf-5.10
      • samba-libs, dont je n'ai absolument pas l'utilité et qui est totalement optionnelle si on recompile les paquets (je l'avais fait, pour debian 10, faut que je refasse)

      Ceux qui ne sont pas gérés par ma distro, sont installés uniquement en dépendance de build pour certains projets.

      Côté perl:

      • perl-base, nécessaire à Debian
      • texlive-binaries
      • dpkg-dev
      • keyboard-configuration
      • mailcap, installé parce que mime-support en a besoin, lui-même requis par python2.7 :p (j'aime l'ironie)
      • git
      • i3-wm
      • i3blocks
      • qdirstat
      • apt-file
      • localepurge
      • autoconf, même si j'aimerai m'en passer, mais je dois le réinstaller trop souvent après, c'est chiant
      • google-perftools
      • linux-perf-5.10 (oui oui, ça dépend des deux)
      • pkg-config
      • dictionnaries-common (requis pour aspell et hunspell)

      Je laisse l'exercice de définir ce qui est vieux ou non au lecteur, et ce qui est a cause du fait que debian construise des paquets complets ou non.
      Ce qui est sûr, c'est que python est très, très peu utilisé sur mon système, alors que perl est une brique importante.

      Il faudrait faire une analyse plus poussée, typiquement, j'ai bien l'impression que python dépend énormément de trucs en python sur plusieurs niveaux, problème qui semble moins présent en perl, ce qui pourrait aider à expliquer pourquoi le nombre de paquets python est double, alors que le nombre de trucs "implemented-in" est lui la moitié (mais le fait que nombre de paquets ne soient pas tagués doit aussi bien aider).

      Côté vécu et expérience personnelle, je n'ai pas souvenir d'avoir un seul paquet aux dépendances mal foutues en perl, alors qu'en python, dire ça serait mentir, et pas qu'un peu. Je ne compte plus le nombre de fois ou j'ai du aller, pestant, lire un truc dans /usr/bin pour trouver quel foutu paquet pourrait bien manquer qui a fait planter un programme python en plein vol… Ce qui explique le faible nombre de trucs installés en python sur mon système: je préfère trouver des alternatives, c'est plus simple.

    • [^] # Re: Qui code en perl ?

      Posté par  (site web personnel) . Évalué à 3.

      En perl, mon client letsencrypt léger :
      https://git.rapsys.eu/acme/

      Un module perl et un binaire qui permet de générer la conf, un certificat et renouveler à j-30 automatiquement via une tâche planifiée.

      Perl c'est bien pour des outils système quand bash n'est plus suffisant.

      Je dois concéder que j'ai jamais réussi à accroché à Python et ai passé ce tournant…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.