Discussion :

[clavier12AZQSWX]

bonjour,


Vaut-il mieux d�clarer un import (import string par exemple) tout le temps tout en haut du fichier .py ou bien quand on en a juste besoin (par exemple dans une fonction ou dans une boucle if )

qu'en pensez-vous ?

y-a-t-il des coups suppl�mentaires � cela ?

[PauseKawa]

Bonjour,

ben... Si vous en avais besoin autant l'importer. Non ?
Le co�t ? La lecture d'un fichier. Suivant le module cela pourrais �tre lourd.
Une contre-indication ?, La port�e

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
class Foo:
     def __init__(self):
        import os
        print(locals())
 
f = Foo()
print(globals(), locals())

Une indication ? La compatibilit� du code ?

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
class ScreenCap(object):
    def __init__(self):
        """Screenshot class"""
        if sys.platform == 'linux2':
            self.grab = self._GarbLinux
        elif sys.platform == 'win32':
            import Image, ImageGrab
            self.grab = self._GrabWin
        elif sys.platform == 'darwin':
            self.grab = self._GrabMac
        else:
            sys.exit(1)
        self._currentf = None
 
    def _FicNormalyze(self, name):
        """Internal Function for generate temp file.
           Use home user directory for rights.
        """
        if name:
            if os.path.basename(name) == name:
                _grabfile = os.path.join(os.path.expanduser('~'), name)
            else:
                _grabfile = name
        else:
            # default name
            _grabfile = os.path.join(os.path.expanduser('~'), 'scrcap.jpg')
        self._currentf = _grabfile
        return _grabfile
 
    def _GarbLinux(self, name=None):
        """Internal function for screen capture under Linux
           Use ImageMagick import utility
        """
        _grabfile = self._FicNormalyze(name)
        _grabcommand = "import -silent -window root " + _grabfile
        os.system(_grabcommand)
        return _grabfile
 
    def _GrabWin(self, name=None):
        """Internal function for screen capture under Windows.
           Use PIL ImageGrab.
        """
        try:
            import ImageGrab
        except:
            # Experimental import for PIL under Python 3.
            from PIL import ImageGrab
        _grabfile = self._FicNormalyze(name)
        ImageGrab.grab().save(_grabfile, "JPEG")
        return _grabfile
 
    def _GrabMac(self, name=None):
        """Internal function for screen capture under Mac.
           Use screencapture command.
        """
        _grabfile = self._FicNormalyze(name)
        _grabcommand = "screencapture -m -x -t jpg " + _grabfile
        os.system(_grabcommand)
        return _grabfile
...

@+

Note pour ce qui est de l'import dans une fonction: Les variables locales sont mises en place lors de l'interpr�tation du code.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
>>> def foo():
...     from os import *
... 
<stdin>:1: SyntaxWarning: import * only allowed at module level

The from form with * may only occur in a module scope. If the wild card form of import � import * � is used in a function and the function contains or is a nested block with free variables, the compiler will raise a SyntaxError.

Il est assez rare que des 'protections' soit mise en place pour le souligner

[rambc]

Bonjour.

Il me semble qu'il vaut mieux toujours indiquer les imports en d�but de script. C'est pour moi une bonne pratique � suivre � la lettre.

[wiztricks]

Salut,

Il me semble qu'il vaut mieux toujours indiquer les imports en d�but de script. C'est pour moi une bonne pratique � suivre � la lettre.

Par d�faut, c'est pr�f�rable.

N'emp�che qu'au plus le programme est gros au plus il contiendra de fonctions utilis�es dans des cas assez particuliers qui pourront se retrouver en tas dans un script.

Mettre les import dans le "block" permet de documenter ces codes et de faciliter leur r�organisation.

C�t� maintenabilit� et optimisation la question peut se poser, mais les r�ponses sont toujours discutables car le "contexte" n'est jamais "clair".

- W

[fred1599]

La r�ponse est dans la PEP 8

Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

[wiztricks]

La r�ponse est dans la PEP 8

PEP 8 d�finit des recommandations applicables aux modules de la "Python Standard Library" et aux codes de l'interpr�teur Python.
Les autres programmeurs Python peuvent l'utiliser pour "standardiser" leurs codes ou s'appliquer � suivre d'autres "standards".

note: l'int�r�t de ce type de "standard" est comme celui d'une FAQ, avoir des r�ponses "good enough" applicables � des questions de bases �vitant de refaire des r�unions/discussions sans fin � chaque fois.

Ceci dit, des recommandations n'ont pas force de "lois".
Et des dimensions optimisation et maintenabilit� peuvent donner lieu � ne pas appliquer une recommandation de fa�on b�te. Ce qui suppose pouvoir motiver le "pourquoi" proc�der diff�remment dans certains cas.

- W

[fred1599]

On a toujours la libert� de coder comme on le souhaite sous certaines r�serves �videmment, mais il me semblait clair de l'indiquer car le mot cl� always est dans cette phrase plut�t affirmative.

Personnellement il est tr�s rare de se "prendre la t�te" sur le fait d'importer un module � un endroit sp�cifique, l'optimisation d'un code ne se faisant pas � cet endroit.

[rambc]

N'emp�che qu'au plus le programme est gros au plus il contiendra de fonctions utilis�es dans des cas assez particuliers qui pourront se retrouver en tas dans un script.

Dans ce cas, j'aurais tendance � casser le script en plusieurs morceaux, cela me parait bien plus efficace c�t� maintenance : un script --> "une" fonctionnalit� --> une liste de modules � importer.

[wiztricks]

Salut,

On a toujours la libert� de coder comme on le souhaite sous certaines r�serves �videmment, mais il me semblait clair de l'indiquer car le mot cl� always est dans cette phrase plut�t affirmative.

"always" s'applique aux codeurs/mainteneurs des modules de la PSL. Etes vous l'un d'entre-eux?
Plus g�n�ralement, s'il fallait s'"interdire" de pourquoi laisser le langage permettre de... et dans quels cas utiliser cette fonctionnalit�s?

Personnellement il est tr�s rare de se "prendre la t�te" sur le fait d'importer un module � un endroit sp�cifque, l'optimisation d'un code ne se faisant pas � cet endroit.

Allez lire ce code ou la discussion sur les lazy import dans le wiki Python.

Dans certains cas, il faut se poser des questions et baliser le chemin qui permettra de construire les r�ponses.
- W

[fred1599]

@Wiztricks

Le code donn� en exemple respecte tout � fait la PEP 8, ou j'ai mal vu?

Les exemples concernant les lazy imports, justifie clairement une p�nalit� du temps d'ex�cution en cas de non respect de la PEP 8, il me semble, non?

En fait quelle serait la bonne raison d'importer un module en dehors du d�but d'un fichier?

[wiztricks]

Le code donn� en exemple respecte tout � fait la PEP 8, ou j'ai mal vu?

Il effectue des "import" � l'int�rieur de blocs et non en t�te de...
De plus, il "fake" les "import" des sous-modules i.e. l'appelant fait ce qu'il veut, le code r�-organise tout ��.

Les exemples concernant les lazy imports, justifie clairement une p�nalit� du temps d'ex�cution en cas de non respect de la PEP 8, il me semble, non?

Il montre surtout comment faire pour ne pas �tre p�nalis�.

En fait quelle serait la bonne raison d'importer un module en dehors du d�but d'un fichier?

L'exemple donn� par PauseKawa qui est une sorte de pattern Strategy et les deux que je vous ai propos� sont de "bonnes" raisons.
- W

[fred1599]

Bon eh bien je vais relire tout �a tranquillement, merci

[clavier12AZQSWX]

par exemple dans une cas de mon exp�rience.

je devais cr�er un script qui r�alise une op�ration suivant plusieurs process diff�rent (un import via tel webservice, un autre via tel autre, encore un autre d'une marque diff�rent...etc)

bref, j'avais le choix entre faire �a :

import ws_sony
import ws_amstrad
import ws_gloria

(...)

et ensuite dans le code, j'avais des choses comme �a

if process_import==CS_sony: ...
if process_import==CS_amstrad: ...
if process_import==CS_gloria: ...

du coup je me suis dit qu'il vallait mieux importer les modules d�di�s en fonction des circonstances plut�t que tout plaquer en haut du fichier

du coup au final, j'avais :
if process_import==CS_sony:
import import ws_sony ...
if process_import==CS_amstrad: ...
import ws_amstrad....
if process_import==CS_gloria: ...
import ws_gloria...


Au d�part je mettais toujours mes import en haut mais j'ai vu quelqu'un le faire (souvant des import datetime, ou strnig) les appeler � la vol�e et �a m'a semblait logique "pourquoi charger un module qu'on utilise pas partout"

Et d�j� en php, on (enfin moi) fait cela gr�ce � l'utilisation de include au lieu de require et mettre grace au chargement des modules � la vol�e de apache (plut�t que tout charger dans le .ini de php)

bref, ce qui est bon en php et apache, est peut-�tre bon aussi en python ! En tout cas �a marche (ne produit pas d'erreur d'ex�cution, ni de compilation avec py2exe)

La question est le co�t (en terme de rapidit� d'ex�cution, non pas en binaire compil� �a en ss'en fiche un peu)

[rambc]

Pour ma part, je ferais un mini-script appelant un script suivant la fonctionnalit� souhait�e sony, amstrad,...

Ensuite en cr�ant un script autonome pour sony, un autre amstrad,... on a aussi un moyen simple de d�bugguer les diff�rents types d'appel.

[wiztricks]

Salut,

A priori, la question n'est pas sur "import" mais plut�t sur des patterns de type Template et Strategy (comme illustr� par PauseKawa) et leur d�clinaison en Python (qui in fine se traduira par des "import")

Imaginez que vous ayez � r�aliser une gestion de verrouillage de fichiers soit multiOS. Vous allez d�finir une class disons "Locker" qui a deux m�thodes acquire et release.
La r�alisation de ces op�rations se traduira par des appels � des fonctions dont la r�alisation sera sp�cifique � chaque os nommons les lock et unlock.
Nous avons donc un module qui contient:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
import os
class Locker:
    def acquire(self, timeout=None):
         ...
         os.lock(...)
         ...
    def release(self)
         ...
         os.unlock()
         ...

Et le module os qui lorsqu'il est charg� d�finira les fonctions lock et unlock "adapt�es" aux attentes de Locker en fonction de ce que l'OS veut bien
faire. Ca peut �tre "compliqu�" genre:

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
16
17
18
def w32_lockers():
    from msvcrt import locking, LK_NBLCK, LK_UNLCK, LK_LOCK
 
    def lock(fd, nbytes, blocking):
        if blocking:
            while True:
                try:
                    locking(fd,  LK_LOCK, nbytes)
                except IOError:
                    e = sys.exc_info()[1]
                    if e.errno not in LOCKING_ERRORS:
                        raise
                else: return
        locking(fd,  LK_NBLCK, nbytes)
 
    def unlock(fd, nbytes):
        locking(fd,  LK_UNLCK, nbytes)
    return lock, unlock

Le but �tant d'avoir construit, dans le module os, en face des attributs 'lock' et 'unlock' attendu par "Lockers" la fonction qui va bien.

L'avantage est qu'il n'y a plus de d�pendance avec l'OS dans le module appelant (et donc plus de "if platform == ...")
Et qu'on peut tester et construire les m�thodes d�pendantes de l'OS ind�pendamment.

Dans votre cas la construction du sp�cifique semble fonction du choix de l'appelant, i.e. import du module "strategy" ne suffira pas, il faudra appeler une fonction ou construire l'instance d'une classe avec en param�tre "sony", "amstrad", ou "gloria".

- W