Name of the Script

[David Bolen]

Paul Moore <paul.moore at uk.origin-it.com> writes:

> Agreed, in principle. However, in practice, I do have occasion to need
> this sort of thing. As a specific example, suppose I had a module
> which provided some form of logging service
> 
> def log(msg):
>     logfile.write(timestamp + ": ")
>     logfile.writeline(msg)
> 
> ... you know the sort of thing. Now, I want my log file to reside in
> the same directory as the calling script (not the same directory as
> the logging module), but with an extension of .log instead of .py.
> 
> The obvious, and most user-friendly, way of doing this is using the
> script name to generate a logfile name. This means looking at
> sys.argv[0] from within the module.

By "user-friendly" do you mean the user of the script or the
developer?  If the developer then I would think a clean maintainable
interface for the logging subsystem with a minimum of implicit
dependencies would be more user-friendly.  If you mean the end user of
the script, I have to admit that I rare place log files where my
scripts are - scripts are executable code and logs are data, and I
like to keep those things separate.

In terms of implementation, I'd probably (and I do) encapsulate my
logging functionality in a class (since I also like to re-route
sys.stdout there), and simply include the location and/or log file I
want to use when initializing the instance of the class.  After all,
why not have a generic log class that can write anywhere, and let the
intelligence of the user (code wise) of that log class instruct it
where to go on an as needed basis?  Better re-use, and more flexible
(for those cases where you _don't_ want the log file to go wherever
that first top level script happened to be run from).

> A less friendly way is to require the main script to call
> logger.init(os.path.abspath(sys.argv[0])) before starting processing.

Essentially this (although in my case during the instance creation).
I'm not sure why it's less friendly though.

> (Which in turn requires sys and os imports which the main script may
> otherwise not use).

True, but I wouldn't avoid it for that reason - or rather, needing
standard library modules shouldn't be a negative.  Even if the main
script doesn't use sys or os, if it imports anything else that does
you're still going to load them at some point, so you won't have a
performance hit.  And it's hard to get through all but tiny scripts
without needing sys or os.  (And sys is really a builtin anyway)

> This is a real-life case - I had a (VB Script, sorry!) program which
> did exactly this. And the initialisation step was a definit pain...

Can you clarify the pain part further?  I see this as normal
initialization that just makes sense and clarity.

This isn't to discourage your desire for another solution, but only to
point out that making the search for such a solution might also be an
indication that the approach could be re-evaluated.

> Maybe having sys.argv[0] always be the full script pathname would be
> something which could be added to Python? The interpreter must know
> where the script is, so it would be easy to do from the startup
> code...

Well, today I'm pretty sure the interpreter just passes on argv as
already initialized by the C RTL without having to do any extra work,
so it would have to encode the equivalent operation as your use of
abspath() above.  Given that you don't want the overhead of that in
your script, why impose it on everyone without an option?

There's also an interesting (or perhaps just debatable) question of
information content in the path.  If the interpreter were to decide to
munge the path to the file as specified on the command line - is what
do you do in the case of ambiguitities or where an absolute path might
lead to information loss.  For example, having the path as specified
by the user would include (under Unix) any symbolic directory links
traversed whereas an absolute path would lose that.  Under Windows, a
UNC path might (I'd have to check this) translate back to a mapped
drive if available, if the underlying Windows API call was made.
That's a loss of information content unnecessarily, since the script
itself can make an absolute path if it really wants one.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/