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 :

Organisation package - Problème avec imports [Python 3.X]


Sujet :

Python

  1. #1
    Membre éprouvé

    Homme Profil pro
    Ingénieur
    Inscrit en
    Août 2010
    Messages
    654
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Août 2010
    Messages : 654
    Points : 1 150
    Points
    1 150
    Par défaut Organisation package - Problème avec imports
    Salut,

    Je souhaite faire un package. N'ayant pas de notions d'architecture logiciel, j'ai jeté un oeil à ce guide et à différentes sources pour l'inspiration. Pour faire court j'ai en tête cette organisation:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    core/
        __init__.py
        solver.py
        solvers/
            __init__.py
            solverbase.py
            solver1.py
    L'idée ici est de pouvoir ajouter différents solvers lorsque le projet évoluera. solver.py suit le design pattern "strategy" qui permet de créer à la volée l'un ou l'autre solver tout en conservant une syntaxe commune. Peut-être fais-je fausse route, n'hésitez pas à pointer un problème.
    Je galère avec les imports relatifs. Il y a quelque chose qui m'échappe.

    solver.py
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    from solvers import *
     
    class Solver(object):
        def __init__(self):
            self.SolverStrat = solver1.Solver1
     
    obj = Solver()
    __init__.py (dans le dossier solvers)
    solverbase.py
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    class SolverBase(object):
        def __init__(self):
            print('Init ok')
    solver1.py
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    from .solverbase import SolverBase
     
    class Solver1(SolverBase):
     
        def __init__(self):
            SolverBase.__init__(self)
    Je m'attends à voir s'afficher 'Init ok' car à l'instanciation de l'objet Solver j'instancie en fait Solver1 qui lui même hérite de SolverBase. Sauf qu'il ne se passe rien. Si je print obj j'ai droit à une info sur l'objet en lui-même:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    >>> __main__.Solver object at 0x00000000074F0F0
    J'en déduit que l'instanciation n'a pas eu lieu. Mais pourquoi?

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    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 235
    Points : 36 684
    Points
    36 684
    Par défaut
    Salut,

    Citation Envoyé par Julien N Voir le message
    "strategy" qui permet de créer à la volée l'un ou l'autre solver tout en conservant une syntaxe commune. Peut-être fais-je fausse route, n'hésitez pas à pointer un problème.
    Je galère avec les imports relatifs. Il y a quelque chose qui m'échappe.
    Il manque des () dans l'appel à solver1.Solver1
    solver.py
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    from solvers import *
     
    class Solver(object):
        def __init__(self):
            self.SolverStrat = solver1.Solver1
     
    obj = Solver()
    pour le reste, c'est galère de distribuer une construction dans 4 modules "à priori".
    C'est plus simple de commencer par tout placer dans un module (quite à utiliser des classes emboîtées pour garder l'impression du nom de module) puis une fois que c'est stable, c'est plus facile à "distribuer".

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

  3. #3
    Membre éprouvé

    Homme Profil pro
    Ingénieur
    Inscrit en
    Août 2010
    Messages
    654
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Août 2010
    Messages : 654
    Points : 1 150
    Points
    1 150
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Il manque des () dans l'appel à solver1.Solver1
    Oook. J'étais tellement en train de réfléchir à l'architecture et à comment gérer les imports que je suis passé à côté de ça... Effectivement si demande pas l'instanciation explicitement ça marche moins bien.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    class Solver(object):
        def __init__(self):
            SolverStrat = solver1.Solver1
            self.solver = SolverStrat()
    Citation Envoyé par wiztricks Voir le message
    Pour le reste, c'est galère de distribuer une construction dans 4 modules "à priori"
    Est-ce que cela veut dire que ce n'est pas recommandé, voir déconseillé, ou est-ce juste une complication excessive? Dans la version actuelle du programme je n'ai qu'un fichier solver.py avec les différentes classes dedans. Mais différents solvers seront amenés à être créé. Et le module fait déjà pas mal de lignes d'où mon envie de découper cela.

    La structure du module est plus complexe que l'exemple que j'ai fourni bien entendu, mais sur le même moule:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    core/
        __init__.py
        solvers/
            __init__.py
            solverbase.py
            solver1.py
            solver2.py
        observers/
            __init__.py
            observerbase.py
            observer1.py
            observer2.py
        solver.py
        observer.py
        logic.py
    Toute autre architecture me conviendrait pourvu qu'elle puisse me permettre assez simplement d'ajouter des "briques" par la suite.

    J

  4. #4
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    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 235
    Points : 36 684
    Points
    36 684
    Par défaut
    Citation Envoyé par Julien N Voir le message
    Est-ce que cela veut dire que ce n'est pas recommandé, voir déconseillé, ou est-ce juste une complication excessive? Dans la version actuelle du programme je n'ai qu'un fichier solver.py avec les différentes classes dedans. Mais différents solvers seront amenés à être créé. Et le module fait déjà pas mal de lignes d'où mon envie de découper cela.
    C'est un constat par rapport à mon expérience personnelle.
    Le fait est que la structure va s'imposer dans le code. Donc si on décide d'un découpage à priori et qu'on n'a pas la chance d'avoir choisi le bon, on risque de se fatiguer à traîner un boulet lorsqu'on va généraliser.
    note: personnellement, j'évite de trop découper avant d'être clair sur le plan de tests.

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

  5. #5
    Membre éprouvé

    Homme Profil pro
    Ingénieur
    Inscrit en
    Août 2010
    Messages
    654
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Août 2010
    Messages : 654
    Points : 1 150
    Points
    1 150
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Le fait est que la structure va s'imposer dans le code.
    C'est bien là tout mon problème. Je n'arrive jamais à avoir les idées claires sur la structure. Par manque de culture, de connaissances et d'expérience sans aucun doute. Merci pour les conseils.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Chrome] problème avec import CSS
    Par rberthou dans le forum Mise en page CSS
    Réponses: 1
    Dernier message: 05/09/2009, 13h47
  2. python26 : problème avec import py2exe
    Par yoshik dans le forum Py2exe
    Réponses: 6
    Dernier message: 20/06/2009, 13h57
  3. [10.1.0.2.0] Problème avec importation datapump
    Par CyBeRoN dans le forum Administration
    Réponses: 7
    Dernier message: 13/02/2008, 12h11
  4. problème avec importation d'un fichier.class
    Par M.a.n.u. dans le forum NetBeans
    Réponses: 4
    Dernier message: 10/10/2007, 10h23
  5. Problème avec Imports
    Par alicia26 dans le forum ASP.NET
    Réponses: 3
    Dernier message: 21/05/2007, 17h50

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