Shebang or Hashbang for modules or not?

Michael Hoffman at mh391.invalid
Mon Apr 23 18:31:33 CEST 2007

Steven W. Orr wrote:
> On Saturday, Apr 21st 2007 at 19:18 +0100, quoth Michael Hoffman:
> =>Chris Lasher wrote:
> =>> Should a Python module not intended to be executed have shebang/
> =>> hashbang (e.g., "#!/usr/bin/env python") or not? I'm used to having a
> =>> shebang in every .py file but I recently heard someone argue that
> =>> shebangs were only appropriate for Python code intended to be
> =>> executable (i.e., run from the command line).
> =>
> =>Personally I include it in all of them, as part of boilerplate in a 
> =>template.
> I'd recommend againt it. The shebang doesn't do you any good unless it's 
> also in the presence  of a file that has its executable bit set. 

It doesn't do any bad either, so I don't understand why you would 
recommend against it.

And the bash function I use to create new files from the template also 
does chmod a+x.

Not to mention that I have emacs set such that things with shebangs at 
the top are automatically chmod a+x, so in my programming environment, 
having a shebang on files I create and being executable are one and the 

> For example, let's leave python out for a second: I have a shell script. 
> And I also have lots of files which are not intended to be executed which 
> are also shell scripts, but which are sucked in by the shell "." or 
> "source" command (which is *somewhat* analogous to python's import). Lots 
> of these shell "library" scripts can't execute as standalone. The same 
> thing is possible with pything scripts.
> Of course, anything that has 
> if __name__ == "__main__":
> in it should always have a shebang and be executable.

That's in my template as well. :)

I try to write all my modules so that they can easily be adapted to run 
as scripts, and all my scripts so that they can easily be adapted to use 
as modules. This has served me well many, many times. I see no reasons 
to create an artificial barrier to doing this by leaving the shebang out 
of files where it has no ill effect.
Michael Hoffman

More information about the Python-list mailing list