Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6257 > unrolled thread

First Program with Python!

Back to article view | Back to comp.programming

Contents

  First Program with Python! anitagoyal571@gmail.com - 2016-02-09 06:11 -0800
    Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-09 14:30 +0000
      Re: First Program with Python! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-09 14:35 +0000
        Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-09 19:06 +0000
          Re: First Program with Python! Öö Tiib <ootiib@hot.ee> - 2016-02-09 16:55 -0800
            Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-10 09:20 +0000
            Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:49 +0000
      Re: First Program with Python! Öö Tiib <ootiib@hot.ee> - 2016-02-09 16:32 -0800
        Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-10 14:07 +0000
          Re: First Program with Python! David Brown <david.brown@hesbynett.no> - 2016-02-10 16:24 +0100
            Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-10 16:55 +0000
              Re: First Program with Python! David Brown <david.brown@hesbynett.no> - 2016-02-11 00:18 +0100
                Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-11 00:07 +0000
            Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:58 +0000
          Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-10 21:51 +0000
            Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-11 00:15 +0000
    Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:46 +0000
      Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-15 17:31 +0000
        Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-15 20:16 +0000
          Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-15 22:45 +0000
            Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-16 03:40 +0000

Page 1 of 2  [1] 2  Next page →

#6257 — First Program with Python!

Python is a very powerful high-level, object-oriented programming language.Python has a very easy-to-use and simple syntax, making it the perfect language for someone trying to learn computer programming for the first time. Python is an interpreted language. Interpreter is a program that converts the high-level program we write into low-level program that the computer understands. Click here to find the difference between interpreter and compiler. This tutorial is based on Python 3 and all the examples in this tutorial have been tested and verified in Python.

Start learning Python from basics to advance levels here...
https://goo.gl/hGzm6o

[toc] | [next] | [standalone]

#6258

On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
> Python is a very powerful high-level, object-oriented programming
 > language.Python has a very easy-to-use and simple syntax, making
 > it the perfect language for someone trying to learn computer
 > programming for the first time. Python is an interpreted language.
 > Interpreter is a program that converts the high-level program we
 > write into low-level program that the computer understands.

That sounds more like a compiler to me. An interpreter is a program that 
interprets instructions written in a high-level language and carries 
them out straight away. It's rather like the difference between an 
interpreter who whispers a constant stream of translated information 
into a delegate's ear, and a translator who takes a batch of original 
Pliny or Tacitus and turns it into deathless English prose. If we take 
BASIC, for example:

10 PRINT "HELLO"
20 END

the interpreter's job is to convince the computer to print HELLO
on the screen RIGHT NOW, whereas the compiler's job is to create a 
program in some other language that expresses the same intent as the 
BASIC program, a program that can be executed at some later time 
/without/ a further need for using the interpreter. These are very 
distinct tasks, and your claim about a "low-level program that the 
computer understands" sounds very much more like a poorly-expressed 
misunderstanding of a compiler than it sounds like an interpreter.

 > Click here to find the difference between interpreter and compiler.

Are you sure you know?

> This tutorial is based on Python 3 and all the examples in this
 > tutorial have been tested and verified in Python.
>
> Start learning Python from basics to advance levels here...

Why should we trust a programming tutorial by someone who takes such 
little care over their grammar? (I'm not saying we shouldn't. I'm just 
asking the question.) What makes your tutorial worth reading?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6259

> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
<stuff I've cut>

Richard Heathfield <rjh@cpax.org.uk> writes:
> [...] What makes your tutorial worth reading?

The link is to a company selling online courses.  It's commercial spam,
pure and simple.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#6260

On 09/02/16 14:35, Ben Bacarisse wrote:
>
>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
> <stuff I've cut>
>
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...] What makes your tutorial worth reading?
>
> The link is to a company selling online courses.  It's commercial spam,
> pure and simple.

Thanks. I like to give people the benefit of the doubt and assume that 
they are posting in comp.programming because they want to talk about 
programming. On the other hand, I'm not naive about it, and I realise 
that spam is commonplace (which is why I carefully snipped the link).

I framed my reply in such a way as to invite the poster into a 
discussion, knowing that a strong possibility existed that they would 
not do so but nevertheless giving them the opportunity, just in case.

Had I followed the link, no doubt I would have discovered what you 
discovered, but I never follow links in Usenet unless I have some prior 
experience of the poster actively contributing to discussions.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6262

On Tuesday, 9 February 2016 21:06:26 UTC+2, Richard Heathfield  wrote:
> On 09/02/16 14:35, Ben Bacarisse wrote:
> >
> >> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
> > <stuff I've cut>
> >
> > Richard Heathfield <rjh@cpax.org.uk> writes:
> >> [...] What makes your tutorial worth reading?
> >
> > The link is to a company selling online courses.  It's commercial spam,
> > pure and simple.
> 
> Thanks. I like to give people the benefit of the doubt and assume that 
> they are posting in comp.programming because they want to talk about 
> programming. On the other hand, I'm not naive about it, and I realise 
> that spam is commonplace (which is why I carefully snipped the link).
> 
> I framed my reply in such a way as to invite the poster into a 
> discussion, knowing that a strong possibility existed that they would 
> not do so but nevertheless giving them the opportunity, just in case.
> 
> Had I followed the link, no doubt I would have discovered what you 
> discovered, but I never follow links in Usenet unless I have some prior 
> experience of the poster actively contributing to discussions.

Spam that contains factual, logical and/or typographical flaws is
often constructed that way so to filter in the people who can not 
spot such flaws.

[toc] | [prev] | [next] | [standalone]

#6263

On 10/02/16 00:55, Öö Tiib wrote:

<snip>

> Spam that contains factual, logical and/or typographical flaws is
> often constructed that way so to filter in the people who can not
> spot such flaws.

Yet another reason to post a counter to it (without, of course, 
promulgating its URL) - to filter /out/ those people who may not be able 
to spot such flaws themselves, but who are able to recognise the 
implications of such flaws when they are pointed out.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6272

On 2016-02-10, Öö Tiib <ootiib@hot.ee> wrote:
> Spam that contains factual, logical and/or typographical flaws is
> often constructed that way so to filter in the people who can not 
> spot such flaws.

Indeed. For instance, scams which rob elderly people of their life
savings are often completely idiotic, and it's that way on purpose.
The criminals need to take their victims through numerous rounds of
exploitation, and for that to be efficient, you need early on to
select for vicitims that are likely to pass through as many rounds
as possible.

The scam is obvious to anyone with a mind that still works at
full capacity.

[toc] | [prev] | [next] | [standalone]

#6261

On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>  > Python is an interpreted language.
>  > Interpreter is a program that converts the high-level program we
>  > write into low-level program that the computer understands.
> 
> That sounds more like a compiler to me.

Good catch. AFAIK Python is simply a programming language without
requirement that it *must* be interpreted. There even are some 
JIT-compiling Python 3 implementations like PyPy and Pyston.

[toc] | [prev] | [next] | [standalone]

#6264

On 10/02/2016 00:32, Öö Tiib wrote:
> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>   > Python is an interpreted language.
>>   > Interpreter is a program that converts the high-level program we
>>   > write into low-level program that the computer understands.
>>
>> That sounds more like a compiler to me.
>
> Good catch. AFAIK Python is simply a programming language without
> requirement that it *must* be interpreted. There even are some
> JIT-compiling Python 3 implementations like PyPy and Pyston.
>

PyPy is such a complex implementation that probably no one knows for 
sure exactly what it is.

 From what I've been able to glean, PyPy is actually an interpreter (and 
an even slower one than CPython), but written in such a way that 
repeated execution paths (through the interpreter apparently, not the 
bytecode being executed) are chosen to be JIT-compiled. So what is 
JIT-compiled, I think, are parts of the interpreter, which is written in 
customised version of Python. It doesn't JIT-compile the user's actual 
program, AFAICT.

It's just a touch confusing.

You can tell from the language anyway that it is completely unsuitable 
for normal 'straight' compilation to native code. So interpretation 
would be the usual start-point.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6265

On 10/02/16 15:07, BartC wrote:
> On 10/02/2016 00:32, Öö Tiib wrote:
>> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>>   > Python is an interpreted language.
>>>   > Interpreter is a program that converts the high-level program we
>>>   > write into low-level program that the computer understands.
>>>
>>> That sounds more like a compiler to me.
>>
>> Good catch. AFAIK Python is simply a programming language without
>> requirement that it *must* be interpreted. There even are some
>> JIT-compiling Python 3 implementations like PyPy and Pyston.

There are few programming languages that /must/ be interpreted, or
/must/ be compiled.  There are C and C++ interpreters available.  And
for many traditionally interpreted languages, there are compilers for
all or part of the language.  (Python is mostly byte-compiled, with the
python byte-code run in a dedicated virtual machine.  Jython compiles
Python source to Java byte code and runs it on a Java virtual machine.)

The exception is for code that is not known at "compile" time, such as
creating Python code from a string - that would have to be interpreted
or JIT-compiled.

>>
> 
> PyPy is such a complex implementation that probably no one knows for
> sure exactly what it is.
> 
> From what I've been able to glean, PyPy is actually an interpreter (and
> an even slower one than CPython), but written in such a way that
> repeated execution paths (through the interpreter apparently, not the
> bytecode being executed) are chosen to be JIT-compiled. So what is
> JIT-compiled, I think, are parts of the interpreter, which is written in
> customised version of Python. It doesn't JIT-compile the user's actual
> program, AFAICT.

PyPy is a Python interpreter with JIT acceleration.  Where possible,
Python code is used to generate C code that is then compiled (with gcc
or clang), and called from the PyPy interpreter.  Some Python code
cannot sensibly be compiled in this way, and it gets interpreted.

So the user's Python code, along with the Python libraries, get
JIT-compiled.


> 
> It's just a touch confusing.
> 
> You can tell from the language anyway that it is completely unsuitable
> for normal 'straight' compilation to native code. So interpretation
> would be the usual start-point.
> 

Certainly interpretation is the common way to handle Python code.  And
static compilation is going to be a lot less efficient than dynamic or
JIT compilation.  For example, consider the function:

def average(it) :
	return sum(it) / len(it)

Your code could call that function with lists of integers, tuples of
floating point, a tree structure of matrix types, or anything else that
supports an iteration interface and whose elements can be added and then
divided by an integer.  Clearly any general compiled version of that
function is going to involve a lot of indirect lookup to get the
required functions to operate on the types that happen to be passed to
any particular call of the function.

But if your code only ever calls the function with tuples of three
floating point numbers, it can be reduced to a few assembly instructions
to operate only on that particular type of argument.  So a JIT compiled
version is going to be a great deal smaller and faster than a statically
compiled version could ever be.

[toc] | [prev] | [next] | [standalone]

#6266

On 10/02/2016 15:24, David Brown wrote:
> On 10/02/16 15:07, BartC wrote:

>>  From what I've been able to glean, PyPy is actually an interpreter (and
>> an even slower one than CPython), but written in such a way that
>> repeated execution paths (through the interpreter apparently, not the
>> bytecode being executed) are chosen to be JIT-compiled.

> PyPy is a Python interpreter with JIT acceleration.  Where possible,
> Python code is used to generate C code that is then compiled (with gcc
> or clang), and called from the PyPy interpreter.  Some Python code
> cannot sensibly be compiled in this way, and it gets interpreted.

I believe PyPy is written in RPython. That is, the interpreter for 
normal Python is written in a special language called RPython, which 
looks like Python but restricts those features that make it slow. That 
RPython undergoes whole-program analysis to turn it into C.

So, we now still have a Python intepreter, but it's in C (a bit like the 
normal CPython), but there is some extra magic in there to optimise 
'hot' execution paths.

This is where it's unclear as to whether those paths are part of the 
RPython interpreter, or part of the Python bytecode being executed.

I thought it was the former. But the end result is that the Python 
program ends up faster (sometimes a magnitude or two faster), than 
normal CPython. In which case, no will really care exactly how it works!

Unless someone is discussing whether the Python is being compiled or 
interpreted...

>> You can tell from the language anyway that it is completely unsuitable
>> for normal 'straight' compilation to native code. So interpretation
>> would be the usual start-point.

> Certainly interpretation is the common way to handle Python code.  And
> static compilation is going to be a lot less efficient than dynamic or
> JIT compilation.  For example, consider the function:
>
> def average(it) :
> 	return sum(it) / len(it)
>
> Your code could call that function with lists of integers, tuples of
> floating point, a tree structure of matrix types, or anything else that
> supports an iteration interface and whose elements can be added and then
> divided by an integer.  Clearly any general compiled version of that
> function is going to involve a lot of indirect lookup to get the
> required functions to operate on the types that happen to be passed to
> any particular call of the function.
>
> But if your code only ever calls the function with tuples of three
> floating point numbers, it can be reduced to a few assembly instructions
> to operate only on that particular type of argument.  So a JIT compiled
> version is going to be a great deal smaller and faster than a statically
> compiled version could ever be.

The JIT compiler needs to find that out first. PyPy for example is good 
at optimising loops, so if average() is called a million times from a 
loop, each time with the same type for 'it', then that because a 'hot path'.

(Yours is not a good example however because most of the work will be 
done inside sum(). If this is a built-in, then it will be executing 
native code N times, not bytecode, even if it still needs to do dynamic 
type-dispatch for each element.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6268

On 10/02/16 17:55, BartC wrote:
> On 10/02/2016 15:24, David Brown wrote:
>> On 10/02/16 15:07, BartC wrote:
>
>>>  From what I've been able to glean, PyPy is actually an interpreter (and
>>> an even slower one than CPython), but written in such a way that
>>> repeated execution paths (through the interpreter apparently, not the
>>> bytecode being executed) are chosen to be JIT-compiled.
>
>> PyPy is a Python interpreter with JIT acceleration.  Where possible,
>> Python code is used to generate C code that is then compiled (with gcc
>> or clang), and called from the PyPy interpreter.  Some Python code
>> cannot sensibly be compiled in this way, and it gets interpreted.
>
> I believe PyPy is written in RPython. That is, the interpreter for
> normal Python is written in a special language called RPython, which
> looks like Python but restricts those features that make it slow. That
> RPython undergoes whole-program analysis to turn it into C.
>
> So, we now still have a Python intepreter, but it's in C (a bit like the
> normal CPython), but there is some extra magic in there to optimise
> 'hot' execution paths.
>
> This is where it's unclear as to whether those paths are part of the
> RPython interpreter, or part of the Python bytecode being executed.
>
> I thought it was the former. But the end result is that the Python
> program ends up faster (sometimes a magnitude or two faster), than
> normal CPython. In which case, no will really care exactly how it works!

For the most part, PyPy means people can write code that has the 
convenience and high-level features of Python, but when it comes to hard 
work code the result runs within spitting distance of a half-decent C 
program with a fraction of the effort.  And when it achieves that, you 
are right that few people will care how it works.

>
> Unless someone is discussing whether the Python is being compiled or
> interpreted...

You just have to accept that this question is no longer as 
black-and-white as it once was.  (Actually, shades of grey such as 
P-code compilation have existed for decades.  JIT compilation just makes 
it more complicated.)

>
>>> You can tell from the language anyway that it is completely unsuitable
>>> for normal 'straight' compilation to native code. So interpretation
>>> would be the usual start-point.
>
>> Certainly interpretation is the common way to handle Python code.  And
>> static compilation is going to be a lot less efficient than dynamic or
>> JIT compilation.  For example, consider the function:
>>
>> def average(it) :
>>     return sum(it) / len(it)
>>
>> Your code could call that function with lists of integers, tuples of
>> floating point, a tree structure of matrix types, or anything else that
>> supports an iteration interface and whose elements can be added and then
>> divided by an integer.  Clearly any general compiled version of that
>> function is going to involve a lot of indirect lookup to get the
>> required functions to operate on the types that happen to be passed to
>> any particular call of the function.
>>
>> But if your code only ever calls the function with tuples of three
>> floating point numbers, it can be reduced to a few assembly instructions
>> to operate only on that particular type of argument.  So a JIT compiled
>> version is going to be a great deal smaller and faster than a statically
>> compiled version could ever be.
>
> The JIT compiler needs to find that out first. PyPy for example is good
> at optimising loops, so if average() is called a million times from a
> loop, each time with the same type for 'it', then that because a 'hot
> path'.
>
> (Yours is not a good example however because most of the work will be
> done inside sum(). If this is a built-in, then it will be executing
> native code N times, not bytecode, even if it still needs to do dynamic
> type-dispatch for each element.)
>

Indeed - a function like "sum" will be handled with optimised specific 
functions, at least in cases where the elements of "it" are all of the 
same basic type.  It was merely an example.

[toc] | [prev] | [next] | [standalone]

#6269

On 10/02/2016 23:18, David Brown wrote:
> On 10/02/16 17:55, BartC wrote:

>> I thought it was the former. But the end result is that the Python
>> program ends up faster (sometimes a magnitude or two faster), than
>> normal CPython. In which case, no will really care exactly how it works!
>
> For the most part, PyPy means people can write code that has the
> convenience and high-level features of Python, but when it comes to hard
> work code the result runs within spitting distance of a half-decent C
> program with a fraction of the effort.

I don't know about that, although some results are certainly very 
impressive. Here are the results of a test of a jpeg decoder, all 
versions running the same algorithm.

To decode a 2Mpix image to memory:

C:            <0.2 secs
M:             2 secs    (my competing bytecode interpreter)
PyPy:          3 secs
CPython 3.4:  22 secs

However, with an 80Mpix image with extra colour detail:

C:             11 secs
M:            300 secs
PyPy:         180 secs
CPython 3.4:  A long time ...

Here the loop optimiser of PyPy starts to kick in. (I'm currently 
looking at my interpreter to address the annoying problem of PyPy being 
somewhat faster.)

So for this application anyway, PyPy is a long way from C's speed. But 
even on other tests, I've seen little evidence of it being anywhere near 
C in performance terms.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6273

On 2016-02-10, David Brown <david.brown@hesbynett.no> wrote:
> On 10/02/16 15:07, BartC wrote:
>> On 10/02/2016 00:32, Öö Tiib wrote:
>>> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>>>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>>>   > Python is an interpreted language.
>>>>   > Interpreter is a program that converts the high-level program we
>>>>   > write into low-level program that the computer understands.
>>>>
>>>> That sounds more like a compiler to me.
>>>
>>> Good catch. AFAIK Python is simply a programming language without
>>> requirement that it *must* be interpreted. There even are some
>>> JIT-compiling Python 3 implementations like PyPy and Pyston.
>
> There are few programming languages that /must/ be interpreted, or
> /must/ be compiled.

No programming language must be compiled, except those which explicitly
target environments that cannot support an interpreter.

> The exception is for code that is not known at "compile" time, such as
> creating Python code from a string - that would have to be interpreted
> or JIT-compiled.

There are other kinds of exceptions, like the use of fexprs.

fexprs are user-defined interpreter routines which get an unevaluated
AST and do something with it.

fexprs can do things which are impossible to compile.

Lisp shook off fexprs in the 1960's, but they are front and centre
in a dialect called NewLisp, which calls them macros.

The main point is that there are also ways for code to do introspection
without going through string evaluation.

The interpreter can open up an API to the data structures which
represent entities such as the program syntax tree, or variable binding
environments.

Code which does things like "look up the variable named by symbol X
in lexical environment object E" doesn't lend itself to compiling;
when compiling, we would X to go away and just be a register, or an
offset in some environment array. The introspection can be retained
through compiled code somehow, but at some great expense and perhaps
with restrictions (e.g. doesn't work at some optimization levels or
whatever).

[toc] | [prev] | [next] | [standalone]

#6267

On 10/02/16 14:07, BartC wrote:
> On 10/02/2016 00:32, Öö Tiib wrote:
>> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>>   > Python is an interpreted language.
>>>   > Interpreter is a program that converts the high-level program we
>>>   > write into low-level program that the computer understands.
>>>
>>> That sounds more like a compiler to me.
>>
>> Good catch. AFAIK Python is simply a programming language without
>> requirement that it *must* be interpreted. There even are some
>> JIT-compiling Python 3 implementations like PyPy and Pyston.
>>
>
> PyPy is such a complex implementation that probably no one knows for
> sure exactly what it is.

That's as maybe, but the point at issue is not whether Python is an 
interpreted language; the point at issue is the very definition of an 
interpreter. The OP said that an "Interpreter is a program that converts 
the high-level program we write into low-level program that the computer 
understands", and that's /not/ an interpreter -- it's a compiler. This 
is the case whether or not Python itself is interpreted, compiled, or 
eaten by an okapi.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6270

On 10/02/2016 21:51, Richard Heathfield wrote:
> On 10/02/16 14:07, BartC wrote:
>> On 10/02/2016 00:32, Öö Tiib wrote:
>>> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>>>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>>>   > Python is an interpreted language.
>>>>   > Interpreter is a program that converts the high-level program we
>>>>   > write into low-level program that the computer understands.
>>>>
>>>> That sounds more like a compiler to me.
>>>
>>> Good catch. AFAIK Python is simply a programming language without
>>> requirement that it *must* be interpreted. There even are some
>>> JIT-compiling Python 3 implementations like PyPy and Pyston.
>>>
>>
>> PyPy is such a complex implementation that probably no one knows for
>> sure exactly what it is.
>
> That's as maybe, but the point at issue is not whether Python is an
> interpreted language; the point at issue is the very definition of an
> interpreter. The OP said that an "Interpreter is a program that converts
> the high-level program we write into low-level program that the computer
> understands", and that's /not/ an interpreter -- it's a compiler.

That hasn't been put very well. And you're right that the quote would 
fit a 'compiler' better.

But interpreters do generally convert human-readable source code into a 
a more efficient internal form, if performance is of any interest. Then 
the quote isn't so far off.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6271

On 2016-02-09, anitagoyal571@gmail.com <anitagoyal571@gmail.com> wrote:
> Interpreter is a program that converts the high-level program we write
> into low-level program that the computer understands.

Complete nonsense. That is a compiler.

An interpreter is a program which reads another another program,
translating it into execution pathways through existing blocks of code
which make the interpreter.

The interpreter looks at the code and using its existing hard-coded
logic (not any newly generated code) performs whatever meaning that code
indicates.

> Start learning Python from basics to advance levels here...
> https://goo.gl/******

From a spammer who doesn't know the difference between an interpreter or
compiler? Bad idea.

[toc] | [prev] | [next] | [standalone]

#6274

On 15/02/2016 16:46, Kaz Kylheku wrote:
> On 2016-02-09, anitagoyal571@gmail.com <anitagoyal571@gmail.com> wrote:
>> Interpreter is a program that converts the high-level program we write
>> into low-level program that the computer understands.
>
> Complete nonsense. That is a compiler.
>
> An interpreter is a program which reads another another program,
> translating it into execution pathways through existing blocks of code
> which make the interpreter.
>
> The interpreter looks at the code and using its existing hard-coded
> logic (not any newly generated code) performs whatever meaning that code
> indicates.

That sounds sensible but it could also apply to a microprogrammed 
processor executing machine code.

And you could take what is thought of as conventionally compiled code 
and run it via an interpreter (or emulator) for that code on any hardware.

If there is any translation involved at all from source code to some 
other, usually less human-readable format, then both compilers and 
interpreters can do that.

Usually a compiler generates native code directly, an interpreter some 
made-up code that has to be executed with a special program. But there 
is plenty of overlap.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6275

On 15/02/16 17:31, BartC wrote:
> On 15/02/2016 16:46, Kaz Kylheku wrote:
>> On 2016-02-09, anitagoyal571@gmail.com <anitagoyal571@gmail.com> wrote:
>>> Interpreter is a program that converts the high-level program we write
>>> into low-level program that the computer understands.
>>
>> Complete nonsense. That is a compiler.
>>
>> An interpreter is a program which reads another another program,
>> translating it into execution pathways through existing blocks of code
>> which make the interpreter.
>>
>> The interpreter looks at the code and using its existing hard-coded
>> logic (not any newly generated code) performs whatever meaning that code
>> indicates.
>
> That sounds sensible but it could also apply to a microprogrammed
> processor executing machine code.

Yes, that's exactly what a CPU is - a machine code interpreter.

> And you could take what is thought of as conventionally compiled code
> and run it via an interpreter (or emulator) for that code on any hardware.

Yes.

> If there is any translation involved at all from source code to some
> other, usually less human-readable format, then both compilers and
> interpreters can do that.

Interpreting is on-the-fly conversion - decode it *right now* and then 
do it *right now*. Compilation is conversion into another language for 
later use.

> Usually a compiler generates native code directly, an interpreter some
> made-up code that has to be executed with a special program. But there
> is plenty of overlap.

There's plenty of overlap between, say, cars and bikes (e.g. motorbikes 
are essentially cars with two wheels, and motorised bicycles are bikes 
with engines, and no, the two are not the same thing), but that doesn't 
mean the distinction between cars and bikes is not useful.

Similarly, there is a certain amount of overlap between compilers and 
interpreters. Nevertheless, one will understand those terms best if one 
looks at the differences, not the similarities, between them.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6276

On 15/02/2016 20:16, Richard Heathfield wrote:
> On 15/02/16 17:31, BartC wrote:

>> If there is any translation involved at all from source code to some
>> other, usually less human-readable format, then both compilers and
>> interpreters can do that.
>
> Interpreting is on-the-fly conversion - decode it *right now* and then
> do it *right now*. Compilation is conversion into another language for
> later use.

That would be an unusual - and inefficient - way for an interpreter to 
work. Very often there is some preprocessing of the whole program or 
module before execution starts, a step that tends to be transparent so 
that it looks like it is interpreting source code directly.

The ones I create are similar but have a discrete compilation step that 
produces byte-code. And there is a further step, transparent this time 
and near-instant, that collates multiple modules into one running program.

This is not that different from what's involved in traditional compiling 
and linking, but those tend to be slower and clunkier processes. Slow 
enough that you want to do it in advance.

If such compilers and linkers were much snappier in operation, then it 
would be harder to tell the difference between a normal compilation and 
interpretation.

(Well, until you run the code then the compiled code can be much faster, 
depending on the kind of application. But there is a cost because such 
code tends to be harder to write.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web