Feedback wanted on programming introduction (Python in Windows)

[Alf P. Steinbach]

* Jon Clements:
> Inline reply:
> 
> On 28 Oct, 11:49, "Alf P. Steinbach" <al... at start.no> wrote:
>> * Jon Clements:
>>
>>> On 28 Oct, 08:58, "Alf P. Steinbach" <al... at start.no> wrote:
>>> [snip]
>>>> Without reference to an OS you can't address any of the issues that a beginner
>>>> has to grapple with, including most importantly tool usage, without which it's
>>>> not even possible to get started, but also, very importantly, a file system.
>>>> Learning programming without tools and without using files (or only using the
>>>> common denominator for file systems in OSes X, Y and Z) is sort of vacuous...
>>>> In addition there's the motivational factor.
>>> I certainly agree that focusing on Windows, you may be able to suggest
>>> certain tools. IDE's, RAD environments, etc...
>> I'm more thinking of things like the command interpreter.
>>
>> It's rather different in Windows and *nix.
> 
> Yes, but not to the point it's required to make a massive distinction.
> 'python myfile.py' will work whatever... This isn't meant to be
> 'shell' scripting / system administration documentation :)

Still there's so much difference between Windows and *nix both in standard tools 
available and in conventions employed for e.g. paths, filenames, text 
representation etc. that it's two different worlds: what works here doesn't work 
there and vice versa. C and C++ suffer from being designed for *nix (e.g. in C++ 
this is a problem for 'main' arguments, for filenames in the standard library 
and for iostreams); it seems Python is better designed or is a better fit for 
the modern kind of environment so to speak but I haven't got that far yet...


>> The first exploratory programs a novice makes almost have to be text-oriented,
>> thus, some exposure to the command interpreter from the start. And most
>> programming languages' text i/o facilities, including those of Python, are
>> oriented towards standard streams and redirection of them, done from some
>> command interpreter. And most Windows users, those who'd like to learn
>> programming, know nothing about that, so unless they learn in a setting with
>> knowledgable people around, it needs to be addressed in the text they're using.
>>
> 
> I've found the average Windows user (even Uni. students studying
> programming) are somewhat amazed at the black window with white text
> that pops up when they run cmd.exe. My favourite comment thus far is,
> "Hey, it's like really dark and stuff, and it knows my name, is that
> good?" :)

He he. Can I quote that? It's really good. :-)


[snip]
>> However, since ActivePython is said here to be just be CPython + packaging +
>> stuff, I don't think there's any point in suggesting CPython, except perhaps to
>> get version 3.x but that would currently have its own problems wrt. libraries
>> and such, wouldn't it?
> 
> Libraries are moving towards the 3.* series. The development team have
> provided tools to assist in migrating, but yes, it's not going to be a
> smooth ride. I think the Python development team, and the timelines
> planned, are brilliant - take for instance the Boost libraries, of
> which some are only making it into the C++200X or whatever now.

I'm thinking about switching the text over to Python 3.x.

That's because I discovered that even the division operator has changed, and 
that xrange() is no more, with range() now playing that rôle, rendering my naïve 
attempts at writing sort of forward-compatible code very moot.

It's not just a new version, it's a new language.

And yes I now installed CPython (is that the right name?) v. 3.1.1 and it was a 
*very* pleasant surprise compared to other ported *nix software I've installed. 
That is, it was much like ActivePython, just an ordinary Windows installer. It 
even has CHM format documentation! :-)

SomeOne(TM) should better look at the IDLE environment, though. When 
single-steopping in that debugger one has to click on the source window after 
each step in order to see the highlighting of the current source code line. I 
guess this is due to ordinary text selection being used for the highlighting, 
and a difference between *nix and Windows in how that's shown (or in Windows not 
shown) for an inactive window.


But anyway, much thanks, I think now perhaps 2.6 was a bad choice of mine, even 
though it's recommended for beginners and seems logical...


Cheers,

- Alf