Packages and PyKyra

[Robert Clayton]

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]

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?

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


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

 

[Robert Clayton]

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:

"ImportError: 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_MACHINE\SOFTWARE\Python\PythonCore\2.2\PythonPath"
3) Creation of a new Registry Key
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PYTHONPATH with the accompanying
directory,

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

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?

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


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

 

[Alex Martelli]

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:

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

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

Therefore I was attempting to define the location of the Package
(directory structure).

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\directory

in your site-packages directory (e.g. C:\Python23\Lib\site-packages\).

There is little information about creating path references for Packages in
Windows.

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