[Pythoncard-users] standardize application sub-directories?

Has anyone experienced problems trying to figure out which .py file to run
with any of the samples?

Once you have more than a single Python script in a directory, knowing which
one is the actual application and which files are just support modules
becomes an issue. PythonCard programs always have at least two files, the
main script such as minimal.py and a resource file like minimal.rsrc.py. The
number of files increases as additional support modules, localized resource
files, images, sounds, and other data files are added.

Should we add standard sub-directory support to PythonCard to reduce clutter
in the main application directory?

The "clutter" increases once a script is compiled (.pyc) and/or optimized
(.pyo) which is something that distutils does by default when it installs a
package. Imagine the minimal sample directory containing:
.cvsignore, minimal.fr.rsrc.py, minimal.fr.rsrc.pyc, minimal.fr.rsrc.pyo,
minimal.py, minimal.pyc, minimal.pyo, minimal.rsrc.py, minimal.rsrc.pyc,
minimal.rsrc.pyo, minimal.spec, readme.txt, setup.py, setup.pyc, setup.pyo

It is likely that we will start splitting the samples off into their own zip
for each release, partly to avoid the distutils auto-compiles.

The suggestion has been made in the past that the resource files should be
renamed so they don't have a .py extension (.rsrc), but there were arguments
in favor of keeping the filenames unchanged as well. If the resource format
migrates to XML then there shouldn't be any confusion over the extension,
but that isn't going to happen soon.

The next thing you need to know is that Python searches for modules and
packages to import using sys.path.

After running minimal.py with the -s (shell) command-line option on my
machine, this is what sys.path returns.
>>> import sys
>>> sys.path
['.', 'C:\\python\\PythonCardPrototype\\samples\\minimal', 'c:\\python',
'C:\\Python21\\Pythonwin', 'C:\\Python21\\win32',
'C:\\Python21\\win32\\Lib', 'C:\\Python21', 'C:\\Python21\\DLLs',
'C:\\Python21\\lib', 'C:\\Python21\\lib\\plat-win',
'C:\\Python21\\lib\\lib-tk', 'C:\\Python21\\PIL', 'C:\\Python21\\PPM']

These are the directories and the order that Python checks for packages and
modules when you use the import statement. Your local configuration will
probably be similar but different. If we added a directory called 'modules'
to a sample like resourceEditor and then added an empty __init__.py file to
the 'modules' directory to make the directory a package then any additional
Python code the application needed could be put in the 'modules' directory
and imported since the current application directory is part of sys.path.

As a test I created separate files for each of the dialog classes used by
the resourceEditor: backgroundInfoDialog.py, stackInfoDialog.py, and
menuDialog.py, and then moved the scripts and their resource files into the
modules directory. I had to update the path each class used to load its
resource file, but ignore that for now. I then updated the resourceEditor.py
code to import the necessary classes.

from modules.backgroundInfoDialog import BackgroundInfoDialog
from modules.stackInfoDialog import StackInfoDialog
from modules.menuDialog import MenuDialog

One thing to note is that you don't want the name of the directory to
conflict with any standard Python package or module name. While each
PythonCard application could have its own directories, it might be easier to
understand scripts written by different people if everyone used the same
directory structure.

When we were discussing localized resource files on the list, the suggestion
was made to have a special directory that contains the localized resource
files. I still think this is a good idea. I lean towards keeping the main
.rsrc.py file and its associated module file in the same directory, but the
issue is open for debate.

Sounds, images, and data files could be placed in a one or more standard
directories.

We don't have to solve this problem now, but we should address it sometime
if it is causing confusion, especially for programmers new to Python. If we
don't provide standard directory support in the framework, one or more of
the samples could show ways of using sub-directories to better organize more
complex programs.

Other suggestions or related issues?

ka