Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach
alfps at start.no
Wed Oct 28 10:15:06 EDT 2009
* 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
More information about the Python-list
mailing list