[Python-checkins] python/nondist/peps pep-0302.txt,1.9,1.10

jvr@users.sourceforge.net jvr@users.sourceforge.net
Mon, 30 Dec 2002 13:24:00 -0800


Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv15036

Modified Files:
	pep-0302.txt 
Log Message:
- renamed __import__ to __loader__
- changed the get_data() definition


Index: pep-0302.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0302.txt,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** pep-0302.txt	28 Dec 2002 10:16:07 -0000	1.9
--- pep-0302.txt	30 Dec 2002 21:23:57 -0000	1.10
***************
*** 261,265 ****
        significance to the importer (more on this later).
  
!     - It should add an __importer__ attribute to the module, set to the
        loader object.  This is mostly for introspection, but can be used
        for importer-specific extras, for example getting data associated
--- 261,265 ----
        significance to the importer (more on this later).
  
!     - It should add an __loader__ attribute to the module, set to the
        loader object.  This is mostly for introspection, but can be used
        for importer-specific extras, for example getting data associated
***************
*** 277,281 ****
              sys.modules[fullname] = mod
              mod.__file__ = "<%s>" % self.__class__.__name__
!             mod.__importer__ = self
              if ispkg:
                  mod.__path__ = []
--- 277,281 ----
              sys.modules[fullname] = mod
              mod.__file__ = "<%s>" % self.__class__.__name__
!             mod.__loader__ = self
              if ispkg:
                  mod.__path__ = []
***************
*** 353,375 ****
      storage backend, loader objects may supply a method named get_data:
  
!         loader.get_data(name)
  
      This method returns the data as a string, or raise IOError if the
!     "file" wasn't found.  The 'name' argument should be seen as a
!     'cookie', meaning the protocol doesn't prescribe any semantics for
!     it.  However, for importer objects that have some file system-like
!     properties (for example zipimporter) it is recommended to use os.sep
!     as a separator character to specify a (possibly virtual) directory
!     hierarchy.  For example if the importer allows access to a module's
!     source code via i.get_data(name), the 'name' argument should be
!     constructed like this:
! 
!         name = mod.__name__.replace(".", os.sep) + ".py"
! 
!     Note that this is not the recommended way to retrieve source code,
!     the (also optional) method loader.get_source(fullname) is more
!     general, as it doesn't imply *any* file-system-like characteristics.
!     This leads us to the next extension.
  
      The following set of methods may be implemented if support for (for
      example) Freeze-like tools is desirable.  It consists of three
--- 353,367 ----
      storage backend, loader objects may supply a method named get_data:
  
!         loader.get_data(path)
  
      This method returns the data as a string, or raise IOError if the
!     "file" wasn't found.  It is meant for importers that have some
!     file-system-like properties.  The 'path' argument is a path that can
!     be constructed by munging module.__file__ (or pkg.__path__ items)
!     with the os.path.* functions, for example:
  
+         d = os.path.dirname(__file__)
+         data = __loader__.get_data(os.path.join(d, "mydata.txt"))
+     
      The following set of methods may be implemented if support for (for
      example) Freeze-like tools is desirable.  It consists of three
***************
*** 475,486 ****
        provides a method get_data(name) which returns the content of the
        "file" called name, as a string.  To allow modules to get at the
!       importer object, zipimport also adds an attribute "__importer__"
        to the module, containing the zipimport object used to load the
        module.  If such an approach is used, it is important that client
        code takes care not to break if the get_data method (or the
!       __importer__ attribute) is not available, so it is not clear that
        this approach offers a general answer to the problem.
  
!     Requiring loaders to set the module's __importer__ attribute means
      that the loader will not get thrown away once the load is complete.
      This increases memory usage, and stops loaders from being
--- 467,478 ----
        provides a method get_data(name) which returns the content of the
        "file" called name, as a string.  To allow modules to get at the
!       importer object, zipimport also adds an attribute "__loader__"
        to the module, containing the zipimport object used to load the
        module.  If such an approach is used, it is important that client
        code takes care not to break if the get_data method (or the
!       __loader__ attribute) is not available, so it is not clear that
        this approach offers a general answer to the problem.
  
!     Requiring loaders to set the module's __loader__ attribute means
      that the loader will not get thrown away once the load is complete.
      This increases memory usage, and stops loaders from being
***************
*** 488,492 ****
      required to offer any useful functionality (any such functionality,
      such as the zipimport get_data() method mentioned above, is
!     optional) it is not clear that the __importer__ attribute will be
      helpful, in practice.
  
--- 480,484 ----
      required to offer any useful functionality (any such functionality,
      such as the zipimport get_data() method mentioned above, is
!     optional) it is not clear that the __loader__ attribute will be
      helpful, in practice.