Feedback wanted on programming introduction (Python in Windows)

[Alf P. Steinbach]

* Jon Clements:

Inline reply:

* Jon Clements:

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

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]

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

 

[Dann Corbit]

[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"?

 

[Dann Corbit]

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.

 

[Alf P. Steinbach]

* Dann Corbit:

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"

 

[Gabriel Genellina]

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.

 

[Dennis Lee Bieber]

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)

 

[Dotan Cohen]

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.

 

[Alf P. Steinbach]

* Martin P. Hellwig:

* tm:

[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

 

[osmium]

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?

 

[Alf P. Steinbach]

* James Harris:

* tm:

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


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.

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.

The graphics and examples are fun. Be clear about what you are
teaching, though, and who your intended audience is.
Thanks!



Agreed. Python is a good introductory language.


It's a good start.


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.

...


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

 

[Martin P. Hellwig]

Alf P. Steinbach wrote:

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

Well, in the college where I used to train my pupils I had written a
number of 'modules' (as in the semester was split into modules).

Here are some names of my modules:

The Computer
(Mostly History)

Storing and Finding Data.
Depending Module - The Computer
Included OS where Mac OS X, Debian (Ubuntu these days) and Windows XP

Text processing
Depending Module - Storing and Finding Data
Open-Office, Word, Notepad given as examples, emphasizing that writing
text does not have anything to do with mark-up.

Data processing
Depending Module - Storing and Finding Data
Open-Office, Excell, grep, sed & awk

Basic Networking
Depending Module, Text and Data processing
This was mostly a fun session to give something lighter after the
previous heavier modules. Showing http, ftp, nntp, bittorrent and
different chat systems

Collaboration and Research
Depending Module, Basic Networking
This concentrates primarily on how to use collaboration tools and how to
write search queries that have more chance to give back what you are
looking for.

The modules above had tests written for them.
The tests where platform specific, though you needed to choose 2
platforms from the given 3. And all tests must have been successful for
passing the module (otherwise you needed to redo the module)

So my module 'Introduction Programming', did not start on page whatever,
but it did say you needed to have passed modules, x,y and z first.

Oh and I don't know about real programming either, the first chapters
relied on printing out paper using scissors to cut out functional blocks
and rearrange them so that they would do a specific task.

I used to teach a bit of Python because in my opinion it is the simplest
platform independent language available, however my students where
allowed to do it in whatever language they liked (including pseudo
code), as long as they can show me the source code and explain it line
for line.

Most of them however did use Python because it was a convenient way for
them to be sure they solved the problem correctly. But then again this
was college and the lessons where only voluntary

About 80% of any given class did show up though, probably because I
promised them how to find their homework more easily on the net and
change it so the teachers wouldn't notice and in the advance courses
(which programming is part of) I promised them to give them enough
knowledge so they can bypass the schools firewall/filter.

 

[Ethan Furman]

* James Harris:


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

The disservice is in teaching folks to use non-standard elements, which
is (sort-of) what __future__ is. Changes to the language are
experimented with in __future__ and can change from one release to the
next. If memory serves, the with statement is an example of having
different behavior when it was moved out of __future__ and made a
standard part of the language.

~Ethan~

 

[Alf P. Steinbach]

* Richard Heathfield:

The best way is the simplest technology that will do the job properly.
If that truly is PDF, okay, use PDF. But it is hard for me to
envisage circumstances where Web content is best presented in that
way.

Google docs sharing. It made a mess of my *Word* documents. <g>

Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Ethan Furman:

The disservice is in teaching folks to use non-standard elements, which
is (sort-of) what __future__ is. Changes to the language are
experimented with in __future__ and can change from one release to the
next. If memory serves, the with statement is an example of having
different behavior when it was moved out of __future__ and made a
standard part of the language.

That's a bit of a straw man argument. I used "from __future__" to write
forward-compatible calls of print, so that those examples would not mysteriously
work or not depending on the Python version. I did not use it to access
experimental features.

However, I didn't know then that the language has changed so much in 3.x that it
isn't practical to aim at general forward compatibility or version independence.

And I didn't know until your comment above that some features, apparently, only
exist in __future__ but are not part of the language, subject to change.

Is there a current example?

And, just a suggestion, would it not be better to have a different name for such
experimental (as opposed to future language version) features, e.g. "from
__experimental__", differentiating between forward compatibility in e.g.
production code, and trying out experimental subject-to-change features?


Cheers,

- Alf

 

[osmium]

Er, no, I didn't have that in mind at all.

In some cultures, implying that someone is illiterate suggests "not smart".
There is a formal disconnect there but possibly you can see how someone
might infer that.

At least I found out what your choice was, HTML, same as mine.

 

[Benjamin Kaplan]

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.

ActiveState does have Python 3 installers. They've had them almost
since the day it was released. It's just not the default because many
of the libraries people use haven't been ported yet.

https://www.activestate.com/activepython/downloads/

 

[Trent Mick]

However, given what I've now learned about the current situation wrt.

...
ActiveState does have Python 3 installers. They've had them almost
since the day it was released. It's just not the default because many
of the libraries people use haven't been ported yet.

https://www.activestate.com/activepython/downloads/

Also:
http://www.activestate.com/activepython/python3/



Trent

 

[Alf P. Steinbach]

* Benjamin Kaplan:

ActiveState does have Python 3 installers. They've had them almost
since the day it was released. It's just not the default because many
of the libraries people use haven't been ported yet.

https://www.activestate.com/activepython/downloads/

Oh well, thanks, but now I've spent some time on *reworking* the text (it took
some time because I had to uninstall and install again to create new screenshot,
and, thus discovered the module docs server in the mainstream distribution .

Is there such a thing also in the ActiveState 3.x distribution?

Since Python has so many batteries included I'm fairly sure that 3rd party
libraries won't be needed. Or, I can probably wing it if necessary.


Cheers,

- Alf

 

[Ethan Furman]

* Ethan Furman:


That's a bit of a straw man argument.

You don't agree, so it's a straw man? You didn't know, and when the
information is pointed out, it's a straw man?

I used "from __future__" to write
forward-compatible calls of print, so that those examples would not
mysteriously work or not depending on the Python version.

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information. File "<stdin>", line 1
SyntaxError: future feature print_function is not defined

Hmmm... Doesn't seem to work in 2.5. So much for not working on a
different version.

I did not use
it to access experimental features.

From what I've seen of your posts so far, you wouldn't have known if
the print in __future__ was slightly different from the actual print in
3.x anyway.

However, I didn't know then that the language has changed so much in 3.x
that it isn't practical to aim at general forward compatibility or
version independence.

And I didn't know until your comment above that some features,
apparently, only exist in __future__ but are not part of the language,
subject to change.

Which is precisely the point raised by several -- writing a book for
novices, while still a novice, is going to be risky... especially if you
keep disregarding good advice about what to include and exclude.

Is there a current example?

And, just a suggestion, would it not be better to have a different name
for such experimental (as opposed to future language version) features,
e.g. "from __experimental__", differentiating between forward
compatibility in e.g. production code, and trying out experimental
subject-to-change features?

You're missing the point. If it's in __future__ it's subject to change.
Most likely it won't be a drastic change, but it *can* change. The
'experimental' is more along the lines of "hey, this is coming down the
pike, let's do some stress-testing so we can nail down the final
implementation".

~Ethan~

 

[bartc]

[Cross-posted comp.programming and comp.lang.python]

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.

Have you ever done technical writing before? With positive feedback?

You use the highly commercial-looking activatestate website; what's wrong
with www.python.org?

You say elsewhere that you're not specifically teaching Python, but the text
is full of technical details specific to both Python and Windows, not much
actual programming!

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.