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.
>
> Which is very convenient. :-)
>
> (2)
> "the difference between console and graphical programs"
>
> This is a Windows issue.
>
> Windows makes this differentiation.
>
> Thus, it's there *regardless* of programming language. And for example, it
> doesn't matter whether the language offers an interpreter. With C or C++ you
> tell the linker which subsystem you want. With Java you use 'java' or 'javaw'
> to
> run the program as respectively console or GUI subsystem. With JScript and
> VBScript (script languages bundled with Windows) you use 'cscript' or
> 'wscript'
> to run the program as respectively console or GUI subsystem. With Ruby you use
> 'ruby' or 'rubyw' to run the program. And so on -- in the end it's always
> the
> bottom level executing machine code program that is console or GUI subsystem.
>
> Do you think I should mention this in the text?
>
> It will make the text longer, and I worked hard to make ch 1 as *short* as
> possible! :-)
>
> (3)
> "Whether to call the file .py or .pyw"
>
> This is a feature, that you can relieve the user from the burden of choosing
> the
> most sensible way to execute the file (the user doesn't have to choose whether
> to use a console or GUI subsystem version of the interpreter, and the user
> doesn't even have to know that there is an interpreter involved).
>
> It's a common convention for many languages (using those languages' filename
> extensions, of course), but it's not universal.
>
> Cheers & hth.,
>
> - Alf
>
> PS: and yes, programming *is* a bit complex! That's what also makes it fun.
> <g>
--
http://mail.python.org/mailman/listinfo/python-list
