Billy Mays wrote:
> Hey c.l.p.,
>
> I wrote a little python script that finds the file that a python module
> came from. Does anyone see anything wrong with this script?
Yes -- the most screamingly obvious question has to be, why are you writing
directly to sys.stdout instead of just using print?
> #!/usr/bin/python
I believe the recommended, platform independent hash-bang line is
#!/usr/bin/which python
> import sys
> if __name__ == '__main__':
> if len(sys.argv) > 1:
> try:
> m = __import__(sys.argv[1])
The major risk here is whether or not you trust the module enough to import
it and run arbitrary code. The alternative would be a lot more work: you
would have to duplicate the logic of the import statement, search the
PYTHONPATH, look for packages, inside zip files, etc.
> sys.stdout.write(m.__file__ + '\n')
Built-in modules don't have a __file__ attribute. The most obvious example:
>>> import builtins # spelled __builtin__ in Python 2.x
>>> builtins.__file__
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__file__'
Also, __file__ is not always entirely honest. In Python 3, module.__file__
may report a .py file when it is actually loaded from a .pyc file, even if
the .py file doesn't exist. So if you care about the distinction
between .py, .pyc, .pyo etc. files, looking at __file__ alone will be
inadequate.
> except ImportError:
> sys.stderr.write("No such module '%s'\n" % sys.argv[1])
That's not a given -- it may be that the module exists, but importing fails
for some other reason. I would recommend not catching ImportError at all,
and just let the standard Python error handling print the traceback.
Especially for a tool aimed at programmers (who else would be interested in
PyWhich?), hiding useful diagnostic errors and replacing them with a
generic, and potentially wrong, message, is very bad.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
