Menu
▾
▴
Re: [Pythoncard-users] standardize application sub-directories?
|
From: Dan S. <py...@da...> - 2002-02-22 08:16:24
|
<html>
<head>
</head>
<body>
<br>
<br>
Kevin Altis wrote:<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap="">Has anyone experienced problems trying to figure out which .py file to run<br>with any of the samples?<br></pre>
</blockquote>
Not when I view the file list in list view rather than icon view! :-)<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Once you have more than a single Python script in a directory, knowing which<br>one is the actual application and which files are just support modules<br>becomes an issue. PythonCard programs always have at least two files, the<br>main script such as minimal.py and a resource file like minimal.rsrc.py. The<br>number of files increases as additional support modules, localized resource<br>files, images, sounds, and other data files are added.<br></pre>
</blockquote>
I'd rather see us adopt a convention than a new folder structure myself.
One of the things that always gets in the way of trying to master Java is
the horrendous amount of time one spends figuring out where stuff is. In
PythonCard, it's all right there.<br>
<br>
Maybe, e.g., if we adopted the rule that you should always prefix or suffix
your main launching Python file with app_ or _app? I think Patrick is doing
this already, no?<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Should we add standard sub-directory support to PythonCard to reduce clutter<br>in the main application directory?<br><br>The "clutter" increases once a script is compiled (.pyc) and/or optimized<br>(.pyo) which is something that distutils does by default when it installs a<br>package. Imagine the minimal sample directory containing:<br>.cvsignore, minimal.fr.rsrc.py, minimal.fr.rsrc.pyc, minimal.fr.rsrc.pyo,<br>minimal.py, minimal.pyc, minimal.pyo, minimal.rsrc.py, minimal.rsrc.pyc,<br>minimal.rsrc.pyo, minimal.spec, readme.txt, setup.py, setup.pyc, setup.pyo<br></pre>
</blockquote>
But if this were set up so that minimal.py would become, say, minimal_app.py
or app_minimal.py or even perhaps something more clear and a tad bizarre
such as run_minimal.py. I know we couldn't *enforce* that but we can only
enforce the subdirectory structure by causing things not to work if they're
not put into the right place. For an inventive user, this yet another barrier
to entry.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>It is likely that we will start splitting the samples off into their own zip<br>for each release, partly to avoid the distutils auto-compiles.<br></pre>
</blockquote>
That sounds like it has some value.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>The suggestion has been made in the past that the resource files should be<br>renamed so they don't have a .py extension (.rsrc), but there were arguments<br>in favor of keeping the filenames unchanged as well. If the resource format<br>migrates to XML then there shouldn't be any confusion over the extension,<br>but that isn't going to happen soon.<br></pre>
</blockquote>
I see both sides of this one. If you lose the .py extension then on Windows
Python 2.2, the automatic menu option to edit in IDLE goes away (as does
the winPython "Edit" option that opens WinPython by default). I think the
value of having that capability out-weighs any confusion that might be caused
by rsrc.py file name endings.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>The next thing you need to know is that Python searches for modules and<br>packages to import using sys.path.<br><br>After running minimal.py with the -s (shell) command-line option on my<br>machine, this is what sys.path returns.<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">import sys<br>sys.path<br></pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->['.', '<a class="moz-txt-link-freetext" href="C:\\python\\PythonCardPrototype\\samples\\minimal">C:\\python\\PythonCardPrototype\\samples\\minimal</a>', '<a class="moz-txt-link-freetext" href="c:\\python">c:\\python</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\Pythonwin">C:\\Python21\\Pythonwin</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\win32">C:\\Python21\\win32</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\win32\\Lib">C:\\Python21\\win32\\Lib</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21">C:\\Python21</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\DLLs">C:\\Python21\\DLLs</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\lib">C:\\Python21\\lib</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\lib\\plat-win">C:\\Python21\\lib\\plat-win</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\lib\\lib-tk">C:\\Python21\\lib\\lib-tk</
a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\PIL">C:\\Python21\\PIL</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\PPM">C:\\Python21\\PPM</a>']<br><br>These are the directories and the order that Python checks for packages and<br>modules when you use the import statement. Your local configuration will<br>probably be similar but different. If we added a directory called 'modules'<br>to a sample like resourceEditor and then added an empty __init__.py file to<br>the 'modules' directory to make the directory a package then any additional<br>Python code the application needed could be put in the 'modules' directory<br>and imported since the current application directory is part of sys.path.<br></pre>
</blockquote>
Again, I don't see this as being such a big problem. I suspect you have bigger
fish to fry, Kevin. This is a problem that nobody has reported or commented
on yet.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>As a test I created separate files for each of the dialog classes used by<br>the resourceEditor: backgroundInfoDialog.py, stackInfoDialog.py, and<br>menuDialog.py, and then moved the scripts and their resource files into the<br>modules directory. I had to update the path each class used to load its<br>resource file, but ignore that for now. I then updated the resourceEditor.py<br>code to import the necessary classes.<br><br>from modules.backgroundInfoDialog import BackgroundInfoDialog<br>from modules.stackInfoDialog import StackInfoDialog<br>from modules.menuDialog import MenuDialog<br></pre>
</blockquote>
More complexity.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>One thing to note is that you don't want the name of the directory to<br>conflict with any standard Python package or module name. While each<br>PythonCard application could have its own directories, it might be easier to<br>understand scripts written by different people if everyone used the same<br>directory structure.<br></pre>
</blockquote>
I think this demonstrates my point: all you are really doing in the end is
shifting complexity from identifying the files to identifying the folders
the files should be in. The hierarchical nature of a file structure inevitably
adds opaqueness to the complexity and for my target audience, that's never
a good thing. The only thing that should be in sub-directories in such a
situation, IMNSHO, is stuff the user can simply ignore.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>When we were discussing localized resource files on the list, the suggestion<br>was made to have a special directory that contains the localized resource<br>files. I still think this is a good idea. I lean towards keeping the main<br>.rsrc.py file and its associated module file in the same directory, but the<br>issue is open for debate.<br></pre>
</blockquote>
Putting the localized resource files in one separate folder will also make
it easy later to do a locale-specific install. The main .rsrc.py file would
always be called that after the installation.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Sounds, images, and data files could be placed in a one or more standard<br>directories.<br></pre>
</blockquote>
This might or might not make sense. I do see that as apps get more and more
complex and we end up with more and more files in the single folder, things
might get edgy. But, these users deal with lots of files at the OS level
all the time. I doubt that will be an issue.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>We don't have to solve this problem now, but we should address it sometime<br>if it is causing confusion, especially for programmers new to Python. If we<br>don't provide standard directory support in the framework, one or more of<br>the samples could show ways of using sub-directories to better organize more<br>complex programs.<br></pre>
</blockquote>
I think this is a good idea! Offer a sort of best-practices recommendation
and teaching on the matter but leave it ulaimately to the individual developer/user
to organize their stuff so it's easy. I suspect down the road very few end
users will be double-clicking Python files; there will be some other launch
mechanism we don't even see yet.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Other suggestions or related issues?<br><br>ka<br><br><br>_______________________________________________<br>Pythoncard-users mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Pyt...@li...">Pyt...@li...</a><br><a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/pythoncard-users">https://lists.sourceforge.net/lists/listinfo/pythoncard-users</a><br><br><br></pre>
</blockquote>
<br>
</body>
</html>
|
