Shebang or Hashbang for modules or not?

Discussion in 'Python' started by Chris Lasher, Apr 11, 2007.

  1. Chris Lasher

    Chris Lasher Guest

    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).
     
    Chris Lasher, Apr 11, 2007
    #1
    1. Advertising

  2. Chris Lasher

    Paddy Guest

    On Apr 11, 5:29 pm, "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).


    If you don't intend the module to be executable then adding a shebang
    line and/or setting the files execute bit are both contrary to
    intended use. You should therefore leave out the shebang/not set the
    execute bit to emphasise your intended use.
    During development however, intended use may differ from use when
    deployed.

    - Paddy.
     
    Paddy, Apr 11, 2007
    #2
    1. Advertising

  3. Chris Lasher

    Ben Finney Guest

    "Chris Lasher" <> writes:

    > I recently heard someone argue that shebangs were only appropriate
    > for Python code intended to be executable (i.e., run from the
    > command line).


    Since that's the purpose of putting in a shebang line, that's what I'd
    argue also; specifically:

    - Modules intended primarily for import should be named 'foo.py' and
    have no shebang line.

    This doesn't preclude having an 'if __name__ == "__main__":'
    block, and running the module as 'python ./foo.py' for whatever
    reason.

    - Modules intended primarily for running as a command should have a
    shebang line and an 'if __name__ == "__main__":' block, and be
    named according to the conventions of the OS for naming command
    programs; on *nix, this means naming the file 'foo'.

    This doesn't preclude importing the module (e.g. for unit
    testing), though it is a little more convoluted than a simple
    'import' statement.

    --
    \ "Dad always thought laughter was the best medicine, which I |
    `\ guess is why several of us died of tuberculosis." -- Jack |
    _o__) Handey |
    Ben Finney
     
    Ben Finney, Apr 11, 2007
    #3
  4. Chris Lasher a écrit :
    > Should a Python module not intended to be executed have shebang/
    > hashbang (e.g., "#!/usr/bin/env python") or not?


    The shebang is only useful for files that you want to make directly
    executable on a *n*x system. They are useless on Windows, and not
    technically required to use the file as a main program -ie: you can
    always run it like this:
    $ /path/to/python filename.py

    > I'm used to having a
    > shebang in every .py file


    An encoding declaration might be more useful IMHO !-)
     
    Bruno Desthuilliers, Apr 11, 2007
    #4
  5. Chris Lasher

    Jorgen Grahn Guest

    On Thu, 12 Apr 2007 00:24:12 +0200, Bruno Desthuilliers <> wrote:
    > Chris Lasher a écrit :
    >> Should a Python module not intended to be executed have shebang/
    >> hashbang (e.g., "#!/usr/bin/env python") or not?

    >
    > The shebang is only useful for files that you want to make directly
    > executable on a *n*x system. They are useless on Windows,


    Probably (unless setup.py uses them for something meaningful there,
    too). But of course often you don't know that the file will always be
    used only on Windows, or that the Windows user won't prefer Cygwin.

    > and not
    > technically required to use the file as a main program -ie: you can
    > always run it like this:
    > $ /path/to/python filename.py


    You can, but sometimes it's not appropriate. If you distribute a
    Python program to Unix users in that form, they may not want to know
    or care which language it's written in. Especially if you decide, a
    few releases later, that you want to switch to Perl or something.

    I realise that you took a more narrow view than I do above, so
    please see this as additional notes rather than critisism. It's just
    that I am struggling with people at work who feel program names
    should encode whatever language they happen to be written in, and so
    I am a bit oversensitive ...

    >> I'm used to having a
    >> shebang in every .py file

    >
    > An encoding declaration might be more useful IMHO !-)


    They are not mutually exclusive, if that is what you mean.
    I always use both.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
     
    Jorgen Grahn, Apr 13, 2007
    #5
  6. Chris Lasher

    Jorgen Grahn Guest

    On 13 Apr 2007 10:54:18 GMT, Jorgen Grahn <> wrote:
    > On Thu, 12 Apr 2007 00:24:12 +0200, Bruno Desthuilliers <> wrote:
    >> Chris Lasher a écrit :
    >>> Should a Python module not intended to be executed have shebang/
    >>> hashbang (e.g., "#!/usr/bin/env python") or not?

    >>
    >> The shebang is only useful for files that you want to make directly
    >> executable on a *n*x system. They are useless on Windows,

    >
    > Probably (unless setup.py uses them for something meaningful there,
    > too).


    There's another, secondary, reason to use a shebang on Python source
    which isn't executable: the Unix file(1) command and friends can see
    that it's Python code.

    (Of course, such files will almost always be named foo.py.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
     
    Jorgen Grahn, Apr 13, 2007
    #6
  7. Jorgen Grahn a écrit :
    > On Thu, 12 Apr 2007 00:24:12 +0200, Bruno Desthuilliers <> wrote:
    >
    >>Chris Lasher a écrit :
    >>
    >>>Should a Python module not intended to be executed have shebang/
    >>>hashbang (e.g., "#!/usr/bin/env python") or not?

    >>
    >>The shebang is only useful for files that you want to make directly
    >>executable on a *n*x system. They are useless on Windows,

    >
    >
    > Probably (unless setup.py uses them for something meaningful there,
    > too). But of course often you don't know that the file will always be
    > used only on Windows, or that the Windows user won't prefer Cygwin.


    From a practical POV, I consider cygwin as a *n*x system. And FWIW, I
    mentionned this platform specificness because it might not be clear to
    anyone reading the OP.

    >
    >>and not
    >>technically required to use the file as a main program -ie: you can
    >>always run it like this:
    >>$ /path/to/python filename.py

    >
    >
    > You can, but sometimes it's not appropriate.


    That's another question. What I meant here is that you don't technically
    need the shebang and x bit to allow execution of a Python file. IOW, the
    shebang is only meaningfull for python files intented to be effectivly
    used as a program.

    > If you distribute a
    > Python program to Unix users in that form, they may not want to know
    > or care which language it's written in. Especially if you decide, a
    > few releases later, that you want to switch to Perl or something.


    <troll>
    No one in it's own mind would decide to switch from Python to Perl !-)
    </troll>

    More seriously, and as far as I'm concerned, when I want to make a
    python script (by opposition to a python 'module') available as a unix
    command, I either use a symlink or a shell script calling the python
    script.

    > I realise that you took a more narrow view than I do above,


    I mostly tried to answer the OP question.

    > so
    > please see this as additional notes rather than critisism. It's just
    > that I am struggling with people at work who feel program names
    > should encode whatever language they happen to be written in,


    OMG.

    > and so
    > I am a bit oversensitive ...


    I can understand this...

    >
    >>>I'm used to having a
    >>>shebang in every .py file

    >>
    >>An encoding declaration might be more useful IMHO !-)

    >
    >
    > They are not mutually exclusive, if that is what you mean.


    Of course not. But one is always usefull (and will become more or less
    mandatory in a near future IIRC), while the other is either totally
    useless (module files) or only partially useful (script files).

    > I always use both.


    Even in modules ?????
     
    Bruno Desthuilliers, Apr 13, 2007
    #7
  8. Chris Lasher

    Jorgen Grahn Guest

    On Fri, 13 Apr 2007 22:46:03 +0200, Bruno Desthuilliers <> wrote:
    > Jorgen Grahn a écrit :

    ....
    >> If you distribute a
    >> Python program to Unix users in that form, they may not want to know
    >> or care which language it's written in. Especially if you decide, a
    >> few releases later, that you want to switch to Perl or something.

    >
    > <troll>
    > No one in it's own mind would decide to switch from Python to Perl !-)
    > </troll>


    I was trolling a bit, too ;-)

    Actually, it made sense in my case. It was a typical Perl task -- a
    filter regex-parsing a huge (a few hundred megabytes) text file.
    Rewriting it in Perl for speed was faster and more readable than
    rewriting it in Python for speed.

    > More seriously, and as far as I'm concerned, when I want to make a
    > python script (by opposition to a python 'module') available as a unix
    > command, I either use a symlink or a shell script calling the python
    > script.


    A symlink yes, but a shell script? Wouldn't it be easier to write a
    one-liner (well, two-liner) Python script in that case?

    >>>>I'm used to having a
    >>>>shebang in every .py file
    >>>
    >>>An encoding declaration might be more useful IMHO !-)


    ....

    >> I always use both.

    >
    > Even in modules ?????


    Yes, for a few reasons:
    - file(1) can tell it's Python source
    - I tend to leave unit tests in my modules
    - I just started doing that when I first tried Python;
    it's part of my mental boilerplate

    I don't claim they are good reasons. And since I strongly dislike
    setting the execute bit on things that aren't executable, I should
    probably stop using the shebang everywhere, too ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
     
    Jorgen Grahn, Apr 19, 2007
    #8
  9. 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.
    --
    Michael Hoffman
     
    Michael Hoffman, Apr 21, 2007
    #9
  10. Jorgen Grahn a écrit :
    > On Fri, 13 Apr 2007 22:46:03 +0200, Bruno Desthuilliers <> wrote:
    >
    >>Jorgen Grahn a écrit :

    >

    (snip)
    >
    >>More seriously, and as far as I'm concerned, when I want to make a
    >>python script (by opposition to a python 'module') available as a unix
    >>command, I either use a symlink or a shell script calling the python
    >>script.

    >
    >
    > A symlink yes, but a shell script? Wouldn't it be easier to write a
    > one-liner (well, two-liner) Python script in that case?


    Not necessarily. Just like there are cases where it makes sens to use
    Perl instead of Python, some things are really far simpler to do with
    shell scripts...
     
    Bruno Desthuilliers, Apr 21, 2007
    #10
  11. 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.

    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.

    --
    Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
    happened but none stranger than this. Does your driver's license say Organ ..0
    Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
    individuals! What if this weren't a hypothetical question?
    steveo at syslang.net
     
    Steven W. Orr, Apr 23, 2007
    #11
  12. 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
    same.

    > 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
     
    Michael Hoffman, Apr 23, 2007
    #12
  13. Chris Lasher

    Steve Holden Guest

    Michael Hoffman wrote:
    > 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
    > same.
    >
    >> 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.


    If you ever create a module that *shouldn't be run you can always put

    if __name__ == "__main__":
    print "Do not run this script: it is a module for import only"

    at the end of it. But what's the point?

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    Recent Ramblings http://holdenweb.blogspot.com
     
    Steve Holden, Apr 23, 2007
    #13
  14. On Monday, Apr 23rd 2007 at 17:31 +0100, quoth Michael Hoffman:

    =>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
    =>same.
    =>
    =>> 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.

    We're going too far here. Anything that ever gets executed should
    obviously always be executable and have a shebang. I'm trying to point out
    to people who create scripts in any language, shell, python, farsi,
    whatever, that if it's intended to be read in as some sort of library then
    don't make it executable and don't add a shebang. To do so is to confuse
    future generations.

    --
    Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
    happened but none stranger than this. Does your driver's license say Organ ..0
    Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
    individuals! What if this weren't a hypothetical question?
    steveo at syslang.net
     
    Steven W. Orr, Apr 23, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan Bishop

    Re: shebang strange thing...

    Dan Bishop, Jun 24, 2003, in forum: Python
    Replies:
    19
    Views:
    1,160
    Ben Finney
    Jun 29, 2003
  2. Andres Corrada-Emmanuel

    Optimize flag on shebang line

    Andres Corrada-Emmanuel, Dec 9, 2003, in forum: Python
    Replies:
    0
    Views:
    340
    Andres Corrada-Emmanuel
    Dec 9, 2003
  3. rbt
    Replies:
    5
    Views:
    17,541
    Bill Mill
    Apr 6, 2005
  4. pradeepbpin

    Hashbang error

    pradeepbpin, Jun 1, 2010, in forum: Python
    Replies:
    3
    Views:
    1,019
    Chris Gonnerman
    Jun 1, 2010
  5. Johnnie Lieske
    Replies:
    6
    Views:
    159
    Johnnie Lieske
    Nov 28, 2008
Loading...

Share This Page