← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/lazy_import.py

  • Committer: Martin Pool
  • Date: 2011-03-28 01:28:09 UTC
  • mto: (5425.4.19 220464-stale-locks)
  • mto: This revision was merged to the branch mainline in revision 5970.
  • Revision ID: mbp@canonical.com-20110328012809-frw003r09tcrxkiz
Represent lock held info as an object, not just a dict

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/lazy_import.py
1
 
# Copyright (C) 2006-2010 Canonical Ltd
 
1
# Copyright (C) 2006 Canonical Ltd
2
2
#
3
3
# This program is free software; you can redistribute it and/or modify
4
4
# it under the terms of the GNU General Public License as published by
19
19
This includes waiting to import a module until it is actually used.
20
20
 
21
21
Most commonly, the 'lazy_import' function is used to import other modules
22
 
in an on-demand fashion. Typically use looks like::
23
 
 
 
22
in an on-demand fashion. Typically use looks like:
24
23
    from bzrlib.lazy_import import lazy_import
25
24
    lazy_import(globals(), '''
26
25
    from bzrlib import (
31
30
    import bzrlib.branch
32
31
    ''')
33
32
 
34
 
Then 'errors, osutils, branch' and 'bzrlib' will exist as lazy-loaded
35
 
objects which will be replaced with a real object on first use.
 
33
    Then 'errors, osutils, branch' and 'bzrlib' will exist as lazy-loaded
 
34
    objects which will be replaced with a real object on first use.
36
35
 
37
 
In general, it is best to only load modules in this way. This is because
38
 
it isn't safe to pass these variables to other functions before they
39
 
have been replaced. This is especially true for constants, sometimes
40
 
true for classes or functions (when used as a factory, or you want
41
 
to inherit from them).
 
36
    In general, it is best to only load modules in this way. This is because
 
37
    it isn't safe to pass these variables to other functions before they
 
38
    have been replaced. This is especially true for constants, sometimes
 
39
    true for classes or functions (when used as a factory, or you want
 
40
    to inherit from them).
42
41
"""
43
42
 
44
43
 
161
160
            None, indicating the module is being imported.
162
161
        :param children: Children entries to be imported later.
163
162
            This should be a map of children specifications.
164
 
            ::
165
 
            
166
 
                {'foo':(['bzrlib', 'foo'], None,
167
 
                    {'bar':(['bzrlib', 'foo', 'bar'], None {})})
168
 
                }
169
 
 
170
 
        Examples::
171
 
 
 
163
            {'foo':(['bzrlib', 'foo'], None,
 
164
                {'bar':(['bzrlib', 'foo', 'bar'], None {})})
 
165
            }
 
166
        Examples:
172
167
            import foo => name='foo' module_path='foo',
173
168
                          member=None, children={}
174
169
            import foo.bar => name='foo' module_path='foo', member=None,
375
370
def lazy_import(scope, text, lazy_import_class=None):
376
371
    """Create lazy imports for all of the imports in text.
377
372
 
378
 
    This is typically used as something like::
379
 
 
380
 
        from bzrlib.lazy_import import lazy_import
381
 
        lazy_import(globals(), '''
382
 
        from bzrlib import (
383
 
            foo,
384
 
            bar,
385
 
            baz,
386
 
            )
387
 
        import bzrlib.branch
388
 
        import bzrlib.transport
389
 
        ''')
 
373
    This is typically used as something like:
 
374
    from bzrlib.lazy_import import lazy_import
 
375
    lazy_import(globals(), '''
 
376
    from bzrlib import (
 
377
        foo,
 
378
        bar,
 
379
        baz,
 
380
        )
 
381
    import bzrlib.branch
 
382
    import bzrlib.transport
 
383
    ''')
390
384
 
391
385
    Then 'foo, bar, baz' and 'bzrlib' will exist as lazy-loaded
392
386
    objects which will be replaced with a real object on first use.