• # des bouts de reponses

    Posté par  . Évalué à 1.

    j'ai pas la reponse pour tout, mais pour celle là :

    y a t-il une difference entre windows et linux en dev ?

    oui et non.

    oui quand tu va vouloir faire des fenetres, gerer la souris/clavier ou des acces à des fichiers c:\documents\utilisateurs\ sous windows, qui serait /home/utilisateurs/ sous linux.

    non quand tu vas developper juste pour un programme en ligne de commande.

    • [^] # Re: des bouts de reponses

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

      Et quelles sont ces différences ? Même en graphique, je vois pas trop ce que ça change.

      • [^] # Re: des bouts de reponses

        Posté par  . Évalué à 1.

        en graphique je ne sais pas trop, mais j'imagine qu'il y a surement des differences.

        et en acces aux fichiers, ben les chemins sous windows ressemblent à
        c:\documents\utilisateur\monfichier.txt
        alors que ce sera
        /home/utilisateur/monfichier.txt sous linux

        • [^] # Re: des bouts de reponses

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

          J'ai développé plusieurs applications graphiques avec PyQt et je n'ai pas remarqué de différence, le code est portable tel quel. Donc tu affirmes des choses sans savoir…

          Au niveau du chemin, qu'est-ce que ça change ? Dans les deux cas, tu demandes à l'utilisateur le chemin et tu le mets dans une variable. Pour récupérer des dossiers précis, il y a des fonctions prévues pour ça.

  • # Tonton python

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

    Fichier __init__:
    Ce fichier est présent dans tous les répertoires qui doivent être identifiés comme des modules python (je crois qu'on peut s'en passer dans les dernières versions de Python3).

    Imaginons tu aies un un module de dessin gfx.py ; avec le temps celui-ci grossit pas mal et tu veux le découper ; tu crées alors un répertoire gfx/ dans lequel tu mets un __init__.py, et les autres fonctionnalités découpées (circle.py, square.py …). Le code présent dans __init__.py sera exécuté dès lors que tu vas faire un import gfx
    Si tu veux accéder au code de dessin tu pourras faire (entre autres):

    from gfx import foo # ca c'est pour le code dans gfx/__init__.py

from gfx import square # ensuite tu pourra faire square.Square(...)

from gfx.square import Square # ensuite tu pourra faire Square(...)

    L’intérêt de mettre un from square import Square dans gfx/__init__.py c'est de pouvoir écrire directement :

    from gfx import Square

    L'idée étant de remonter les symboles les plus utiles par exemples, mais ce n'est pas du tout obligatoire.

    chaque developpement python , faut il créer un environnement virtuel ou c'est crée directement par python ?

    Je ne suis pas sûr de comprendre la question. De base Python va utiliser l'environnement de ton shell, et va alors chercher les libs installées par ta distro (ou 'pip' lancé sans virtualenv). Le problème c'est quand les libs fournies par ta distro n'ont pas la version que tu souhaites ; ou pire que tu veux faire cohabiter des softs utilisant des versions différentes des mêmes libs. Du coup ça dépend que ce que tu veux !
    Si tu veux utiliser/suivre les versions des libs de ta distro (pour être inclus un jour dedans par exemple), ben tu ne vas pas utiliser de virtualenv pour ton soft. Si tu t'en tapes et que tu veux des versions plus récentes, alors oui un virtualenv sera sûrement indiqué (histoire de ne pas foutre la grouille dans ton système). Et si tu distribues ton soft, donne au moins le moyen d'installer les bonnes versions des libs (fichier requirements.txt que tu peux donner directement à manger à pip).

    y a t-il une difference entre windows et linux en dev

    Il me semble que faire des virtualenv sous windows est encore un peu compliqué, mais que ça évolue dans le bon sens. Et sous windows il faudra un peu de taff pour avoir un shell/terminal de qualité ; de plus, en pratique un certain nombre de packages Python ne sont pas testés sous windows, ou ne marche pas du tout avec (mais ce n'est pas une majorité hein).

  • # Gestion de paquet

    Posté par  . Évalué à 1.

    __init__.py est un fichier qui défini des paquets python.

    Par exemple, si ta structure de répertoires ressemble à ça :

    $ tree
.
└── paquet
    └── fichier.py

1 directory, 1 file

    Et que tu lance python dans le répertoire ..

    $ python
Python 2.7.8 (default, Apr 15 2015, 09:26:43) 
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paquet.fichier
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named paquet.fichier

    Maintenant, si ta structure de répertoire ressemble à ça :

    $ tree
.
└── paquet
    ├── fichier.py
    └── __init__.py

    Tu peux faire :

    $ python
Python 2.7.8 (default, Apr 15 2015, 09:26:43) 
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paquet.fichier
>>> paquet.fichier
<module 'paquet.fichier' from 'paquet/fichier.py'>

    Le fichier __init__.py sera le racine de ton paquet. Par exemple :

    $ cat paquet/__init__.py
valeur = 1
$ python
Python 2.7.8 (default, Apr 15 2015, 09:26:43) 
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paquet
>>> paquet
<module 'paquet' from 'paquet/__init__.py'>
>>> paquet.valeur
1

    À la question « pourquoi avoir des import dans ce fichier? » En général c'est pour rendre disponible des fonction/classes qui sont enfoncées profondément dans ton paquet, et les rendre disponible à la racine.

    Comme ceci (NOQA est un commentaire très souvent utilisé pour éviter que pyflakes ne signale les import inutiles) :

    $ tree
.
└── paquet
    ├── fichier.py
    ├── __init__.py
    └── souspaquet
        ├── __init__.py
        └── sousfichier.py

2 directories, 6 files
$ cat paquet/__init__.py
from .souspaquet.sousfichier import fonction  # NOQA
$ cat paquet/souspaquet/sousfichier.py
def fonction(a, b):
    return (a * a) + (b * b)
$ pythona
Python 2.7.8 (default, Apr 15 2015, 09:26:43) 
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from paquet import fonction
>>> fonction(2, 3)
13

    Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

  • # précisions

    Posté par  . Évalué à 1.

    Bonjour , merci bcp pour vos retours , par contre je me sens encore novice .
    J'explique conceretement mon cas :
    J'ai mon code principale blabla.py dans un répértoire nommé code , blabla.py herite d'un "module"complement.py .. , pour moi un fichier.py dont on herite est un module (corrige moi si c'est faux )
    donc comment dois-je placer les .py et que dois-je mettre dans le init.py pour que ça marche et que dois-je mettre dans mon répértoire code  ?

    merci
    pythonement :)

    • [^] # Re: précisions

      Posté par  . Évalué à 2.

      donc comment dois-je placer les .py et que dois-je mettre dans le init.py pour que ça marche et que dois-je mettre dans mon répértoire code  ?

      peut-etre en regardant d'autres codes python ?
      c'est l'avantage de l'opensource, tu peux voir comment font les autres projets.

      sinon des reponses precedentes, il ressort que tu peux faire

      blabla.py
      complements.py

      dans le meme dossier,
      tant que complements n'est pas trop gros, trop decoupés.

      plus tard si complements.py devient trop complexe, tu voudras le decouper en morceau,
      tu feras alors un dossier complements
      qui contiendra les morceaux ET le init.py qui decrira ce qu'il y a dans le dossier

      permettant alors de faire un simple from complements import morceau1

      • [^] # Re: précisions

        Posté par  . Évalué à 2.

        from complements import morceau1

        Il faudrait penser à cesser cette façon d'importer vos fonctions/modules. Pensez que d'autres auront un jour à maintenir vos développements: Certes, écrire un truc du genre nom_paquet.fonction ou nom_paquet.Objet est un peu lourd mais on y gagne énormément en clarté lorsqu'on doit débugger/modifier un programme : on sait facilement ou chercher.

        • [^] # Re: précisions

          Posté par  . Évalué à 2.

          et du coup, dans notre exemple ici, ca donnerait quoi ?

          • [^] # Re: précisions

            Posté par  . Évalué à 3. Dernière modification le 08 juin 2015 à 11:23.

            Un truc du genre :

            import complements

            et a l'appel :

            complements.morceau()

  • # supposons que .

    Posté par  . Évalué à 1.

    supposons que les compléments ( compelement1.py , complément2.py ….) ne soient pas dans le meme dossier que mon code originale (blabla.py ) :
    dans : /home/code/ : j'ai blabla.py .
    dans /home/complementcode/ : j'ai les compléments.py (comlement1, complément2 …) .
    - Je met par exemple un fichier _init_.py dans le dossier complementcode dans lequel j'emporte tous les fichier complement1.py …
    from complementcode import complement1
    from complementcode import complement2

    et dans le dossier code j'ajoute un fichier _init_.py dans le quel je met :
    from /home/complementcode/ import /home/complementcode/  ??
    merci

    • [^] # Re: supposons que .

      Posté par  . Évalué à 2.

      je ne code pas en python, mais je dirais oui pour le "complement", ca devient un module, un package
      et non pour le code, c'est directement dans le code que tu va importer le complement

      suivi d'aller voir les examples de la documentation.

    • [^] # Re: supposons que .

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

      Si tu es un novice en programmation tout court, je te conseillerai dans un premier de ne pas chercher à découper ton code en plusieurs fichiers, et plutôt à comprendre les notions fondamentales (variables, types, structures de contrôle, classes, fonctions …), quitte à d'abord tout mettre dans un seul fichier. De toutes les façons tes premiers programmes seront très simples, et tu ne vas pas te lancer dans quelques chose de trop ambitieux sans avoir bien compris les bases.

      Mais bon revenons à ta question, qui nécessite quelques explications préliminaires:

      Lorsque tu fais import foo, 'foo' doit être :

      1. à l'endroit où sont présents les libs Python de ton système.
      2. dans le même module que ton fichier courant.

      Pour connaître les chemins où va chercher python tu peux faire dans une console python:

      import sys
sys.path

      En fait le problème du point 2, c'est qu'un de tes propres fichiers peut masquer un module standard (ex: tu crées un fichier 'math.py'). C'est pourquoi à partir de Python3, la façon 2 disparaît, et tu peux du coup faire :

      from math import cos # la c'est la lib standard
from .math import ta_fonction_a_toi # ton propre math.py

      Note que tu peux utiliser ce comportement en Python2 en mettant from __future__ import absolute_import au début de tes fichiers.

      Attention si tu veux utiliser des imports relatifs ('from .math import ') tu devras lancer ton script avec l'option '-m' (et sans le '.py') pour le considérer comme un module.

      Du coup pour ta question, et ben soit :

      • tu mets complement/ dans le même module.
      • tu le mets avec les libs installées classiquement (genre dans ton virtualenv histoire de pas péter ton système).
      • tu modifies l'environnement Python (ce que fait virtualenv au final), genre comme ça.

  • # recap

    Posté par  . Évalué à 1.

    si j'ai bien compris en tout cas :
    quand je crée un module et que je peux l'importer dans mon fichier courant qui contient mon code .py de base , le module doit :
    être soit dans le dossier relatif a lib dans l'install python .
    soit je peut mettre mon module dans le meme dossier que celui de mon code de base tout en ajoutant un fichier init.py qui indique le chemin vers ce module depuis l'arborscence .
    exemple
    dans home/code : j'ai code.py
    je veux ajouter un module noté complément.py , donc je fais import complément dans code.py
    puis dans le fichier init je met : from code import complément .
    est ce exacte ..??

    • [^] # Re: recap

      Posté par  . Évalué à 3.

      je veux ajouter un module noté complément.py , donc je fais import complément dans code.py
      puis dans le fichier init je met : from code import complément .
      est ce exacte ..??

      pourquoi veux-tu importer 2x ton complement ?

      Relis bien chacune de nos reponses, va eventuellement lire le manuel de python qui t'en dira plus sur l'art et la maniere de coder en python.

      tu as bien compris que le init.py devait son existence uniquement quand le "module" est un dossier contenant plusieurs complements ?

      donc aujourd"hui avec juste
      code.py
      complement.py

      tu n'as pas besoin de init.py
      tu fais juste from complement import foo dans ton code.py

  • # foo

    Posté par  . Évalué à 1.

    foo c'est quoi ça ? un module spécifique ??
    merci pour ta dernière réponse

    • [^] # Re: foo

      Posté par  . Évalué à 2.

      un truc par defaut, pour dire d'importer tout le module.

      mais qui visiblement peut etre simplifier en
      import complements
      ou
      complements.morceau1()

Suivre le flux des commentaires

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