Python Interpreter question.

[Anon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all

I am a beginner teaching myself python, and I am enjoying it immensely
As a language it is great, I real treat to study, I actually find it fun to
study the language heh

Anyways to the point of my post.....

The other day I was talking with a few others about the age old Interpreted
v compiled language issue.
Were one person was saying,

"You cannot beat a compiled language."
"Interpreted scripting languages like python are just to slow" he said.

Well I agreed with him that compared to say C or any other compiled
language, languages like python and
[dare I mention the word here] 'perl', are slower in some cases;

"But!!", I said, "they are also more advantageous in many other ways as
well."

Well, after a few minutes, another Python champion came into the debate, and
turned everything on it's head by saying this,

"Python is also a compiled language, and it doesn't use an interpreter, it
uses the Python VM"

Well I was shocked at first lol, and indignant, telling him that Python does
indeed have an interpreter and python was an interpreted language, while
also reminding him that I also prefer python to to other languages as well.

I asked him, "Well what is sitting on my hard drive if not the Python
Interpreter?"

He replied that it wasn't an interpreter and was the Python compiler and VM
that did what I was refering to.
He went on to explain that the so called, "Interpreter" I was referring to
didn't exist, and that what python does when it gets python source, or
[shudders at the word] "script", is to compile the python source into
python byte code and then pass that compiled data to the python VM for
running.

So my question is this really,

Is all of that true? is it right to say in fact that python doesn't have an
interpreter, but rather it has a compiler and VM for running the python
code?

Please forgive me if all this sounds so simple to you experienced types,
Python is my 1st language, and while I am loving it and learning at a good
steady rate, python is still my, "first computer language".

Thanks in advance..
Anon




- --
*************
The Imagination may be compared to Adam's dream-
he awoke and found it truth.
John Keats.
*************
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQT3kwi/z2sM4qf2WEQLKsQCcDwg03n7KYM7OmGRVjCCoCUk8PpkAn2Pa
EEwtRUMnMLHi+iYtIqR1mAgT
=o/5V
-----END PGP SIGNATURE-----

 

[Roy Smith]

Is all of that true? is it right to say in fact that python doesn't have an
interpreter, but rather it has a compiler and VM for running the python
code?

Python source code is indeed converted into an intermediate form (byte
code) which is then executed on a virtual machine. Very much like Java
is. Whether you want to call this "interpreted" or "compiled" is, I
suppose, a matter of personal opinion.

 

[Alex Martelli]

Is all of that true? is it right to say in fact that python doesn't have an
interpreter, but rather it has a compiler and VM for running the python
code?

Python is indeed based on a compiler to bytecode plus a VM, like Java.

However, Python goes the extra step to make an interpreter out of the
combination of the two -- after all, compiling source to bytecode and
then handing the bytecode over to the VM _is_ easy. So, any time you're
using exec, eval, or execfile on source strings or files, in practice,
to all intents and purposes, you ARE using an interpreter, even if it's
put together with smoke and mirrors, oops, I mean compilers and VM's.

Similarly for anything you type at the interactive >>> prompt -- the
fact that whatever source you type gets compiled into bytecode first,
and then that bytecode is handed over to the VM for execution, is no
problem to you... in practice you DO have an interpreter, even though
"deep down" it's just a compiler + a VM!-)


Alex

 

[Jeremy Bowers]

Whether you want to call this "interpreted" or "compiled" is, I
suppose, a matter of personal opinion.

It is, for some suitable (but widely-agreed upon) definitions of those
words, both.

It is compiled into a form that is then interpreted.

Suitable definitions, for instance:

* Compile: To take some semantic meaning in one format (.py Python source
files) and convert it to some other format (.pyc compiled source) with
equivalent semantics. (This is a very general definition.)
* Interpret: To run a program not encoded in the native binary format of
the processor executing the program by providing it with a virtual machine
to run on that executes the program.

Java, .NET, and a lot of other things work this way now. The day is
rapidly approaching, if not already here, where rejecting "interpreted"
languages is to reject the majority of running code as "not real code".

 

[Roy Smith]

Similarly for anything you type at the interactive >>> prompt -- the
fact that whatever source you type gets compiled into bytecode first,
and then that bytecode is handed over to the VM for execution, is no
problem to you... in practice you DO have an interpreter, even though
"deep down" it's just a compiler + a VM!-)

And this is one of the coolest features of python. Being able to just
type stuff at an interactive prompt instead of having to create a file,
compile it, and run it, makes it so easy to explore bits of the system
you're not sure of. For example, if I want to find out what methods
lists have, I can just type

dir ([])

which is a lot faster than looking it up in the docs.

 

[Anon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[edit:snip]

OK, thanks peoplethe clarification helps me
I had often wondered if other language devlopers would go the same as what
the.NET JIT style and Java had gone, with the VM side of things I mean.

Anyways -what-ever- it's all facinating to me, it's like a whole new world
with it's own set of social orders-languages and politics hehe
I am really enjoying myself

Thanks:
Anon
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQT4lVy/z2sM4qf2WEQJh8gCg23lWdkAQKM7bnjA8v1fF49IGJFUAn2PY
tAklqLVa0Uywa1e1io9+4AB3
=SMSY
-----END PGP SIGNATURE-----

 

[Terry Reedy]

"Python is also a compiled language, and it doesn't use an interpreter,

it
uses the Python VM"

Well I was shocked at first lol, and indignant, telling him that Python
does
indeed have an interpreter and python was an interpreted language, while
also reminding him that I also prefer python to to other languages as
well.

Would you be shocked to also learn that humanly programmed languages are
generally not compiled to actual machine code, but, as I understand it, to
multibyte code which invokes subroutines written in actual machine code,
which is usually called microcode. One can, I believe, think of Pentiums
and Athlons, for instance, as hardware interpreters or emulators of what is
now mostly the virtual 386 machine (plus extensions). Intel and AMD can
change the real machine code as they please as long as they properly
emulate the 386, as seen from the programmer view. Whether the 386 machine
was ever a real machine or whether it was also microcoded, I do not know.

Terry J. Reedy

 

[Bryan Olson]

> And this is one of the coolest features of python. Being able to just
> type stuff at an interactive prompt instead of having to create a file,
> compile it, and run it, makes it so easy to explore bits of the system
> you're not sure of.

Incidentally, that feature does not require that the language be
interpreted. There are interactive programming language systems
that attempt to compile text as you type in at the prompt. If
syntactically incorrect they report the error, otherwise they
execute the native jump or call instruction to the generated
machine code.

 

[Heiko Wundram]

Am Mittwoch, 8. September 2004 06:46 schrieb Terry Reedy:

Whether the 386 machine
was ever a real machine or whether it was also microcoded, I do not know.

All CPUs made by Intel up to and including the Pentium (586) were "real"
machines, which ran the bytecode as it came from RAM, without an intermediate
layer of microcoding. Only with the wake of the Pentium II (IIRC), the
concept of microcode with a (somewhat) RISC core became seasonable in the PC
CPU-producing community.

Also, IIRC, the AMD K6-* were real CPUs in the sense that they didn't have a
microcode layer between the execution and the runtime environment.

The first AMD CPU to feature microcode (although it wasn't software
changeable, as it was with all Intel CPUs from the PII on; using a little
software tool you can change the behaviour of your Pentium to resemble that
of a Motorola 68000, except for the endianness issue, now isn't that cool?)
was the Athlon, which used microcode not only for the core instruction set,
but also to drive its FPU, which is completely different to the standard FPUs
found in the Intel CPUs (it is a RISC processor in the true sense of the
word). This is also what made the Athlon so easily extensible, as
implementing a new set of FPU-instructions (like SSE/MMX/SSE2, etc.) only
needed some additional microcode on the chip (which is cheap to write),
something that Intel has much more trouble with, as the FPU is decoupled from
the CPUs microcode layer, and isn't microcoded at all AFAIK.

Anybody correct me if I'm wrong; this is all that I remember from my first
semester classes on CPU-design.

Heiko.

 

[Tim Roberts]

Would you be shocked to also learn that humanly programmed languages are
generally not compiled to actual machine code, but, as I understand it, to
multibyte code which invokes subroutines written in actual machine code,
which is usually called microcode. One can, I believe, think of Pentiums
and Athlons, for instance, as hardware interpreters or emulators of what is
now mostly the virtual 386 machine (plus extensions). Intel and AMD can
change the real machine code as they please as long as they properly
emulate the 386, as seen from the programmer view. Whether the 386 machine
was ever a real machine or whether it was also microcoded, I do not know.

This has changed over time. The 386, 486, and Pentium are partly
microcoded. The complicated instructions are in microcode, but the most
common instructions are hardwired. This results in many non-intuitive
situations in which a single, complicated instruction would take longer
than a sequence of two or three simpler instructions.

Starting with the PentiumPro, all instructions are chopped into
"micro-operations", the pieces of which can be executed out of order. This
renders instruction timing practically impossible...

 

[Tim Williams]

[newbie still]

I have a dictionary with around 500 keys, 50 to 100 of those keys will be
in the format *text or text* (eg "*williams" or "tim*" ) for use as
wildcards.

I need to be able to match some input text to these wildcards (eg timothy
will match tim*), * on its own is invalid, there must be text before or
after the *.

I've never used Regular Expressions, and so can't judge whether they are
suitable (ie the best way) for searching MyDict.keys() to match the input
text and get the key's value, or whether iterating the keys and using
startwith() or endswith() would be better. Or (probably) there is a
different and much better way of doing it.

Any advice would be gratefully received.

TIA

Tim

 

[Heiko Wundram]

Am Donnerstag, 9. September 2004 13:28 schrieb Tim Williams:

I need to be able to match some input text to these wildcards (eg timothy
will match tim*), * on its own is invalid, there must be text before or
after the *.

Check out the fnmatch module (if you use simple wildcards, unix shell style,
which aren't regular expressions):
True

For documentation on the wildcards accepted by fnmatch.fnmatch, use

help(fnmatch)

in an interactive console window after you have imported the module.

HTH!

Heiko.

 

[Tim Williams]

----- Original Message -----

Am Donnerstag, 9. September 2004 13:28 schrieb Tim Williams:

Check out the fnmatch module (if you use simple wildcards, unix shell style,
which aren't regular expressions):

True

Yes, this does the trick, many thanks.

I used something like

import fnmatch as f
t = 'tim.williams'

# in place of L = MyDict.keys()
L = ['tim*' , 'dav* ', 'david' , 'peter' , '*m' , '*y' , ' not-a-name ',
'timoth?' , '*.*' , '*iams' , '*']

L.sort() # to give a consistent search order

for name in L:
.... if f.fnmatch(t, name):
.... print t, 'matches', name

tim.williams matches *
tim.williams matches *.*
tim.williams matches *iams
tim.williams matches tim*