Feedback wanted on programming introduction (Python in Windows)

[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 :)

>
> 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?" :)




> > However, I'm sure you
> > would consider that if you were writing a C++ guide, you would promote
> > portability and the STL. Of course, both languages offer platform-
> > specific libraries. Maybe a 'down side' with Python is that the
> > "batteries included" also include some functions marked in the
> > documentation as "Available on Windows only" etc... And specifically
> > suggesting an ActiveState install
>
> I suggested ActiveState because I know from earlier that their packages are easy
> to install and provide documentation in reasonable Windows CHM help file format.
> I did try the IronPython .NET implementation first :-). But my experience with
> *nix folks' porting efforts is that they create Windows ports that don't handle
> spaces in paths, don't even handle backspace in dialogs they present, require
> undocumented environment variables set up (and explaining such takes a lot of
> pages & is demotivating), and just generally without any forethought or any
> reasonable automation, requiring a lot of explanation and hand-holding which
> would run to many pages, so I didn't even look at the CPython implementation.
>
> Perhaps I should.

Sorry you've had bad experiences. However, I would take a leap that
someone has used system/os specific calls (which are mostly un-
necessary) and that at least they've made an effort to port to
Windows. How many projects do you see authors porting from Win to
*nix? :)
[This could be construed as a slight rant, but oh well...]

>
> 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.
>
> > which includes COM interop etc...
> > (although I hope this would appear much later, if at all).
>
> I haven't looked at that part of things yet in Python but I guess it's the same
> as with other languages, some Automation-interface.
>
> I can't think of anything useful to do with that, though, except that some
> hardware is supplied with Automation interface drivers.
>
> For example, if I wanted to automate Excel (Microsoft's spreadsheet) I'd rather
> do that in VBA in Excel than in Python with COM interop driving the Excel
> Automation model.

My most used tools for Excel (as you mention it) are listed on
www.python-excel.org where John Machin has done a brilliant job of a
platform independent library for reading content from excel
spreadsheets [check out xlwt (for writing) and xlutils (by Chris
Withers for convenience functions)].



>
> Microsoft has discontinued all the fun beginner's stuff that earlier was
> available via Automation.
>
> The only thing left in XP is the Microsoft assistant with an animated Wizard
> figure on the screen, but IIRC that's discontinued already in Vista.

Oh the memories! The fun of programming another one, and popping up
messages such as: "Are you making a phone call yet?", "You have a
virus, call your doctor" etc... etc...

Can't say I'm sad it's gone though :)

>
> > PS. Can I suggest PSpad as an editor for the Windows environment, I
> > much prefer it to Notepad++ and it may well be worth mentioning.
>
> He he, it supports Esperanto!
>
> Great!
>
> Thx.
>
> Cheers,
>
> - Alf