Import mechanism to support multiple Python versions

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Nicolas Fleury

    #1

    Import mechanism to support multiple Python versions

    Hi,
    I'm trying to support two Python versions at the same time and I'm
    trying to find effective mechanisms to support modules compiled in C++
    transparently.

    All my code in under a single package. Is it possible to override the
    import mechanism only for modules under that package and sub-packages so
    that?:

    import cppmymodule

    would be equivalent to:

    if sys.version == "2.4":
    import cppmymodule24 as cppmymodule
    elif sys.version == "2.3":
    import cppmymodule23 as cppmymodule

    for all modules under the package and all modules with names beginning
    with cpp (or another way to identify them).


    I have also third party packages. Is it possible to make a package
    point to another folder? For example:

    psyco23/...
    psyco24/...
    psyco/__init__.py => points to psyco23 or psyco24 depending on Python
    version used.

    Note that I cannot use .pth files or symbolic links, since I would want
    the exact same code hierarchy to work with both Python 2.3 and 2.4.

    Any help appreciated.
    Thx and regards,
    Nicolas
  • Thomas Heller

    #2
    Re: Import mechanism to support multiple Python versions

    Nicolas Fleury <nid_oizo@yahoo .com_remove_the _> writes:
    [color=blue]
    > I have also third party packages. Is it possible to make a package
    > point to another folder? For example:
    >
    > psyco23/...
    > psyco24/...
    > psyco/__init__.py => points to psyco23 or psyco24 depending on Python
    > version used.[/color]

    You may manipulate the package path in the __init__.py file.
    pkgutil may also be useful.

    Thomas

    Comment

    • Nicolas Fleury

      #3
      Re: Import mechanism to support multiple Python versions

      Nicolas Fleury wrote:[color=blue]
      > import cppmymodule
      >
      > would be equivalent to:
      >
      > if sys.version == "2.4":
      > import cppmymodule24 as cppmymodule
      > elif sys.version == "2.3":
      > import cppmymodule23 as cppmymodule
      >
      > for all modules under the package and all modules with names beginning
      > with cpp (or another way to identify them).[/color]

      Since all my imports are absolute, my code looks more like:

      import root.subpackage .cppmymodule

      So I guess, I can add this in root/__init__.py and everything would be fine:

      def myimport(name, globals=None, locals=None, fromlist=None,
      __import__=__im port__):
      names = name.split('.')
      if names[0] == 'root' and names[-1][0:3] == 'cpp':
      name += '%s%s' % sys.version_inf o[0:2]
      return __import__(name , globals, locals, fromlist)

      __builtins__['__import__'] = myimport

      It seems to work, is that right?

      Thx and regards,
      Nicolas

      Comment

      • Serge Orlov

        #4
        Re: Import mechanism to support multiple Python versions

        Nicolas Fleury wrote:[color=blue]
        > Hi,
        > I'm trying to support two Python versions at the same time and I'm
        > trying to find effective mechanisms to support modules compiled in
        > C++ transparently.
        >
        > All my code in under a single package. Is it possible to override
        > the import mechanism only for modules under that package and
        > sub-packages so that?:
        >
        > import cppmymodule
        >
        > would be equivalent to:
        >
        > if sys.version == "2.4":
        > import cppmymodule24 as cppmymodule
        > elif sys.version == "2.3":
        > import cppmymodule23 as cppmymodule
        >
        > for all modules under the package and all modules with names
        > beginning with cpp (or another way to identify them).[/color]

        I used the following approach application-wide:
        ===== The very start of main file ===
        resolve_package _dependencies()
        import package

        def main():
        ...

        # boilerplate at the end of main file
        def resolve_package _dependencies() :
        if sys.version_inf o[0:2] == (2,5):
        import package1
        sys.modules["package"] = sys.modules["package1"]
        else:
        import package2
        sys.modules["package"] = sys.modules["package2"]

        =============== =============== =======

        I've never needed that for packages like you, but as far as I
        remember package specific modules are stored like
        "package.module " so aliasing "package45" with "package" in your
        case will look like
        sys.modules[__name__+".pack age"] = sys.modules[__name__+".pack age45"]

        Serge.

        Comment

        • Greg Ewing

          #5
          Re: Import mechanism to support multiple Python versions

          Nicolas Fleury wrote:[color=blue]
          > All my code in under a single package. Is it possible to override the
          > import mechanism only for modules under that package and sub-packages so
          > that?:[/color]

          Yes. A package module has a __path__ attribute to which
          you can add additional directories to be searched for
          submodules of that package. So in your package's
          __init__.py you can do something like

          if sys.version == "2.4":
          subdir = "python24"
          elif sys.version == "2.3":
          subdir = "python23"

          __path__.append (os.path.join(o s.path.basename (__file__, subdir)))

          The directory structure is then

          yourpackage/
          __init__.py
          python23/
          cppmymodule.pyd (2.3 version)
          python24/
          cppmymodule.pyd (2.4 version)

          but at run time it will appear as though one version or
          the other of cppmymodule is a direct submodule of
          yourpackage.

          --
          Greg Ewing, Computer Science Dept,
          University of Canterbury,
          Christchurch, New Zealand

          Comment

          Working...