Packages and PyKyra

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Robert Clayton

    Packages and PyKyra

    In the PyKyra example programs what does the statement:

    "from PyKyra import *"

    I now assume that this represents a Package hierarchy and not the file
    "PyKyra.py" as there is none but for Windows 2000 I am unable to determine
    whereor how the path is represented (registry, environment, etc.). Any
    suggestions?

    Thanks,

    Bob


  • Alex Martelli

    #2
    Re: Packages and PyKyra

    Robert Clayton wrote:
    [color=blue]
    > In the PyKyra example programs what does the statement:
    >
    > "from PyKyra import *"
    >
    > I now assume that this represents a Package hierarchy and not the file
    > "PyKyra.py" as there is none but for Windows 2000 I am unable to determine
    > whereor how the path is represented (registry, environment, etc.). Any
    > suggestions?[/color]

    I have no idea about what PyKyra is, but:

    [a]
    You can find out what the path is, at any time, by the two statements:

    import sys
    print sys.path

    [b]
    If you're right in stating there is no PyKyra.py file, then the
    import may be coming from:
    [b1] a PyKyra.pyc or .pyo bytecode file
    [b2] a PyKyra.pyd or .dll C-coded extension module
    [b3] the __init__.py file in a PyKyra directory on the path

    The only case involving "packages" is [b3] -- that's what a
    package _IS_... a directory with an __init__.py file.


    In any case, the "from PyKyra import *" statement gets the
    contents listed in the __all__ entry in module PyKyra, or, if
    no such entry, then all entries in module PyKyra whose names
    do not start with a single underscore character _ .

    The usage of "from whatever import *" is generally unadvisable
    except perhaps in those rare cases in which module 'whatever'
    has been carefully designed to support this. Personally, I've
    lost the habit of "import *" just about entirely -- even for
    carefully designed modules such as Tkinter and Numeric, I do
    "import Tkinter as Tk" or "import Numeric as N" and then access
    their entries explicitly as Tk.Tk, N.array, etc, etc. I find,
    personally, that this makes my programs more maintainable.


    Alex

    Comment

    • Robert Clayton

      #3
      Re: Packages and PyKyra

      Thank you!

      There are no PyKyra .py, .pyc, .pyd files.

      There is a release PyKyra.dll and a source directory contains a __init__.py
      file.

      Trying to use the PyKyra.dll returns:

      "ImportErro r: dynamic module does not define init function (initPyKyra)"

      Therefore I was attempting to define the location of the Package (directory
      structure).
      There is little information about creating path references for Packages in
      Windows.
      Some material suggest various registry entrys others suggest a environment
      variable.

      I have attempted the three suggestions I found:

      1) A System Environment Variable "PYTHONPATH " with the directory string.
      2) Addition of the directory to the existing Registry Key String
      "HKEY_LOCAL_MAC HINE\SOFTWARE\P ython\PythonCor e\2.2\PythonPat h"
      3) Creation of a new Registry Key
      HKEY_LOCAL_MACH INE\SOFTWARE\Py thon\PYTHONPATH with the accompanying
      directory,

      None of these seem to work. The error "ImportErro r: No module named
      xxxxxxxx" appears to mean that nothing is treated as a package.

      "Alex Martelli" <aleax@aleax.it > wrote in message
      news:6wCcb.1647 99$R32.5291608@ news2.tin.it...[color=blue]
      > Robert Clayton wrote:
      >[color=green]
      > > In the PyKyra example programs what does the statement:
      > >
      > > "from PyKyra import *"
      > >
      > > I now assume that this represents a Package hierarchy and not the file
      > > "PyKyra.py" as there is none but for Windows 2000 I am unable to[/color][/color]
      determine[color=blue][color=green]
      > > whereor how the path is represented (registry, environment, etc.). Any
      > > suggestions?[/color]
      >
      > I have no idea about what PyKyra is, but:
      >
      > [a]
      > You can find out what the path is, at any time, by the two statements:
      >
      > import sys
      > print sys.path
      >
      > [b]
      > If you're right in stating there is no PyKyra.py file, then the
      > import may be coming from:
      > [b1] a PyKyra.pyc or .pyo bytecode file
      > [b2] a PyKyra.pyd or .dll C-coded extension module
      > [b3] the __init__.py file in a PyKyra directory on the path
      >
      > The only case involving "packages" is [b3] -- that's what a
      > package _IS_... a directory with an __init__.py file.
      >
      >
      > In any case, the "from PyKyra import *" statement gets the
      > contents listed in the __all__ entry in module PyKyra, or, if
      > no such entry, then all entries in module PyKyra whose names
      > do not start with a single underscore character _ .
      >
      > The usage of "from whatever import *" is generally unadvisable
      > except perhaps in those rare cases in which module 'whatever'
      > has been carefully designed to support this. Personally, I've
      > lost the habit of "import *" just about entirely -- even for
      > carefully designed modules such as Tkinter and Numeric, I do
      > "import Tkinter as Tk" or "import Numeric as N" and then access
      > their entries explicitly as Tk.Tk, N.array, etc, etc. I find,
      > personally, that this makes my programs more maintainable.
      >
      >
      > Alex
      >
      >[/color]


      Comment

      • Alex Martelli

        #4
        Re: Packages and PyKyra

        Robert Clayton wrote:
        [color=blue]
        > Thank you!
        >
        > There are no PyKyra .py, .pyc, .pyd files.
        >
        > There is a release PyKyra.dll and a source directory contains a
        > __init__.py file.
        >
        > Trying to use the PyKyra.dll returns:
        >
        > "ImportErro r: dynamic module does not define init function (initPyKyra)"[/color]

        Thus, PyKyra.dll, whatever else it may be, is not a Python extension
        module named PyKyra.

        [color=blue]
        > Therefore I was attempting to define the location of the Package
        > (directory structure).[/color]

        You need to put the PARENT directory of the PyKyra directory (where
        the latter is the one containing __init__.py) on sys.path. Simplest
        is to have a textfile, call it e.g. pykyra.pth, with a single line:

        c:\the\parent\d irectory

        in your site-packages directory (e.g. C:\Python23\Lib \site-packages\).
        [color=blue]
        > There is little information about creating path references for Packages in
        > Windows.[/color]

        I thought I covered .pth files and various alternatives (all cross-platform:
        why go to platform-specific approaches when cross-platform works fine?) in
        an adequate fashion in "Python in a Nutshell". Specifically, it seemed to
        me that the sentences:
        """
        A package named P resides in a subdirectory, also called P, of some
        directory in sys.path. The module body of P is in the file P/__init__.py.
        You must have a file named P/__init__.py, even if it's empty (representing
        an empty module body), in order to indicate to Python that directory P
        is indeed a package.
        """
        (in section Packages, p. 124) were adequate coverage of THAT issue; and
        (on p.121, "Searching the Filesystem for a Module"), the sentences:
        """
        If a text file with extension .pth is found in the PYTHONHOME directory
        at startup, its contents are added to sys.path, one item per line
        """
        (and following), were adequate coverage of THAT one (except that, sigh,
        the mention of site-packages as a preferable alternative to PYTHONHOME
        dropped by the wayside -- doesn't even seem to be among the errata, which
        were fixed in the current [09/03] reprint of which I don't yet have a
        printed copy).

        Did you find this coverage unclear, or inadequate? If so, then perhaps
        you might suggest how to enhance it in a future edition -- thanks!


        Alex

        Comment

        Working...