Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach
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
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
--
http://blog.rebertia.com
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?
--
Steven
Alf P. Steinbach
> On Tue, Oct 27, 2009 at 11:52 PM, Alf P. Steinbach <al...@start.no> wrote:
>> [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.
> <snip>
>> 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.
Jon Clements
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.
Jon Clements
Maybe not quite 'woken up'...
http://datasyzygy.com/alf/01%20-%20getting%20started.pdf
http://datasyzygy.com/alf/02%20-%20asd.pdf
Richard Heathfield
<snip>
> I may finally have found the perfect language for a practically
> oriented introductory book on programming, namely Python.
<snip>
> I don't know whether this will ever become an actual book. I hope
> so!
<snip>
> So I would would be very happy for feedback.
"Sorry, but this browser does not support web word processing. Please
see our system requirements page for a list of supported browsers."
A Web site should be able to provide at least basic content provision
in *any* standard-conforming browser.
I've seen Steven's parallel comment along similar lines, and Jon
Clements's reply - which appears to solve the problem, albeit in a
semi-proprietary way. So I'm not asking for a solutio, just adding my
vote for "let's try to keep the Web as open to everyone as we can".
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
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.
Alf P. Steinbach
> 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.
Doing only academic examples, utilizing only a language's more or less portable
functionality, is very de-motivational, while the opposite is motivational.
>> 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. :-)
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.
> Seed7 Homepage: http://seed7.sourceforge.net
I'm not familiar with Seed, sorry.
Cheers, & thanks for your thoughts,
- Alf
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 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.
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... 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.
Martin P. Hellwig
> * 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.
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!
--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoning to own preference.'
Alf P. Steinbach
> On Oct 28, 7:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
> [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.
> 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
eb303
> * eb303:
>
> > On Oct 28, 7:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
> > [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?
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?
> > 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++. :-)
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.
James Harris
> * 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.
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.
...
> >> 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.
...
> 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
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
-----
FB
Alf P. Steinbach
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.
>>> 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++. :-)
>
> 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
tm
> * 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. :-)
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
I can think of several reasons why some people would not see it this
way.
> > Seed7 Homepage: http://seed7.sourceforge.net
>
> I'm not familiar with Seed, sorry.
Maybe you take the opportunity and look at it now. :-)
Alf P. Steinbach
> 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.
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
Jon Clements
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 :)
>
> The first exploratory programs a novice makes almost have to be text-oriented,
> thus, some exposure to the command interpreter from the start. And most
> programming languages' text i/o facilities, including those of Python, are
> oriented towards standard streams and redirection of them, done from some
> command interpreter. And most Windows users, those who'd like to learn
> programming, know nothing about that, so unless they learn in a setting with
> knowledgable people around, it needs to be addressed in the text they're using.
>
I've found the average Windows user (even Uni. students studying
programming) are somewhat amazed at the black window with white text
that pops up when they run cmd.exe. My favourite comment thus far is,
"Hey, it's like really dark and stuff, and it knows my name, is that
good?" :)
> > However, I'm sure you
> > would consider that if you were writing a C++ guide, you would promote
> > portability and the STL. Of course, both languages offer platform-
> > specific libraries. Maybe a 'down side' with Python is that the
> > "batteries included" also include some functions marked in the
> > documentation as "Available on Windows only" etc... And specifically
> > suggesting an ActiveState install
>
> I suggested ActiveState because I know from earlier that their packages are easy
> to install and provide documentation in reasonable Windows CHM help file format.
> I did try the IronPython .NET implementation first :-). But my experience with
> *nix folks' porting efforts is that they create Windows ports that don't handle
> spaces in paths, don't even handle backspace in dialogs they present, require
> undocumented environment variables set up (and explaining such takes a lot of
> pages & is demotivating), and just generally without any forethought or any
> reasonable automation, requiring a lot of explanation and hand-holding which
> would run to many pages, so I didn't even look at the CPython implementation.
>
> Perhaps I should.
Sorry you've had bad experiences. However, I would take a leap that
someone has used system/os specific calls (which are mostly un-
necessary) and that at least they've made an effort to port to
Windows. How many projects do you see authors porting from Win to
*nix? :)
[This could be construed as a slight rant, but oh well...]
>
> However, since ActivePython is said here to be just be CPython + packaging +
> stuff, I don't think there's any point in suggesting CPython, except perhaps to
> get version 3.x but that would currently have its own problems wrt. libraries
> and such, wouldn't it?
Libraries are moving towards the 3.* series. The development team have
provided tools to assist in migrating, but yes, it's not going to be a
smooth ride. I think the Python development team, and the timelines
planned, are brilliant - take for instance the Boost libraries, of
which some are only making it into the C++200X or whatever now.
>
> > which includes COM interop etc...
> > (although I hope this would appear much later, if at all).
>
> I haven't looked at that part of things yet in Python but I guess it's the same
> as with other languages, some Automation-interface.
>
> I can't think of anything useful to do with that, though, except that some
> hardware is supplied with Automation interface drivers.
>
> For example, if I wanted to automate Excel (Microsoft's spreadsheet) I'd rather
> do that in VBA in Excel than in Python with COM interop driving the Excel
> Automation model.
My most used tools for Excel (as you mention it) are listed on
www.python-excel.org where John Machin has done a brilliant job of a
platform independent library for reading content from excel
spreadsheets [check out xlwt (for writing) and xlutils (by Chris
Withers for convenience functions)].
>
> Microsoft has discontinued all the fun beginner's stuff that earlier was
> available via Automation.
>
> The only thing left in XP is the Microsoft assistant with an animated Wizard
> figure on the screen, but IIRC that's discontinued already in Vista.
Oh the memories! The fun of programming another one, and popping up
messages such as: "Are you making a phone call yet?", "You have a
virus, call your doctor" etc... etc...
Can't say I'm sad it's gone though :)
eb303
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... ;-)
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++... ;-)
Alf P. Steinbach
> 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
Dann Corbit
says...
Why is chapter 2 called "ASD"?
Dann Corbit
ste...@REMOVE.THIS.cybersource.com.au says...
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
>> 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"
Gabriel Genellina
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
Richard Heathfield
Corbit wrote:
> In article <hc8pn3$ddn$1...@news.eternal-september.org>, al...@start.no
> says...
>>
<snip>
>> 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"?
Presumably its subtitle is "Introducing UPPER CASE".
Richard Heathfield
Corbit wrote:
<snip>
>
> You can read PDF with the ghostscript stuff or the free Adobe stuff.
Agreed. But why should you have to?
> A man who cannot read .pdf or .ps in today's computer science world
> is a crippled man (IMO-YMMV).
A man who doesn't particularly enjoy relying on proprietary non-text
formats, however, is not crippled, just cautious.
A man who cannot express what he needs to express /without/ resorting
to .pdf format is computer-illiterate.
<snip>
Dotan Cohen
> 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
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
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
Alf P. Steinbach
> 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
Martin P. Hellwig
<cut> 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?".
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:
>
>> 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.
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~
Richard Heathfield
> "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?
Firstly, I want to make clear that I'm not objecting to the OP's use
of .pdf format - and even if I were (which I'm not), why should he
care? He should be choosing a format to suit his readers, not me!
My comment was more general. If .pdf is the right choice, fine, use
.pdf - but be aware that there will be some subset of potential
readers who are unable to use that format.
I wrote a little freebie program that is quite popular round here
(Physical World "here", not Usenet "here"), which uses a PDF reader
(you get to choose which one - Adobe, Foxit, whatever) for output. I
don't like that situation, but I had bitten the bullet and decided to
live with it. Two evenings ago, I was asked for Yet Another Copy
(perhaps I should charge for it), so I cheerfully installed it on the
user's desktop machine (Windows ME, would you believe), and then set
about configuring the reader, when... ouch! No PDF reader on the
machine. Not even an ancient Adobe version. Oh dear. Program suddenly
rendered completely useless for that person. An Internet connection
was available, but in the very limited time available I did not have
time to download and install a reader. I'll do what I can to fix that
over the next week or so, but it drove home the lesson that I need to
rewrite the program to use bitmaps instead.
So - what format do I suggest? That's easy - the simplest possible
format that will do the job. If unmarked text will do it, use text.
If that doesn't cut it, use HTML or some other markup language. If
that won't do, okay, use PDF or Word or WordPro or WordPerfect or
whatever your users have. Personally, for stuff I want to display
over the Web, I have always found HTML/CSS, together with common
graphics formats, to be perfectly adequate.
> I have some ideas on what I would have
> used, but you seem to love these veiled references that there is a
> better way,
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.
> if the OP had just been smarter.
Er, no, I didn't have that in mind at all.
> Did it ever occur to you that this is
> not very helpful and might even be annoying?
Judging by the tone of your replies to me, I'm perfectly sure that you
frequently (but not always) find my articles annoying. I also
frequently (but not always) find your articles annoying. Did that
ever occur to you? (I ask only for information - I'm really truly not
trying to get on your case here, although I recognise that it might
sound like it, hence this disclaimer.)
osmium
>> if the OP had just been smarter.
>
> 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.
Alf P. Steinbach
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
Alf P. Steinbach
>
> 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
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.
Trent Mick
>> 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.
> 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
--
Trent Mick
trentm at activestate.com
http://trentm.com/blog/
Alf P. Steinbach
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
bartc
"Alf P. Steinbach" <al...@start.no> wrote in message
news:hc8pn3$ddn$1...@news.eternal-september.org...
> [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.
--
Bartc
Ethan Furman
> * Ethan Furman:
>
>> Alf P. Steinbach wrote:
>>
>>> * James Harris:
>>>
>>>> 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.
>>
>> 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.
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.
>>> from __future__ import print_function
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~
Richard Heathfield
> "Richard Heathfield" wrote:
>
>>> if the OP had just been smarter.
>>
>> Er, no, I didn't have that in mind at all.
>
> In some cultures, implying that someone is illiterate suggests "not
> smart".
I don't see that at all. Babies are illiterate. Nobody knows whether
they're smart. In any case, I /said/ "computer-illiterate". Albert
Einstein was computer-illiterate.
> There is a formal disconnect there but possibly you can see
> how someone might infer that.
I can see how an unsmart person might infer that.
> At least I found out what your choice was, HTML, same as mine.
Naturally. It's the smart person's choice. :-)
Richard Heathfield
wrote:
> In <7ku6jhF...@mid.individual.net>, osmium wrote:
<snip>
>>
>> In some cultures, implying that someone is illiterate suggests "not
>> smart".
>
> I don't see that at all. Babies are illiterate. Nobody knows whether
> they're smart.
Clarification: nobody knows for sure how smart any given baby is, but
certainly some babies are going to be very smart indeed. Illiteracy
is clearly not a measure of unsmartness.
When I use the word "illiterate", I am describing, not insulting.
Likewise, when I use the word "literate", I am describing, not
praising.
Rhodri James
wrote:
> 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.
I'd say this was at best an extremely misleading statement. The robust,
dependable, usable, low-fat, carcinogen-free programs that I've written
fall into two categories; either they are embedded programs whose
environment is the silicon they're running on pretty much literally, or
they carefully *don't* know about their environment so run equally
effectively everywhere. It's the programs that do know about their
environment and go on to make assumptions about it that turn out
not to be robust, dependable, or very often usable.
> 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
Bwahahahahahahaha.
Uh, sorry. I know that wasn't terribly nice, but the politest answer
I can think of that gets over the utter wrongness of this assumption is
"Hell, no."
> 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.
You may or may not be aware that some of these things are limitations of
the underlying disc format, and some of them limitations of the API.
Laying them at the feet of Windows Explorer is a tad unfair.
> 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.
That rather depends on what tool you're using for what purpose. Tools
which require stonking amounts of flagging or button-pressing for simple
uses are IMHO bad tools. Most IDEs fall into this category. If your
tools make simple things hard, stop recommending them to people and get
better tools.
> 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.
Mercifully this is rubbish. For most purposes with most tools even
Windows users don't need to know much if anything about environment
variables and the registry. Needing to know anything about the
registry is usually a sign that Windows has stuffed you up royally.
> * Martin P. Hellwig:
>> 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.
The fact that you can say this and write "How to program" books
terrifies me. Don't make me compare you to Herbert Schildt!
--
Rhodri James *-* Wildebeest Herder to the Masses
Alf P. Steinbach
>
> "Alf P. Steinbach" <al...@start.no> wrote in message
> news:hc8pn3$ddn$1...@news.eternal-september.org...
>> [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?
Yes, and yes.
> You use the highly commercial-looking activatestate website; what's
> wrong with www.python.org?
I guess "commercial looking" is something negative.
Please note regarding the question: I'm not a telepath. I don't know what you
think is wrong with [www.python.org]. And I have no interest in evaluating the
site for you, at least not unless you pay me for that job.
> You say elsewhere that you're not specifically teaching Python, but the
> text is full of technical details specific to both Python
Yes. A programming language is required to do programming. Can't do without it,
sorry.
> and Windows,
> not much actual programming!
Hm. There's /only/ programming in there and nothing else so far. But given that
you think programming can be done without a programming language, I hypothesize
that there is something to learn for you about what programming is. :-)
> 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.
Well.
Alf P. Steinbach
Sorry no, it isn't.
Even assuming you meant the more reasonable "file system", no, it isn't.
Depending on the file system a program may be unable to create such things as I
mentioned. And depending on the program design it may be reasonable to refuse to
create them.
But a program should have no trouble deleting the files etc. once they're there.
That's why the Windows API handles them just fine, while Windows Explorer does
not. You may consider, since you're unfamiliar with the API, that mostly it's no
problem doing these things in the command interpreter, which has no special
support (rather, the reason it's easy is because it doesn't properly check
command arguments). And from that you can deduce that the API support is there.
> and some of them limitations of the API.
> Laying them at the feet of Windows Explorer is a tad unfair.
Sorry, no. That's where the responsibility is. No other program or API is
responsible.
>> 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.
>
> That rather depends on what tool you're using for what purpose. Tools
> which require stonking amounts of flagging or button-pressing for simple
> uses are IMHO bad tools. Most IDEs fall into this category. If your
> tools make simple things hard, stop recommending them to people and get
> better tools.
>
>> 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.
>
> Mercifully this is rubbish. For most purposes with most tools even
> Windows users don't need to know much if anything about environment
> variables and the registry. Needing to know anything about the
> registry is usually a sign that Windows has stuffed you up royally.
I deduce that you mainly use IDEs and don't know about the things you're
commenting on here (more than you did above). Sorry, but there it is.
>> * Martin P. Hellwig:
>>> 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.
>
> The fact that you can say this and write "How to program" books
> terrifies me. Don't make me compare you to Herbert Schildt!
I'm sorry but you haven't written anything correct in this article.
Steven D'Aprano
> Alf P. Steinbach wrote:
>> * James Harris:
>>
>>> 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.
>
> 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__
That is incorrect. Changes to the syntax or language semantics are
*introduced* with __future__, so as to avoid a sudden and disruptive
backwards incompatible change. If a feature makes it into __future__, it
is anything but experimental.
http://www.python.org/dev/peps/pep-0236/
There is nothing "non-standard" about features introduced with
__future__. The only thing that concerns me is that __future__ may be a
little too advanced for beginners.
> and can change from one release to the next.
Python guarantees that no feature will ever be removed from __future__.
It may become a no-op, but it will always be there. Note that 3.0 still
defines nested_scopes, even though that's been standard in the language
since 2.2:
[steve@sylar ~]$ python3.0
Python 3.0.1 (r301:69556, Apr 2 2009, 00:41:38)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import nested_scopes
>>>
>>> import __future__
>>> __future__.nested_scopes
_Feature((2, 1, 0, 'beta', 1), (2, 2, 0, 'alpha', 0), 16)
> 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.
I feel safe to claim you are wrong without even checking.
--
Steven
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Ethan Furman:
>>
>>> Alf P. Steinbach wrote:
>>>
>>>> * James Harris:
>>>>
>>>>> 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.
>>>
>>> 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.
>
> 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?
No. It's a "straw man" argument when the argument is made against something
that's not the real position -- often it's the opposite position -- of the
opponent. And that's what you (probably unwittingly, but literally) did: you
claimed the text used "non-standard elements" and therefore was subject to
changes in new versions of the language, while the reality was opposite: a
defense against changes in new versions, and improvement in that respect.
Not that it matters much now. ;-)
I mean, I've started the work to change the text to 3.1.1.
>> 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.
> >>> from __future__ import print_function
> 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.
That's a bit of a straw man argument. :-) "Forward compatibility" is one way.
What you illustrate is lack of "backward compatibility", which is the other way.
It would be utterly silly to try to make the examples backward compatible.
I mean, how far back? :-D
>> 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.
Then you probably haven't read the passage in ch 2 where I introduced that.
If so then I understand why you commented as you did -- misled by the other
poster's comment.
That happens a lot on Usenet, people use all kinds of rhetoric devices and
assumptions, sometimes intentionally and sometimes uninentionally, and sometimes
that "works", misleading others.
>> 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.
Yes, it's risky.
Although please note that I'm very far from a novice at programming.
I have, through the years, learned quite a number of programming languages
(started with Basic and 8080 assembler back around 1980), so I believe there is
a >0 chance of doing this with a positive result, but yes, risky!
And no, I'm not disregarding advice; on the contrary, the reason I asked for
feedback in a public forum was precisely because I'm *very* aware of the risk,
as I stated in the thread's starting article. But there is also a risk with this
public exposure, of course. Not everyone on Usenet is equally serious.
Btw., regarding the serious ones, I really appreciated your point about
"Tkinter" -> "tkinter", for example. ;-)
>> 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".
Does that mean that 'print' is still subject to change as of 3.1.1?
Cheers,
- Alf
alex23
> 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.
I hope the rest of your research is a little more thorough:
"Current releases of ActivePython are 2.6.3.7, 3.1.1.2, and 2.5.4.4."
Alf P. Steinbach
Thanks.
Several others have already mentioned the same else-thread, but thanks anyway! :-)
And no, I didn't do any research on that. If it mattered more (e.g. appearing as
statement in the text) I'd have done that. The nice thing about Usenet is that
people rush in to correct things. ;-) <url: http://xkcd.com/386/>
Cheers,
- Alf
bartc
>* bartc:
>>
>> "Alf P. Steinbach" <al...@start.no> wrote in message
>> news:hc8pn3$ddn$1...@news.eternal-september.org...
>>> [Cross-posted comp.programming and comp.lang.python]
>> You use the highly commercial-looking activatestate website; what's wrong
>> with www.python.org?
>
> I guess "commercial looking" is something negative.
>
> Please note regarding the question: I'm not a telepath. I don't know what
> you think is wrong with [www.python.org].
python.org seems to be the main site. Google "python download" and that is
the first hit.
Their windows download seems to be 13MB against the 32MB of activestate, and
the IDE provided seems more advanced that the 'console window' you have in
your tutorial. I'm just asking why your chose one over the other...
> And I have no interest in evaluating the site for you, at least not unless
> you pay me for that job.
...but if that answer is going to cost me money, then forget it. I think
that statement just answered it.
>> You say elsewhere that you're not specifically teaching Python, but the
>> text is full of technical details specific to both Python
>
> Yes. A programming language is required to do programming. Can't do
> without it, sorry.
You make it sound complicated however.
--
bartc
Bruno Desthuilliers
(snip)
> Microsoft's
> own Windows Explorer, the main GUI shell for Windows, which presumably
> was made by the best programmers available
Mouarf !!!
+1 JOFY (=> Joke Of The Year)
Alf P. Steinbach
>
> python.org seems to be the main site. Google "python download" and that
> is the first hit.
>
> Their windows download seems to be 13MB against the 32MB of activestate,
> and the IDE provided seems more advanced that the 'console window' you
> have in your tutorial. I'm just asking why your chose one over the other...
I've changed that choice, so it's not something very important, but an
ActiveState installation of some language generally Just Works, while other
installations of non-Windows-specific programming stuff generally doesn't,
requiring manual fixups.
For example, the mainstream Python 2.6 distribution failed to install when asked
to pre-compile (advanced option).
Regarding the "IDE" I'm not sure what you're referring to because there's no
such thing AFAICS. There's IDLE, which is referred to as an IDE but is (1) also
present in the ActiveState distribution and is (2) not really an IDE in any but
perhaps a formal sense. It's just a primitive editor with a primitive debugger
that, in Windows, has an annoying bug regarding highlighting of code.
[snippety]
Alf P. Steinbach
> * bartc:
>>
>> python.org seems to be the main site. Google "python download" and
>> that is the first hit.
>>
>> Their windows download seems to be 13MB against the 32MB of
>> activestate, and the IDE provided seems more advanced that the
>> 'console window' you have in your tutorial. I'm just asking why your
>> chose one over the other...
>
> I've changed that choice, so it's not something very important, but an
> ActiveState installation of some language generally Just Works, while
> other installations of non-Windows-specific programming stuff generally
> doesn't, requiring manual fixups.
>
> For example, the mainstream Python 2.6 distribution failed to install
> when asked to pre-compile (advanced option).
Sorry, I meant 3.1.1. I posted links to screenshots else-thread. Earlier.
Dann Corbit
r...@see.sig.invalid says...
>
> In <MPG.255246264...@news.eternal-september.org>, Dann
> Corbit wrote:
>
> <snip>
> >
> > You can read PDF with the ghostscript stuff or the free Adobe stuff.
>
> Agreed. But why should you have to?
As opposed to...?
PDF and PS are no more or less proprietary than any other format. And
Ghostscript is open source.
> > A man who cannot read .pdf or .ps in today's computer science world
> > is a crippled man (IMO-YMMV).
>
> A man who doesn't particularly enjoy relying on proprietary non-text
> formats, however, is not crippled, just cautious.
Since Ghostscript is an open source project, this is a non-sequitor.
> A man who cannot express what he needs to express /without/ resorting
> to .pdf format is computer-illiterate.
You have two choices at citeseer:
PDF, PS.
All college papers are also posed in one of those two formats.
It takes me about 7 seconds to download the latest reader from
Ghostscript/Ghostgum or Adobe. If I need to know the guts of these
formats, I can simply examine the Ghostscript guts. Quite frankly, I
don't care at all, since I am interested in the information content and
find the method of delivery utterly irrelevant.
To me, the argument is like objecting to money because it is either
paper or metal and you would prefer stone.
Everyone uses paper or metal and either is superior to stone anyway.
> <snip>
Alf P. Steinbach
>
> 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.
Hi.
I forgot or decided not to really answer this part earlier, so...
First of all, note that nothing of this is specific to Python.
(1)
"Where to put the program (typed in live or in a file)".
This is common to all languages that offer interpreted execution.
It is a feature, not a problem: in *addition* to putting your statements in a
file for later execution, i.e. in addition to creating ordinary programs, you
can explore the effects of statements by typing them at the interpreter.
Storing the statements in a file is to create a "program" in the usual sense.
Typing statements at the interpreter is just interactive use of the interpreter.
Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.
Which is very convenient. :-)
(2)
"the difference between console and graphical programs"
This is a Windows issue.
Windows makes this differentiation.
Thus, it's there *regardless* of programming language. And for example, it
doesn't matter whether the language offers an interpreter. With C or C++ you
tell the linker which subsystem you want. With Java you use 'java' or 'javaw' to
run the program as respectively console or GUI subsystem. With JScript and
VBScript (script languages bundled with Windows) you use 'cscript' or 'wscript'
to run the program as respectively console or GUI subsystem. With Ruby you use
'ruby' or 'rubyw' to run the program. And so on -- in the end it's always the
bottom level executing machine code program that is console or GUI subsystem.
Do you think I should mention this in the text?
It will make the text longer, and I worked hard to make ch 1 as *short* as
possible! :-)
(3)
"Whether to call the file .py or .pyw"
This is a feature, that you can relieve the user from the burden of choosing the
most sensible way to execute the file (the user doesn't have to choose whether
to use a console or GUI subsystem version of the interpreter, and the user
doesn't even have to know that there is an interpreter involved).
It's a common convention for many languages (using those languages' filename
extensions, of course), but it's not universal.
Cheers & hth.,
- Alf
PS: and yes, programming *is* a bit complex! That's what also makes it fun. <g>
Richard Heathfield
wrote:
> In article <XfWdnVPDB-3MkHTX...@bt.com>,
> r...@see.sig.invalid says...
>>
>> In <MPG.255246264...@news.eternal-september.org>, Dann
>> Corbit wrote:
>>
>> <snip>
>> >
>> > You can read PDF with the ghostscript stuff or the free Adobe
>> > stuff.
>>
>> Agreed. But why should you have to?
>
> As opposed to...?
Something you can grep.
<snip>
Mensanator
> * bartc:
>
>
>
> > 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.
>
> Hi.
>
> I forgot or decided not to really answer this part earlier, so...
>
> First of all, note that nothing of this is specific to Python.
>
> (1)
> "Where to put the program (typed in live or in a file)".
>
> This is common to all languages that offer interpreted execution.
>
> It is a feature, not a problem: in *addition* to putting your statements in a
> file for later execution, i.e. in addition to creating ordinary programs, you
> can explore the effects of statements by typing them at the interpreter.
>
> Storing the statements in a file is to create a "program" in the usual sense.
>
> Typing statements at the interpreter is just interactive use of the interpreter.
> Depending on the phase of the moon, one's shoe size and other factors <g>,
> what's typed may be called a "program". But it's not a program in the usual
> sense, it's not a stored program: it's just interactive use of the interpreter.
Unless you type something like:
>>> def Collatz(n):
while n>1:
if n%2 == 0:
n //= 2
else:
n = 3*n + 1
print(n)
which *IS* a stored program. It's just stored in RAM and will
be lost on shutdown if not specifically saved.
Even a single line is a "stored" program in the sense that you
can put your cursor on the line and hit return to repeat the
execution, so obviously, it's stored somewhere.
Alf P. Steinbach
Yes.
As you quoted me on:
Depending on the phase of the moon, one's shoe size and other factors <g>,
what's typed may be called a "program". But it's not a program in the usual
sense, it's not a stored program: it's just interactive use of the interpreter.
However, at least for [comp.programming] the term "stored program" has a
different often used meaning, the one that you employ above (which, by the way,
was not von Neumann's invention, he was falsely credited with that idea).
And perhaps that needs to be pointed out when or if I discuss stored programs,
like some kind of Wikipedia disambiguation page, so, thanks! :-)
But geneally getting into that kind of terminological fine distinction, such as
here, what can be regarded as "stored", isn't really useful, though. It assumes
an adversarial reading, which is not a useful assumption. And the only possible
way out with that assumption is to define all relevant terms in a very technical
way, which (1) leads to qualifications that end up being umpteen times longer
than a simple statement of whatever one attempts to communicate (like,
replicating all thousand+ pages of a technical language standard just to define
the concept of "variable", which is silly), (2) leads to ungrokkable lawyereese
language, absolutely not suitable for novices, and (3) in practice never
actually accomplishes the purpose of ironclad definitions, as evidenced by e.g.
"variable" in C++ still being subject to some disagreement over what it is...
I'm very very happy that most comments about perceived defects in the text and
in my responses here, have only disagreements over terminology. I had expected a
slew of errors being pointed out, since I'm new to Python. <g> Still, I'm fairly
sure that there actually *is* such a slew of errors, because there is in any
text of more than ten pages or so; any good book has a volumious errata list...
Cheers, & thanks,
- Alf
Richard Heathfield
<snip>
> I'm very very happy that most comments about perceived defects in
> the text and in my responses here, have only disagreements over
> terminology. I had expected a slew of errors being pointed out,
> since I'm new to Python. <g> Still, I'm fairly sure that there
> actually *is* such a slew of errors, because there is in any text of
> more than ten pages or so; any good book has a volumious errata
> list...
That's "voluminous", and I claim my $2.56. :-)
But of course you're right. No book is perfect, so every book /should/
have an errata list - at least until such time as an author can
correct errors in already-sold books. That not every book does have
such a list is therefore of some concern.
alex23
Unfortunately, the idiocy people say on the internet can be linked to
and referenced forever.
I guess it's better to say things like "you seem to have a bunch of
astoundingly ignorant preconceptions for someone passing themselves
off as a teacher" if I append a smiley to it, yeah? :)
Alf P. Steinbach
Don't know, but you sound like a troll.
Of course since you post anonymously it doesn't matter.
Goodbye,
- Alf
Rhodri James
wrote:
> * Rhodri James:
>> On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach <al...@start.no>
>> wrote:
>>> 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.
>> You may or may not be aware that some of these things are limitations
>> of
>> the underlying disc format,
>
> Sorry no, it isn't.
>
> Even assuming you meant the more reasonable "file system", no, it isn't.
Actually I should have mentioned the filing system as well as the disc
format (which does matter). I may not be using correct Windows
terminology,
since I'm referring to both the bytes on hardware and the software stack
that terminates in the OS API.
Still, colour me surprised. I had assumed that NTFS had some (large)
limit on filenames, and 256 sounded plausible. More to the point, I
was under the impression that path manipulation logic in the filing
system had limited sized buffers, which were the cause of this fault,
and that Exploder's only sin was not programming around the bug. In
fact, the more I think about it, the more sure I am that I've had to
play silly buggers on the command line myself to get around this.
> Depending on the file system a program may be unable to create such
> things as I mentioned. And depending on the program design it may be
> reasonable to refuse to create them.
>
> But a program should have no trouble deleting the files etc. once
> they're there.
Your faith is touching, but fundamentally misplaced.
> That's why the Windows API handles them just fine, while Windows
> Explorer does not. You may consider, since you're unfamiliar with the
> API, that mostly it's no problem doing these things in the command
> interpreter, which has no special support (rather, the reason it's easy
> is because it doesn't properly check command arguments). And from that
> you can deduce that the API support is there.
Having stuffed this up many, many years ago, my recollection is that
it needed a certain deviousness to get around. In the case of the long
path names, my deduction from comparing the behaviours of the command
line and Explorer was that the API limited the path name length, and
Explorer didn't use relative paths to get around it. I find it hard
to call that a bug, when it's only really exposing a limitation of the
underlying FS.
>>> 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.
>> Mercifully this is rubbish. For most purposes with most tools even
>> Windows users don't need to know much if anything about environment
>> variables and the registry. Needing to know anything about the
>> registry is usually a sign that Windows has stuffed you up royally.
>
> I deduce that you mainly use IDEs and don't know about the things you're
> commenting on here (more than you did above). Sorry, but there it is.
You deduce incorrectly. I'd unbend enough to admit that setting
environment variables is frequently very useful to inveterate command-
line users like myself, and that Windows makes that a lot harder than
necessary, but your original statement still reads like scaremongering.
Why am I defending Windows again?
Alf P. Steinbach
> On Fri, 30 Oct 2009 03:26:45 -0000, Alf P. Steinbach <al...@start.no>
> wrote:
>
>> * Rhodri James:
>>> On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach <al...@start.no>
>>> wrote:
>>>> 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.
>>> You may or may not be aware that some of these things are
>>> limitations of
>>> the underlying disc format,
>>
>> Sorry no, it isn't.
>>
>> Even assuming you meant the more reasonable "file system", no, it isn't.
>
> Actually I should have mentioned the filing system as well as the disc
> format (which does matter). I may not be using correct Windows
> terminology,
> since I'm referring to both the bytes on hardware and the software stack
> that terminates in the OS API.
>
> Still, colour me surprised. I had assumed that NTFS had some (large)
> limit on filenames, and 256 sounded plausible.
For NTFS it's 32K or 64K wide characters, I don't recall which. But what's
important is that that's also the API level limit. You can find most of the
details in Microsoft's documentation of CreateFile (but it's off-topic here).
Given that the API level makes it possible for long paths/names to exist, a
program should be prepared to handle them, although it may reasonably refuse to
create them. Windows Explorer fails to handle them. Not only to create them.
A filesystem may impose a lower limit, but a program should ideally not be
limited to or just work with a given filesystem (note: Windows supports multiple
different filesystems, but accessed via the same general API).
> More to the point, I
> was under the impression that path manipulation logic in the filing
> system had limited sized buffers, which were the cause of this fault,
> and that Exploder's only sin was not programming around the bug. In
> fact, the more I think about it, the more sure I am that I've had to
> play silly buggers on the command line myself to get around this.
>
>> Depending on the file system a program may be unable to create such
>> things as I mentioned. And depending on the program design it may be
>> reasonable to refuse to create them.
>>
>> But a program should have no trouble deleting the files etc. once
>> they're there.
>
> Your faith is touching, but fundamentally misplaced.
By the facts, if I believed that most programs have no problem it would be a
misplaced belief, yes (assuming that's what you mean above). But my argument and
concrete example was the opposite. It expanded on my statement that
"Unfortunately even most professional programs do not handle the requirements
of their environs very well"
So in what you quoted above I used "should" in the sense of the ideal to strive
for, and illustrated the harsh reality that it currently isn't that way, by the
concrete Windows Explorer example.
This is worth keeping in mind: in a Usenet discussion, context often disappears.
Looking up-thread is then one way to find out what it's all about. :-)
>> That's why the Windows API handles them just fine, while Windows
>> Explorer does not. You may consider, since you're unfamiliar with the
>> API, that mostly it's no problem doing these things in the command
>> interpreter, which has no special support (rather, the reason it's
>> easy is because it doesn't properly check command arguments). And from
>> that you can deduce that the API support is there.
>
> Having stuffed this up many, many years ago, my recollection is that
> it needed a certain deviousness to get around.
Yes.
<example>
C:\> md rhodri & cd rhodri
C:\rhodri> md \\?\c:\rhodri\con
C:\rhodri> dir
Volume in drive C is maindisk
Volume Serial Number is C469-4FA2
Directory of C:\rhodri
01.11.2009 22:16 <DIR> .
01.11.2009 22:16 <DIR> ..
01.11.2009 22:16 <DIR> con
0 File(s) 0 bytes
3 Dir(s) 18 405 834 752 bytes free
C:\rhodri> cd con
The system cannot find the path specified.
C:\rhodri> cd \\?\c:\rhodri\con
'\\?\c:\rhodri\con'
CMD does not support UNC paths as current directories.
C:\rhodri> rd \\?\c:\rhodri\con
C:\rhodri> _
</example>
To keep it short the above example is of something that no program really is
expected to handle. It's just an example of the mechanisms involved. Also, it's
nice with concrete examples, to show that one is not just blowing wind. :-)
> In the case of the long
> path names, my deduction from comparing the behaviours of the command
> line and Explorer was that the API limited the path name length, and
> Explorer didn't use relative paths to get around it. I find it hard
> to call that a bug, when it's only really exposing a limitation of the
> underlying FS.
No, it's not exposing a limitation of the underlying FS.
It's exposing a limitation in the way that the program deals with paths.
Apparently Windows Explorer uses fixed size buffers for paths, rather small buffers.
>>>> 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.
>>> Mercifully this is rubbish. For most purposes with most tools even
>>> Windows users don't need to know much if anything about environment
>>> variables and the registry. Needing to know anything about the
>>> registry is usually a sign that Windows has stuffed you up royally.
>>
>> I deduce that you mainly use IDEs and don't know about the things
>> you're commenting on here (more than you did above). Sorry, but there
>> it is.
>
> You deduce incorrectly. I'd unbend enough to admit that setting
> environment variables is frequently very useful to inveterate command-
> line users like myself, and that Windows makes that a lot harder than
> necessary, but your original statement still reads like scaremongering.
>
> Why am I defending Windows again?
Because I used a Windows-based concrete example. Then by attempting to raise
doubts about that which you found hard to believe, you got into an absurd
rhetorical position. He he, it happens very often, but happily you saw it at
once & adjusted: some folks just go on defending an indefensible position, they
happily disregard facts and logic, and then it gets, "interesting". :-)
Cheers,
- Alf
Rhodri James
wrote:
> * Rhodri James:
This is a weird attribution style, by the way. I don't think it helps.
Actually it's not, since it's a perfect example of the "not reading quite
carefully enough" others have pointed out before. You make this statement
as an absolute, iron-clad assertion. Checking the MS website, we find it
actually says:
"Maximum Path Length Limitation
In the Windows API (with some exceptions discussed in the following
paragraphs), the maximum length for a path is MAX_PATH, which is defined
as 260 characters."
The exceptions are unicode versions of some of the functions, which do
give you ~32K characters. However, the docs are pretty specific about
what is and isn't the API limit. Since this applies to the command
line just as much as to GUIs, I'll repeat my claim that blaming Explorer
for something that causes just as much grief on a command line is a
tad unfair.
More importantly, I accuse you of making very definitive statments
that turn out to be insufficiently researched. That's not an
encouraging state of affairs in someone planning to write a beginners'
textbook. Having originally learned C from one of Herbert Schildt's
books, I reckon I've earned the right to be highly allergic to this!
Alf P. Steinbach
> On Sun, 01 Nov 2009 21:20:20 -0000, Alf P. Steinbach <al...@start.no>
> wrote:
>
>> * Rhodri James:
>
> This is a weird attribution style, by the way. I don't think it helps.
That's a pretty weird thing to comment on.
And as far as I can see the comment doesn't make sense except as an attempt to
find something negative to say.
But anyway, the point about '*' was, once upon a time, that it made for a very
clear style of quoting in old newsreaders. Nowadays the tools are generally of
lesser quality (e.g. I'm using Thunderbird). And so it doesn't really have much
of that advantage left, but I'm using it anyway; I can be pretty stubborn about
issues of quality.
> Actually it [the limit]'s not
You're disputing a plain fact.
For which you've been given a technical reference, as well as concrete example.
I'm sorry, but it's idiotic to dispute plain facts.
>, since it's a perfect example of the "not reading quite
> carefully enough" others have pointed out before. You make this statement
> as an absolute, iron-clad assertion. Checking the MS website, we find it
> actually says:
>
> "Maximum Path Length Limitation
>
> In the Windows API (with some exceptions discussed in the following
> paragraphs), the maximum length for a path is MAX_PATH, which is defined
> as 260 characters."
>
> The exceptions are unicode versions of some of the functions, which do
> give you ~32K characters. However, the docs are pretty specific about
> what is and isn't the API limit.
I'm sorry but you're misunderstanding the documentation.
In your own words, you're "not reading quite carefully enough".
By the way, your technique of vague ad hominem attack here is detestable.
But anyway, if you read the documentation of CreateFile as I directed you to, or
simply read on where you was, then you get a more technically correct picture.
Or, by applying logic you can /deduce/ that since >260 character paths can and
do exist, 260 characters is not "the limit".
The MS documentation is unfortunately not all that clear. In many cases (the
most infamous one is perhaps the claim that a program's entry point is WinMain)
it's just plain incorrect, being written by technical writers. But it's simple
enough to write a few programs to check it out.
> Since this applies to the command
> line just as much as to GUIs,
No, it doesn't. And you've been given a concrete example of how.
You can't just go on *inventing* facts.
Facts are facts, your fantasies & wishes are your fantasies & wishes.
> I'll repeat my claim that blaming Explorer
> for something that causes just as much grief on a command line is a
> tad unfair.
I'm sorry, but there's a complete lack of logic in that, as well as misdirection.
First, regarding the misdirection, it is untrue that I have "blamed" Windows
Explorer for this. The blame, if any is to be affixed anywhere, belongs
elsewhere than with a computer program.
Second, regarding the logic, that a program exhibits low quality in some respect
is not OK just because there's another program that also exhibits low quality.
> More importantly, I accuse you of making very definitive statments
> that turn out to be insufficiently researched.
That would be OK and what I want. :-) But you haven't. You're making general
vague statements about quality, but haven't addressed any concrete thing in the
text. And what you have responded to here in this thread, it's all been
incorrect. In this latest article you have even started disputing simple
technical facts and started making fallacious deductions, shown above.
> That's not an
> encouraging state of affairs in someone planning to write a beginners'
> textbook. Having originally learned C from one of Herbert Schildt's
> books, I reckon I've earned the right to be highly allergic to this!
I'm sorry to hear that you had to endure that.
It's an old saying that the low price of Herbert's annotated C++ reference,
compared to the official standard, reflected the value of his annotations...
But that's no excuse to now start emulating Herbert, regarding blatant disregard
for facts and logic, as you've done above.
Thad Smith
> ... so I cheerfully installed it on the
> user's desktop machine (Windows ME, would you believe), and then set
> about configuring the reader, when... ouch! No PDF reader on the
> machine. Not even an ancient Adobe version. Oh dear. Program suddenly
> rendered completely useless for that person.
There is a Catch 22 for installing Adobe Reader from the Adobe site (
http://get.adobe.com/reader/ ) for the first time, without making a
blind promise: "By clicking the Download button you agree to the License
Agreements and Privacy Policies for the software included." Guess what
format the license agreement is in. ;-)
--
Thad
Pascal J. Bourguignon
Use xpdf to read it!
Then use xpdf to read the other pdf documents, and forget about
proprietary software?
--
__Pascal Bourguignon__
Rhodri James
wrote:
> * Rhodri James:
>> On Sun, 01 Nov 2009 21:20:20 -0000, Alf P. Steinbach <al...@start.no>
>> wrote:
>>
>>> * Rhodri James:
>> This is a weird attribution style, by the way. I don't think it helps.
>
> That's a pretty weird thing to comment on.
>
> And as far as I can see the comment doesn't make sense except as an
> attempt to find something negative to say.
>
> But anyway, the point about '*' was, once upon a time, that it made for
> a very clear style of quoting in old newsreaders. Nowadays the tools are
> generally of lesser quality (e.g. I'm using Thunderbird). And so it
> doesn't really have much of that advantage left, but I'm using it
> anyway; I can be pretty stubborn about issues of quality.
I'm struggling to recall as single instance of this in all of my Usenet
days. And failing.
And with that, I officially give up on you.
Alf P. Steinbach
Again, a '*' in attributions is a pretty weird thing to focus on.
But all you have posted so far in this thread has been technically incorrect
(even when you've been led by hand to technical doc), logically fallacious,
plus, and mostly, your vague unfocused negative feelings like above.
So, it's understandable. :-)
Cheers,
- Alf