Newbie: "compiling" scrips (?)

[Thomas Weber]

Hi,

I've just started to play around with python, I like the syntax quite
a lot...

But I have some problems to execute my scripts (in Linux, bash) that I
wrote in an editor.

Is there a way to compile the scripts into binary form like
like in C: 'gcc source.c -o binary'


Sorry, if this was a silly question...


Tom

 

[Troels Therkelsen]

Hi,

I've just started to play around with python, I like the syntax quite
a lot...

But I have some problems to execute my scripts (in Linux, bash) that I
wrote in an editor.

Is there a way to compile the scripts into binary form like
like in C: 'gcc source.c -o binary'


Sorry, if this was a silly question...


Tom

Hello Tom,

I don't know if this answers your question, but in order for a Python script
(or any script, really) to be executable under Linux (and all UNIX-like
systems), you need to do two things:

1) Make sure that the file has the executable bit set. This can be done
with the chmod command, for example 'chmod +x my_file.py'. Be sure to
read the man page for chmod, if you aren't already familiar with this
command.

2) At the very first line of your script file you must have a so-called
shebang line. This line tells your shell how to execute the file. The
Python tutorial recommends this shebang:

#! /usr/bin/env python

(No spaces before the # and the newline *must* be '\n'. If you use
'\r\n' it won't work and the error message isn't very helpful)

Alternatively, if you don't wish to do all this, you can also execute your
script by typing 'python my_file.py'. Regardless of which approach you take,
however, python must be in your $PATH for either of them to work. If python
has been properly installed on your system, it will be.

Regards,

Troels Therkelsen

 

[Alan Kennedy]

But I have some problems to execute my scripts (in Linux, bash) that I
wrote in an editor.

It might help if you told us what you have already tried that didn't work.

Generally, scripts are executed in one of three ways

1. Typed directly into a command line interpreter or IDE (Integrated Developed
Environment), and executed as they are typed.

2. They are created in a text editor, and executed by instructing the python
interpreter to execute them, like so

python myscriptfile.py

3. They are initiated by your *nix shell. For this to work, you need to have
what is called a "shebang line" as the first line of your script, e.g.

#myscriptfile------------------------
#!/usr/bin/python
for x in range(5):
print "Hello world!"
#------------------------------------

and your script needs to have the execute bit set (man "chmod" for more details)

bash>myscriptfile
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!

Is there a way to compile the scripts into binary form like
like in C: 'gcc source.c -o binary'
Sorry, if this was a silly question...

No, not a silly question, quite the opposite in fact. However, you'll just
confuse yourself thinking like that if you are just starting with python.

If I were you, I'd start with method 1 above, and then progress through methods
2 and 3 when you're more familiar with what's happening.

HTH,

 

[Steve Holden]

[how to "compile" Python]

I don't know if this answers your question, but in order for a Python script
(or any script, really) to be executable under Linux (and all UNIX-like
systems), you need to do two things:

1) Make sure that the file has the executable bit set. This can be done
with the chmod command, for example 'chmod +x my_file.py'. Be sure to
read the man page for chmod, if you aren't already familiar with this
command.

2) At the very first line of your script file you must have a so-called
shebang line. This line tells your shell how to execute the file. The
Python tutorial recommends this shebang:

#! /usr/bin/env python

(No spaces before the # and the newline *must* be '\n'. If you use
'\r\n' it won't work and the error message isn't very helpful)

Alternatively, if you don't wish to do all this, you can also execute your
script by typing 'python my_file.py'. Regardless of which approach you take,
however, python must be in your $PATH for either of them to work. If python
has been properly installed on your system, it will be.

Of course, if the shebang line explicitly names the Python executable then
there is no need for it to be on the user's PATH. On Red Hat 8.0, for
example:

[sholden@munger sholden]$ cat test.py
#!/usr/bin/python
print "So, Python need not be on the path!"
[sholden@munger sholden]$ export PATH=`pwd` # don't try this at home ...
[sholden@munger sholden]$ echo $PATH
/home/sholden
[sholden@munger sholden]$ test.py
So, Python need not be on the path!

regards

 

[Steve Holden]

I think this is what I am looking for! Where can I find these tools?
http://www.python.org/cgi-bin/faqw.py?req=all#4.28

I am still thinking in terms of 'source code' and 'binary', like in C.
I have been trying to learn C for some time now, and I now the basics
now, but it still feels a litte 'unhandy' and complex.
In a book about the open source movement, I read about Python and I
liked the idea of a easy-to-learn, object-oriented laguage.

As indeed why shouldn't you? ;-)

Perhaps this is not the right newsgroup to discuss the sense of
interpreted laguages, but can you give me a few hints what
the advantages are?

Well, mostly portability. You don't need to compile into the machine
language of every platform you target. Instead the "compilation" process
generates bytecodes for a fictitious virtual computer. Then all you have to
write is the virtual machine, and it turns out much of this is also
portable. Both Java and Perl work in a similar way, for example, although
variuos techniques have been used to improve eventual execution efficiency
in all three languages. Look for "psyco" and "pypy" in Google for the latest
and most promising approaches int he Python world.

I must admit, the only interpreted language I know is old Qbasic from
the 'good old (Dos) times' ;-)

Well, you know the principles, then.

regards

 

[Steve McAllister]

You don't need to compile into the machine language of every

> platform you target. Instead the "compilation" process
generates bytecodes for a fictitious virtual computer. [...]
Both Java and Perl work in a similar way

I would add the nuance that unlike Java, no explicit compilation
phase has to be performed, which, in combination with lightweight
syntax and library ergonomy, saves a lot of time, undermine anything.

For instance, when you go into quick-and-dirty checks, no sticks will
be put in your wheels because you forgot to throw IOException,
because a method throws more than the superclass's, etc.

 

[Gerrit Holl]

although
variuos techniques have been used to improve eventual execution efficiency
in all three languages. Look for "psyco" and "pypy" in Google for the latest
and most promising approaches int he Python world.

I don't understand how pypy can improve performance. Am I correct that pypy
is an effort to implement Python as much as possible in Python? And am I
correct that implementing a module in C will probably speed it up? Combining
these two, wouldn't implementing Python in Python slow things down? If so,
what is the advantage of pypy?

I don't want to clutter pypy-dev with these questions, because they must
be very trivial and Pypy-people probably have better things to do than
answering trivial questions

Well, you know the principles, then.

When I started with Python, I did not know the difference between a language
an IDE, a compiler and an interpreter; you can search Google and look at my
first posts here to check I'm right

yours,
Gerrit.

--
142. If a woman quarrel with her husband, and say: "You are not
congenial to me," the reasons for her prejudice must be presented. If she
is guiltless, and there is no fault on her part, but he leaves and
neglects her, then no guilt attaches to this woman, she shall take her
dowry and go back to her father's house.
-- 1780 BC, Hammurabi, Code of Law

 

[Alan Kennedy]

I don't understand how pypy can improve performance. Am I correct that pypy
is an effort to implement Python as much as possible in Python?

Yes, that's a part of what the PyPy people are doing.

And am I
correct that implementing a module in C will probably speed it up?

In some scenarios, implementing a module in C will speed things up, but it is
not guaranteed. It depends on the data being transferred back and forth between
the C extension and the users python script. This transfer comes at a cost. If
the cost of the transfer outweighs the time spent in the C extension, then it
will be slower. Which doesn't happen very often, mind.

Combining
these two, wouldn't implementing Python in Python slow things down?

Not necessarily. That's true only if you assume that the python virtual machine
interpreting the python byte codes doesn't run any faster than the current
Python VM.

If so,
what is the advantage of pypy?

From my readings, I think the PyPy project is very ambitious (and I wish them
the very best of luck getting funding for it).

Since the current python implementation has gone through many evolutions, it has
become tough to manage (at a code level) in certain areas. This is in no small
part due to the number of platforms and C compilers that the current python
works with, and the number of utilities used in producing the compiler, for
lexing, parsing, etc. Because there is so much "inertia" in the codebase, a lot
of time and effort go into making small changes.

Reimplementing python, from the grammar up, in python would free up much
development resources, allowing the python developers to focus more on things
that are important, e.g. improving the language, and adding new libraries, etc.
Also, PyPy can "leverage" (I hate that word) the fantastic portability of the
current python implementation to be running everywhere quickly: i.e. the current
Python VM would be the "bootstrap" VM.

Also, a clean redesign of the compiler and interpreter would allow for hooks to
be inserted for such products as psyco, which change the operation of the main
interpreter loop (usually optimising it for speed efficiency). This is
comparable to JIT in the jython world. Your jython script *may* run faster on
one Java VM compared to another, because the JVM interpreting the jvm bytecodes
may be using fancy assembler-level tricks to optimise for speed/memory/etc, e.g.
the "hotspot" VM. You get the benefit of increased execution speed, without a
single code change.

Another advantage is that because your VM is simpler to understand, because it's
written in python, it is easier to maintain and optimise. There is a data
structure called an "Abstract Syntax Tree", which contains a representation of
python your scripts as they are running. Sometimes, by recording statistics and
doing pattern matching on the bytecodes that are running through the machine, it
is possible to reduce the number of operations needed to execute a given script:
this is called optimisation. Native code compilers do it all the time, but
obviously only once at compilation time. Interpreters can optimise in exactly
same way, but at run time. The above mentioned hotspot java VM is an instance of
one of these.

There are many pieces to what the PyPy people are trying to do, and they have a
lot of work to do building the separate pieces, with nothing to show until it's
all ready to fit nicely together. But I think their overall model looks
promising. So hopefully, with the description above, you'll be in a better
position to understand the content of these links.

http://codespeak.net/moin/pypy/moin.cgi/PyPythonCore
http://codespeak.net/moin/pypy/moin.cgi/ObjectModel
http://codespeak.net/moin/pypy/moin.cgi/BytecodeCompiler
http://codespeak.net/moin/pypy/moin.cgi/BytecodeInterpreter

For a look at the kinds of tricks that optimising interpreters can use, in the
java world, take a look over this link

http://java.sun.com/products/hotspo...tspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_1.html

Looking at the PyPy object model, I can't help but wonder how they're going to
deal with continuations? (If full integration of stackless is the intention).