The way you call scripts on Windows differs from the way scripts are called on Linux/ UNIX, and that difference can affect what kind of scripts you develop and how you write them. This line allows the script to be executed on UNIX. It has no effect on Windows. On UNIX, after this has been made executable and placed on your path, you're able to navigate into any desired directory and call this with wildcards and output redirection. This UNIX shell will find all files in the current directory that start with sole and end with .tst, and these will be sent in as command-line arguments. On Windows, it's not so easy. As you've just discovered, using the convenient double- click mechanism, you can't pass in command-line arguments. Using the Run box, you can pass in arguments but not redirect the output. The closest you can come is to use the command prompt window: place the script in the desired directory, navigate into the directory, and then type. But using the glob.glob function, you can obtain the wildcard character functionality.
This will be true if you're running under Windows XP, Vista, or Windows 7. Replace the single wildcarded filename string in the argument list with those files into which it expands. Assuming that we've placed our script in the same directory as our .tst files and navigated to that directory in a command prompt window, we can now call our script with a single wildcarded argument. With the use of copy and paste and storing the command text in a file, this might be acceptable for your situation. But the script can be set up so that it can be started using the double-click open mechanism. This is often done for scripts that will be run by end users. When you start a script with a double-click, its working directory is the directory where the Python interpreter resides, not where the script is. Fortunately, the directory where the script is is appended as the first string in sys.path. The script uses this fact and changes into that directory. It then prompts the user for a possibly wildcarded input filename and expands it. Next, it prompts for the name of the output file and redirects standard output to this file. Finally, it proceeds to the original script's functionality. For small scripts that contain only a few lines of code, a single function works well. But if the script grows beyond this, separating your controlling function from the rest of the code is a good option to take. Our controlling function here calls the function num2words with the appropriate argument and prints the result. It's standard to have the call at the bottom, but sometimes you'll see the controlling function's definition at the top of the file. I prefer it at the bottom, just above the call, so I don't have to scroll back up to find it after going to the bottom to find out its name.
This also cleanly separates the scripting plumbing from the rest of the file. This is useful when combining scripts and modules. People combine scripts with modules when they want to make functions they've created in a script available to other modules or scripts. Also, a module may be instrumented so it can run as a script either to provide a quick interface to it for users or to provide hooks for automated module testing. If it's called as a script, it will be run with the name __main__ and the controlling function, main, will be called. If it has been imported into an interactive session or another module, its name will be its filename. When creating a script, I often set it as a module as well, right from the start. This allows me to import it into a session and interactively test and debug my functions as I create them. Only the controlling function needs to be debugged externally. If it grows, or I find myself writing functions I might be able to use elsewhere, I can separate those functions into their own module or have other modules import this module. This main function illustrates the purpose of a controlling function for a command- line script, which, in effect, is to create a simplistic user interface for the user. It may handle the following tasks: Ensure that there is the right number of command-line arguments and that they're of the right types. Inform the user, giving usage information if not. Here, it ensures that there is a single argument, but it doesn't explicitly test to ensure that the argument contains only digits. Possibly handle a special mode. Here, a '--test' argument puts us in a test mode.
Map the command-line arguments to those required by the functions, and call them in the appropriate manner. Here, commas are stripped out and the single function num2words is called. Possibly catch and print a more user-friendly message for exceptions that may be expected. Here, KeyErrors are caught, which will occur if the argument contains nondigits. Map the output if necessary to a more user-friendly form. This is done here in the print statement. If this were a script to run on Windows, you would probably want to let the user open it with the double-click method-that is, to use the input to query for the parameter, rather than having it as a command-line option and keeping the screen up to display the output by ending the script with the line: input("Press the Enter key to exit"). But you may still want to leave the test mode in as a command-line option. The output file can be easily checked for correctness. This was run a number of times during its creation and can be rerun anytime num2words or any of the functions it calls are modified. And, yes, I'm aware that full exhaustive testing certainly didn't occur. I admit that well over 999 trillion valid inputs for this program haven't been checked!
Often, the provision of a test mode for a module is the only function of a script. I know of at least one company where part of its development policy is to always create one for every Python module developed. Python's built-in data object types and methods usually make this easy, and those who practice this technique seem to be unanimously convinced that it's well worth the effort. Another option here would have been to create a separate file with just the portion of the main function that handles the argument and import n2w into this file. Then only the test mode would be left in the main function of n2w.py.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Ewan A. Woodsen at 01052010
1. Definitions and uses of functions in Python
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.