On Mon, Jul 25, 2011 at 10:16, Ethan Coon <ecoon at lanl.gov> wrote: > It's not really a stand-alone script though, so it shouldn't get the > hashbang or lose the extension. But it's not a full-fledged package of > libraries either. I don't think it should be anywhere in the default path > -- it's the kind of code that you should have to explicitly include (either > via sys.path manipulation or via PYTHONPATH) because too many little scripts > of utility code makes for a nasty, polluted namespace. There just isn't a > good place (that I know of) in the standard file system hierarchy for this > kind of stuff.
Making the user/scripts do manual sys.path or PYTHONPATH manipulation makes it nearly impossible to make portable scripts that depend on these functions. Should we start a "proper" Python package containing PETSc utilities? Then scripts could rely on from petsc.io import binary_read or whatever working. Of course it might only contain two functions right now, but I could add my "petscplot" (makes various types of convergence and scaling plots from convergence monitors and -log_summary output), and I'm sure the community has other useful scripts. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110725/f2024bf9/attachment.html>