compile shebang into pyc file

[Joerg Schuster]

Hello,

is there a way to compile a python file foo.py to foo.pyc (or foo.pyo)
such that foo.pyc can be run with 'foo.pyc' (as opposed to 'python
foo.pyc') on the command line?

Jörg Schuster

 

[johnlichtenstein]

Is there some reason why you want to run the .pyc file, rather than the
..py file? If you start the script with

#! /usr/bin/env python

Then if the file has the execution permission set, typing the file name
(foo.py) will make the script call up the Python interpreter on its
own.

 

[Michael Soulier]

Is there some reason why you want to run the .pyc file, rather than the
.py file? If you start the script with

a. It's more efficient, since the code doesn't need to be compiled
before it's run.
b. What if you want to ship closed-source?

Mike

 

[Fredrik Lundh]

a. It's more efficient, since the code doesn't need to be compiled
before it's run.
b. What if you want to ship closed-source?

#!/usr/bin/env python
import app

hardly qualifies as "hard to compile" or "open source"

</F>

 

[Joerg Schuster]

#!/usr/bin/env python

import app

Yes, of course this is a possibility. But it implies having (or giving
away) two files.

I think having one file is always better than having two files. Because
if you have two files, you need a third one: a README that tells you
what to do with the two files and that one of the files must either be
in $PYTHONPATH, or in the same directory as the other one and '.' must
be in your $PYTHONPATH , and so on. Actually, some people will also
need a fourth file: One that contains an explanation of terms like
"$PYTHONPATH" and the like.

Jörg

 

[Steve M]

I just happened across the page linked to below, and remembered this
thread, and, well... here you go:

http://www.lyra.org/greg/python/

Executable .pyc files

Ever wanted to drop a .pyc file right into your web server's
cgi-bin directory? Frustrated because the OS doesn't know what to do
with a .pyc? (missing the #! line)

Look no further! Below is a tiny Bash script to do this. "cat"
your .pyc onto the end of this and drop it wherever you need direct
execution of that .pyc

 

[Dennis Lee Bieber]

a. It's more efficient, since the code doesn't need to be compiled
before it's run.
b. What if you want to ship closed-source?

You stuff the real code into a module that gets imported (hence
cached as a .pyc), and the main program in source looks like:

import thedirtystuff
thedirtystuff.main()

--

 

[Fredrik Lundh]

Yes, of course this is a possibility. But it implies having (or giving
away) two files.

yeah, think of all the disk space you'll waste!

Because if you have two files, you need a third one: a README
that tells you what to do with the two files

so you're saying that the set of people that can deal with no more than one
file at a time but knows how to install and configure Python (which in itself
comes with a few thousand files) is larger than zero?

I think having one file is always better than having two files.

so you don't ever use modules?

you haven't distributed many Python programs, have you?

</F>

 

[Grant Edwards]

so you're saying that the set of people that can deal with no
more than one file at a time but knows how to install and
configure Python (which in itself comes with a few thousand
files) is larger than zero?

There are a lot of Linux users who already have python
installed but don't know it. Python was always a required package for
a RedHat install. It's not required on some distros, but it's
installed by default and you've got to go out of your way to
de-selected it when you install.

I've found that giving Linux users a single file "executable"
Python script works wonderfully, but it's really only an option
for fairly small applications -- and I don't care if they have
source code.

 

[rbt]

yeah, think of all the disk space you'll waste!



so you're saying that the set of people that can deal with no more than one
file at a time but knows how to install and configure Python (which in
itself
comes with a few thousand files) is larger than zero?

On Windows, installing Python takes only a few clicks. No brain cycles
needed

 

[Dennis Lee Bieber]

On Windows, installing Python takes only a few clicks. No brain cycles
needed

Until you try to set it so that ActiveState Python(win) doesn't
conflict with Plone-2 Python (at least I'm still on 2.3.x -- If it
worked, I removed ASP, installed P2, then told ASP to install into the
P2 Python directory...)

--

 

[Joerg Schuster]

so you're saying that the set of people that can deal with

no more than one
file at a time but knows how to install and configure Python
(which in itself
comes with a few thousand files) is larger than zero?

Take me as an example: Very often, I needed software that could solve a
specific problem. I used to find, say, 10 different packages. Usually
none of the programs REALLY did the job as I wanted it to be done. Yet,
in order to find this out (or in order to find the package that suited
my needs best), I had to try out all of these packages. This used to
take an unnecessary amount of time.

I would have found (say) one java program, one c++ program, one Python
program, one perl program, ...

I know that java, c++, Python and Perl are all installed on our system.
And if they weren't, I would know how to install them myself: By using
yast or by saying 'apt-get install <package>'.

Yet: I don't want to have to know how to install all these packages in
all these different languages. I think a program should work out of the
box. And the should be no fumbling it out of the box.

Jörg