[Python-3000] Should package __init__ files include pkgutil.extend_path?

[Nick Coghlan]

Brett Cannon wrote:
> On Sat, Sep 6, 2008 at 2:06 PM,  <skip at pobox.com> wrote:
>> I'm trying to figure out how to install this dbm.sqlite module I have
>> without overwriting the basic install.  My thought was to create a dbm
>> package in site-packages then copy sqlite.py there.  That doesn't work
>> though.  Modifying dbm.__init__.py to include this does:
>>
>>    import pkgutil
>>    __path__ = pkgutil.extend_path(__path__, __name__)
>>
>> I'm wondering if all the core packages in 3.x should include the above in
>> their __init__.py files.
>>
> 
> Well, a side-effect of this is that all package imports will suddenly
> spike the number of stat calls linearly to the number of entries on
> sys.path.
> 
> Another option is to use a pth file that imports your module (as like
> _dbm_sqlite.py or something) and have it, as a side-effect of
> importing, set itself on dbm.

It would probably be cleaner to add "extend_path" functions to the
extensible core packages rather than have them automatically extend
their path list on startup.

E.g. dbm.__init__.py may have something like the following:

def extend_package(dirs=None):
  global __path__
  if dirs is None:
    import pkgutil
    if __package_name__ is not None:
      name = __package_name__
    else:
      name = __name__
    __path__ = pkgutil.extend_path(__path__, name)
  else:
    __path__.extend(dirs)

So the standard library packages would be self-contained by default, but
an application could explicitly request that the extensible packages be
expanded to incorporate other directories.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
            http://www.boredomandlaziness.org