Forum Programmation.python python et connections

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
17
avr.
2020

bonjour,
j'apprend lentement python et je vois qu'il gère des connections.
jai fait un petit script qui permet de copier des fichiers localement, qui fonctionne comme je le souhaite, mais je voudrais l'utiliser pour copier des fichiers sur un répertoire distant.
naïvement, je pensais qu'avec un module adapté je pourrais simplement remplacer ma variable de "path" local par une variable de "path" distant avec une fonction importée d'un module qui gère ssh si cest ssh, samba si cest samba, http si c'est http, ftp si c'est ftp, etc.
en lisant les documentations des modules sensés gérer les connections, il y a des problemes de versions de partout, il n'y a rien de simples et des parametres en pagaille, la documentation et les explications sont ambigües et ne remplacent évidemment pas un cours exhaustif d'informatique sur les
le repertoire distant utilise samba (support usb sur livebox). le module smb pour python me parait un peu opaque et ne sais pas bien comment l'utiliser. j'ai vu que dans samba 4, python semblait pris en charge en natif, mais je ne suis pas sur que la livebox ait un moyen simple de mettre à jour samba 4 réseaux et toutes ses subtilités.

dans la documentation libre que j'utilise pour apprendre python, il y est question du module socket (parametrage rudimentaire du client et serveur) et d'outils pour créer un serveur web. mais je n'ai pas vu de partie sur la façon d'utiliser les protocoles ci-dessus. D'où 3 questions:
1. Une suggestion de documentation simple, claire, didactique?
2.quand on travaille sous linux est-il plus pertinent d'avoir recours à os, sys, subprocess et lancer des popen(),system(),subprocess() avec les programmes linux adhoc?
3.plus compliqué: si on veut utiliser du python sur une application qui fonctionne sur des smartphones par exemples, est ce que les modules os,sys,subprocess fonctionnent ?

  • # base de la programmation

    Posté par  . Évalué à 3. Dernière modification le 17/04/20 à 18:27.

    D'où 3 questions:
    2.quand on travaille sous linux est-il plus pertinent d'avoir recours à os, sys, subprocess et lancer des popen(),system(),subprocess() avec les programmes linux adhoc?

    ca peut simplifier le boulot dans un premier temps
    car tu fais faire via le système, ce que tu souhaites faire à la fin en python

    3.plus compliqué: si on veut utiliser du python sur une application qui fonctionne sur des smartphones par exemples, est ce que les modules os,sys,subprocess fonctionnent ?

    justement, comment avec la méthode 2°) tu vas devoir gérer des OS/SYS/SUBPROCESS différents selon que tu es sous linux, windows, osx, android, iOS

    1. Une suggestion de documentation simple, claire, didactique?

    regarder ce que l'on appelle les LIBs de développement,
    ca doit te permettre d'appeler des bouts de codes que d'autres ont deja écrits pour te simplifier la tache et rester en Python partout dans ton programme,
    c'est alors la LIB qui détecte l'OS utilisé, et fera les bons appels pour toi, le cas échéant avec des OS/SYS/SUBPROCESS

  • # Éléments de réponse

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

    Le module socket de la bibliothèque standard de Python permet l'utilisation bas niveau des sockets réseau de ton OS (c'est globalement la même chose que ce qu'il y a dans la lib standard du C). Ça te permettrait dans l'absolu, et avec beaucoup de temps, d'implémenter tous les protocoles dont tu as besoin. Mais ce n'est probablement pas ce que tu veux.

    Si tu veux juste pouvoir télécharger des fichiers en 3 lignes de code, c'est ailleurs qu'il faut regarder (en gros des gens qui ont déjà fait le travail décrit ci-dessus). Pour HTTP, tu as dans les modules standard de python urllib.request, mais la très bonne bibliothèque externe requests lui est nettement supérieure. Si tu veux une seule bibliothèque qui s'occupe de tout un tas de protocoles, peut-être que pycurl te conviendra plus.

Suivre le flux des commentaires

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