«

* Jon Clements:
> Inline reply:
>
> On 28 Oct, 11:49, "Alf P. Steinbach" <al...@start.no> wrote:
>> * Jon Clements:
>>
>>> On 28 Oct, 08:58, "Alf P. Steinbach" <al...@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

In article <hc8pn3$ddn$>,
says...
>
> [Cross-posted comp.programming and comp.lang.python]
>
> Hi.
>
> I may finally have found the perfect language for a practically oriented
> introductory book on programming, namely Python.
>
> C++ was way too complex for the novice, JScript and C# suffered from too
> fast-changing specifications and runtime environment, Java, well, nothing
> particularly wrong but it's sort of too large and unwieldy and inefficient.
>
> I don't know whether this will ever become an actual book. I hope so!
>
> But since I don't know much Python -- I'm *learning* Python as I write -- I know
> that there's a significant chance of communicating misconceptions, non-idiomatic
> ways to do things, bad conventions, etc., in addition to of course plain errors
> of fact and understanding in general, to which I'm not yet immune...
>
> So I would would be very happy for feedback.
>
> But note: although I'm a complete Python newbie I'm not a novice programmer; my
> usual programming language is C++. So if you are a novice and think there's
> something wrong, then please do report it because it may help me explain things
> better, but since it's likely my explanation that is misleading, don't waste
> time on building up a case! This also goes for something that is simply
> difficult to understand. Then reporting that may help me explain it better. On
> the other hand, if you do have some experience, then chances are that what you
> think is an error, actually *is* an error!
>
> Unfortunately Google docs doesn't display the nice table of contents in each
> document, but here's the public view of ch 1 (complete) and ch 2 (about one
> third completed, I've not yet settled on a title so it's just chapter "asd"):
>
> http://preview.tinyurl.com/progintro
>
> Cheers,

Why is chapter 2 called "ASD"?

In article < om.au>,
says...
>
> On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote:
>
> > Unfortunately Google docs doesn't display the nice table of contents in
> > each document, but here's the public view of ch 1 (complete) and ch 2
> > (about one third completed, I've not yet settled on a title so it's just
> > chapter "asd"):
> >
> > http://preview.tinyurl.com/progintro
>
> Unfortunately Google wants me to change my browser, accept a privacy
> breach (cookies), and open a moderately large security hole in my browser
> (Javascript). Any one of these on its own, and I wouldn't mind; two of
> them, and I'd give it some thought; but all three, well, no thank you.
>
>
> I don't suppose you have these chapters available on a public website in
> an open document format like .odt or similar? Or even better, plain text
> with markup?

You can read PDF with the ghostscript stuff or the free Adobe stuff.

A man who cannot read .pdf or .ps in today's computer science world is a
crippled man (IMO-YMMV).

I couldn't live without citeseer, and almost all university computer
science papers are in either pdf or ps.

I can send you the documents via email if you are unable to collect
them.

* Dann Corbit:
> In article <hc8pn3$ddn$>,
>>
>> Unfortunately Google docs doesn't display the nice table of contents in each
>> document, but here's the public view of ch 1 (complete) and ch 2 (about one
>> third completed, I've not yet settled on a title so it's just chapter "asd"):
>>
>> http://preview.tinyurl.com/progintro
>>
>> Cheers,
>
> Why is chapter 2 called "ASD"?

The leftmost three keys on the middle row of the keyboard.


Cheers,

- Alf "The Ramans do everything in threes"

En Wed, 28 Oct 2009 08:49:02 -0300, Alf P. Steinbach <>
escribió:

> 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.

Certainly. The ActiveState folks do a great work, but currently most of
the "features" listed for ActivePython on Windows are standard in the
python.org distribution. Like .chm help files, all "core extensions"
(zlib, bz2, sqlite...), all additional documentation (FAQ, What's new,
PEPs, everything except the "dive into python" book). The biggest thing
not included in the python.org distribution is the pywin32 package and
related stuff (like the PythonWin editor).
Maybe in the past the gap between both distributions were larger, but now,
the official Python build is perfecty suitable for Windows users.

--
Gabriel Genellina

On Wed, 28 Oct 2009 05:29:38 -0700 (PDT), Jon Clements
<> declaimed the following in
gmane.comp.python.general:


> 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?"
>
Rampant plagiarism...

.... One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them

<G>

What would this modern world be like if students had to learn JCL
{using the acronym generically, not IBM specific -- even my TRS-80 had a
/compiled/ [well, preprocessed might be closer] JCL}, keypunches... And
(horrors) Drum Card Programming (which was a whole lesson when I took
COBOL in the late 70s)
--
Wulfraed Dennis Lee Bieber KD6MOG
HTTP://wlfraed.home.netcom.com/

> What would be good is if there was a "balancing book" eg. one specifically
> targeting ubuntu, which is gaining popularity as we mail.
>

Agreed 100%. I opened this thread as I am learning Python, but my
platform is Kubuntu. Of the students in my faculty, about one third
have already moved to Ubuntu or some other Linux distribution.
Windows-only tutorials just look outdated, even if their principles
apply to other OSs as well.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

* Martin P. Hellwig:
> Alf P. Steinbach wrote:
>> * tm:
>>> On 28 Okt., 07:52, "Alf P. Steinbach" <al...@start.no> wrote:
>>>> [Cross-posted comp.programming and comp.lang.python]
>>>
>>> Looking at your topic '(Python in Windows)', without taking a
>>> glimpse at your actual introduction, I have the following to say:
>>> I think it is not a good idea to teach programming with a focus
>>> on a specific operating system. Programming should IMHO be taught
>>> without reference to an operating system. Otherwise you just teach
>>> how to write unportable programs.
>>
>> I think you're trolling a little.
>>
>> 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 conclude from this that your assumption is that the reader might not
> be competent enough to have basic portable knowledge of using a
> computer. Which is fair enough, however I would suggest writing an
> introduction to solve this fundamental absence of knowledge first before
> introducing concepts like programming in python for which already are a
> number of freely available/modifiable resources online.

You're right that I assume no knowledge of the command interpreter, and just the
most cursory knowledge of folder structure etc. However I would not phrase that
in terms of competence . Writing an introduction to solve that knowledge gap
problem is generally a good idea and I've done that a number of times. But
having done that I know very well what it entails when it includes What The
Student Should Know instead of just recipes. In an environment with other folks
that the student can seek help from it works well, but in a book it's rather
off-putting: "hey, it's page 90!, when are we getting to do real programming?".

And I'm not taking that "page 90" from thin air.

There's rather a lot to know about the environment that a program executes in if
one is going to create robust, dependable, generally usable programs, not just
toy examples. Unfortunately even most professional programs do not handle the
requirements of their environs very well, and I think that educators, even such
as I, have a responsibility to now start teaching students to do things right.
To take but one example that you may or may not be aware of, Microsoft's own
Windows Explorer, the main GUI shell for Windows, which presumably was made by
the best programmers available with the best knowledge of the program's
environment, is unable to handle (such as delete) files or folders with paths
greater than some 260 characters, is unable to handle filenames that differ only
in case and are in the same directory, and is unable to e.g. delete a folder
called "con" -- although such files & folders can very easily be created.

In addition to such things impacting on the design and functionality of programs
even just the tool usage is very complex and runs to a great many pages.

For example, for general tool usage in Windows the student needs to know about
levels of environment variable specifications and file associations, which in
turn requires knowledge of processes and the Windows registry database and
various commands.

And there's stuff you don't find in most textbooks that, in an introduction for
that knowledge gap, IMO needs to be there. For example, the student should
ideally know that it's not a good idea to write "MZ" as the first two characters
in a Windows text file, or to let a program do that. But instead of collecting
all this stuff in a very long-winded introduction, my idea now is to just/mostly
introduce it by way of programming examples, and then the student also gets the
connection to how this functionality is from a programming perspective.


> I don't think it is a virtue to help adding to the pool of programmers
> unaware of the command line, whatever platform that might be.

This comment baffles me.


> But ignoring the above (I assumed and assumption you made, so it is
> likely I've got it totally wrong ), I think that creating such a
> document provides a unique opportunity to document things that the more
> experienced developers take for granted but is a complete enigma for
> beginners in programming and using computers in general.

This comment also baffles me.


> Good luck with your effort!

Thanks!


Cheers,

- Alf

"Richard Heathfield" wrote:

> A man who cannot express what he needs to express /without/ resorting
> to .pdf format is computer-illiterate.

What format do you suggest? I have some ideas on what I would have used,
but you seem to love these veiled references that there is a better way, if
the OP had just been smarter. Did it ever occur to you that this is not
very helpful and might even be annoying?

* James Harris:
> On 28 Oct, 08:58, "Alf P. Steinbach" <al...@start.no> wrote:
>> * tm:
>>
>>> On 28 Okt., 07:52, "Alf P. Steinbach" <al...@start.no> wrote:
>>>> [Cross-posted comp.programming and comp.lang.python]
>>> Looking at your topic '(Python in Windows)', without taking a
>>> glimpse at your actual introduction, I have the following to say:
>>> I think it is not a good idea to teach programming with a focus
>>> on a specific operating system. Programming should IMHO be taught
>>> without reference to an operating system. Otherwise you just teach
>>> how to write unportable programs.
>> I think you're trolling a little.
>
> Whether tm is promoting his own language or not I agree with some of
> his comments. I was going to avoid giving any feedback because most of
> my thoughts are, I'm afraid, negative but seeing your response to tm
> here I changed my mind. You asked for feedback. Hopefully you are
> looking for genuine criticism and honest opinions rather than flattery
> 'cause I'm not going to flatter.
>
> If you want to teach programming then target programming concepts
> (albeit using Python as a means to express them) and as tm says, avoid
> teaching either a particular OS or a particular set of bundled tools.
>
> If you want to teach programming under Windows then change the title
> to say so.

The working title says "in Windows".

But you have a misconception, a false dichotomy.

Learning programming in some concrete environment, which is a practical
necessity, is not to learn programming for that environment.


> Sorry but I find the overall tone too patronising. Phrases like "send
> your browser galloping in the direction of" are offputting. With this
> and other phrases it sounds like you are either
>
> 1) writing this for young children, or
> 2) having more fun writing it than your readers will have reading it
> or,
> 3) being self-indulgent and not planning to help others at all.
>
> I know you don't mean any of these. Hopefully you can change the
> approach to suit. There are many of these jocular phrases and they
> appear in both chapters.

Ah, don't be so stuffed-up!


> Given that this is a Windows-based course it's good that you include
> teaching on Notepad rather than just the IDE.

No, I don't intend to teach Notepad or any editor or IDE.


> The x squared graph is a good example to show that some fun can be had
> in a small space.

Thanks.


> I wouldn't condemn but I would query the use of Activestate's
> distribution. A vanilla Python may have been better if you want to
> teach transportable skills. Teaching Activestate reminds me of how
> Compuserve bundled their own stuff with Internet access so people
> thought the Internet was what they saw on Compuserve.

ActiveState is simplest to install.

However, given what I've now learned about the current situation wrt. versions
of Python, where Python 3.x is effectively a new language, and where apparently
ActiveState has no installer for that, I'm rewriting to use the "official"
distribution.

It has some bugs in the installer and is in many respects incompatible with the
information the student can find and will most easily stumble on on the net,
even the sites that the 3.1.1 documentation links to (e.g. now "tkinter" instead
of "Tkinter", now "/" does not perform integer division and there goes my
example of that, so on), but it's a more clean language.


> You get way too deep into Python in places (for a beginner's course in
> programming). For example, "from now on I’ll always use from
> __future__ in any program that uses print."

Sorry, but I think that hiding such concerns is a real disservice.

Nobody learns to swim by reading.

They can at best learn something /about/ swimming, but not swimming.


> The MIT course that you mention takes a more apt approach for teaching
> *programming*. For example, it explains some things like floating
> point numbers in Python not being able to express 0.1 perfectly in
> binary but that's appropriate as other languages have the same issue.

I believe in mostly going from the concrete to the abstract.

Sometimes theory has to precede the concrete examples.

Sometimes, and most often, theory is best served after having seen what it's all
about.


> As you say, you are an experienced programmer who is learning Python
> and the chapters read that way. They rush in to all kinds of gotchas
> and mechanisms. Perhaps you should either change it to be a book on
> learning Python for experienced programmers (this seems the best
> option) or start again and take a different approach.

I'm sorry but the above is not meaningful to me. What gotchas? What "mechanisms"?


> With what you have written so far your audience seems to be youself
> (or someone in your position).
>
>> 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.
>
> There's a difference between referring to an OS and tieing it in
> throughout the text which is what I think tm was getting at.

I'm sorry but this again is not meaningful to me. It seems more like you'd wish
there was some strong tie-in to an OS somewhere. But have you found one? No. So,
it's just hogwash.


>> 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...
>
> OSes generally support concepts of files and editors. If you cannot
> teach the general concepts make it clear that you are teaching
> Activestate Python under Windows.

I'm sorry but you have a misconception about ActiveState. It's not a special
dialect of the Python language. It's just an installation package.

Anyone is free to install more things with any Python distribution.


>> In addition there's the motivational factor.
>>
>> Doing only academic examples, utilizing only a language's more or less portable
>> functionality, is very de-motivational, while the opposite is motivational.
>
> The graphics and examples are fun. Be clear about what you are
> teaching, though, and who your intended audience is.

Thanks!


> ...
>
>>>> C++ was way too complex for the novice, JScript and C# suffered from too
>>>> fast-changing specifications and runtime environment, Java, well, nothing
>>>> particularly wrong but it's sort of too large and unwieldy and inefficient.
>
> Agreed. Python is a good introductory language.
>
>>>> I don't know whether this will ever become an actual book. I hope so!
>
> It's a good start.
>
>>>> But since I don't know much Python -- I'm *learning* Python as I write
>
> This and that you are an experienced programmer show in what you have
> written. If you don't recast the material for a beginner now it will
> only get harder to change the approach later.

What exactly do you think is difficult for a beginner?

I'd like to fix up those parts.

But I find this inconsistent with your comment about starting with theory about
floating point representations and the like, which *is* difficult for beginners.


> ...
>
>> Yes, it would be silly to write a book or whatever about Python. This text is
>> primarily about programming, at the novice level, not about the Python language.
>> The programming language is only a vehicle.
>
> It doesn't seem that way. Whether intended or not the text is about
> Python.

I'm sorry, that's just silly.


> ...
>
> I don't think you will get my meaning and will want to stick to what
> you have started so I'll try to illustrate:
>
> If you really want to teach *programming* start by planning out what
> concepts you need to teach. You might come up with a list such as:
>
> 1. Values, types, variables, expressions.
> 2. Immediate and stored operations.
> 3. Statements, functions, arguments and parameters.
> 4. Control flow.
> 5. etc.

Yes, that's a good summary of the so-far-completed part of ch 2. Thanks!


> Once you have worked out the concepts you want to teach break them
> down to key points and then think about how to express them in the
> language you have chosen.
>
> If, on the other hand, you want to teach Python to experienced
> programmers, carry on as you are doing. Judged from that position I
> would rate the text far more positively.

It's difficult to understand your point of view. It's inconsistent. The only
consistency I detect, but this may of course be a false impression, is some kind
of old-fashioned academic flavor (teaching hard to grok theory first, avoiding
dirty actual programming, avoiding "jokular" phrases), with the emphasis on a
surface impression of respectability or something like that -- and IMHO that's
only a hindrance for learning.


Cheers,

- Alf