New user questions ... be gentle

[Jonadab the Unsightly One]

=?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard at iro.umontreal.ca> wrote:

> > I may be wrong on this but some scripts look as thought they are
> > executable like .exe files.  How is this done?
> 
> From your question, I presume you work on Windows, while my culture is
> more on the Unix side.  I'm sure this is quite doable on both platforms.
> On Linux, you just mark your script as executable (with `chmod +x FILE')
> and ensure it starts with the line `#/usr/bin/env python'.

This is a very system-specific solution.  It works if you never
intend to distribute your script.  On Windows, the equivalent is
to go to MyComputer, select View->Options, pick the File Types
tab (in '95; it's called something slightly different in '98,
but same idea and it's the third tab), and set up an association
for py files so that the default action is "Run" and points to
your Python interpreter.  Voila, doubleclicking a py script
will now run it.  (Under NT, it is also possible to set up
associations that work from the command line; on '95-series
systems you need a hack like PythonLauncher to accomplish 
this same thing.)  

However, the Unix #! syntax and the Windows association
both do the same thing:  they tell the system where to
find an interpreter for the script.  Everyone who wants
to use your script still needs to have Python installed.

There really ought to be a Windows<==>Unix translator's
dictionary...

When a Windows person asks about making something 
"executable", he means that he wants an independent 
binary that does not require any interpreter beyond
what ships with Windows.  In DOS/Windows culture it
is taboo to require the user to install a separate
package in order to use your software unless the 
software you require is a "standard" upgrade to 
the OS or to the software that comes bundled with
the OS (such as DirectX or IE).  This is gradually
changing, but very gradually.  If your software is
a port from Unix you may be able these days to get 
away with requiring cygwin, for example.  (Of course,
some people consider cygwin to be a necessary standard 
upgrade...)

Furthermore, "standalone executable", which a Unix
person might think would mean the same thing, usually
refers to a statically linked binary that does not
need QR7B3D~1.DLL and FOOOCX07.OCX and LAK3JDX2.VBX
and so on and so forth, either.  So early versions 
of VB, for example, were often lambasted for their 
inability to make standalone executables.  I have
heard this complaint far more often than the (highly
justified) complaint that VB apps crash a lot.  More 
recent versions of VB have made a deliberate attempt 
to provide the option of linking more statically to 
overcome this deficiency.  (I do not have a recent 
version and cannot attest to the completeness of the 
implementation here, but it is a heralded feature.)  A 
Unix person will protest that the deficiency was only 
in perception, but in fact because of versioning issues 
and other kinds of poor implementation (especially buggy 
installation software that often does the Wrong Thing), 
dynamic linking is more of a problem on Windows than 
in Unix, and the inability to produce a statically 
linked binary (or, in Windows parlance, a "standalone
executable") can sometimes be a veritable plague,
especially on fifth-generation development systems.
The stigma carries over to other things, therefore.

Personally, I'm not concered with whether Python can
produce binaries, since I view it mainly as a scripting
language (for my purposes, that is -- please, no flames).  
If, however, I were producing anything with it that I 
wanted to distribute, I would want to be sure that it 
could produce binaries, preferably statically linked ones.

- jonadab