* Mensanator:
On Oct 30, 2:07 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* bartc:



Python has a lot of baggage which is OK if that's what's going to be
used, but otherwise is unnecessary confusion: where to put the program
code (typed in live or in a file, or some combination); whether to call
the file .py or .pyw; the difference between console and graphical
programs and so on.
Hi.

I forgot or decided not to really answer this part earlier, so...

First of all, note that nothing of this is specific to Python.

(1)
"Where to put the program (typed in live or in a file)".

This is common to all languages that offer interpreted execution.

It is a feature, not a problem: in *addition* to putting your statements in a
file for later execution, i.e. in addition to creating ordinary programs, you
can explore the effects of statements by typing them at the interpreter.

Storing the statements in a file is to create a "program" in the usual sense.

Typing statements at the interpreter is just interactive use of the interpreter.
Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.

Unless you type something like:

def Collatz(n):
        while n>1:
                if n%2 == 0:
                        n //= 2
                else:
                        n = 3*n + 1
                print(n)

which *IS* a stored program. It's just stored in RAM and will
be lost on shutdown if not specifically saved.

Even a single line is a "stored" program in the sense that you
can put your cursor on the line and hit return to repeat the
execution, so obviously, it's stored somewhere.

Yes.

As you quoted me on:

Depending on the phase of the moon, one's shoe size and other factors <g>, what's typed may be called a "program". But it's not a program in the usual sense, it's not a stored program: it's just interactive use of the interpreter.

However, at least for [comp.programming] the term "stored program" has a different often used meaning, the one that you employ above (which, by the way, was not von Neumann's invention, he was falsely credited with that idea).

And perhaps that needs to be pointed out when or if I discuss stored programs, like some kind of Wikipedia disambiguation page, so, thanks! :-)

But geneally getting into that kind of terminological fine distinction, such as here, what can be regarded as "stored", isn't really useful, though. It assumes an adversarial reading, which is not a useful assumption. And the only possible way out with that assumption is to define all relevant terms in a very technical way, which (1) leads to qualifications that end up being umpteen times longer than a simple statement of whatever one attempts to communicate (like, replicating all thousand+ pages of a technical language standard just to define the concept of "variable", which is silly), (2) leads to ungrokkable lawyereese language, absolutely not suitable for novices, and (3) in practice never actually accomplishes the purpose of ironclad definitions, as evidenced by e.g. "variable" in C++ still being subject to some disagreement over what it is...

I'm very very happy that most comments about perceived defects in the text and in my responses here, have only disagreements over terminology. I had expected a slew of errors being pointed out, since I'm new to Python. <g> Still, I'm fairly sure that there actually *is* such a slew of errors, because there is in any text of more than ten pages or so; any good book has a volumious errata list...


Cheers, & thanks,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to