From Scott.Daniels at Acm.Org Sat May 1 13:58:13 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sat May 1 17:30:14 2004 Subject: [Edu-sig] Re: How do we tell truths that might hurt In-Reply-To: <0HWP0066Y4IKZE@mta5.srv.hcvlny.cv.net> References: <005901c42a0f$98f84520$6501a8c0@vaio> <0HWP0066Y4IKZE@mta5.srv.hcvlny.cv.net> Message-ID: Arthur wrote: >>The key skill to impart and develop is surely *thinking* clearly and >>learning how to express that clear thinking in the appropriate language, >>which include speech, prose, computer programming and also Mathematics. > Computer programming is mathematics. I would find this a lot easier to swallow (though I might still quibble) if you, like Dijkstra, wrote, "Programming is one of the most difficult branches of applied mathematics". I believe I could have been a rather mediocre mathematician, but I instead became a fairly good programmer. Dijstra's claim is about the difficulty of programming, rather than its position in applied mathematics. Many of his claims in the cited article flow from the quote, "The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities." The tools are improving. One of the reasons he denigrates FORTRAN and COBOL so severely is that they have remained fairly fixed, while more expressive and useful language ideas have been explored and agreed to. Continuing to use them to write and maintain programs cripples us. This quote _is_ a dated communication, I expect a few copies of IBM might be replaced by Microsoft, Oracle, or Sun were the memo to be written today. Python is one of those "better tools" that changes how you think. A huge reason that python is so popular with good old coders is that it closely resembles the way we sketch the solution to a problem, without falling prey to the problems Dijkstra alludes to with APL. It is intriguing that we can execute a language so close to our stripped down communication. Python is one of those languages that seems to embrace the current idea that a more readable program is a substantially better program, and I believe that is one way it outpaces APL. The second advantage for python is inter-operation. C was designed to replace assembly language (which it has except for special apps). Because Python has a well-defined way to communicate with C, and because it doesn't insist on being "fully in charge," Python intercommunicates quite well with many other language systems. So, to sum up, I very slightly believe both: > Dijkstra is wrong, These statements are problems at a point in time (1975). Some things have improved since then. > I am misinterpreting what Dijkstra means. Well, since I learned to program in 1966, I _certainly_ believe the task was harder then than it is now. We actually know more about what a usable set of abstractions is. -Scott David Daniels From ajsiegel at optonline.net Sat May 1 21:36:29 2004 From: ajsiegel at optonline.net (Arthur) Date: Sat May 1 21:38:37 2004 Subject: [Edu-sig] Re: How do we tell truths that might hurt In-Reply-To: Message-ID: <0HX200LWSCKU1O@mta1.srv.hcvlny.cv.net> > > Computer programming is mathematics. > I would find this a lot easier to swallow (though I might still quibble) > if you, like Dijkstra, wrote, "Programming is one of the most difficult > branches of applied mathematics". I believe I could have been a rather > mediocre mathematician, but I instead became a fairly good programmer. > > Dijstra's claim is about the difficulty of programming, rather than its > position in applied mathematics. Or both. I agree it is more intended as a swipe at the pure mathematician, than a statement that "programming is mathematics" But "programming is mathematics" is, to me, implicit in the statement. And certainly, "programming is hard", is implicit in the statement. > > Python is one of those "better tools" that changes how you think. A > huge reason that python is so popular with good old coders is that it > closely resembles the way we sketch the solution to a problem, without > falling prey to the problems Dijkstra alludes to with APL. It is > intriguing that we can execute a language so close to our stripped down > communication. Python is one of those languages that seems to embrace > the current idea that a more readable program is a substantially better > program, and I believe that is one way it outpaces APL. The second > advantage for python is inter-operation. C was designed to replace > assembly language (which it has except for special apps). Because > Python has a well-defined way to communicate with C, and because it > doesn't insist on being "fully in charge," Python intercommunicates > quite well with many other language systems. All that sounds right to me. > > So, to sum up, I very slightly believe both: > > Dijkstra is wrong, > These statements are problems at a point in time (1975). Some things > have improved since then. No doubt much has improved. But I don't think the essence of what the word programming should mean has changed. But it can be changed like all words, by usage. I don't consider marking up an html page to be programming. Others might argue otherwise. All I could say is that we are using the same word to mean different things, then. Happens all the time in language: one word, different meanings. I would accept something about "algorithmic thinking" as core to the definition as I would use the word programming. But then find it impossible to see not only the point, but the possibility, of arguing that this is something somehow not in its essence mathematical. > > I am misinterpreting what Dijkstra means. > Well, since I learned to program in 1966, I _certainly_ believe the > task was harder then than it is now. We actually know more about what > a usable set of abstractions is. > Mathematics always seems to move in the direction of more powerful abstraction. So it makes perfect sense that is the direction in the development of programming and programming languages. Art From Scott.Daniels at Acm.Org Sun May 2 11:31:50 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun May 2 11:31:10 2004 Subject: [Edu-sig] Re: How do we tell truths that might hurt In-Reply-To: <0HX200LWSCKU1O@mta1.srv.hcvlny.cv.net> References: <0HX200LWSCKU1O@mta1.srv.hcvlny.cv.net> Message-ID: Arthur wrote: >>>Computer programming is mathematics. >> >>...Dijkstra: "Programming is one of the most difficult >> branches of applied mathematics".... >> >>Dijstra's claim is about the difficulty of programming, rather than its >>position in applied mathematics. > Or both. > I agree it is more intended as a swipe at the pure mathematician, than a > statement that "programming is mathematics" Why a swipe? I always considered pure and applied mathematicians to be quite distinct in attitude and aptitude. The pure mathematician has impatience with non-mathematical detail; the applied mathematician has impatience with abstraction without a visible use. Neither of these is wrong; it simply leads one to where they might work best. > ... "programming is mathematics" is, to me, implicit in the statement... But, perhaps, while programming is appropriately examined with mathematics, there is non-mathematical content as well. > >>So, to sum up, I very slightly believe both: >> > Dijkstra is wrong, >>These statements are problems at a point in time (1975). Some things >>have improved since then. > > No doubt much has improved. But I don't think the essence of what the word > programming should mean has changed. Ah, but it was almost all creative work then, and there are places now where programming has turned into a bit of "plug and chug". > I don't consider marking up an html page to be programming. Yet another place where we agree. > I would accept something about "algorithmic thinking" as core to the > definition as I would use the word programming. But then find it impossible > to see not only the point, but the possibility, of arguing that this is > something somehow not in its essence mathematical. So, to you, all completely rational thought is mathematics? This is, by the way, a question and not a jab. I don't know how you would answer that. >>We actually know more about what a usable set of abstractions is. > > Mathematics always seems to move in the direction of more powerful > abstraction. So it makes perfect sense that is the direction in the > development of programming and programming languages. My point is not about the discovery of those abstractions, but the ability of particular abstractions to clearly express the kinds of programs that people want written. Dijkstra's screed on APL in this memo is interesting here. Here is where I think the two (mathematics and programming, not necessarily you and I) diverge. Some programming languages head directly for abstaction, the earliest of which is, I suppose, was McCarthy's LISP. ML is a more modern form of that system. One of the key esthetics of such languages is a certain minimalism. The languages generally create a consistent universe that is often quite analyzable. These are languages designed more by mathematicians than practitioners, and they all have trouble talking to programs in other languages. This communication with other process, and other languages in the same image, seems a particularly non-mathematical consideration for programming. Anyhow, I do find reading your point of view interesting, although I definitely find places where I disagree. -Scott David Daniels Scott.Daniels@Acm.Org From jimleisy at fbeedle.com Mon May 3 12:08:48 2004 From: jimleisy at fbeedle.com (Jim Leisy) Date: Mon May 3 12:09:11 2004 Subject: [Edu-sig] Re: How do we tell truths that might hurt (reply to all) Message-ID: <5.1.0.14.2.20040503082755.00a82540@192.168.0.249> Hello All--Scott David Daniels has made some great observations. I have been a computer science textbook editor for the past 26 years. My career straddles two major programming paradigm shifts and several big language trends. Below the ==== is an email I have been sending to college CS department heads to inspire a revolutionary change in CS0 and CS1. In it I reference the historic shift from FORTRAN to Pascal. Pascal did a great job of introducing neophytes to structured programming and computer science concepts. The sun set on Pascal, principally, because it was not an industry standard production language. Python has many of the same attributes and none of the perceived drawbacks. Computer science education is contending with circumstances very similar to those of the era that gave rise to Pascal. The motivation for my campaign is a strong belief in the benefits Python can bring to computer science education, and to encourage the use of John Zelle's textbook Python Programming: An Introduction to Computer Science (published by my company). Cheers, Jim ============================== Professor ( ___________), I think we are experiencing deja v? in computer science. FORTRAN once was the gateway to the discipline. It was a quagmire for students. Wirth created Pascal to address this and to support a paradigm shift?structured programming methodology. Pascal took. Over 80% of the colleges in the US taught CS1 using it well into the 90s. Remember the flood of students intent on majoring in CS? Retention is a serious issue everywhere. C++ and Java are now the gateway. Are they assets in the effort to attract majors? Frequent compiler syntax errors create mounting frustration in students. Few programs are written and computer science fundamentals are obscured. A growing number of colleges have switched to Python in CS1 (they transition into C++ or Java in CS2). It works. Students write more programs and learn computer science fundamentals. It is an OO language and open source?the language and tools are all free. It's used by Google, Industrial Light & Magic, John Deere, and NASA. Like Pascal it makes things simple, not simplistic. We've got a great book to support the switch: John Zelle's Python Programming: An Introduction to Computer Science. Would you like to review it? Is there anyone in the department who should see it? Cheers, Jim Jim Leisy Publisher Franklin, Beedle & Associates Incorporated www.fbeedle.com 8536 SW St Helens Drive, Suite D Wilsonville, Oregon 97070 USA free (USA) call 1-800-322-2665 otherwise call 1(503)682-7668 fax 1(503)682-7638 From nico at tekNico.net Tue May 4 12:26:24 2004 From: nico at tekNico.net (Nicola Larosa) Date: Tue May 4 14:41:05 2004 Subject: [Edu-sig] Psyco explained by animations Message-ID: <4097C430.6070804@tekNico.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An animated, written with Pygame, videogame-styled presentation of the Psyco JIT compiler, by its author, Armin Rigo: Psyco explained by animations http://www.hole.fi/jajvirta/weblog/20040503T0901.html (as noted in the Daily Python-URL: http://www.pythonware.com/daily/ ) Very nice. - -- Nicola Larosa - nico@tekNico.net "People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby." -- Joel Spolsky, January 2004 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAl8QtXv0hgDImBm4RAppIAJ0WcUW4tv6V75jh+C4OlX1QHt+j+QCeKOnJ cI/65agRKJTf75LB95cl14E= =oCiY -----END PGP SIGNATURE----- From ehlersjp at msn.com Wed May 5 21:48:25 2004 From: ehlersjp at msn.com (Joseph Ehlers) Date: Wed May 5 21:48:40 2004 Subject: [Edu-sig] Introductory high school programming class - Python or TeachScheme Message-ID: I'm trying to propose an introductory computer programming class for high school students. I do not have a programming background so I will be learning the language just like the students. Through my research I came across Python. It sounds great - easy to learn, teaches thinking skills, and is fun. I was set to go with Python then I came across the TeachScheme project which also sounds great - it too is easy to learn, teaches thinking skills and comes with lots of curriculum. I have a few questions and I'm hoping this group can shed some light on this issue. 1. Is one better than the other (Python vs. TeachScheme) to teach high school novices programming skills, thinking skills, language, and keeping their attention so I can then have an audience for a second, more advanced programming class? 2. I've looked at "How to Think Like a Computer Scientist", it looks very doable for a novice and "Python Programming for the Absolute Beginner" (Premier Press) looks like a lot of fun. Is there any other curriculum for high school students out there? 3. Is it possible to teach a semester of TeachScheme and a semester of Python or is that overkill on the basics and not doing justice to either program? I appreciate your assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20040505/4c88119c/attachment.html From garret_mcgraw at yahoo.com Wed May 5 22:59:38 2004 From: garret_mcgraw at yahoo.com (Garret McGraw) Date: Wed May 5 23:10:58 2004 Subject: [Edu-sig] Python for High School Students Message-ID: <4099AA1A.6030508@yahoo.com> Hey there, I don't know a whole lot about what kinds of curriculums there are for high school classes but some things I have discovered in my 2 years of programming with Python are these. As great as Python already is, it has great pontental for becoming greater as differences between modern platforms widen because it as totally portable between platforms. It is available for almost any operating system and is 100% compatable between all of them. It is great for the younger generations because it is used for almost anything from homework (specificly math) to many large industry-level projects and buisnesses such as Google and I think Yahoo! also. I know this comparison is a little out-of-place but I think with intrests of preparing young minds for the real world, its very appropriate to use, because python, due to its extreme ease in which it can be learned and its enjoyable programming qualities known to many of us is the perfect tool for any computer minded teen-ager. I could go on all day about python but I think I'll just end here by giving a list of reasons why I believe you should seriously consider using Python in the classroom. 1. It is fun and quick to write code using. 2. It is actually very easy and fast to learn. 3. It is (as earlier mentioned) used in the real world for a variety of projects. 4. It is very well documented and if you have questions, there is always somebody out there who had that question at one time and can answer yours by means of newsgroup or other internet forum. 5. It is 100% portable between systems. 6. It has the coolest mascot. (The snake of course) 7. I am a high school sophomore myself and I use it for just about everything from school assignments to website CGIs. I hope this helps, GEM From urnerk at qwest.net Wed May 5 23:23:49 2004 From: urnerk at qwest.net (Kirby Urner) Date: Wed May 5 23:23:54 2004 Subject: [Edu-sig] Introductory high school programming class - Python orTeachScheme In-Reply-To: Message-ID: Hi Joseph -- Congrats on doing good research and landing two big fish. Years back on this list, one of the TeachScheme principals (Matthias) subscribed for a spell, so he could debate some of these very questions you raise. The discussion gets rather technical at times. See: http://mail.python.org/pipermail/edu-sig/2001-May/thread.html#1285 See also this quick summary: http://www.python.org/doc/pythonVSscheme.html My points in favor of Python: 1. the object oriented paradigm is close to the surface ("everything is an object") while in Scheme it's a more advanced feature. 2. because of 1, Python is a natural lead-in to other object oriented languages, Java in particular, which is currently the language used for the high school advanced placement test (check out Jython) 3. Python has more libraries and bindings to other packages, has been extended in more directions, features in the still-popular LAMP configuration (= Linux + Apache + MySQL + Perl, Python or PHP). 4. Python is more used outside of academia than Scheme (no, I can't cite a survey, so feel free to take this with a grain of salt). 5. Scheme is heavy into recursion, which is cool, but one needn't get so heavily into it in order to program. Python'll recurse too if that's what you need (though not with "tail call elimination" i.e. you push/pop a stack, vs. running through the same code at the top level). I like your idea of featuring some of both. It's good to give beginning students a sense of the variety of languages out there. Python and Scheme are different enough to drive this point home. The proportions could be up to you. I think you should go some distance towards learning both languages -- use free on-line tutorials and curricula for a few hours into each. Play around. And then decide for yourself which you'd like to teach more, or if you'd feel up to a 50-50 split. In other words, take the taste test and see if you like Coke or Pepsi more. I think there's more than enough education material for either choice. Neither all Python nor all Scheme would be outside the ballpark (here in Oregon, I know of at least one example of each -- with even more going with Java), nor would some mix of the two be weird. Here's a HS course that does both, and more besides (yes, Stuyvesant is pretty hard core: http://cs.stuy.edu/mcs1/ ). If you haven't already, check http://www.python.org/sigs/edu-sig/ . Specifically, you might want to click on the Live Wires link towards the bottom, under 'Of Interest to Educators' (another example curriculum). Dr. John Zelle's text could also be used for high schoolers, why not? Kirby PS: DrPython is an IDE modeled somewhat after DrScheme, which the DrPython's author admires. ________________________________________ From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Joseph Ehlers Sent: Wednesday, May 05, 2004 6:48 PM To: edu-sig@python.org Subject: [Edu-sig] Introductory high school programming class - Python orTeachScheme I'm trying to propose an introductory computer programming class for high school students.? I do not have a programming background so I will be learning the language just like the students.? Through my research I came across Python.? It sounds great - easy to learn, teaches thinking skills, and is fun.? I was set to go with Python then I came across the TeachScheme project which also sounds great - it too is easy to learn, teaches thinking skills and comes with lots of curriculum.? I have a few questions and I'm hoping this group can shed some light on this issue. ? 1.? Is one better than the other (Python? vs. TeachScheme) to teach high school novices programming skills, thinking skills, language, and keeping their attention so I can then have an audience for a second, more advanced programming class?? ? 2.? I've looked at "How to Think Like a Computer Scientist", it looks very doable for a novice and "Python Programming for the Absolute Beginner" (Premier Press) looks like a lot of fun.? Is? there any other curriculum for high school students out there? ? 3.? Is it possible to teach a semester of TeachScheme and a semester of Python or is that overkill on the basics and not doing justice to either program? ? I appreciate your assistance. From yliow at ccis.edu Thu May 6 09:24:49 2004 From: yliow at ccis.edu (Liow, Dr. Yihsiang) Date: Thu May 6 09:25:00 2004 Subject: [Edu-sig] Introductory high school programming class - Python orTeachScheme Message-ID: <67B838580AAD104BBFFB92FE177AFACC1EA3B1@exchange.ccis.edu> To make programming fun, you have to go beyond the language and do interesting things with it. That means using libraries or tools/frameworks. Two semesters of Python will get you much further and you'll retain more students too. "How to Think Like a Computer Scientist" will not get your students into interesting applications yet. So I strongly suggest you cover "How to Think ..." in 1 semester and spend the next doing some fun projects such as web applications using Zope or game using PyGame, etc. You can also put some of the more advance stuff in "How to Think ..." in the second semester and start a project during the first semester. Scheme is a great language but it is more "academic" than Python and does not seem to have as strong a pull as Python in the industry. So Python will definitely catch more attention. For instance compare the two: CS101. Do you want to learn a programming language, Scheme, taught at MIT? ... CS101. Do you want to learn a programming language, Python, used by Google and Yahoo! and Industrial Light & Magic and NASA? ... There are success stories in Scheme. If you want to use Scheme, you might want to check out http://www.schemers.org/Documents/FAQ/, but I think most of your potential students will not identify with the software listed there. For Python's success stories, go to http://pythonology.org/success. Hope this helps. - yihsiang -----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Joseph Ehlers Sent: Wednesday, May 05, 2004 8:48 PM To: edu-sig@python.org Subject: [Edu-sig] Introductory high school programming class - Python orTeachScheme I'm trying to propose an introductory computer programming class for high school students. I do not have a programming background so I will be learning the language just like the students. Through my research I came across Python. It sounds great - easy to learn, teaches thinking skills, and is fun. I was set to go with Python then I came across the TeachScheme project which also sounds great - it too is easy to learn, teaches thinking skills and comes with lots of curriculum. I have a few questions and I'm hoping this group can shed some light on this issue. 1. Is one better than the other (Python vs. TeachScheme) to teach high school novices programming skills, thinking skills, language, and keeping their attention so I can then have an audience for a second, more advanced programming class? 2. I've looked at "How to Think Like a Computer Scientist", it looks very doable for a novice and "Python Programming for the Absolute Beginner" (Premier Press) looks like a lot of fun. Is there any other curriculum for high school students out there? 3. Is it possible to teach a semester of TeachScheme and a semester of Python or is that overkill on the basics and not doing justice to either program? I appreciate your assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20040506/fdc39f28/attachment.html From jorjohns at cs.indiana.edu Thu May 6 13:14:09 2004 From: jorjohns at cs.indiana.edu (Jordan Johnson) Date: Thu May 6 13:10:04 2004 Subject: [Edu-sig] Introductory high school programming class - Python orTeachScheme In-Reply-To: <67B838580AAD104BBFFB92FE177AFACC1EA3B1@exchange.ccis.edu> Message-ID: On Thursday, May 6, 2004, at 06:24 AM, Liow, Dr. Yihsiang wrote: > Scheme is a great language but it is more ?academic? than Python and > does not seem to have as strong a pull as Python in the industry. So > Python will definitely catch more attention. For instance compare the > two: > > CS101. Do you want to learn a programming language, Scheme, taught at > MIT? ? > > CS101. Do you want to learn a programming language, Python, used by > Google and Yahoo! and Industrial Light & Magic and NASA? ? This isn't a fair comparison; in addition to the page you link in your message, Scheme is being and/or has been used at Microsoft and Disney, among others. See also the second question on: http://www.teach-scheme.org/Notes/scheme-faq.html Obviously, though, the Scheme community hasn't been as successful at making the public aware of such uses, but the two languages are both used for "real work," for those who ask. The more important question, IMO, is how to use either language to get the major non-language-specific concepts across. jmj : Jordan Johnson - jorjohns @ cs . indiana . edu : If I were a bug, I would want to be a true Renaissance bug. From bic at cgl.ucsf.edu Thu May 6 13:30:42 2004 From: bic at cgl.ucsf.edu (Bruce Cohen) Date: Thu May 6 13:30:47 2004 Subject: [Edu-sig] Re: Introductory high school programming class - Python or TeachScheme In-Reply-To: References: Message-ID: Having taught a high school programming class using each language, I want to throw in my two cents. I am a math teacher who (having both academic training and experience in CS) was willing to teach a programming class when I arrived at my current school in 2000. To prepare students for the AP CS class, students were required to take a one semester class in programming. My colleague was using C++ (then the AP language) as the vehicle for introducing programming. Although I was comfortable with C, I did not think that C++ would work well, so I too went off to the net and found Python. I really liked Python, but was somewhat concerned about having to develop my own curriculum. In 2000, there was not as many Python resources available as there are now. Through this very list, I discovered TeachScheme and attended a workshop during the summer of 2001. I really liked the TeachScheme philosophy and the availablility of the text _How to Design Programs_, online. (I teach in a public high school where resources are very limited.) In scheme, the focus is really on design ideas and not on syntax -- not that Python syntax is that difficult. I don't have a clear preference for either language. I think both are good places for students to begin. The advantage of TeachScheme (for me) was the well designed curriculum. My sense is that students have more fun with Python. At any rate, I am now very happy to limit my CS involvement to monitoring this list, while all of my teaching is limited to geometry and calculus. -Bruce Bruce Cohen | e-mail: bic@cgl.ucsf.edu Lowell High School | http://www.cgl.ucsf.edu/home/bic From sandysj at juno.com Thu May 6 18:17:28 2004 From: sandysj at juno.com (Jeff Sandys) Date: Thu May 6 18:17:31 2004 Subject: [Edu-sig] Introductory high school programming class - Python or TeachScheme Message-ID: <409AB978.3DB9C980@juno.com> I guess it matters on what you want to do. If you want to prep for the AP, teach java. because the test uses java. If you want to teach Computer Science, teach Scheme, because Scheme is used in _Structure and Interpretation of Computer Programs_, the seminal computer science book. If you want to teach programming, teach Python, because it has the best balance of power and ease of use. At our Seattle Python Interest Group we went around the room saying what we use Python for. My answer, to write programs! Because when I need a program to do something, I need it now, I want it fast, and it has to be easy to write. Lisp (Scheme is a dialect of Lisp) is a great porgramming language, but I find even after years of practice I have to think really hard when I write Lisp code, and with Python I hardly have to think to write code. The language I have used in a middle school programming club is Logo, which has an expression, "no threshold, no ceiling". And Logo has a low threshold and is very expressive, but without the libraries it has a low ceiling. Python has a higher threshold than Logo, IMHO, but with the libraries it has a high ceiling. Scheme's threshold is higher than Python and with limited libraries Scheme's ceiling is lower. Scheme's expresiveness is more powerful, sometimes when programming in Python I wish Python had a feature or syntax found in Lisp, but then I code around it and remember why I am using Python in the first place. Thanks, Jeff Sandys From inxdr at yahoo.com.au Sat May 8 07:49:36 2004 From: inxdr at yahoo.com.au (Darren Payne) Date: Sat May 8 07:49:42 2004 Subject: [Edu-sig] Re: Introductory high school programming In-Reply-To: Message-ID: <20040508114936.69297.qmail@web11207.mail.yahoo.com> See topics & msgs below to put my comments in context. I have been a member of this group for quite a while and content myself with reading the interesting things people have to say. Now I would like to add some of my experiences for others to consider. I teach computing to high school students in Australia (Sydney, NSW actually). I currently work in a "selective" school - US readers would understand this better as magnet school. Entry is gained via a battery of tests & positions offered. A few years ago I completed post grad study in gifted ed - at the end was invited to write a 2 day unit to be used in the university's gifted program. I have taken up this offer and based it on work by Jeff Spence (Canadian guy on exchange in my hometown a few years back) Anyway - I have been using Java and have reasonably successfully taught an introduction to Java - as a first language - to 10 and 11 year old children. This year I decided I would introduce my year 7 classes to Java. Now, after one term (10 weeks), I fear it is just too difficult. In essence, the more Java I learn the less I like Java. The decision to go with Java was encouraged by my current yr12 class whom last year were determined to learn a "real" language AKA C++. I compromised and "taught" them Java. Only one of these students has put in enough effort to establish any level of skill with the language. I really wanted to show them Python. Last year (as well - in parallel to yr12) I started teaching Python as a first language to my yr9 (now yr10) class - they loved it and I enjoyed teaching it. Re Scheme; my yr12 class also do an option involving different paradigms - one of these is the functional paradigm. So I teach Haskell. I really like it, I like the way it makes me think. Because the students can be examined on either Hskell or Scheme (Lisp) I also show them some Scheme - but prefer Haskell becasue no reverse Polish notation and no brackets! In summary, I have found Python far and away to be the best language for high school students. It is powerful, easy to use, has clear simple syntax that doesn't "get in the way", is extendable with loads of other modules, has an active developer community, is open source so I can burn it CD and legally give it to kids to take home and so much more. Perhaps best of all it teaches the major, MODERN CONCEPTS in programming and these are easily transferred to other languages. I don't like Java (read this like "tiggers don't like Java" - I have a 3 yr old and 4 old!)- it is all just hype and we have all been suckered in. Compiler errors are a hassle for students - interpreted is much better during learning & development of programs. Being forced to use OO for even trivial programs puts too much overhead in the way of learning to program. Python overcomes this because OO is optional - you don't have to use it with trivial programs. Anyway - enough from me at this point. Hope this offers a semi empirical flavour to the discussion. regards P.S. - consider Python Programming for absolute beginner by Michael Dawson as a text. Darren Payne Hurlstone Agricultural High School > > > Today's Topics: > > 1. Introductory high school programming class - > Python or > TeachScheme (Joseph Ehlers) > 2. Python for High School Students (Garret > McGraw) > 3. RE: Introductory high school programming class > - Python > orTeachScheme (Kirby Urner) > 4. RE: Introductory high school programming class > - Python > orTeachScheme (Liow, Dr. Yihsiang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 May 2004 20:48:25 -0500 > From: "Joseph Ehlers" > Subject: [Edu-sig] Introductory high school > programming class - Python > or TeachScheme > To: > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > I'm trying to propose an introductory computer > programming class for high school students. I do > not have a programming background so I will be > learning the language just like the students. > Through my research I came across Python. It sounds > great - easy to learn, teaches thinking skills, and > is fun. I was set to go with Python then I came > across the TeachScheme project which also sounds > great - it too is easy to learn, teaches thinking > skills and comes with lots of curriculum. I have a > few questions and I'm hoping this group can shed > some light on this issue. > > 1. Is one better than the other (Python vs. > TeachScheme) to teach high school novices > programming skills, thinking skills, language, and > keeping their attention so I can then have an > audience for a second, more advanced programming > class? > > 2. I've looked at "How to Think Like a Computer > Scientist", it looks very doable for a novice and > "Python Programming for the Absolute Beginner" > (Premier Press) looks like a lot of fun. Is there > any other curriculum for high school students out > there? > > 3. Is it possible to teach a semester of > TeachScheme and a semester of Python or is that > overkill on the basics and not doing justice to > either program? > > I appreciate your assistance. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.python.org/pipermail/edu-sig/attachments/20040505/4c88119c/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 05 May 2004 22:59:38 -0400 > From: Garret McGraw > Subject: [Edu-sig] Python for High School Students > To: edu-sig@python.org > Message-ID: <4099AA1A.6030508@yahoo.com> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Hey there, > > I don't know a whole lot about what kinds of > curriculums there are for > high school classes but some things I have > discovered in my 2 years of > programming with Python are these. As great as > Python already is, it has > great pontental for becoming greater as differences > between modern > platforms widen because it as totally portable > between platforms. It is > available for almost any operating system and is > 100% compatable between > all of them. > > It is great for the younger generations because it > is used for almost > anything from homework (specificly math) to many > large industry-level > projects and buisnesses such as Google and I think > Yahoo! also. I know > this comparison is a little out-of-place but I think > with intrests of > preparing young minds for the real world, its very > appropriate to use, > because python, due to its extreme ease in which it > can be learned and > its enjoyable programming qualities known to many of > us is the perfect > tool for any computer minded teen-ager. > > I could go on all day about python but I think I'll > just end here by > giving a list of reasons why I believe you should > seriously consider > using Python in the classroom. > > 1. It is fun and quick to write code using. > > 2. It is actually very easy and fast to learn. > > 3. It is (as earlier mentioned) used in the real > world for a variety of > projects. > > 4. It is very well documented and if you have > questions, there is > always somebody out there who had that question at > one time and can > answer yours by means of newsgroup or other internet > forum. > > 5. It is 100% portable between systems. > > 6. It has the coolest mascot. (The snake of course) > > 7. I am a high school sophomore myself and I use it > for just about > everything from school assignments to website CGIs. > > I hope this helps, > GEM > > > > > ------------------------------ > > Message: 3 > Date: Wed, 5 May 2004 20:23:49 -0700 > From: "Kirby Urner" > Subject: RE: [Edu-sig] Introductory high school > programming class - > Python orTeachScheme > To: "'Joseph Ehlers'" , > edu-sig@python.org > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > Hi Joseph -- > > Congrats on doing good research and landing two big > fish. > > Years back on this list, one of the TeachScheme > principals (Matthias) > subscribed for a spell, so he could debate some of > these very questions you > raise. > > The discussion gets rather technical at times. See: > http://mail.python.org/pipermail/edu-sig/2001-May/thread.html#1285 > > See also this quick summary: > http://www.python.org/doc/pythonVSscheme.html > > My points in favor of Python: > > 1. the object oriented paradigm is close to the > surface ("everything is an > object") while in Scheme it's a more advanced > feature. > > 2. because of 1, Python is a natural lead-in to > other === message truncated === ===== ----------------- regards Darren Payne Hurlstone Agricultural High School Ph: 9829 9222 Fax: 98292026 web: www.hurlstone.com.au email: computing@hurlstone.com.au __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From urnerk at qwest.net Sat May 8 13:22:47 2004 From: urnerk at qwest.net (Kirby Urner) Date: Sat May 8 13:22:49 2004 Subject: [Edu-sig] Re: Introductory high school programming In-Reply-To: <20040508114936.69297.qmail@web11207.mail.yahoo.com> Message-ID: <> > > Anyway - enough from me at this point. Hope this > offers a semi empirical flavour to the discussion. > regards > Excellent, experience-based post Darren. Valuable input. Teaching Java to 10-11 year olds or younger -- my daughter is around that age, quite bright, but I wouldn't consider miring her in that language. Seems so baroque, rococo even, by comparison. Python? Sure (but we haven't yet, except she's watched me write some Pygame stuff over the shoulder, guiding the aesthetics). Kirby =========== I'm finally making the time to work with VPython again. My previous high on that score was reading Arthur's Pygeo code (many versions ago) and trying to see how it all worked. These days, I'm just adapting what I've used to output to POV-Ray, and a lot of the same code over top. A motivation is 'Teaching Python with Graphics', which I'm suppose to present 45 minutes on at OSCON end of July. I'm planning to use my not-so-fancy laptop (1.2 Duron Compaq Presario 700) running Linux 2.4 (Mandrake 9.2) and Python 2.3, and graphics libraries (PIL, PyGame, VPython). The focus is on smallish projects involving graphics and Python programming. For example, awhile back I posted re some of that Wolfram-style cellular automata stuff, using POV-Ray for output. I've since adapted that to PIL. On the POV-Ray side, I do want to demo simple animation-building, though I haven't yet moved the whole stills-to-movie process to Linux (however, I'm confidant mplayer will both build and play the stuff). Kirby > P.S. - consider Python Programming for absolute > beginner by Michael Dawson as a text. > Darren Payne > Hurlstone Agricultural High School > > > > > > > Today's Topics: > > > > 1. Introductory high school programming class - > > Python or > > TeachScheme (Joseph Ehlers) > > 2. Python for High School Students (Garret > > McGraw) > > 3. RE: Introductory high school programming class > > - Python > > orTeachScheme (Kirby Urner) > > 4. RE: Introductory high school programming class > > - Python > > orTeachScheme (Liow, Dr. Yihsiang) > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 5 May 2004 20:48:25 -0500 > > From: "Joseph Ehlers" > > Subject: [Edu-sig] Introductory high school > > programming class - Python > > or TeachScheme > > To: > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > I'm trying to propose an introductory computer > > programming class for high school students. I do > > not have a programming background so I will be > > learning the language just like the students. > > Through my research I came across Python. It sounds > > great - easy to learn, teaches thinking skills, and > > is fun. I was set to go with Python then I came > > across the TeachScheme project which also sounds > > great - it too is easy to learn, teaches thinking > > skills and comes with lots of curriculum. I have a > > few questions and I'm hoping this group can shed > > some light on this issue. > > > > 1. Is one better than the other (Python vs. > > TeachScheme) to teach high school novices > > programming skills, thinking skills, language, and > > keeping their attention so I can then have an > > audience for a second, more advanced programming > > class? > > > > 2. I've looked at "How to Think Like a Computer > > Scientist", it looks very doable for a novice and > > "Python Programming for the Absolute Beginner" > > (Premier Press) looks like a lot of fun. Is there > > any other curriculum for high school students out > > there? > > > > 3. Is it possible to teach a semester of > > TeachScheme and a semester of Python or is that > > overkill on the basics and not doing justice to > > either program? > > > > I appreciate your assistance. > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://mail.python.org/pipermail/edu- > sig/attachments/20040505/4c88119c/attachment-0001.html > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 05 May 2004 22:59:38 -0400 > > From: Garret McGraw > > Subject: [Edu-sig] Python for High School Students > > To: edu-sig@python.org > > Message-ID: <4099AA1A.6030508@yahoo.com> > > Content-Type: text/plain; charset=ISO-8859-1; > > format=flowed > > > > Hey there, > > > > I don't know a whole lot about what kinds of > > curriculums there are for > > high school classes but some things I have > > discovered in my 2 years of > > programming with Python are these. As great as > > Python already is, it has > > great pontental for becoming greater as differences > > between modern > > platforms widen because it as totally portable > > between platforms. It is > > available for almost any operating system and is > > 100% compatable between > > all of them. > > > > It is great for the younger generations because it > > is used for almost > > anything from homework (specificly math) to many > > large industry-level > > projects and buisnesses such as Google and I think > > Yahoo! also. I know > > this comparison is a little out-of-place but I think > > with intrests of > > preparing young minds for the real world, its very > > appropriate to use, > > because python, due to its extreme ease in which it > > can be learned and > > its enjoyable programming qualities known to many of > > us is the perfect > > tool for any computer minded teen-ager. > > > > I could go on all day about python but I think I'll > > just end here by > > giving a list of reasons why I believe you should > > seriously consider > > using Python in the classroom. > > > > 1. It is fun and quick to write code using. > > > > 2. It is actually very easy and fast to learn. > > > > 3. It is (as earlier mentioned) used in the real > > world for a variety of > > projects. > > > > 4. It is very well documented and if you have > > questions, there is > > always somebody out there who had that question at > > one time and can > > answer yours by means of newsgroup or other internet > > forum. > > > > 5. It is 100% portable between systems. > > > > 6. It has the coolest mascot. (The snake of course) > > > > 7. I am a high school sophomore myself and I use it > > for just about > > everything from school assignments to website CGIs. > > > > I hope this helps, > > GEM > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 5 May 2004 20:23:49 -0700 > > From: "Kirby Urner" > > Subject: RE: [Edu-sig] Introductory high school > > programming class - > > Python orTeachScheme > > To: "'Joseph Ehlers'" , > > edu-sig@python.org > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hi Joseph -- > > > > Congrats on doing good research and landing two big > > fish. > > > > Years back on this list, one of the TeachScheme > > principals (Matthias) > > subscribed for a spell, so he could debate some of > > these very questions you > > raise. > > > > The discussion gets rather technical at times. See: > > > http://mail.python.org/pipermail/edu-sig/2001-May/thread.html#1285 > > > > See also this quick summary: > > http://www.python.org/doc/pythonVSscheme.html > > > > My points in favor of Python: > > > > 1. the object oriented paradigm is close to the > > surface ("everything is an > > object") while in Scheme it's a more advanced > > feature. > > > > 2. because of 1, Python is a natural lead-in to > > other > === message truncated === > > > ===== > ----------------- > regards > Darren Payne > Hurlstone Agricultural High School > Ph: 9829 9222 Fax: 98292026 > web: www.hurlstone.com.au > email: computing@hurlstone.com.au > > > > > __________________________________ > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > http://hotjobs.sweepstakes.yahoo.com/careermakeover > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig From john.zelle at wartburg.edu Sat May 8 13:56:11 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Sat May 8 13:57:09 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductory high school programming) In-Reply-To: References: Message-ID: <409D1F3B.20705@wartburg.edu> Just a quick comment to Kirby's latest post. Kirby Urner wrote: >I'm finally making the time to work with VPython again. My previous high on >that score was reading Arthur's Pygeo code (many versions ago) and trying to >see how it all worked. These days, I'm just adapting what I've used to >output to POV-Ray, and a lot of the same code over top. > > For those of you working with VPython, if you've not tried it out yet, take a look at the stereoscopic mode. I contributed the main code for this in the fall of 2003. It's a spin-off from some VR work I've been doing with my students. The stereo mode allows you to take virtually any VPython program and turn it into true stereographic 3D. You can make the objects seem to jump right out of the screen at you. The stereo graphics are viewable in a variety of modes, but the really neat part is that you can do it with no special equipment at all. Just set the stereo mode to 'redblue' and you can use the cheap red-blue glasses that come with kids books and happy meals (and are used for viewing Mars photos). You can buy these glasses in bulk for pennies a piece and show true 3D programs to a roomful of people using a standard LCD projector. Kids love this! Typically, making a program stereoscopic is as simple as doing: scene.stereo = 'redblue' You can also control where the scene seems to be relative to the display. By default, the scene is behind the screen, which is easiest to view. Setting the stereodepth to 1 centers the scene at the screen. Setting it to 2 puts the back edge of the scene on the screen. The objects seem to float in space in front of the screen. For some programs, the effect is really quite eye-popping. I usually use something like: scene.stereodepth = 1.5 >A motivation is 'Teaching Python with Graphics', which I'm suppose to >present 45 minutes on at OSCON end of July. I'm planning to use my >not-so-fancy laptop (1.2 Duron Compaq Presario 700) running Linux 2.4 >(Mandrake 9.2) and Python 2.3, and graphics libraries (PIL, PyGame, >VPython). > >The focus is on smallish projects involving graphics and Python programming. >For example, awhile back I posted re some of that Wolfram-style cellular >automata stuff, using POV-Ray for output. I've since adapted that to PIL. > > Kirby, I'm wondering if you have tried any of the cellular automata stuff using my graphics package. I suspect it would be dead simple, probably much eaiser than with POV-Ray or PIL. I haven't actually compared, so that's just a hunch. >On the POV-Ray side, I do want to demo simple animation-building, though I >haven't yet moved the whole stills-to-movie process to Linux (however, I'm >confidant mplayer will both build and play the stuff). > >Kirby > > > >>P.S. - consider Python Programming for absolute >>beginner by Michael Dawson as a text. >>Darren Payne >>Hurlstone Agricultural High School >> >> >> >>>Today's Topics: >>> >>> 1. Introductory high school programming class - >>>Python or >>> TeachScheme (Joseph Ehlers) >>> 2. Python for High School Students (Garret >>>McGraw) >>> 3. RE: Introductory high school programming class >>>- Python >>> orTeachScheme (Kirby Urner) >>> 4. RE: Introductory high school programming class >>>- Python >>> orTeachScheme (Liow, Dr. Yihsiang) >>> >>> >>> >>> >>> >>---------------------------------------------------------------------- >> >> >>>Message: 1 >>>Date: Wed, 5 May 2004 20:48:25 -0500 >>>From: "Joseph Ehlers" >>>Subject: [Edu-sig] Introductory high school >>>programming class - Python >>> or TeachScheme >>>To: >>>Message-ID: >>> >>>Content-Type: text/plain; charset="iso-8859-1" >>> >>>I'm trying to propose an introductory computer >>>programming class for high school students. I do >>>not have a programming background so I will be >>>learning the language just like the students. >>>Through my research I came across Python. It sounds >>>great - easy to learn, teaches thinking skills, and >>>is fun. I was set to go with Python then I came >>>across the TeachScheme project which also sounds >>>great - it too is easy to learn, teaches thinking >>>skills and comes with lots of curriculum. I have a >>>few questions and I'm hoping this group can shed >>>some light on this issue. >>> >>>1. Is one better than the other (Python vs. >>>TeachScheme) to teach high school novices >>>programming skills, thinking skills, language, and >>>keeping their attention so I can then have an >>>audience for a second, more advanced programming >>>class? >>> >>>2. I've looked at "How to Think Like a Computer >>>Scientist", it looks very doable for a novice and >>>"Python Programming for the Absolute Beginner" >>>(Premier Press) looks like a lot of fun. Is there >>>any other curriculum for high school students out >>>there? >>> >>>3. Is it possible to teach a semester of >>>TeachScheme and a semester of Python or is that >>>overkill on the basics and not doing justice to >>>either program? >>> >>>I appreciate your assistance. >>>-------------- next part -------------- >>>An HTML attachment was scrubbed... >>>URL: >>> >>> >>> >>http://mail.python.org/pipermail/edu- >>sig/attachments/20040505/4c88119c/attachment-0001.html >> >> >>>------------------------------ >>> >>>Message: 2 >>>Date: Wed, 05 May 2004 22:59:38 -0400 >>>From: Garret McGraw >>>Subject: [Edu-sig] Python for High School Students >>>To: edu-sig@python.org >>>Message-ID: <4099AA1A.6030508@yahoo.com> >>>Content-Type: text/plain; charset=ISO-8859-1; >>>format=flowed >>> >>>Hey there, >>> >>>I don't know a whole lot about what kinds of >>>curriculums there are for >>>high school classes but some things I have >>>discovered in my 2 years of >>>programming with Python are these. As great as >>>Python already is, it has >>>great pontental for becoming greater as differences >>>between modern >>>platforms widen because it as totally portable >>>between platforms. It is >>>available for almost any operating system and is >>>100% compatable between >>>all of them. >>> >>>It is great for the younger generations because it >>>is used for almost >>>anything from homework (specificly math) to many >>>large industry-level >>>projects and buisnesses such as Google and I think >>>Yahoo! also. I know >>>this comparison is a little out-of-place but I think >>>with intrests of >>>preparing young minds for the real world, its very >>>appropriate to use, >>>because python, due to its extreme ease in which it >>>can be learned and >>>its enjoyable programming qualities known to many of >>>us is the perfect >>>tool for any computer minded teen-ager. >>> >>>I could go on all day about python but I think I'll >>>just end here by >>>giving a list of reasons why I believe you should >>>seriously consider >>>using Python in the classroom. >>> >>>1. It is fun and quick to write code using. >>> >>>2. It is actually very easy and fast to learn. >>> >>>3. It is (as earlier mentioned) used in the real >>>world for a variety of >>>projects. >>> >>>4. It is very well documented and if you have >>>questions, there is >>>always somebody out there who had that question at >>>one time and can >>>answer yours by means of newsgroup or other internet >>>forum. >>> >>>5. It is 100% portable between systems. >>> >>>6. It has the coolest mascot. (The snake of course) >>> >>>7. I am a high school sophomore myself and I use it >>>for just about >>>everything from school assignments to website CGIs. >>> >>>I hope this helps, >>>GEM >>> >>> >>> >>> >>>------------------------------ >>> >>>Message: 3 >>>Date: Wed, 5 May 2004 20:23:49 -0700 >>>From: "Kirby Urner" >>>Subject: RE: [Edu-sig] Introductory high school >>>programming class - >>> Python orTeachScheme >>>To: "'Joseph Ehlers'" , >>>edu-sig@python.org >>>Message-ID: >>>Content-Type: text/plain; charset="iso-8859-1" >>> >>> >>>Hi Joseph -- >>> >>>Congrats on doing good research and landing two big >>>fish. >>> >>>Years back on this list, one of the TeachScheme >>>principals (Matthias) >>>subscribed for a spell, so he could debate some of >>>these very questions you >>>raise. >>> >>>The discussion gets rather technical at times. See: >>> >>> >>> >>http://mail.python.org/pipermail/edu-sig/2001-May/thread.html#1285 >> >> >>>See also this quick summary: >>>http://www.python.org/doc/pythonVSscheme.html >>> >>>My points in favor of Python: >>> >>>1. the object oriented paradigm is close to the >>>surface ("everything is an >>>object") while in Scheme it's a more advanced >>>feature. >>> >>>2. because of 1, Python is a natural lead-in to >>>other >>> >>> >>=== message truncated === >> >> >>===== >>----------------- >>regards >>Darren Payne >>Hurlstone Agricultural High School >>Ph: 9829 9222 Fax: 98292026 >>web: www.hurlstone.com.au >>email: computing@hurlstone.com.au >> >> >> >> >>__________________________________ >>Do you Yahoo!? >>Win a $20,000 Career Makeover at Yahoo! HotJobs >>http://hotjobs.sweepstakes.yahoo.com/careermakeover >> >>_______________________________________________ >>Edu-sig mailing list >>Edu-sig@python.org >>http://mail.python.org/mailman/listinfo/edu-sig >> >> > > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > > > > From Scott.Daniels at Acm.Org Sat May 8 16:12:21 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sat May 8 16:12:56 2004 Subject: [Edu-sig] Re: Introductory high school programming In-Reply-To: References: <20040508114936.69297.qmail@web11207.mail.yahoo.com> Message-ID: Kirby Urner wrote: > I'm finally making the time to work with VPython again. My previous high on > that score was reading Arthur's Pygeo code (many versions ago) and trying to > see how it all worked. These days, I'm just adapting what I've used to > output to POV-Ray, and a lot of the same code over top. You might want to check out Ruth Chabay's code to emit POV-Ray code from a VPython scene. It is a little rough (I tried cleaning it up a bit once but abandoned the attempt before I got a really good slice of a torus), but could be the basis of a good movie preview setup that will let you tweak your movie viewpoints. > > A motivation is 'Teaching Python with Graphics', which I'm suppose to > present 45 minutes on at OSCON end of July. I'm planning to use my > not-so-fancy laptop (1.2 Duron Compaq Presario 700) running Linux 2.4 > (Mandrake 9.2) and Python 2.3, and graphics libraries (PIL, PyGame, > VPython). > > The focus is on smallish projects involving graphics and Python programming. > For example, awhile back I posted re some of that Wolfram-style cellular > automata stuff, using POV-Ray for output. I've since adapted that to PIL. > > On the POV-Ray side, I do want to demo simple animation-building, though I > haven't yet moved the whole stills-to-movie process to Linux (however, I'm > confidant mplayer will both build and play the stuff). -Scott David Daniels Scott.Daniels@Acm.Org From urnerk at qwest.net Sat May 8 20:52:00 2004 From: urnerk at qwest.net (Kirby Urner) Date: Sat May 8 20:52:03 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhigh school programming) In-Reply-To: <409D1F3B.20705@wartburg.edu> Message-ID: > Kirby, I'm wondering if you have tried any of the cellular automata > stuff using my graphics package. I suspect it would be dead simple, > probably much eaiser than with POV-Ray or PIL. I haven't actually > compared, so that's just a hunch. > I think that's an excellent idea. I've been wanting to include Tk in the mix for sure. Your idea to incorporate your stereo mode in the VPython stuff is also very interesting. I'm fantasizing about handing out stereographic glasses at OSCON. So just now I cut and pasted my PIL code and wrote it slightly differently for graphics.py. The graphics.py code is indeed somewhat simpler. This business about pixelsize (below) is a bit confusing, but basically I'm using "virtual pixels" with a canvas made up of those. This is because actual pixels tend to be rather tiny, and I often want to use "fat pixels" that are actually 2x2 or 3x3 or 4x4 regular pixels. Instead of using rectanglar fills, I just fill in a 3x3 pixel by hitting all 9 actual pixels individually. I should try it with rectangles. What I find with the current setup is that the PIL graphic, in building off screen until view time, develops quickly. The Tk-based implementation, on the other hand, in painting pixel by pixel, crawls along one row at a time, taking 15 minutes versus a few seconds. On the other hand, slow crawling has its appeal, i.e. one has time to think about how one row of cells determines the next, and so on. Here are my two canvas objects (PIL and graphics.py). I'll post the complete code for doing these 'New Kind of Science' cell maps once I clean it up a bit. Oh heck, I'll just toss nks.py to www.4dsolutions.net/ocn/python and revise it online. (for color coded view, in browser, use: http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/nks.py ) I don't mind showing some awkwardness (I have these reversals of binary strings going on because I wanted 110, say, to come out in binary going left to right, but for this Wolfram stuff, a right to left string would simplify the code -- I'll likely be revising accordingly). class Canvas(object): """ Uses PIL -- so far doesn't include option to save picture to disk """ def __init__(self, width, rows, pixelsize): self.pixelsize = pixelsize self.im = Image.new('RGB',(width*pixelsize, rows*pixelsize),(0,0,0)) self.draw = ImageDraw.Draw(self.im) def drawcell(self, thepoint): therow = thepoint[0]*self.pixelsize thecol = thepoint[1]*self.pixelsize for i in range(self.pixelsize): for j in range(self.pixelsize): self.draw.point((therow + i, thecol + j), fill=(255,255,0)) def showimage(self): self.im.show() class Canvas2(object): """ Uses graphics.py by Dr. John Zelle See: http://mcsp.wartburg.edu/zelle/python/ """ def __init__(self, width, rows, pixelsize): self.pixelsize = pixelsize self.c = GraphWin('NKS',width*pixelsize, rows*pixelsize) def drawcell(self, thepoint): therow = thepoint[0]*self.pixelsize thecol = thepoint[1]*self.pixelsize for i in range(self.pixelsize): for j in range(self.pixelsize): thepoint = Point(therow + i, thecol + j) thepoint.draw(self.c) Kirby PS: a win for me just now was getting Samba server on the laptop visible on the Windows network neighborhood via wifi. So I'm writing email on my XP desktop, while editing/uploading source code from the Linux laptop via the XP desktop. Fun fun. From urnerk at qwest.net Sat May 8 23:14:06 2004 From: urnerk at qwest.net (Kirby Urner) Date: Sat May 8 23:14:09 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhighschool programming) In-Reply-To: Message-ID: Re: www.4dsolutions.net/ocn/python/nks.py > individually. I should try it with rectangles. > Definitely faster with rectangles. In Tk, getting down to the actual pixel level (pixelsize=1), even with Point (tried in place of Rectangle), I get a fuzzy picture. Might be some problem with my algorithm I didn't catch. An advantage of the PIL method is you're building something savable. With graphics.py, I don't see a way to save the canvas to a file. (for color coded view, in browser, use: http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/nks.py Kirby From jj2kk4 at yahoo.com Sun May 9 06:34:22 2004 From: jj2kk4 at yahoo.com (Joel Kahn) Date: Sun May 9 06:34:25 2004 Subject: [Edu-sig] VPython Message-ID: <20040509103422.74543.qmail@web60606.mail.yahoo.com> I'm glad to see that there is a strong interest in VPython among members of the edu-sig. Keep an eye on the "contributed programs" page at vpython.org: I've already got a couple of my recent humble efforts up there, and I'm planning more. . . . An idea for you folks to chew on: making posters &c of Python-graphical artworks and selling them to raise money for Python educational R&D. Think it over. Joel __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From john.zelle at wartburg.edu Sun May 9 20:54:03 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Sun May 9 20:54:58 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhighschool programming) In-Reply-To: <200405082214642.SM02408@mpls-qmqp-03.inet.qwest.net> References: <200405082214642.SM02408@mpls-qmqp-03.inet.qwest.net> Message-ID: <409ED2AB.2050007@wartburg.edu> Kirby Urner wrote: >Re: www.4dsolutions.net/ocn/python/nks.py > > > >>individually. I should try it with rectangles. >> >> >> > >Definitely faster with rectangles. > >In Tk, getting down to the actual pixel level (pixelsize=1), even with Point >(tried in place of Rectangle), I get a fuzzy picture. > > > >Might be some problem with my algorithm I didn't catch. > > > Actually, Tk doesn't give you pixel level control. In my graphics package, I fake it with small rectangles. So yes, using rectangles would be much better. Another problem with rendering speed is that my graphics package automatically flushes the graphics window after every operation. This makes simple animations easier, but when you are doing lots of small updates, this is very inefficient. My latest version of the package (still in testing) adds an option to turn off the auto-flush. Using this option, you can do a bunch of draws before actually updating the view. I think the result would be a much faster draw, but it's still going to be slower than PIL If you're interested, I could post the latest version of graphics.py. >An advantage of the PIL method is you're building something savable. With >graphics.py, I don't see a way to save the canvas to a file. > > > > This is problem with graphics.py. Tk provides a method to dump canvases to postscript, but the last time I checked it only worked under Unix/Linux. I'm not sure if this has been brought into the Windows world as well, I haven't looked recently. --John >(for color coded view, in browser, use: >http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/nks.py > >Kirby > > > > > > From urnerk at qwest.net Mon May 10 00:56:14 2004 From: urnerk at qwest.net (Kirby Urner) Date: Mon May 10 00:56:16 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhighschool programming) In-Reply-To: <409ED2AB.2050007@wartburg.edu> Message-ID: > If you're interested, I could post the latest version of graphics.py. > Yes, I'm interested. > This is problem with graphics.py. Tk provides a method to dump canvases > to postscript, but the last time I checked it only worked under > Unix/Linux. I'm not sure if this has been brought into the Windows world > as well, I haven't looked recently. > Interesting. I like learning the technical ins and outs. Kirby From urnerk at qwest.net Mon May 10 01:00:02 2004 From: urnerk at qwest.net (Kirby Urner) Date: Mon May 10 01:00:04 2004 Subject: [Edu-sig] VPython In-Reply-To: <20040509103422.74543.qmail@web60606.mail.yahoo.com> Message-ID: > -----Original Message----- > From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On > Behalf Of Joel Kahn > Sent: Sunday, May 09, 2004 3:34 AM > To: edu-sig@python.org > Subject: [Edu-sig] VPython > > I'm glad to see that there is a strong interest in > VPython among members of the edu-sig. Keep an eye on > the "contributed programs" page at vpython.org: I've > already got a couple of my recent humble efforts up > there, and I'm planning more. . . . Yes. I'm meaning to pursue Scott's suggestion to look at Ruth Chabay's code. The idea of getting a good camera angle has direct application to these animations I'm doing around this ballerina with sensors strapped to her body. ( examples: ftp://www.4dsolutions.net/pub ) And I want to try John's stereographic code option (with the glasses). I want to move these ballerina animations to real time VPython displays. However, today I ran out of disk space on the laptop, booted into Windows to use Partition Magic to give myself more room, and found on returning to Linux that my ext3 filesystem was now booting as ext2. I spend much of the day trying to get back to ext3, to no avail. I don't think it matters much, but I have this ability to waste many hours obsessing about such things. Now I'm just going to call it quits for today. More fun and games soon I hope. Kirby > > An idea for you folks to chew on: making posters &c of > Python-graphical artworks and selling them to raise > money for Python educational R&D. Think it over. > > Joel From glingl at aon.at Mon May 10 08:14:42 2004 From: glingl at aon.at (Gregor Lingl) Date: Mon May 10 08:14:11 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhighschool programming) In-Reply-To: <409ED2AB.2050007@wartburg.edu> References: <200405082214642.SM02408@mpls-qmqp-03.inet.qwest.net> <409ED2AB.2050007@wartburg.edu> Message-ID: <409F7232.50401@aon.at> John Zelle schrieb: > ... > My latest version of the package (still in testing) adds an option to > turn off the auto-flush. Using this option, you can do a bunch of > draws before actually updating the view. Interestigly the module turtle.py (in the standard distribution of Python) already has a similar feature, namely the function (method) tracer(). > I think the result would be a much faster draw, but it's still going > to be slower than PIL > > If you're interested, I could post the latest version of graphics.py. > Yes, I'm also interested in this latest version. > This is problem with graphics.py. Tk provides a method to dump > canvases to postscript, but the last time I checked it only worked > under Unix/Linux. I'm not sure if this has been brought into the > Windows world as well, I haven't looked recently. In my experience this still dowsn't work correctly. A ps-file will be produced but it displays only as a tiny blank rectangle. Regards, Gregor > > --John > From john.zelle at wartburg.edu Mon May 10 11:30:46 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Mon May 10 11:31:41 2004 Subject: [Edu-sig] Re: Teaching graphics with Python (was Introductoryhighschool programming) In-Reply-To: <409F7232.50401@aon.at> References: <200405082214642.SM02408@mpls-qmqp-03.inet.qwest.net> <409ED2AB.2050007@wartburg.edu> <409F7232.50401@aon.at> Message-ID: <409FA026.1000508@wartburg.edu> A number of folks expressed interest, so the newest version of graphics.py is now available on my Python page: http://mcsp.wartburg.edu/zelle/python/graphics.py The only difference between this version and the previous is that it allows the auto-flush of graphics updates to be turned off. This line creates a graphics window w/o immediate automatic updates: myWin = GraphWin("Example Graphics Window", 300, 300, False) The "False" in the last parameter turns off auto-updates. This window will be updated when the Tk event loop is idle or when myWin.flush() is called. I tested this out with Kirby's nks.py code, and it makes the drawing essentially instantaneous on my machine. I normally do not release tweaks to the graphics package until it has gone through an entire semester of class-use testing, but I am relatively confident that this small change is working. The documentation has not yet been updated. Please let me know if you find any bugs. By the way, for any who are interested in the history of such things, versions of my graphics package before 2.0 (the previous release) always used lazy updating (the auto-flush False behavior). I added the forced updates to version 2.0 to make the package behave better interactively under windows with Idle 1.0 and newer (using subprocesses). The newest version (2.1) now lets you select which mode you want. --John Gregor Lingl wrote: > > > John Zelle schrieb: > >> ... >> My latest version of the package (still in testing) adds an option to >> turn off the auto-flush. Using this option, you can do a bunch of >> draws before actually updating the view. > > > Interestigly the module turtle.py (in the standard distribution of > Python) already has a similar feature, > namely the function (method) tracer(). > >> I think the result would be a much faster draw, but it's still going >> to be slower than PIL >> >> If you're interested, I could post the latest version of graphics.py. >> > Yes, I'm also interested in this latest version. > >> This is problem with graphics.py. Tk provides a method to dump >> canvases to postscript, but the last time I checked it only worked >> under Unix/Linux. I'm not sure if this has been brought into the >> Windows world as well, I haven't looked recently. > > > In my experience this still dowsn't work correctly. A ps-file will be > produced but it displays > only as a tiny blank rectangle. > > Regards, Gregor > >> >> --John >> > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > > From urnerk at qwest.net Mon May 10 13:25:08 2004 From: urnerk at qwest.net (Kirby Urner) Date: Mon May 10 13:25:17 2004 Subject: [Edu-sig] re: new graphics.py etc. In-Reply-To: <409FA026.1000508@wartburg.edu> Message-ID: Hi John -- Thank you for sharing your latest graphics.py -- indeed it runs a *lot* faster, plus it's nice to have the option of watching screen updates as they happen IF you want to. This is definitely a worthwhile upgrade. ====== Notes: With WinXP, Python 2.3.3, IDLE 1.0.2: * no Tk canvas appears, or, if I add a canvas.flush(), a blank one with an hour glass cursor appears. If I change auto-refresh to True, then I see the canvas being drawn properly. Once it's done, it has the last problem (below) With WinXP, Python 2.3.3, command window: * no problems with Tk canvas With Linux (Mandrake 9.2), Python 2.3.3., IDLE 1.0 * Tk canvas appears, no problem. Both platforms (with or without IDLE): I notice that loading both the PIL and graphics.py modules at the same time causes problems. PIL will fail to show anything if graphics.py is loaded (same with the older version). I think this may have to do with both modules contending for a Tk root, a problem even when running in shell mode. To address the latter problem, I've separated the PIL and graphics.py Canvas classes into separate modules (canvas1.py and canvas2.py), so that only one or the other library gets used. Both platforms, using IDLE: if I choose dimensions greater than the screen, or move the Tk canvas off the edge, portions of the canvas get wiped and don't refresh. ===== Note re nks.py PS: a more demanding test for nks is t1(30,400,200,3). That creates a 3*400 x 3*200 (i.e. 1200x600) canvas. In general, pixelsize (3) multiplies the width (400) and height (200). Plus height should be half the width, given how these particular cellular automata propagate from the center (45 degree slope). > -----Original Message----- > From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On > Behalf Of John Zelle > Sent: Monday, May 10, 2004 8:31 AM > To: edu-sig@python.org > Subject: Re: [Edu-sig] Re: Teaching graphics withPython (was > Introductoryhighschool programming) > > > A number of folks expressed interest, so the newest version of > graphics.py is now available on my Python page: > http://mcsp.wartburg.edu/zelle/python/graphics.py > > The only difference between this version and the previous is that it > allows the auto-flush of graphics updates to be turned off. This line > creates a graphics window w/o immediate automatic updates: > > myWin = GraphWin("Example Graphics Window", 300, 300, False) > > The "False" in the last parameter turns off auto-updates. This window > will be updated when the Tk event loop is idle or when myWin.flush() is > called. I tested this out with Kirby's nks.py code, and it makes the > drawing essentially instantaneous on my machine. > > I normally do not release tweaks to the graphics package until it has > gone through an entire semester of class-use testing, but I am > relatively confident that this small change is working. The > documentation has not yet been updated. Please let me know if you find > any bugs. > > By the way, for any who are interested in the history of such things, > versions of my graphics package before 2.0 (the previous release) always > used lazy updating (the auto-flush False behavior). I added the forced > updates to version 2.0 to make the package behave better interactively > under windows with Idle 1.0 and newer (using subprocesses). The newest > version (2.1) now lets you select which mode you want. > > --John From john.zelle at wartburg.edu Mon May 10 14:08:35 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Mon May 10 14:09:30 2004 Subject: [Edu-sig] re: new graphics.py etc. In-Reply-To: References: Message-ID: <409FC523.4070704@wartburg.edu> Kirby Urner wrote: >Hi John -- > >Thank you for sharing your latest graphics.py -- indeed it runs a *lot* >faster, plus it's nice to have the option of watching screen updates as they >happen IF you want to. This is definitely a worthwhile upgrade. > >====== > >Notes: > >With WinXP, Python 2.3.3, IDLE 1.0.2: > >* no Tk canvas appears, or, if I add a canvas.flush(), a blank one with an >hour glass cursor appears. > > Right. This is a well-known issue. Under IDLE, the graphics program runs as a separate process, and does not share the Tkinter mainloop that runs in IDLE. When IDLE is waiting for input, the subprocess is "frozen." There are a couple of things that you can do to remedy this. One is to simply not get input through the IDLE shell window. For example, instead for pausing to view graphics output with a raw_input (something that requires typing in the shell window), do a win.getMouse() that waits for a mouse click. That will keep the Tk window active. The other "fix" is to run IDLE with the -n option so that the program is not run as a subprocess, but shares IDLE's Tk event loop. >If I change auto-refresh to True, then I see the canvas being drawn >properly. Once it's done, it has the last problem (below) > > > Right, since the updates are done on each draw, the window is fully drawn before the raw_input in the IDLE shell "freezes" it. >With WinXP, Python 2.3.3, command window: > >* no problems with Tk canvas > >With Linux (Mandrake 9.2), Python 2.3.3., IDLE 1.0 > >* Tk canvas appears, no problem. > >Both platforms (with or without IDLE): > >I notice that loading both the PIL and graphics.py modules at the same time >causes problems. PIL will fail to show anything if graphics.py is loaded >(same with the older version). I think this may have to do with both >modules contending for a Tk root, a problem even when running in shell mode. > > I was not aware of this problem, I'll have to look into this. Things always get a bit funky with multiple modules attempting to use Tk. >To address the latter problem, I've separated the PIL and graphics.py Canvas >classes into separate modules (canvas1.py and canvas2.py), so that only one >or the other library gets used. > > > Good workaround for now. >Both platforms, using IDLE: > >if I choose dimensions greater than the screen, or move the Tk canvas off >the edge, portions of the canvas get wiped and don't refresh. > > > This is actually the same problem as above. When IDLE is paused for input, the subprocess freezes, hence you don't get a window repaint. By the way, if you are experimenting interactively and have a variable that contains the GraphWin, you can always force an update by doing win.flush(). That should cause a repaint. >===== > >Note re nks.py > >PS: a more demanding test for nks is t1(30,400,200,3). That creates a >3*400 x 3*200 (i.e. 1200x600) canvas. In general, pixelsize (3) multiplies >the width (400) and height (200). Plus height should be half the width, >given how these particular cellular automata propagate from the center (45 >degree slope). > > > >>-----Original Message----- >>From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On >>Behalf Of John Zelle >>Sent: Monday, May 10, 2004 8:31 AM >>To: edu-sig@python.org >>Subject: Re: [Edu-sig] Re: Teaching graphics withPython (was >>Introductoryhighschool programming) >> >> >>A number of folks expressed interest, so the newest version of >>graphics.py is now available on my Python page: >>http://mcsp.wartburg.edu/zelle/python/graphics.py >> >>The only difference between this version and the previous is that it >>allows the auto-flush of graphics updates to be turned off. This line >>creates a graphics window w/o immediate automatic updates: >> >>myWin = GraphWin("Example Graphics Window", 300, 300, False) >> >>The "False" in the last parameter turns off auto-updates. This window >>will be updated when the Tk event loop is idle or when myWin.flush() is >>called. I tested this out with Kirby's nks.py code, and it makes the >>drawing essentially instantaneous on my machine. >> >>I normally do not release tweaks to the graphics package until it has >>gone through an entire semester of class-use testing, but I am >>relatively confident that this small change is working. The >>documentation has not yet been updated. Please let me know if you find >>any bugs. >> >>By the way, for any who are interested in the history of such things, >>versions of my graphics package before 2.0 (the previous release) always >>used lazy updating (the auto-flush False behavior). I added the forced >>updates to version 2.0 to make the package behave better interactively >>under windows with Idle 1.0 and newer (using subprocesses). The newest >>version (2.1) now lets you select which mode you want. >> >>--John >> >> > > > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > > > > From glingl at aon.at Mon May 10 15:43:20 2004 From: glingl at aon.at (Gregor Lingl) Date: Mon May 10 15:42:39 2004 Subject: [Edu-sig] re: new graphics.py etc. In-Reply-To: References: Message-ID: <409FDB58.8000201@aon.at> Thanks, too, John! By changing 2 or 3 lines in Kirbys code I arrived at a tiny animation. (attachment). It's intended to run from the command line. Question: The raw_input() in line 70 seems to be indispensable. It doesn't work without it. Why is this the case? Regards, Gregor > > -------------- next part -------------- """ Kirby Urners nks.py using Tkinter with tiny animation """ # uncomment one or the other, reload if switching from graphics import GraphWin, Point, Rectangle class Canvas(object): def __init__(self, width, rows, pixelsize): self.pixelsize = pixelsize self.c = GraphWin('NKS',width*pixelsize, rows*pixelsize, False) self.c.setBackground('black') def drawcell(self, thepoint): therow = thepoint[0]*self.pixelsize thecol = thepoint[1]*self.pixelsize therect = Rectangle(Point(therow, thecol), Point(therow + self.pixelsize-1, thecol + self.pixelsize-1)) therect.setFill('yellow') therect.setOutline('yellow') therect.draw(self.c) def showimage(self): self.c.flush() g = raw_input("Hit Enter on this line to close window") self.c.close() def base2(n,pad=8): output = [] while n > 1: digit = n%2 n //= 2 output.append(str(digit)) output.append(str(n)) output.reverse() return (''.join(output)).zfill(pad) def makerule(n): therule = {} output = base2(n) for i in range(8): therule[base2(7-i,3)] = output[i] return therule def sayrule(themap): for i in range(7,-1,-1): thekey = base2(i,3) print "%s --> %s" % (thekey, themap[thekey]) class Pattern(object): def __init__(self, n, width=40, rows=20, pixelsize = 1): self.width = width self.rule = makerule(n) self.therow = ('0' * (width//2) + '1' + '0' * (width - width//2 - 1)) self.rownum = 0 # Canvas imported from either of 2 modules self.canvas = Canvas(width,rows,pixelsize) self.canvas.c.flush() # <=== raw_input("Hit Enter to start automaton!") # <=== def next(self): while True: yield self.therow for i in range(len(self.therow)): if self.therow[i]=='1': self.canvas.drawcell((i,self.rownum)) newrow = ['0'] * len(self.therow) for i in range(1,len(self.therow)-1): thekey = (self.therow[i-1] + self.therow[i] + self.therow[i + 1]) newrow[i] = self.rule[thekey] self.therow = ''.join(newrow) self.rownum += 1 def showimage(self): self.canvas.showimage() def __iter__(self): return self.next() def t1(rule, width, height, pixelsize=1): p = Pattern(rule ,width, height, pixelsize) g = p.next() for i in range(width/2): g.next() p.canvas.c.flush() p.showimage() if __name__ == '__main__': t1(30,200,100,4) From john.zelle at wartburg.edu Mon May 10 17:23:41 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Mon May 10 17:24:40 2004 Subject: [Edu-sig] re: new graphics.py etc. In-Reply-To: <409FDB58.8000201@aon.at> References: <409FDB58.8000201@aon.at> Message-ID: <409FF2DD.6000006@wartburg.edu> Gregor Lingl wrote: > > Thanks, too, John! > > By changing 2 or 3 lines in Kirbys code I arrived > at a tiny animation. (attachment). It's intended to > run from the command line. > > Question: The raw_input() in line 70 seems to be > indispensable. It doesn't work without it. Why is > this the case? Hmmm, this is a bit confusing to me too. I think the problem is that all of the drawing is complete before Tk even creates the window (under Windows that is; it works fine in Linux). If you change the self.canvas.c.flush() to self.canvas.c.update() then the raw_input is not needed. The difference is that flush() calls Tk's update_idletask() rather than the more definite update. I need to look into the platform differences on these calls. Most of the time, I am developing/testing under Linux, so I used the weaker update, which seems to work fine there. > > Regards, Gregor > >> >> >------------------------------------------------------------------------ > >""" > >Kirby Urners nks.py using Tkinter with >tiny animation > > >""" > ># uncomment one or the other, reload if switching > >from graphics import GraphWin, Point, Rectangle > >class Canvas(object): > > def __init__(self, width, rows, pixelsize): > self.pixelsize = pixelsize > self.c = GraphWin('NKS',width*pixelsize, rows*pixelsize, False) > self.c.setBackground('black') > > def drawcell(self, thepoint): > therow = thepoint[0]*self.pixelsize > thecol = thepoint[1]*self.pixelsize > > therect = Rectangle(Point(therow, thecol), > Point(therow + self.pixelsize-1, > thecol + self.pixelsize-1)) > therect.setFill('yellow') > therect.setOutline('yellow') > therect.draw(self.c) > > def showimage(self): > self.c.flush() > g = raw_input("Hit Enter on this line to close window") > self.c.close() > >def base2(n,pad=8): > output = [] > while n > 1: > digit = n%2 > n //= 2 > output.append(str(digit)) > output.append(str(n)) > output.reverse() > return (''.join(output)).zfill(pad) > >def makerule(n): > therule = {} > output = base2(n) > for i in range(8): > therule[base2(7-i,3)] = output[i] > return therule > >def sayrule(themap): > for i in range(7,-1,-1): > thekey = base2(i,3) > print "%s --> %s" % (thekey, themap[thekey]) > >class Pattern(object): > > def __init__(self, n, width=40, rows=20, pixelsize = 1): > self.width = width > self.rule = makerule(n) > self.therow = ('0' * (width//2) + > '1' + > '0' * (width - width//2 - 1)) > self.rownum = 0 > # Canvas imported from either of 2 modules > self.canvas = Canvas(width,rows,pixelsize) > self.canvas.c.flush() # <=== > raw_input("Hit Enter to start automaton!") # <=== > > def next(self): > while True: > yield self.therow > for i in range(len(self.therow)): > if self.therow[i]=='1': > self.canvas.drawcell((i,self.rownum)) > > newrow = ['0'] * len(self.therow) > for i in range(1,len(self.therow)-1): > thekey = (self.therow[i-1] + > self.therow[i] + > self.therow[i + 1]) > newrow[i] = self.rule[thekey] > self.therow = ''.join(newrow) > self.rownum += 1 > > def showimage(self): > self.canvas.showimage() > > def __iter__(self): > return self.next() > >def t1(rule, width, height, pixelsize=1): > p = Pattern(rule ,width, height, pixelsize) > g = p.next() > for i in range(width/2): > g.next() > p.canvas.c.flush() > p.showimage() > >if __name__ == '__main__': > t1(30,200,100,4) > > >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From ajsiegel at optonline.net Tue May 11 14:04:48 2004 From: ajsiegel at optonline.net (ajsiegel@optonline.net) Date: Tue May 11 14:07:50 2004 Subject: [Edu-sig] VPython Message-ID: <10256101023452.10234521025610@optonline.net> Kirby writes - >Yes. I'm meaning to pursue Scott's suggestion to look at Ruth Chabay's >code. FWIW, PyGeo's copy of Ruth's povexport module extends it a bit, allowing, for example, export of the VPython "faces" (triangle mesh) primitives. The export of the "faces" relies on some functionality not added to Pov-ray until version 3.5. Art From mmclay at comcast.net Wed May 26 10:55:03 2004 From: mmclay at comcast.net (Michael McLay) Date: Wed May 26 10:47:40 2004 Subject: [Edu-sig] Fwd: [Fwd: Why we need "Fat Python"] Message-ID: <200405261055.03782.mmclay@comcast.net> Jeff's message to this list bounced for some reason. He asked that I forward it to the list. I agree with Jeff that we need to get Python made a requirement for the NOCTI exam. I'd also like to see the requirement for Visual Basic dropped. That is a proprietary technology that may not be available to someone who does not have access to a Windows computer. Anything that can be done in Visual Basic also can be done with Python (with the Glade tool if you need to demonstrate the development of a GUI application.) ---------- Forwarded Message ---------- Subject: [Fwd: Why we need "Fat Python"] Date: Wednesday 26 May 2004 6:40 am From: Jeffrey Elkner To: Michael McLay Hi Michael, The message below was bounced back to me from the mailing list because it said I'm not a member (I've been active on the list for years, so I don't know why that happened?) Any chance you could send it to the list for me? I really want to get discussion going around this topic. There have been several opportunities recently to advance Python in education, but distribution difficulties of the software are a big impediment. There are also threats. I just received from my supervisor a sample competency list for a new National Occupational Competency Testing Institute (NOCTI) exam in Computer Programming. Under the heading "Code Programs" was the following options: Write a BASIC program Write a COBOL program Write a C program Write a Visual Basic program Python is not on the list. Neither is Java, and that will never stand, so there might be an opportunity here to do some more education around the merits of Python. Thanks! -- Jeffrey Elkner Open Book Project ------------------------------------------------------- -------------- next part -------------- An embedded message was scrubbed... From: Jeffrey Elkner Subject: Why we need "Fat Python" Date: Tue, 25 May 2004 10:47:52 -0400 Size: 2090 Url: http://mail.python.org/pipermail/edu-sig/attachments/20040526/536e9074/attachment.mht From sandysj at juno.com Wed May 26 12:36:51 2004 From: sandysj at juno.com (Jeff Sandys) Date: Wed May 26 12:36:32 2004 Subject: [Edu-sig] Re: Fwd: [Fwd: Why we need "Fat Python"] Message-ID: <40B4C7A3.6D73269F@juno.com> > The message below was bounced back to me from the mailing list > because it said I'm not a member ... The list owner changed the list properties 2 months ago to stop the spam, check your email address or resubscribe at: http://mail.python.org/mailman/listinfo/edu-sig > > I really want to get discussion going around this topic. There > have been several opportunities recently to advance Python in > education, but distribution difficulties of the software are a > big impediment. What are the distribution difficulties that cause the impediment? > There are also threats. I just received from my supervisor a > sample competency list for a new National Occupational > Competency Testing Institute (NOCTI) exam in Computer > Programming. ... Who uses the NOCTI? Is it stodgy companies who are looking for VB programmers, or companies the NOCTI sells its services to? > Python is not on the list. Neither is Java, and that will > never stand, so there might be an opportunity here to do some > more education around the merits of Python. > > Thanks! I think that computers and programming are getting to a critical mass where the is division between computer science and CP4E. I think that computer programming should be a modern skill that every student learns, like reading, writing, arithmetic, art, music, and sports. Every student should have the ability to express themselves in all these media because these media will be a part of there lives. Not everyone will make a vocation of computer science or other expressive media but they will use all these media in whatever vocation they choose. To me if NOCTI has 'write a program in Python' or not, doesn't matter as much as getting more (every) student exposed to programming. So tell me more about the distribution problems. Thanks, Jeff Sandys From Scott.Daniels at Acm.Org Mon May 31 16:04:21 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon May 31 16:03:37 2004 Subject: [Edu-sig] Re: VPython In-Reply-To: <10256101023452.10234521025610@optonline.net> References: <10256101023452.10234521025610@optonline.net> Message-ID: ajsiegel@optonline.net wrote: > Kirby writes - >>Yes. I'm meaning to pursue Scott's suggestion to look at Ruth Chabay's >>code. > FWIW, PyGeo's copy of Ruth's povexport module extends it a bit, allowing, for example, export of the VPython "faces" (triangle mesh) primitives. The export of the "faces" relies on some functionality not added to Pov-ray until version 3.5. > > Art I looked over the code I thought I had re-done, and it was not what I remembered working on. Here is a working version that doesn't build up a massive string, but rather writes to a destination. If you need a destination, make a CStringIO and use it. It would be fun to try and mix this with the PyGeo code. -------------- next part -------------- # ruth chabay, carnegie mellon university (rchabay@andrew.cmu.edu) # $Id: povexport.py 1.3 2004/05/31 19:56:05 daniels Exp daniels $ # v1.0 2000-12-17 # Markus Gritsch (gritsch@iue.tuwien.ac.at) # v.1.1 2001-03-09 # *) replaced 'scene' by 'display' everywhere # *) added spheres at the joints of a curve # *) consistent pov_texture usage in process_arrow() also for the shaft # *) ambient light, light sources, up, and fov are now handled correctly # *) some cosmetic changes to the code # v.1.1.1 2001-03-22 # *) added 'shadowless' keyword to export() # Ruth Chabay # 2001-06-23 # hack to fix error in export_curve introduced by Python 2.1 # now can't assign obj.color = array(...) # Markus Gritsch (gritsch@iue.tuwien.ac.at) # v.1.2 2001-11-23 # *) added 'xy_ratio' and 'custom_text' keywords to export() # *) the pov-strings are now directly written to a file # Scott David Daniels (Scott.Daniels@Acm.Org) # v.1.3 2004-May-31 Move code to output rather than concatenate text. """This module exports a VPython scene as POV-Ray scene description code. Lights and camera location from the current visual scene are included. Optionally, you may specify a list of include files, and pov textures for objects. For an example of its use, see 'povexample.py' convex objects are not exported. """ from visual import * from string import rfind __version__ = '0.1' ihat=vector(1, 0, 0) jhat=vector(0, 1, 0) khat=vector(0, 0, 1) def getpolar(a): # a is a vector # find rotation angles (standard polar coord) xy = sqrt(a.x**2 + a.y**2) theta = atan2(xy, a.z) phi = atan2(a.y, a.x) return theta, phi def process_frame(a, dest): # add in frame rotations & translations (may be nested) frame_code = '' fr = a.frame while fr: # orientation of frame.axis theta, phi = getpolar(fr.axis) aup = fr.up*1.0 # find rotation around x-axis (if fr.up <> jhat) # "undo" theta & phi rotations so can find alpha aup = rotate(aup, axis=khat, angle=-phi) aup = rotate(aup, axis=jhat, angle=pi/2.0-theta) a_sin = dot(cross(jhat, norm(aup)), ihat) a_cos = dot(norm(aup), jhat) alpha = atan2(a_sin, a_cos) frx=alpha*180./pi fry=-90+theta*180./pi frz=phi*180./pi print >>dest, ' rotate <%f, %f, %f>' % (frx, fry, frz) print >>dest, ' translate <%f, %f, %f>' % (fr.x, fr.y, fr.z) fr = fr.frame def add_texture(a, dest): # add in user-specified texture (will override color) try: print >>dest, ' texture { %s }' % a.pov_texture except AttributeError: pass def export_sphere(a, dest): print >>dest, """ sphere { <%(posx)f, %(posy)f, %(posz)f>, %(radius)f pigment { color rgb <%(red)f, %(green)f, %(blue)f> } """ % { 'posx':a.x, 'posy':a.y, 'posz':a.z, 'radius':a.radius, 'red':a.red, 'green':a.green, 'blue':a.blue } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" def export_box(a, dest): # create box at origin along x-axis # then rotate around x,y,z axes # then translate to final location # find rotations theta, phi = getpolar(a.axis) # find rotation around x-axis (if a.up <> jhat) # "undo" theta & phi rotations so can find alpha aup = a.up*1.0 aup = rotate(aup, axis=khat, angle=-phi) aup = rotate(aup, axis=jhat, angle=pi/2.0-theta) a_sin = dot(cross(jhat, norm(aup)), ihat) a_cos = dot(norm(aup), jhat) alpha = atan2(a_sin, a_cos) # pos of visual box is at center # generate two opposite corners for povray pos1=vector(0, 0, 0) - a.size / 2.0 pos2=vector(0, 0, 0) + a.size / 2.0 print >>dest, """ box { <%(posx)f, %(posy)f, %(posz)f>, <%(pos2x)f, %(pos2y)f, %(pos2z)f> pigment {color rgb <%(red)f, %(green)f, %(blue)f>} rotate <%(rotx)f, %(roty)f, %(rotz)f> translate <%(transx)f, %(transy)f, %(transz)f>""" % { 'posx':pos1.x, 'posy':pos1.y, 'posz':pos1.z, 'pos2x':pos2.x, 'pos2y':pos2.y, 'pos2z':pos2.z, 'rotx':alpha*180./pi, 'roty':-90.+theta*180./pi, 'rotz':phi*180./pi, 'transx':a.x, 'transy':a.y, 'transz':a.z, 'red':a.red, 'green':a.green, 'blue':a.blue } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" def export_cylinder(a, dest): endpt1=a.pos endpt2=a.pos+a.axis print >>dest, """cylinder { <%(posx)f, %(posy)f, %(posz)f>,<%(pos2x)f, %(pos2y)f, %(pos2z)f>, %(radius)f pigment { color rgb <%(red)f, %(green)f, %(blue)f> }""" % { 'posx':a.x, 'posy':a.y, 'posz':a.z, 'pos2x':endpt2.x, 'pos2y':endpt2.y, 'pos2z':endpt2.z, 'red':a.red, 'green':a.green, 'blue':a.blue, 'radius':a.radius } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" def export_curve(a, dest): object_code = '' if len(a.pos) > 1: ii = 0 radius = max(0, a.radius) ccyl = cylinder(pos=a.pos[0], axis=a.pos[0] - a.pos[0], radius=radius or .1, color=tuple(a.color[0]), frame=a.frame, visible=0) csph = sphere(pos=a.pos[0], radius=ccyl.radius, color=tuple(a.color[0]), frame=a.frame, visible=0) if hasattr(a, 'pov_texture'): csph.pov_texture = ccyl.pov_texture = a.pov_texture for ii in xrange(len(a.pos) - 1): # create a dummy cylinder to export csph.pos = ccyl.pos = a.pos[ii] ccyl.axis = a.pos[ii+1] - a.pos[ii] csph.radius = ccyl.radius = radius or mag(ccyl.axis) / 200. csph.color = ccyl.color = tuple(a.color[ii]) export_cylinder(ccyl, dest) export_sphere(csph, dest) ii = ii+1 ii = len(a.pos) - 1 csph.pos = a.pos[ii] # csph.radius is identical csph.color = tuple(a.color[ii]) export_sphere(csph, dest) elif len(a.pos) == 1 and a.radius > 0: csph = sphere(pos=a.pos[0], radius=a.radius, color=tuple(a.color[0]), frame=a.frame, visible=0) if hasattr(a, 'pov_texture'): csph.pov_texture = a.pov_texture export_sphere(csph, dest) def export_ring(a, dest): theta, phi = getpolar(a.axis) print >>dest, """ torus { %(radius)f, %(minorradius)f pigment { color rgb <%(red)f, %(green)f, %(blue)f> } rotate <0.0, 0.0, -90.0> // align with x-axis rotate <%(rotx)f, %(roty)f, %(rotz)f> translate <%(transx)f, %(transy)f, %(transz)f>""" % { 'radius':a.radius, 'minorradius':a.thickness, 'transx':a.x, 'transy':a.y, 'transz':a.z, 'rotx':0.0, 'roty':-90.+theta*180./pi, 'rotz':phi*180./pi, 'red':a.red, 'green':a.green, 'blue':a.blue } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" def export_arrow(a, dest): pyramid_template = """ object {Pyramid pigment { color rgb <%(red)f, %(green)f, %(blue)f> } scale <%(scalex)f, %(scaley)f, %(scalez)f> rotate <0, 0, -90> // align with x-axis rotate <%(rotx)f, %(roty)f, %(rotz)f> translate <%(transx)f, %(transy)f, %(transz)f> } """ al = a.length hl = a.headlength sl = al-hl # length of shaft hw = a.headwidth sw = a.shaftwidth # head is a pyramid ppos = a.pos+a.axis*(sl/al) theta, phi = getpolar(a.axis) print >>dest, """ object {Pyramid pigment { color rgb <%(red)f, %(green)f, %(blue)f> } scale <%(scalex)f, %(scaley)f, %(scalez)f> rotate <0, 0, -90> // align with x-axis rotate <%(rotx)f, %(roty)f, %(rotz)f> translate <%(transx)f, %(transy)f, %(transz)f> """ % { 'scalex':hw, 'scaley':hl, 'scalez':hw, 'rotx':0., 'roty':-90.+theta*180./pi, 'rotz':phi*180./pi, 'red':a.red, 'green':a.green, 'blue':a.blue, 'transx':ppos.x, 'transy':ppos.y, 'transz':ppos.z } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" # shaft is a box; need to create a dummy box abox = box(pos=a.pos+a.axis*(sl/al)/2.0, axis=a.axis*(sl/al), up = a.up, width=a.shaftwidth, height=a.shaftwidth, color=a.color, frame=a.frame, visible = 0) if hasattr(a, 'pov_texture'): abox.pov_texture = a.pov_texture export_box(abox, dest) ## ??? inhibit process_frame code. ??? def export_cone(a, dest): pos2 = a.pos + a.axis print >>dest, """ cone { <%(posx)f, %(posy)f, %(posz)f>, %(radius)f <%(pos2x)f, %(pos2y)f, %(pos2z)f>, %(minorradius)f pigment { color rgb <%(red)f, %(green)f, %(blue)f> }""" % { 'radius':a.radius, 'minorradius':0.0, 'posx':a.x, 'posy':a.y, 'posz':a.z, 'pos2x':pos2.x, 'pos2y':pos2.y, 'pos2z':pos2.z, 'red':a.red, 'green':a.green, 'blue':a.blue } process_frame(a, dest) add_texture(a, dest) print >>dest, "}" def dontexport(a, dest): pass export_table = dict( sphere=export_sphere, box=export_box, cylinder=export_cylinder, curve=export_curve, ring=export_ring, arrow=export_arrow, cone=export_cone, frame=dontexport) def export(display=None, filename=None, include_list=None, xy_ratio=4./3., custom_text='', shadowless=False): if display is None: # no display specified so find active display dummy = sphere(visible=0) display = dummy.display del dummy if filename is None: filename = display.title + '.pov' dest = open(filename, 'wt') print >>dest, '// povray code generated by povexport.py v%s' % __version__ if include_list is not None: for x in include_list: print >>dest, '#include "%s"\n' % x print >>dest, custom_text # The next is needed only for arrows. print >>dest, """// Four-sided pyramid from shapes2.inc, slightly modified. #declare Pyramid = union { triangle { <-1, 0, -1>, <+1, 0, -1>, <0, 1, 0> } triangle { <+1, 0, -1>, <+1, 0, +1>, <0, 1, 0> } triangle { <-1, 0, +1>, <+1, 0, +1>, <0, 1, 0> } triangle { <-1, 0, +1>, <-1, 0, -1>, <0, 1, 0> } triangle { <-1, 0, -1>, <-1, 0, +1>, <1, 0, 1> } triangle { <-1, 0, -1>, <+1, 0, -1>, <1, 0, 1> } scale <.5, 1, .5> // so height = width = 1 }""" print >>dest, 'global_settings { ambient_light rgb', print >>dest, '<%(a)f, %(a)f, %(a)f> }' % {'a': display.ambient * 10} print >>dest, 'background { color rgb <%(r)f, %(g)f, %(b)f> }' % { 'r':display.background[0], 'g':display.background[1], 'b':display.background[2] } # begin povray setup for i in arange(len(display.lights)): # reproduce visual lighting (not ideal, but good approximation) light = display.lights[i] # vector in direction of light intensity = mag(light) # intensity of light (all lights are white) pos = norm(light) * max(display.range) * 100.0 # far away to simulate parallel light print >>dest, """light_source { <%(posx)f, %(posy)f, %(posz)f> color rgb <%(int)f, %(int)f, %(int)f>""" % { 'posx':pos.x, 'posy':pos.y, 'posz':pos.z, 'int':intensity*5/3.} if shadowless: print >>dest, ' shadowless' print >>dest, '}' ## ??? Frame code for lights??? cpos = display.mouse.camera ctr = display.center cup = display.up print >>dest, """camera { right <-%(xyratio)f, 0, 0> //visual uses right-handed coord. system location <%(posx)f, %(posy)f, %(posz)f> sky <%(upx)f, %(upy)f, %(upz)f> look_at <%(pos2x)f, %(pos2y)f, %(pos2z)f> angle %(fov)f rotate <0, 0, 0> }""" % { 'xyratio':xy_ratio, 'posx':cpos.x, 'posy':cpos.y, 'posz':cpos.z, 'upx':cup.x, 'upy':cup.y, 'upz':cup.z, 'pos2x':ctr.x, 'pos2y':ctr.y, 'pos2z':ctr.z, 'fov':display.fov*180/pi } exports = export_table.copy() for obj in display.objects: name = str(obj.__class__) try: function = exports[name] except AttributeError: print 'WARNING: export function for %s not implemented' % name exports[name] = dontexport # Only report each type once. else: function(obj, dest) dest.close() return 'The export() function no longer returns the scene as an\n' \ 'endless POV-Ray string, but saves it to a file instead.' if __name__ == '__main__': import sys print 'povexport %s\nPython %s' % (__version__, sys.version) print __doc__