Feedback wanted on programming introduction (Python in Windows)

A

Alf P. Steinbach

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

- Alf

PS: Please use the groups, this thread, for feedback; not e-mail. -DS
 
C

Chris Rebert

[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.
   http://preview.tinyurl.com/progintro

Cheers,

- Alf

PS: Please use the groups, this thread, for feedback; not e-mail. -DS

- The slogan is "batteries included", not "all batteries included".
- As a user of the platform, I can tell you it's "Mac OS X" (with a
space, not a slash).
- ActivePython is a distribution, not an implementation. It's just the
standard CPython from python.org with some bundled extras.
- I might consider making the first example multiline. Most cringe at
the use of semicolons in a Python program, although I can understand
it might be easier for the newbie to type correctly.
- You might mention how unit testing is used in interpreted languages
to detect many sorts of errors detected by the compiler in compiled
languages

Cheers,
Chris
 
S

Steven D'Aprano

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?
 
A

Alf P. Steinbach

* Chris Rebert:
[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.
http://preview.tinyurl.com/progintro

Cheers,

- Alf

PS: Please use the groups, this thread, for feedback; not e-mail. -DS

- The slogan is "batteries included", not "all batteries included".
- As a user of the platform, I can tell you it's "Mac OS X" (with a
space, not a slash).

Thanks!

I'll fix that right away. :)

- ActivePython is a distribution, not an implementation. It's just the
standard CPython from python.org with some bundled extras.

Thanks, but it's also a language implementation, the way I use that word :).
This is the same as the MinGW g++ C++ compiler is a language implementation, in
spite of being just a packaging of the CygWin compiler. Its origin doesn't
matter. But perhaps there is some better term than implementation, something not
involving discussing distributions and derivative works and so on? I.e. a term
that can be introduced in one line of text and is even more clear?

- I might consider making the first example multiline. Most cringe at
the use of semicolons in a Python program, although I can understand
it might be easier for the newbie to type correctly.

Hm. I didn't know that about "most cringe at" semicolons in Python. But I still
think the example is better on one line: short, concise, not introducing extra
tool usage (which is what the reader absolutely *has* to relate to).

- You might mention how unit testing is used in interpreted languages
to detect many sorts of errors detected by the compiler in compiled
languages

Yes, later. Unit-testing is done also for statically type checked languages. The
big difference lies in how much testing and at what time; this involves in
particular test-driven development (TDD). And it's touchy. Proponents of this
and that methodology will invariably argue that their methodology is best... :)



Cheers, & thanks,

- Alf

PS: I added back in [comp.programming], since I think it's simplest to have all
the discussion, both Python-specific and general, in one single thread.
 
J

Jon Clements

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?

Umm, seem to have woken up in a good mood this morning (for a change);
just in case the OP can't...

http://datasyzygy.com/alf/01 - getting started.pdf
http://datasyzygy.com/alf/02 - asd.pdf

Jon.
 
T

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

I may finally have found the perfect language for a practically oriented
introductory book on programming, namely Python.

What is considered 'perfect' depends on the point of view. Languages
have assets and drawbacks and I don't even use the term 'perfect'
for my own language. :) There is always room to improve. Some of
the features I consider important are discussed here:

http://seed7.sourceforge.net/faq.htm
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.

While many people consider Java inefficient they do so in comparison
to C/C++. I doubt that Java is inefficient compared to most
interpreted languages.
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

Normally I prefer books written by people who already know the
stuff they are writing about. I would consider that it is not a good
selling argument when a book was written to *learn* a language. :)

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
A

Alf P. Steinbach

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

Doing only academic examples, utilizing only a language's more or less portable
functionality, is very de-motivational, while the opposite is motivational.


What is considered 'perfect' depends on the point of view. Languages
have assets and drawbacks and I don't even use the term 'perfect'
for my own language. :) There is always room to improve. Some of
the features I consider important are discussed here:

http://seed7.sourceforge.net/faq.htm


While many people consider Java inefficient they do so in comparison
to C/C++. I doubt that Java is inefficient compared to most
interpreted languages.


Normally I prefer books written by people who already know the
stuff they are writing about. I would consider that it is not a good
selling argument when a book was written to *learn* a language. :)

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.

However, as a vehicle the language needs to be suited for transport of the
novice. :)

And it seems that Python is very well suited for that.


I'm not familiar with Seed, sorry.


Cheers, & thanks for your thoughts,

- Alf
 
E

eb303

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.

OK, I'll start the flame war then: I can see the purpose of section
1.5, but from the end of the 3rd paragraph, you seem to go into
religious matters rather than actual facts, which seems to me a bit
out of place in a book only supposed to teach programming. Basically
saying that any "serious" program has to be written in a statically
typed language and that such a language kind of automatically makes
the development faster and the quality higher is just not true from my
experience, and from the experience of many people on this group, I
guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
highly subjective and should be completely rewritten, if not simply
removed.

Sorry if that sounds rough: I've seen this written too many times
(usually without any argumentation, BTW) and it has a tendency to make
me a little upset.
 
J

Jon Clements

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... 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 which includes COM interop etc...
(although I hope this would appear much later, if at all).

Cheers,

Jon.

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

Martin P. Hellwig

Alf said:
* 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.

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.

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.

Good luck with your effort!
 
A

Alf P. Steinbach

* eb303:
OK, I'll start the flame war then: I can see the purpose of section
1.5, but from the end of the 3rd paragraph, you seem to go into
religious matters rather than actual facts, which seems to me a bit
out of place in a book only supposed to teach programming. Basically
saying that any "serious" program has to be written in a statically
typed language

No, I didn't write that.

and that such a language kind of automatically makes
the development faster and the quality higher

No, I didn't write that.

is just not true from my experience,

Yes, that's a strawman -- nearly always good in flame wars. ;-)

and from the experience of many people on this group, I
guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is
highly subjective and should be completely rewritten, if not simply
removed.

Just to fuel the flame war, consider a million line Python system. It's not
uncommon with C++. :)

Sorry if that sounds rough: I've seen this written too many times
(usually without any argumentation, BTW) and it has a tendency to make
me a little upset.

Sorry if the above sounds a little harsh, but, u know, flame wars & all that. He
he. Thanks anyway!


Cheers,

- Alf
 
E

eb303

* eb303:



No, I didn't write that.


No, I didn't write that.

Well, honestly, this is really what I understood when I've read:
"the compiler can detect a lot of errors and save you from having to
painstakingly & laboriously test every little detail. For a large
program or system that really cuts down on the work (and hence time)
and really increases quality"
which what you did write, right?

So maybe it is an understanding problem on my side, but even if it is,
other people may have the same as I had, don't you think?
Yes, that's a strawman -- nearly always good in flame wars. ;-)


Just to fuel the flame war, consider a million line Python system. It's not
uncommon with C++. :)

Well, I won't go into how C++ code tends to be quite longer than their
Python equivalent (maybe I'm not too good at flame wars after
all... ;-) ). But the application I'm working on right now includes
nearly 300000 lines of Python (among other languages). That's not a
million indeed, but I wouldn't call it a small application. I've done
a lot of C, Java, and some C++ as well before. And so far, what I'm
seeing is that if you organize your work properly (TDD mainly...), the
development goes faster, with no significant decrease in quality for
the final product. So yes: I would consider a million line Python
system without fear.
 
J

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.

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.

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

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

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.

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

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.

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.

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

....

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.

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

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.

HTH

James
 
F

Francesco Bochicchio

Just to fuel the flame war, consider a million line Python system. It's not
uncommon with C++. :)

In python, with one-miliion lines of code, you can demonstrate
the existence of God, and then demostrate its non-existance by
changing a single line of code :)


Ciao
 
A

Alf P. Steinbach

* eb303:
* eb303:
[snip]
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.
OK, I'll start the flame war then: I can see the purpose of section
1.5, but from the end of the 3rd paragraph, you seem to go into
religious matters rather than actual facts, which seems to me a bit
out of place in a book only supposed to teach programming. Basically
saying that any "serious" program has to be written in a statically
typed language
No, I didn't write that.
and that such a language kind of automatically makes
the development faster and the quality higher
No, I didn't write that.

Well, honestly, this is really what I understood when I've read:
"the compiler can detect a lot of errors and save you from having to
painstakingly & laboriously test every little detail. For a large
program or system that really cuts down on the work (and hence time)
and really increases quality"
which what you did write, right?

Yes that's what I wrote. What I intended to communicate was literally what I
wrote (which is true), but that's very far from what you understood, e.g. it
seems that you read my word "can" as, quoting you, "will automatically",
apparently with an implied "always".

So maybe it is an understanding problem on my side, but even if it is,
other people may have the same as I had, don't you think?

Some will have the same misreading, and some will probably have other misreadings.

I could reformulate it to cater for people who'd tend to read it your way and
other ways, but one the problem with that is that there are so many possible
ways to read a text when one s/can/will automatically/g, insert frivoluous
claims about a "serious" (what's that?) category of programs, etc., and, being a
fallible human being, I would be bound to miss some of them. ;-).

Another problem is that delving into such details about possible things that
I've *not* intended to write, listing all possible such things I could imagine,
like, "note: I'm not claiming XYZ, even though that claim, made by some, is
vaguely associated with some of what I'm discussing", would make the first get
started chapter not 9 pages or whatever this one is, but 150 pages and going.

Well, I won't go into how C++ code tends to be quite longer than their
Python equivalent (maybe I'm not too good at flame wars after
all... ;-) ). But the application I'm working on right now includes
nearly 300000 lines of Python (among other languages). That's not a
million indeed, but I wouldn't call it a small application. I've done
a lot of C, Java, and some C++ as well before. And so far, what I'm
seeing is that if you organize your work properly (TDD mainly...), the
development goes faster, with no significant decrease in quality for
the final product. So yes: I would consider a million line Python
system without fear.

Uhm. :)


Cheers, & thanks for your comments,

- Alf
 
T

tm

* 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. :)

No, I just saw too much stuff which pretends to teach something, but
instead promotes an operating system. Contrary to many people I do
not believe that something is automatically better when it runs
under windows and when 'win' is part of the name.
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.

IMHO a beginner needs to use an editor and an interpreter or
compiler. How to copy and remove files and directories is helpful
also.
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...

I did not consider to teach programming without tools and without
using files. The common denominator for file systems is IMHO enough
to teach programming to beginners. Do you consider access control
lists, mount points and symbolic links essential for the programs
taught after 'hello world'?
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.

You obviously think that unportable programming is needed to
motivate people. This is IMHO far from true. There are many portable
programs which are motivational. I cannot provide portable Python
examples but examples of portable Seed7 programs can be found here:

http://seed7.sourceforge.net/scrshots/index.htm
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.

However, as a vehicle the language needs to be suited for transport of the
novice. :)

And it seems that Python is very well suited for that.

I can think of several reasons why some people would not see it this
way.
I'm not familiar with Seed, sorry.

Maybe you take the opportunity and look at it now. :)

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
A

Alf P. Steinbach

* Jon Clements:
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.

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.

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.

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?

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.

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.

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
 
J

Jon Clements

Inline reply:

* Jon Clements:



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



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.
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 :)
 
E

eb303

* eb303:


* eb303:
[snip]
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.
OK, I'll start the flame war then: I can see the purpose of section
1.5, but from the end of the 3rd paragraph, you seem to go into
religious matters rather than actual facts, which seems to me a bit
out of place in a book only supposed to teach programming. Basically
saying that any "serious" program has to be written in a statically
typed language
No, I didn't write that.
and that such a language kind of automatically makes
the development faster and the quality higher
No, I didn't write that.
Well, honestly, this is really what I understood when I've read:
"the compiler can detect a lot of errors and save you from having to
painstakingly & laboriously test every little detail. For a large
program or system that really cuts down on the work (and hence time)
and really increases quality"
which what you did write, right?

Yes that's what I wrote. What I intended to communicate was literally what I
wrote (which is true), but that's very far from what you understood, e.g. it
seems that you read my word "can" as, quoting you, "will automatically",
apparently with an implied "always".

Well, sorry to keep the topic going, but I have a really hard time
understanding your text as you claim you mean it. The word 'can' is
actually there, but in the first sentence, not in the second. And when
I read "For a large program or system that really cuts down on the
work (and hence time) and really increases quality" after stating the
supposed benefits of statically typed compiled languages, I do
understand that a "large program or system" just has to be written in
such a language, and certainly not in Python, which - again according
to my experience - I know is just not true.

But well, it seems I'm the only one around bothered by this text, so I
guess the problem is with me. So if I ever get to teach programming, I
guess I'll just have to find another book than yours... ;-)
Some will have the same misreading, and some will probably have other misreadings.

I could reformulate it to cater for people who'd tend to read it your way and
other ways, but one the problem with that is that there are so many possible
ways to read a text when one s/can/will automatically/g, insert frivoluous
claims about a "serious" (what's that?) category of programs, etc., and, being a
fallible human being, I would be bound to miss some of them. ;-).

Another problem is that delving into such details about possible things that
I've *not* intended to write, listing all possible such things I could imagine,
like, "note: I'm not claiming XYZ, even though that claim, made by some, is
vaguely associated with some of what I'm discussing", would make the first get
started chapter not 9 pages or whatever this one is, but 150 pages and going.





Uhm. :)

I'm serious. And even more: I'd fear a *lot* more a million lines
application written in C++... But I do have a problem with C++... ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top