Re: Feedback wanted on programming introduction (Python in Windows)
On Mon, 02 Nov 2009 00:49:50 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Sun, 01 Nov 2009 21:20:20 -, 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. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Rhodri James: On Mon, 02 Nov 2009 00:49:50 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Sun, 01 Nov 2009 21:20:20 -, 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Fri, 30 Oct 2009 03:26:45 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Thu, 29 Oct 2009 16:53:05 -, 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? -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Rhodri James: On Fri, 30 Oct 2009 03:26:45 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Thu, 29 Oct 2009 16:53:05 -, 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:16DIR . 01.11.2009 22:16DIR .. 01.11.2009 22:16DIR 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
Re: Feedback wanted on programming introduction (Python in Windows)
On Sun, 01 Nov 2009 21:20:20 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: This is a weird attribution style, by the way. I don't think it helps. On Fri, 30 Oct 2009 03:26:45 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Thu, 29 Oct 2009 16:53:05 -, 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). 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! -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Rhodri James: On Sun, 01 Nov 2009 21:20:20 -, 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. On Fri, 30 Oct 2009 03:26:45 -, Alf P. Steinbach al...@start.no wrote: * Rhodri James: On Thu, 29 Oct 2009 16:53:05 -, 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). 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.
Re: Feedback wanted on programming introduction (Python in Windows)
Richard Heathfield wrote: ... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Thad Smith thadsm...@acm.org writes: Richard Heathfield wrote: ... 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. ;-) Use xpdf to read it! Then use xpdf to read the other pdf documents, and forget about proprietary software? -- __Pascal Bourguignon__ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach al...@start.no wrote in message news:hcdlsp$9a...@news.eternal-september.org... * bartc: Alf P. Steinbach al...@start.no wrote in message news:hc8pn3$dd...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach a écrit : (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) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf, I kindly urge you to re-read bartc's comments. He does have a good point and you seem to be avoiding direct answers. On Fri, Oct 30, 2009 at 1:17 PM, Alf P. Steinbach al...@start.no wrote: * bartc: 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. As an author of a programming textbook, you have to make the reader comfortable in coding before he/she can do something useful, or play around with. When I read through yours, my impression was a lot of terms, and the examples don't seem to be particular interesting. They do what they do - practical feedbacks such as what type a literal is, but they don't teach the student how to self-teach. Try to grant imaginations. I think you can use a lot more examples that are actual programs, maybe 4-10 lines long, and actually does something interesting. It'll allow the reader more familiar seeing a code snippet that works, and in turn having them used to the syntax and so on. Complete examples are one of the best ways to teach. not much actual programming! Hm. There's /only/ programming in there and nothing else so far. I think bartc means you don't have actual examples. Sure you have a lot of examples, but they don't do anything. As a self-taught Python programmer, I only read /interesting/ tutorials and/or examples. I find your text filled with terms I didn't need to know until later, which I simply googled about. That reminds me a good point: allow the student to explore. Don't try to tell them everything, but show them the way. Once they start walking, they'll see new things for themselves. 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. Again here you're avoiding giving him answers. I just wanted to chime in and resonate with bartc's comment here: you do have a lot of unnecessary confusion in your first chapter. Why go through all the trouble to explain how to compile a program, or what's the difference between python and pythonw? You even went into try-except blocks and error-handling in the second chapter! That's a little... fast, don't you think? The reader/student hasn't done anything practical or interesting yet, and you're putting all these weight on him/her ... that's something for you to think about. I believe teaching needs to be interesting. While I appreciate your humour in the writing style, I was not thrilled by the examples you're using. Could you make your book more interesting to read by providing examples that do things, please? Also, last thing, could you use and instead of ampersand () in your book? That would be so awesome. It just irks me. I really don't know why. But heh, I suppose you can do that when you finish the book, with a quick find-and-replace. Best of luck and continue with your good efforts, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Fri, Oct 30, 2009 at 1:48 PM, Alf P. Steinbach al...@start.no wrote: Does that mean that 'print' is still subject to change as of 3.1.1? Funny that. They removed reduce() when Python moved from 2.6.x to 3.0. They even removed __cmp__(). Makes me a sad panda. Is print() subject to change as of 3.1.1? I'd say so. Nothing drastic, as others have pointed out, but anything is subject to change. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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). 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] Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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. 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] Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In article xfwdnvpdb-3mkhtxnz2dnuvz8nvi4...@bt.com, r...@see.sig.invalid says... In mpg.255246264331509a989...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In mpg.2554d283970cde989...@news.eternal-september.org, Dann Corbit wrote: In article xfwdnvpdb-3mkhtxnz2dnuvz8nvi4...@bt.com, r...@see.sig.invalid says... In mpg.255246264331509a989...@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 -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Oct 30, 2:07 pm, Alf P. Steinbach al...@start.no wrote: * 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 n1: 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Mensanator: On Oct 30, 2:07 pm, Alf P. Steinbach al...@start.no wrote: * 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 n1: 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In hcfj10$1o...@news.eternal-september.org, Alf P. Steinbach wrote: 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. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach al...@start.no wrote: 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/ 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? :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* alex23: Alf P. Steinbach al...@start.no wrote: 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/ 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? :) Don't know, but you sound like a troll. Of course since you post anonymously it doesn't matter. Goodbye, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
What would be good is if there was a balancing book eg. one specifically targeting ubuntu, which is gaining popularity as we mail. Agreed 100%. I opened this thread as I am learning Python, but my platform is Kubuntu. Of the students in my faculty, about one third have already moved to Ubuntu or some other Linux distribution. Windows-only tutorials just look outdated, even if their principles apply to other OSs as well. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Richard Heathfield wrote: A man who cannot express what he needs to express /without/ resorting to .pdf format is computer-illiterate. What format do you suggest? I have some ideas on what I would have used, but you seem to love these veiled references that there is a better way, if the OP had just been smarter. Did it ever occur to you that this is not very helpful and might even be annoying? -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Martin P. Hellwig: Alf P. Steinbach wrote: * tm: On 28 Okt., 07:52, Alf P. Steinbach al...@start.no wrote: [Cross-posted comp.programming and comp.lang.python] Looking at your topic '(Python in Windows)', without taking a glimpse at your actual introduction, I have the following to say: I think it is not a good idea to teach programming with a focus on a specific operating system. Programming should IMHO be taught without reference to an operating system. Otherwise you just teach how to write unportable programs. I think you're trolling a little. :-) Without reference to an OS you can't address any of the issues that a beginner has to grapple with, including most importantly tool usage, without which it's not even possible to get started, but also, very importantly, a file system. Learning programming without tools and without using files (or only using the common denominator for file systems in OSes X, Y and Z) is sort of vacuous... In addition there's the motivational factor. I conclude from this that your assumption is that the reader might not be competent enough to have basic portable knowledge of using a computer. Which is fair enough, however I would suggest writing an introduction to solve this fundamental absence of knowledge first before introducing concepts like programming in python for which already are a number of freely available/modifiable resources online. You're right that I assume no knowledge of the command interpreter, and just the most cursory knowledge of folder structure etc. However I would not phrase that in terms of competence :-). Writing an introduction to solve that knowledge gap problem is generally a good idea and I've done that a number of times. But having done that I know very well what it entails when it includes What The Student Should Know instead of just recipes. In an environment with other folks that the student can seek help from it works well, but in a book it's rather off-putting: hey, it's page 90!, when are we getting to do real programming?. And I'm not taking that page 90 from thin air. There's rather a lot to know about the environment that a program executes in if one is going to create robust, dependable, generally usable programs, not just toy examples. Unfortunately even most professional programs do not handle the requirements of their environs very well, and I think that educators, even such as I, have a responsibility to now start teaching students to do things right. To take but one example that you may or may not be aware of, Microsoft's own Windows Explorer, the main GUI shell for Windows, which presumably was made by the best programmers available with the best knowledge of the program's environment, is unable to handle (such as delete) files or folders with paths greater than some 260 characters, is unable to handle filenames that differ only in case and are in the same directory, and is unable to e.g. delete a folder called con -- although such files folders can very easily be created. In addition to such things impacting on the design and functionality of programs even just the tool usage is very complex and runs to a great many pages. For example, for general tool usage in Windows the student needs to know about levels of environment variable specifications and file associations, which in turn requires knowledge of processes and the Windows registry database and various commands. And there's stuff you don't find in most textbooks that, in an introduction for that knowledge gap, IMO needs to be there. For example, the student should ideally know that it's not a good idea to write MZ as the first two characters in a Windows text file, or to let a program do that. But instead of collecting all this stuff in a very long-winded introduction, my idea now is to just/mostly introduce it by way of programming examples, and then the student also gets the connection to how this functionality is from a programming perspective. I don't think it is a virtue to help adding to the pool of programmers unaware of the command line, whatever platform that might be. This comment baffles me. But ignoring the above (I assumed and assumption you made, so it is likely I've got it totally wrong :-) ), I think that creating such a document provides a unique opportunity to document things that the more experienced developers take for granted but is a complete enigma for beginners in programming and using computers in general. This comment also baffles me. :-) Good luck with your effort! Thanks! Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* James Harris: On 28 Oct, 08:58, Alf P. Steinbach al...@start.no wrote: * tm: On 28 Okt., 07:52, Alf P. Steinbach al...@start.no wrote: [Cross-posted comp.programming and comp.lang.python] Looking at your topic '(Python in Windows)', without taking a glimpse at your actual introduction, I have the following to say: I think it is not a good idea to teach programming with a focus on a specific operating system. Programming should IMHO be taught without reference to an operating system. Otherwise you just teach how to write unportable programs. I think you're trolling a little. :-) Whether tm is promoting his own language or not I agree with some of his comments. I was going to avoid giving any feedback because most of my thoughts are, I'm afraid, negative but seeing your response to tm here I changed my mind. You asked for feedback. Hopefully you are looking for genuine criticism and honest opinions rather than flattery 'cause I'm not going to flatter. If you want to teach programming then target programming concepts (albeit using Python as a means to express them) and as tm says, avoid teaching either a particular OS or a particular set of bundled tools. If you want to teach programming under Windows then change the title to say so. The working title says in Windows. But you have a misconception, a false dichotomy. Learning programming in some concrete environment, which is a practical necessity, is not to learn programming for that environment. Sorry but I find the overall tone too patronising. Phrases like send your browser galloping in the direction of are offputting. With this and other phrases it sounds like you are either 1) writing this for young children, or 2) having more fun writing it than your readers will have reading it or, 3) being self-indulgent and not planning to help others at all. I know you don't mean any of these. Hopefully you can change the approach to suit. There are many of these jocular phrases and they appear in both chapters. Ah, don't be so stuffed-up! :-) Given that this is a Windows-based course it's good that you include teaching on Notepad rather than just the IDE. No, I don't intend to teach Notepad or any editor or IDE. The x squared graph is a good example to show that some fun can be had in a small space. Thanks. I wouldn't condemn but I would query the use of Activestate's distribution. A vanilla Python may have been better if you want to teach transportable skills. Teaching Activestate reminds me of how Compuserve bundled their own stuff with Internet access so people thought the Internet was what they saw on Compuserve. ActiveState is simplest to install. However, given what I've now learned about the current situation wrt. versions of Python, where Python 3.x is effectively a new language, and where apparently ActiveState has no installer for that, I'm rewriting to use the official distribution. It has some bugs in the installer and is in many respects incompatible with the information the student can find and will most easily stumble on on the net, even the sites that the 3.1.1 documentation links to (e.g. now tkinter instead of Tkinter, now / does not perform integer division and there goes my example of that, so on), but it's a more clean language. You get way too deep into Python in places (for a beginner's course in programming). For example, from now on I’ll always use from __future__ in any program that uses print. Sorry, but I think that hiding such concerns is a real disservice. Nobody learns to swim by reading. They can at best learn something /about/ swimming, but not swimming. The MIT course that you mention takes a more apt approach for teaching *programming*. For example, it explains some things like floating point numbers in Python not being able to express 0.1 perfectly in binary but that's appropriate as other languages have the same issue. I believe in mostly going from the concrete to the abstract. Sometimes theory has to precede the concrete examples. Sometimes, and most often, theory is best served after having seen what it's all about. As you say, you are an experienced programmer who is learning Python and the chapters read that way. They rush in to all kinds of gotchas and mechanisms. Perhaps you should either change it to be a book on learning Python for experienced programmers (this seems the best option) or start again and take a different approach. I'm sorry but the above is not meaningful to me. What gotchas? What mechanisms? With what you have written so far your audience seems to be youself (or someone in your position). Without reference to an OS you can't address any of the issues that a beginner has to grapple with, including most importantly tool usage, without which it's not even possible to get started, but also, very importantly, a file system. There's a difference between referring to an OS and tieing it in throughout the text which is what I
Re: Feedback wanted on programming introduction (Python in Windows)
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. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In 7ktsj6f3bciq...@mid.individual.net, osmium wrote: 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.) -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Richard Heathfield: The best way is the simplest technology that will do the job properly. If that truly is PDF, okay, use PDF. But it is hard for me to envisage circumstances where Web content is best presented in that way. Google docs sharing. It made a mess of my *Word* documents. g Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Thu, Oct 29, 2009 at 1:24 PM, Alf P. Steinbach al...@start.no wrote: ActiveState is simplest to install. However, given what I've now learned about the current situation wrt. versions of Python, where Python 3.x is effectively a new language, and where apparently ActiveState has no installer for that, I'm rewriting to use the official distribution. It has some bugs in the installer and is in many respects incompatible with the information the student can find and will most easily stumble on on the net, even the sites that the 3.1.1 documentation links to (e.g. now tkinter instead of Tkinter, now / does not perform integer division and there goes my example of that, so on), but it's a more clean language. ActiveState does have Python 3 installers. They've had them almost since the day it was released. It's just not the default because many of the libraries people use haven't been ported yet. https://www.activestate.com/activepython/downloads/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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. ... 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Benjamin Kaplan: On Thu, Oct 29, 2009 at 1:24 PM, Alf P. Steinbach al...@start.no wrote: ActiveState is simplest to install. However, given what I've now learned about the current situation wrt. versions of Python, where Python 3.x is effectively a new language, and where apparently ActiveState has no installer for that, I'm rewriting to use the official distribution. It has some bugs in the installer and is in many respects incompatible with the information the student can find and will most easily stumble on on the net, even the sites that the 3.1.1 documentation links to (e.g. now tkinter instead of Tkinter, now / does not perform integer division and there goes my example of that, so on), but it's a more clean language. ActiveState does have Python 3 installers. They've had them almost since the day it was released. It's just not the default because many of the libraries people use haven't been ported yet. https://www.activestate.com/activepython/downloads/ 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach al...@start.no wrote in message news:hc8pn3$dd...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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? 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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In 7ku6jhf3a23e...@mid.individual.net, osmium wrote: 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 http://www.cpax.org.uk Email: -http://www. +rjh@ Usenet is a strange place - dmr 29 July 1999 Sig line vacant - apply within -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In yiudnvuxceucgxfxnz2dnuvz7thi4...@bt.com, Richard Heathfield wrote: In 7ku6jhf3a23e...@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. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Thu, 29 Oct 2009 16:53:05 -, Alf P. Steinbach al...@start.no 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* bartc: Alf P. Steinbach al...@start.no wrote in message news:hc8pn3$dd...@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. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Rhodri James: On Thu, 29 Oct 2009 16:53:05 -, Alf P. Steinbach al...@start.no 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, 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. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Thu, 29 Oct 2009 11:05:11 -0700, Ethan Furman wrote: 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: [st...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Ethan Furman: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach al...@start.no wrote: 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. From: http://www.activestate.com/activepython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* alex23: Alf P. Steinbach al...@start.no wrote: 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. From: http://www.activestate.com/activepython/ 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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). - 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote: Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Unfortunately Google wants me to change my browser, accept a privacy breach (cookies), and open a moderately large security hole in my browser (Javascript). Any one of these on its own, and I wouldn't mind; two of them, and I'd give it some thought; but all three, well, no thank you. I don't suppose you have these chapters available on a public website in an open document format like .odt or similar? Or even better, plain text with markup? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Chris Rebert: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On 28 Oct, 07:31, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote: Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Unfortunately Google wants me to change my browser, accept a privacy breach (cookies), and open a moderately large security hole in my browser (Javascript). Any one of these on its own, and I wouldn't mind; two of them, and I'd give it some thought; but all three, well, no thank you. I don't suppose you have these chapters available on a public website in an open document format like .odt or similar? Or even better, plain text with markup? -- Steven 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
2009/10/28 Alf P. Steinbach al...@start.no * Chris Rebert: 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? Distribution? - 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. -- http://mail.python.org/mailman/listinfo/python-list -- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On 28 Oct, 07:44, Jon Clements jon...@googlemail.com wrote: On 28 Oct, 07:31, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote: Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Unfortunately Google wants me to change my browser, accept a privacy breach (cookies), and open a moderately large security hole in my browser (Javascript). Any one of these on its own, and I wouldn't mind; two of them, and I'd give it some thought; but all three, well, no thank you. I don't suppose you have these chapters available on a public website in an open document format like .odt or similar? Or even better, plain text with markup? -- Steven 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.pdfhttp://datasyzygy.com/alf/02- asd.pdf Jon. Maybe not quite 'woken up'... http://datasyzygy.com/alf/01%20-%20getting%20started.pdf http://datasyzygy.com/alf/02%20-%20asd.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In hc8pn3$dd...@news.eternal-september.org, Alf P. Steinbach wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
Alf P. Steinbach wrote: * tm: On 28 Okt., 07:52, Alf P. Steinbach al...@start.no wrote: [Cross-posted comp.programming and comp.lang.python] Looking at your topic '(Python in Windows)', without taking a glimpse at your actual introduction, I have the following to say: I think it is not a good idea to teach programming with a focus on a specific operating system. Programming should IMHO be taught without reference to an operating system. Otherwise you just teach how to write unportable programs. I think you're trolling a little. :-) Without reference to an OS you can't address any of the issues that a beginner has to grapple with, including most importantly tool usage, without which it's not even possible to get started, but also, very importantly, a file system. Learning programming without tools and without using files (or only using the common denominator for file systems in OSes X, Y and Z) is sort of vacuous... In addition there's the motivational factor. I conclude from this that your assumption is that the reader might not be competent enough to have basic portable knowledge of using a computer. Which is fair enough, however I would suggest writing an introduction to solve this fundamental absence of knowledge first before introducing concepts like programming in python for which already are a number of freely available/modifiable resources online. 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.' -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
2009/10/28 Martin P. Hellwig martin.hell...@dcuktec.org Alf P. Steinbach wrote: * tm: On 28 Okt., 07:52, Alf P. Steinbach al...@start.no wrote: [Cross-posted comp.programming and comp.lang.python] Looking at your topic '(Python in Windows)', without taking a glimpse at your actual introduction, I have the following to say: I think it is not a good idea to teach programming with a focus on a specific operating system. Programming should IMHO be taught without reference to an operating system. Otherwise you just teach how to write unportable programs. I think you're trolling a little. :-) Without reference to an OS you can't address any of the issues that a beginner has to grapple with, including most importantly tool usage, without which it's not even possible to get started, but also, very importantly, a file system. Learning programming without tools and without using files (or only using the common denominator for file systems in OSes X, Y and Z) is sort of vacuous... In addition there's the motivational factor. I conclude from this that your assumption is that the reader might not be competent enough to have basic portable knowledge of using a computer. Which is fair enough, however I would suggest writing an introduction to solve this fundamental absence of knowledge first before introducing concepts like programming in python for which already are a number of freely available/modifiable resources online. What would be good is if there was a balancing book eg. one specifically targeting ubuntu, which is gaining popularity as we mail. 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.' -- http://mail.python.org/mailman/listinfo/python-list -- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Oct 28, 10:48 am, Alf P. Steinbach al...@start.no wrote: * 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 30 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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. 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
Re: Feedback wanted on programming introduction (Python in Windows)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* eb303: On Oct 28, 10:48 am, Alf P. Steinbach al...@start.no wrote: * 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? 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 30 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
jajajajajajajajajaja +1 for Francesco 2009/10/28 Francesco Bochicchio bieff...@gmail.com 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 -- http://mail.python.org/mailman/listinfo/python-list -- Mi twitter: http://twitter.com/garito -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On 28 Okt., 09: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. :-) 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 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. 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. :-) 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
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 :) 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
Re: Feedback wanted on programming introduction (Python in Windows)
On Oct 28, 11:57 am, Alf P. Steinbach al...@start.no wrote: * eb303: On Oct 28, 10:48 am, Alf P. Steinbach al...@start.no wrote: * 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? Yes that's what I wrote. What I intended to communicate was literally what I wrote (which is true), but that's very far from what you understood, e.g. it seems that you read my word can as, quoting you, will automatically, apparently with an implied always. Well, sorry to keep the topic going, but I have a really hard time understanding your text as you claim you mean it. The word 'can' is actually there, but in the first sentence, not in the second. And when I read For a large program or system that really cuts down on the work (and hence time) and really increases quality after stating the supposed benefits of statically typed compiled languages, I do understand that a large program or system just has to be written in such a language, and certainly not in Python, which - again according to my experience - I know is just not true. But well, it seems I'm the only one around bothered by this text, so I guess the problem is with me. So if I ever get to teach programming, I guess I'll just have to find another book than yours... ;-) 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 30 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. :-) 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++... ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Jon Clements: Inline reply: On 28 Oct, 11:49, Alf P. Steinbach al...@start.no wrote: * Jon Clements: On 28 Oct, 08:58, Alf P. Steinbach al...@start.no wrote: [snip] Without reference to an OS you can't address any of the issues that a beginner has to grapple with, including most importantly tool usage, without which it's not even possible to get started, but also, very importantly, a file system. Learning programming without tools and without using files (or only using the common denominator for file systems in OSes X, Y and Z) is sort of vacuous... In addition there's the motivational factor. I certainly agree that focusing on Windows, you may be able to suggest certain tools. IDE's, RAD environments, etc... I'm more thinking of things like the command interpreter. It's rather different in Windows and *nix. Yes, but not to the point it's required to make a massive distinction. 'python myfile.py' will work whatever... This isn't meant to be 'shell' scripting / system administration documentation :) Still there's so much difference between Windows and *nix both in standard tools available and in conventions employed for e.g. paths, filenames, text representation etc. that it's two different worlds: what works here doesn't work there and vice versa. C and C++ suffer from being designed for *nix (e.g. in C++ this is a problem for 'main' arguments, for filenames in the standard library and for iostreams); it seems Python is better designed or is a better fit for the modern kind of environment so to speak but I haven't got that far yet... The first exploratory programs a novice makes almost have to be text-oriented, thus, some exposure to the command interpreter from the start. And most programming languages' text i/o facilities, including those of Python, are oriented towards standard streams and redirection of them, done from some command interpreter. And most Windows users, those who'd like to learn programming, know nothing about that, so unless they learn in a setting with knowledgable people around, it needs to be addressed in the text they're using. I've found the average Windows user (even Uni. students studying programming) are somewhat amazed at the black window with white text that pops up when they run cmd.exe. My favourite comment thus far is, Hey, it's like really dark and stuff, and it knows my name, is that good? :) He he. Can I quote that? It's really good. :-) [snip] However, since ActivePython is said here to be just be CPython + packaging + stuff, I don't think there's any point in suggesting CPython, except perhaps to get version 3.x but that would currently have its own problems wrt. libraries and such, wouldn't it? Libraries are moving towards the 3.* series. The development team have provided tools to assist in migrating, but yes, it's not going to be a smooth ride. I think the Python development team, and the timelines planned, are brilliant - take for instance the Boost libraries, of which some are only making it into the C++200X or whatever now. I'm thinking about switching the text over to Python 3.x. That's because I discovered that even the division operator has changed, and that xrange() is no more, with range() now playing that rôle, rendering my naïve attempts at writing sort of forward-compatible code very moot. It's not just a new version, it's a new language. And yes I now installed CPython (is that the right name?) v. 3.1.1 and it was a *very* pleasant surprise compared to other ported *nix software I've installed. That is, it was much like ActivePython, just an ordinary Windows installer. It even has CHM format documentation! :-) SomeOne(TM) should better look at the IDLE environment, though. When single-steopping in that debugger one has to click on the source window after each step in order to see the highlighting of the current source code line. I guess this is due to ordinary text selection being used for the highlighting, and a difference between *nix and Windows in how that's shown (or in Windows not shown) for an inactive window. But anyway, much thanks, I think now perhaps 2.6 was a bad choice of mine, even though it's recommended for beginners and seems logical... Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In article hc8pn3$dd...@news.eternal-september.org, al...@start.no says... [Cross-posted comp.programming and comp.lang.python] Hi. I may finally have found the perfect language for a practically oriented introductory book on programming, namely Python. C++ was way too complex for the novice, JScript and C# suffered from too fast-changing specifications and runtime environment, Java, well, nothing particularly wrong but it's sort of too large and unwieldy and inefficient. I don't know whether this will ever become an actual book. I hope so! But since I don't know much Python -- I'm *learning* Python as I write -- I know that there's a significant chance of communicating misconceptions, non-idiomatic ways to do things, bad conventions, etc., in addition to of course plain errors of fact and understanding in general, to which I'm not yet immune... So I would would be very happy for feedback. But note: although I'm a complete Python newbie I'm not a novice programmer; my usual programming language is C++. So if you are a novice and think there's something wrong, then please do report it because it may help me explain things better, but since it's likely my explanation that is misleading, don't waste time on building up a case! This also goes for something that is simply difficult to understand. Then reporting that may help me explain it better. On the other hand, if you do have some experience, then chances are that what you think is an error, actually *is* an error! :-) Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Cheers, Why is chapter 2 called ASD? -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In article pan.2009.10.28.07.31...@remove.this.cybersource.com.au, ste...@remove.this.cybersource.com.au says... On Wed, 28 Oct 2009 07:52:17 +0100, Alf P. Steinbach wrote: Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Unfortunately Google wants me to change my browser, accept a privacy breach (cookies), and open a moderately large security hole in my browser (Javascript). Any one of these on its own, and I wouldn't mind; two of them, and I'd give it some thought; but all three, well, no thank you. I don't suppose you have these chapters available on a public website in an open document format like .odt or similar? Or even better, plain text with markup? You can read PDF with the ghostscript stuff or the free Adobe stuff. A man who cannot read .pdf or .ps in today's computer science world is a crippled man (IMO-YMMV). I couldn't live without citeseer, and almost all university computer science papers are in either pdf or ps. I can send you the documents via email if you are unable to collect them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
* Dann Corbit: In article hc8pn3$dd...@news.eternal-september.org, al...@start.no Unfortunately Google docs doesn't display the nice table of contents in each document, but here's the public view of ch 1 (complete) and ch 2 (about one third completed, I've not yet settled on a title so it's just chapter asd): http://preview.tinyurl.com/progintro Cheers, Why is chapter 2 called ASD? The leftmost three keys on the middle row of the keyboard. :-) Cheers, - Alf The Ramans do everything in threes -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
En Wed, 28 Oct 2009 08:49:02 -0300, Alf P. Steinbach al...@start.no 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In mpg.255244b37d76cfb5989...@news.eternal-september.org, Dann Corbit wrote: In article hc8pn3$dd...@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 http://www.cpax.org.uk Email: -http://www. +rjh@ Usenet is a strange place - dmr 29 July 1999 Sig line vacant - apply within -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
In mpg.255246264331509a989...@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? 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 -- 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 -- http://mail.python.org/mailman/listinfo/python-list
