From mtobis at gmail.com Thu Feb 1 04:20:06 2007 From: mtobis at gmail.com (Michael Tobis) Date: Wed, 31 Jan 2007 21:20:06 -0600 Subject: [Edu-sig] [PyCON-Organizers] Interest in Newby lecture at PyC on? In-Reply-To: <37E3DF6920CC664D924AFA9966C33EE868E1B9@bn-exchdmz> References: <37E3DF6920CC664D924AFA9966C33EE868E1B9@bn-exchdmz> Message-ID: OK. So I think people should not need to be registered for the conference to attend. Is that possible? I imagine Python 101 is for professionals learning Python as an nth language. I don't intend to compete with that. I would like to call the presentation "Python as a First Language", and would like attendees to have a working copy of Idle on a laptop. The intended audience will be in town (locals or accompanying family) but is unlikely to pony up for the conference. If it is OK with you all and the hotel I will be happy to proceed on the basis that it is free of charge and doesn't require conference registration. Alternatively I could offer sort of a dress rehearsal, and edu-sig types can attend but it would probably be of little interest to other badge carrying conference attendees. This would be much shorter. My current plan is to be arriving Friday and leaving Sunday so I'd much prefer early on Saturday evening. Michael On 1/31/07, Napoleone, Doug wrote: > > > Please feel free to give this presentation as an Open Space talk or a BoF: > http://us.pycon.org/TX2007/OpenSpace > > We have the conference rooms the entire weekend, and this type of talk > would > be perfect for one of the evenings. > We have 5 Open space rooms for use durring the day when other talks are > given, and all the rooms will be available in the evenings. > (space listed on the floorplan: > http://us.pycon.org/uploads/TX2007/HotelFloorPlan07.png) > > We recommend that people giving talks along side the scheduled talks also > keep them to the 30, 45, or 60min slot they will be running in parallel > with. That way people will not be leaving early or arriving late you the > open space talk due to wanting to see other presentations. This is only a > recommendation. > > It is too late to get this on as an official presentation (especially as > presentations are 30 or 45min long and the deadline for submission was > October.) This sounds more like a tutorial, a Pre-Python101 tutorial if > you > will; (We have a 3 hour Python 101 tutorial already: > http://us.pycon.org/TX2007/TutorialsAM#AM5). Please consider giving this > talk as a tutorial next year, possably as a pre-cursor to the python 101 > tutorial. > > I am working with Jeff Rush to try to get the schedule system to be more > flexible and include evening BoF/Meeting and fun social activities. We > have > some things planned and some unofficial stuff we would like to see on > there, > your talk could be one of those. I will let you know if we can get that to > happen. > > I am working on a call for proctors for the Python Lab > (http://us.pycon.org/TX2007/PythonLab). Please consider helping out with > that as well. It would be nice if people could attend your talk before > going > to the lab, unfortunatly it is running Friday evening, so I doubt that > will > happen. > > -Doug > > > -----Original Message----- > > From: pycon-organizers-bounces at python.org > > [mailto:pycon-organizers-bounces at python.org] On Behalf Of Vern Ceder > > Sent: Wednesday, January 31, 2007 1:47 PM > > To: Michael Tobis > > Cc: edu-sig at python.org; pycon-organizers at python.org > > Subject: Re: [PyCON-Organizers] [Edu-sig] Interest in Newby > > lecture at PyCon? > > > > I don't know if we would have the newbies around who would > > benefit from the presentation, but I would be interested in > > getting at least an overview of your presentation. > > > > Is there any interest in having that sort of presentation be > > one of the main topics we discuss as a BOF? Maybe Michael > > could get us started with an outline of what he does and the > > rest could offer their apporoaches? > > Just thinking out loud here... > > > > Cheers, > > Vern > > > > > > Michael Tobis wrote: > > > I guess it's a bit late to try to put this together, but is > > there any > > > interest in putting together a Python for Newbies presentation at > > > PyCon for friends and family? > > > > > > I have a two-hour presentation I've given a few times, so > > it would not > > > take much prep for me to do this. It has some nice > > features, in that > > > it gives people the flavor of programming in just one session. > > > > > > best > > > Michael Tobis > > > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Edu-sig mailing list > > > Edu-sig at python.org > > > http://mail.python.org/mailman/listinfo/edu-sig > > > > -- > > This time for sure! > > -Bullwinkle J. Moose > > ----------------------------- > > Vern Ceder, Director of Technology > > Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 > > vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 > > _______________________________________________ > > Pycon-organizers mailing list > > Pycon-organizers at python.org > > http://mail.python.org/mailman/listinfo/pycon-organizers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070131/5e78ac8f/attachment.htm From ajsiegel at optonline.net Thu Feb 1 23:25:58 2007 From: ajsiegel at optonline.net (Arthur) Date: Thu, 01 Feb 2007 17:25:58 -0500 Subject: [Edu-sig] arthur siegel has passed away Message-ID: <45C268F6.6020900@optonline.com> We wanted to inform anyone familiar with Arthur Siegel's work with PyGeo that Arthur passed away on Tuesday. Anyone interested in more information can email his sister at bethsiegel at rcn.com. The funeral will be at 12:00 at the Riverside Memorial Chapel, 21 West Broad Street in Mount Vernon New York. From kirby.urner at gmail.com Fri Feb 2 01:55:24 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 1 Feb 2007 16:55:24 -0800 Subject: [Edu-sig] arthur siegel has passed away In-Reply-To: <45C268F6.6020900@optonline.com> References: <45C268F6.6020900@optonline.com> Message-ID: I have written to Beth, offering my condolances to the family. I was in touch with Arthur by private email up to his final hours, but had no idea this was coming. I think he did though, looking back. Kirby On 2/1/07, Arthur wrote: > > We wanted to inform anyone familiar with Arthur Siegel's work with PyGeo > that Arthur passed away on Tuesday. Anyone interested in more > information can email his sister at bethsiegel at rcn.com. The funeral > will be at 12:00 at the Riverside Memorial Chapel, 21 West Broad Street > in Mount Vernon New York. > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070201/c204916f/attachment.htm From pdfernhout at kurtz-fernhout.com Fri Feb 2 15:05:16 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 02 Feb 2007 09:05:16 -0500 Subject: [Edu-sig] arthur siegel has passed away In-Reply-To: <45C268F6.6020900@optonline.com> References: <45C268F6.6020900@optonline.com> Message-ID: <45C3451C.6070702@kurtz-fernhout.com> Beth- I just read your note. I am sorry to hear about the death of Arthur. I enjoyed conversing with Arthur via email. We didn't always agree (who does?), but he made a lot of great points and I learned much from reading his writing, including looking back on is contributions for years in the edusig archives. Arthur had many thought provoking things to say, and I am glad he took the time to say them and contribute to a large discussion on computers and education. We were certainly in broad general agreement about the value of learning and a desire to make the learning experience as good a one as possible for as many people as possible. Arthur may not have had the publicly-recognized "star" quality of some in the computer field (including some whom he critiqued here on the edusig list), but "the woods would be very quiet if no bird sang there but the one judged best". Arthur's was an important voice in the wilderness of technology, and it saddens me that I will no longer be able to get his perspective on new technology issues as they arise. Arthur made a positive contribution to education with PyGeo (and I'm sure other things, including his writings to edusig, the archive of which will hopefully continue to echo his voice for a long time to come). I am glad PyGeo is hosted at SourceForge and so will also continue to be available to learners as a monument to Arthur's dedication and caring and generosity and love of learning and love of Geometry. One of the most insightful things Arthur wrote to edusig recently was: : One theme that seems to run through discussions here is related to this : issue. Is it the educators' mission to find just the right motivational : buttons and push them just right ??? Or rather focus on responding : appropriately to those who come to the learning process with some : critical mass level of motivation??? : : It seems to be one of the fault lines, in some of the discussions here. It was a great insight into the nature of education and the soul of the educator and the learner. It is an insight I still need to reflect on more, along with his other writings. Arthur will be missed. Whatever the nature of the great Geometric mystery beyond the end of life in this world, I wish him well. Again, my condolences in this difficult time for you and the rest of his family. --Paul Fernhout Arthur wrote: > We wanted to inform anyone familiar with Arthur Siegel's work with PyGeo > that Arthur passed away on Tuesday. Anyone interested in more > information can email his sister at bethsiegel at rcn.com. The funeral > will be at 12:00 at the Riverside Memorial Chapel, 21 West Broad Street > in Mount Vernon New York. From vcowal at yahoo.com Fri Feb 2 17:59:51 2007 From: vcowal at yahoo.com (Vincent Cowal) Date: Fri, 2 Feb 2007 08:59:51 -0800 (PST) Subject: [Edu-sig] Arthur Siegel In-Reply-To: Message-ID: <635986.87449.qm@web51007.mail.yahoo.com> I never met Arthur. I have only read his frequent contributions to this list. Yet I am deeply saddened by news of his passing. His words were thought-provoking, his ideas challenging (and he sometimes even kept Kirby at bay...). I will miss him a great deal. --------------------------------- We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070202/7285d84e/attachment.htm From jeff at elkner.net Sat Feb 3 17:45:10 2007 From: jeff at elkner.net (Jeffrey Elkner) Date: Sat, 3 Feb 2007 16:45:10 +0000 Subject: [Edu-sig] [edupython] PyCon Activities In-Reply-To: Message-ID: <20070203164510.25807.1945445589.divmod.quotient.8588@ohm> Thanks for taking the initiative on this Michael. I'll be heavily involved in SchoolTool/CanDo planning. In addition to sprinting Feb. 26 to Mar. 1, the team will probably be meeting evenings durning the conference as well. I'll be able to sneak out to edupython events, however, and look forward to meeting with other edupython folks at the conference. Thanks! jeff On Sat, 3 Feb 2007 10:39:46 -0600, Michael Tobis wrote: >Happy February y'all. > >So, what are we planning to do at PyCon in the edu-sig? It's linked from the >PyCon 07 front page but doesn't seem to go anywhere. Is there some >organizing activity that I don't know about? > >Any ideas about rooms, times, presentations? Another dinner? > >mt From mtobis at gmail.com Sat Feb 3 17:39:46 2007 From: mtobis at gmail.com (Michael Tobis) Date: Sat, 3 Feb 2007 10:39:46 -0600 Subject: [Edu-sig] PyCon Activities Message-ID: Happy February y'all. So, what are we planning to do at PyCon in the edu-sig? It's linked from the PyCon 07 front page but doesn't seem to go anywhere. Is there some organizing activity that I don't know about? Any ideas about rooms, times, presentations? Another dinner? mt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070203/d70fd5e9/attachment.htm From vceder at canterburyschool.org Sat Feb 3 19:50:35 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Sat, 03 Feb 2007 13:50:35 -0500 Subject: [Edu-sig] PyCon Activities In-Reply-To: References: Message-ID: <45C4D97B.5090604@canterburyschool.org> The link from the PyCon 2007 page is all that I know of. We do need to decide on a night for dinner, and I assume that might be followed (as in the past) by moving to a room for more discussion. When were you thinking of giving your Python as a First Language talk? Last year we did dinner in the hotel restaurant on Friday evening, followed by a gathering for discussion in one of the conference rooms. If someone has a suggestion for a restaurant, that would be good, but we need to decide on the night... Cheers, Vern Ceder Michael Tobis wrote: > Happy February y'all. > > So, what are we planning to do at PyCon in the edu-sig? It's linked from > the PyCon 07 front page but doesn't seem to go anywhere. Is there some > organizing activity that I don't know about? > > Any ideas about rooms, times, presentations? Another dinner? > > mt > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From vceder at canterburyschool.org Sun Feb 4 06:25:21 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Sun, 04 Feb 2007 00:25:21 -0500 Subject: [Edu-sig] PyCon Activities In-Reply-To: <45C4D97B.5090604@canterburyschool.org> References: <45C4D97B.5090604@canterburyschool.org> Message-ID: <45C56E41.1030505@canterburyschool.org> One thought comes to me in looking at the schedule... The newby talk could be on Friday, opposite the Python lab session and the edu-sig dinner would then be Saturday. My reasoning is that the Python lab session will attract the more experienced programmers, but not anyone new to programming or Python. Just a thought... Cheers, Vern Vern Ceder wrote: > The link from the PyCon 2007 page is all that I know of. We do need to > decide on a night for dinner, and I assume that might be followed (as in > the past) by moving to a room for more discussion. > > When were you thinking of giving your Python as a First Language talk? > Last year we did dinner in the hotel restaurant on Friday evening, > followed by a gathering for discussion in one of the conference rooms. > > If someone has a suggestion for a restaurant, that would be good, but we > need to decide on the night... > > Cheers, > Vern Ceder > > > Michael Tobis wrote: >> Happy February y'all. >> >> So, what are we planning to do at PyCon in the edu-sig? It's linked from >> the PyCon 07 front page but doesn't seem to go anywhere. Is there some >> organizing activity that I don't know about? >> >> Any ideas about rooms, times, presentations? Another dinner? >> >> mt >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig at python.org >> http://mail.python.org/mailman/listinfo/edu-sig > -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From christian.mascher at gmx.de Sun Feb 4 21:28:33 2007 From: christian.mascher at gmx.de (Christian Mascher) Date: Sun, 04 Feb 2007 21:28:33 +0100 Subject: [Edu-sig] Arthur Siegel In-Reply-To: <635986.87449.qm@web51007.mail.yahoo.com> References: <635986.87449.qm@web51007.mail.yahoo.com> Message-ID: <45C641F1.2030901@gmx.de> Arthur wrote: >thank you all for listening. > >Art > > Thank you, Arthur. I will miss you on this list, too. Christian From jeff at taupro.com Tue Feb 6 14:04:54 2007 From: jeff at taupro.com (Jeff Rush) Date: Tue, 06 Feb 2007 07:04:54 -0600 Subject: [Edu-sig] PyCon Activities In-Reply-To: <45C56E41.1030505@canterburyschool.org> References: <45C4D97B.5090604@canterburyschool.org> <45C56E41.1030505@canterburyschool.org> Message-ID: <45C87CF6.4020805@taupro.com> Vern Ceder wrote: > One thought comes to me in looking at the schedule... > > The newby talk could be on Friday, opposite the Python lab session and > the edu-sig dinner would then be Saturday. My reasoning is that the > Python lab session will attract the more experienced programmers, but > not anyone new to programming or Python. Actually the Python Lab session is intended to attract those at least somewhat new to Python, by trying to show how different skill levels would approach the same problem. If the only people who show up for the lab are experts, it's going to be rather boring. ;-) But those completely new to programming, or who don't feel comfortable tackling problems in a group environment yet may want the newbie talk. So it's probably a good scheduling timeslot, to do it on Fri. We're also looking for a BoF timeslot, probably on Sat, at which Ivan can provide hands-on/upclose access to the One Laptop per Child demo unit he is bringing, and answer questions about the project. He suggested holding it over beer/dinner if not too many people are going, but I expect strong interest in OLPC. I'm wondering if we can do an edu-sig dinner early and then regroup back at the hotel for the demo and other presentations the edu-sig has mentioned may happen. -Jeff From drake at lclark.edu Tue Feb 6 20:03:42 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 11:03:42 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE Message-ID: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> Okay, so I've got a simple system worked up that allows students (these are "CS0" non-CS-majors) to manipulate objects with commands in the IDLE command window. The file is attached. The next thing I'd like to do is define a function mouse() that starts the main loop, waits for a mouse click, stops the main loop, and returns the coordinates of the mouse click. Any suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: graphics.py Type: text/x-python-script Size: 1891 bytes Desc: not available Url : http://mail.python.org/pipermail/edu-sig/attachments/20070206/815a26bc/attachment.bin -------------- next part -------------- Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ From kirby.urner at gmail.com Tue Feb 6 23:43:44 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 6 Feb 2007 14:43:44 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> Message-ID: Have you checked John Zelle's book and site? He has a wrapper for Tkinter that significantly simplifies Python programming for Tk, plus it has some nifty features. Zelle's is the best CS0 book I'm aware of at this point: http://mcsp.wartburg.edu/zelle/python/ Kirby On 2/6/07, Peter Drake wrote: > > Okay, so I've got a simple system worked up that allows students > (these are "CS0" non-CS-majors) to manipulate objects with commands > in the IDLE command window. The file is attached. > > The next thing I'd like to do is define a function mouse() that > starts the main loop, waits for a mouse click, stops the main loop, > and returns the coordinates of the mouse click. Any suggestions? > > > > Peter Drake > Assistant Professor of Computer Science > Lewis & Clark College > http://www.lclark.edu/~drake/ > > > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070206/f11977d7/attachment.htm From john.zelle at wartburg.edu Tue Feb 6 23:23:42 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Tue, 6 Feb 2007 16:23:42 -0600 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> Message-ID: <200702061623.42765.john.zelle@wartburg.edu> Hi Peter, Just a quick question for you. I am wondering if you have checked out the simple graphics package that I built on top of Tkinter for doing these sorts of simple manipulations. It's also name graphics.py. If you haven't seen it, you can check it out at: http://mcsp.wartburg.edu/zelle/python. It's probably that case that it doesn't meet your needs, but if it does it would keep you from aving to "reinvent the wheel." --John On Tuesday 06 February 2007 1:03 pm, Peter Drake wrote: > Okay, so I've got a simple system worked up that allows students > (these are "CS0" non-CS-majors) to manipulate objects with commands > in the IDLE command window. The file is attached. > > The next thing I'd like to do is define a function mouse() that > starts the main loop, waits for a mouse click, stops the main loop, > and returns the coordinates of the mouse click. Any suggestions? -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From drake at lclark.edu Wed Feb 7 00:05:48 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 15:05:48 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> Message-ID: I should probably send this to the entire list... On Feb 6, 2007, at 3:04 PM, Peter Drake wrote: > Yes, and you're the third person to have suggested it today. (Nice > book, by the way!) > > Three things prevent me from using your package as-is: > > 1) The graphics window appears BEHIND the Console window (which in > turn appears behind the IDLE window). > > 2) Once the main loop starts, you can't enter new commands into the > IDLE shell. > > 3) It is object-oriented, confusing students with the combination > of regularFunctions() and object.methods(). I'd just as soon avoid > this if possible. > > If anyone can direct me to a way around the first two problems I > could, of course, write wrapper functions to deal with the third. > > Thanks, > > Peter Drake > Assistant Professor of Computer Science > Lewis & Clark College > http://www.lclark.edu/~drake/ > > > > > On Feb 6, 2007, at 2:23 PM, John Zelle wrote: > >> Hi Peter, >> >> Just a quick question for you. I am wondering if you have checked >> out the >> simple graphics package that I built on top of Tkinter for doing >> these sorts >> of simple manipulations. It's also name graphics.py. If you >> haven't seen it, >> you can check it out at: http://mcsp.wartburg.edu/zelle/python. >> It's probably that case that it doesn't meet your needs, but if it >> does it >> would keep you from aving to "reinvent the wheel." >> >> --John >> >> >> >> On Tuesday 06 February 2007 1:03 pm, Peter Drake wrote: >>> Okay, so I've got a simple system worked up that allows students >>> (these are "CS0" non-CS-majors) to manipulate objects with commands >>> in the IDLE command window. The file is attached. >>> >>> The next thing I'd like to do is define a function mouse() that >>> starts the main loop, waits for a mouse click, stops the main loop, >>> and returns the coordinates of the mouse click. Any suggestions? >> >> -- >> John M. Zelle, Ph.D. Wartburg College >> Professor of Computer Science Waverly, IA >> john.zelle at wartburg.edu (319) 352-8360 >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig at python.org >> http://mail.python.org/mailman/listinfo/edu-sig > From kirby.urner at gmail.com Wed Feb 7 00:32:44 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 6 Feb 2007 15:32:44 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> Message-ID: > > > > 3) It is object-oriented, confusing students with the combination > > of regularFunctions() and object.methods(). I'd just as soon avoid > > this if possible. In my course, we go to the object model very early, on the assumption that OO is Python's paradigm. But we're not doing a formal CS0, so aren't a puzzle piece in someone's larger grand scheme of things. The way we introduce OO is demonstrated in my "classes and subclasses" screencast here: http://controlroom.blogspot.com/2007/01/python-for-math-teachers.html I also much prefer VPython to Tk for doing intro level graphics (not that it has to be either/or -- Tk is better for widgets (which I wouldn't touch without OO already established)). As for what windows open in front of what, seems to me if the windows are small to begin with it's not a big deal to click on the one you want to have focus, but I guess I'm not understanding your real problem. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070206/17b52593/attachment.html From drake at lclark.edu Wed Feb 7 01:12:08 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 16:12:08 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> Message-ID: <04179AD1-DE7D-4BBE-943F-8BE0FED21328@lclark.edu> I'm planning to keep things at a very low level throughout the course. These students aren't ever going to be writing programs more than ten or twenty lines long, so all of the OO machinery is unnecessarily confusing. (I am, of course, not trying to start any kind of paradigm war here; I'm just explaining where I'm coming from.) I don't intend to have any buttons or other widgets; just a single canvas on which lines, ovals, polygons, and text are drawn. As for the window issue, it is an annoyance to have to explicitly bring the graphics window forward every time you reload your program. Is there no command I could put into the program to bring this window to the front? I may play with writing a procedural front end for Zelle's library. Stay tuned. Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ On Feb 6, 2007, at 3:32 PM, kirby urner wrote: > > > 3) It is object-oriented, confusing students with the combination > > of regularFunctions() and object.methods(). I'd just as soon avoid > > this if possible. > > In my course, we go to the object model very early, on the assumption > that OO is Python's paradigm. But we're not doing a formal CS0, so > aren't a puzzle piece in someone's larger grand scheme of things. > > The way we introduce OO is demonstrated in my "classes and subclasses" > screencast here: > > http://controlroom.blogspot.com/2007/01/python-for-math-teachers.html > > I also much prefer VPython to Tk for doing intro level graphics > (not that it > has to be either/or -- Tk is better for widgets (which I wouldn't > touch without > OO already established)). > > As for what windows open in front of what, seems to me if the windows > are small to begin with it's not a big deal to click on the one you > want to > have focus, but I guess I'm not understanding your real problem. > > Kirby > From john.zelle at wartburg.edu Wed Feb 7 01:20:45 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Tue, 6 Feb 2007 18:20:45 -0600 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> Message-ID: <200702061820.45854.john.zelle@wartburg.edu> Hi Peter, On Tuesday 06 February 2007 5:04 pm, Peter Drake wrote: > Yes, and you're the third person to have suggested it today. (Nice > book, by the way!) > > Three things prevent me from using your package as-is: > > 1) The graphics window appears BEHIND the Console window (which in > turn appears behind the IDLE window). You're right that on some platforms Tk windows will not "surface." I haven't found a way around this problem yet. I don't understand what you mean by the Console window. Aren't you using IDLE's shell? In general the popping up behind problem is not a big deal since you can just click on the appropriate icon on the task bar to bring it to the front (Windows and Linux). Although this may not work on the Mac... > > 2) Once the main loop starts, you can't enter new commands into the > IDLE shell. > I don't understand this comment. Are you running IDLE in it's normal mode (with a separate subprocess for user code)? I expended a fair amount of effort making my graphics library play nicely with IDLE. The mainloop is completely hidden in the graphics module, and you can continue interacting with any number of graphics objects and/or windows at the IDLE shell. If that's not working for you, make sure to get the newest version of the library. BTW if you are running IDLE in the no-subprocess (-n) mode, then you might want to use the older (non-threaded) version of the library. > 3) It is object-oriented, confusing students with the combination of > regularFunctions() and object.methods(). I'd just as soon avoid this > if possible. I can understand this if that's your goal. My point was to use graphics as a very concrete way to introduce the idea of objects. I don't find that my students have any problems at all with using objects (writing their own classes is another story). > > If anyone can direct me to a way around the first two problems I > could, of course, write wrapper functions to deal with the third. Yes, it would be very easy to wrap flat functions around my graphics library if you restrict yourself to one graphics window. --John > > Peter Drake > Assistant Professor of Computer Science > Lewis & Clark College > http://www.lclark.edu/~drake/ > > On Feb 6, 2007, at 2:23 PM, John Zelle wrote: > > Hi Peter, > > > > Just a quick question for you. I am wondering if you have checked > > out the > > simple graphics package that I built on top of Tkinter for doing > > these sorts > > of simple manipulations. It's also name graphics.py. If you haven't > > seen it, > > you can check it out at: http://mcsp.wartburg.edu/zelle/python. > > It's probably that case that it doesn't meet your needs, but if it > > does it > > would keep you from aving to "reinvent the wheel." > > > > --John > > > > On Tuesday 06 February 2007 1:03 pm, Peter Drake wrote: > >> Okay, so I've got a simple system worked up that allows students > >> (these are "CS0" non-CS-majors) to manipulate objects with commands > >> in the IDLE command window. The file is attached. > >> > >> The next thing I'd like to do is define a function mouse() that > >> starts the main loop, waits for a mouse click, stops the main loop, > >> and returns the coordinates of the mouse click. Any suggestions? > > > > -- > > John M. Zelle, Ph.D. Wartburg College > > Professor of Computer Science Waverly, IA > > john.zelle at wartburg.edu (319) 352-8360 > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Wed Feb 7 01:58:18 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 6 Feb 2007 16:58:18 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <04179AD1-DE7D-4BBE-943F-8BE0FED21328@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> <04179AD1-DE7D-4BBE-943F-8BE0FED21328@lclark.edu> Message-ID: On 2/6/07, Peter Drake wrote: > > I'm planning to keep things at a very low level throughout the > course. These students aren't ever going to be writing programs more > than ten or twenty lines long, so all of the OO machinery is > unnecessarily confusing. (I am, of course, not trying to start any > kind of paradigm war here; I'm just explaining where I'm coming from.) I confess to being overtly suspicious of any programming course using Python that doesn't dive in to OO. Seems a waste of a good opportunity to enlighten students as to the state of the art, even if they're not planning to become programmers. Indeed, some of the simplest programs one might want to write in Python involve subclassing something from the standard library and overwriting a few methods. But this isn't to heap criticism on your CS0 in particular. I've seen any number of CS departments doing this ontogeny recapitulates phylogeny thing, slogging through procedural code for an entire semester, before unveiling OO in a second year. I explicitly inveigh against that practice in my aforementioned screencast "classes and subclasses". But then, I have a different demographic. My students are learning mathematics, and need operator overloading from the get go. How else to implement Vectors in a satisfying manner, other than by implementing __add__ and/or __mul__? Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070206/70028573/attachment.html From johannes.wollard at gmail.com Wed Feb 7 02:19:28 2007 From: johannes.wollard at gmail.com (Johannes Woolard) Date: Wed, 7 Feb 2007 01:19:28 +0000 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> Message-ID: <10c99c2a0702061719t4589a5f8vd0939c74307e5641@mail.gmail.com> On 2/6/07, Peter Drake wrote: > Okay, so I've got a simple system worked up that allows students > (these are "CS0" non-CS-majors) to manipulate objects with commands > in the IDLE command window. The file is attached. > hmm, coincidentally I started playing with a similar system for Crunchy a couple of days ago - more or less the same except it uses Crunchy's in browser interface instead of IDLE. Hopefully I'll be able to give Andr? some demo code before PyCon - I think this is one of the best uses of the Python interpreter in education. Johannes -- Johannes Woolard, Oriel College, Oxford, UK 0X1 4EW From drake at lclark.edu Wed Feb 7 02:21:43 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 17:21:43 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <200702061820.45854.john.zelle@wartburg.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> <200702061820.45854.john.zelle@wartburg.edu> Message-ID: <3C5A93C1-74F1-4640-A430-F4696CF74F2B@lclark.edu> On Feb 6, 2007, at 4:20 PM, John Zelle wrote: > You're right that on some platforms Tk windows will not "surface." > I haven't > found a way around this problem yet. I don't understand what you > mean by the > Console window. Aren't you using IDLE's shell? Yes. > In general the popping up behind problem is not a big deal since > you can just > click on the appropriate icon on the task bar to bring it to the front > (Windows and Linux). Although this may not work on the Mac... Yes, there's a workaround, but it feels like one shouldn't have to work around it. We Mac users are spoiled that way. :-) >> 2) Once the main loop starts, you can't enter new commands into the >> IDLE shell. > > I don't understand this comment. Are you running IDLE in it's > normal mode Please disregard this comment. It's okay as long as you don't run mainloop(). >> 3) It is object-oriented, confusing students with the combination of >> regularFunctions() and object.methods(). I'd just as soon avoid this >> if possible. > > I can understand this if that's your goal. My point was to use > graphics as a > very concrete way to introduce the idea of objects. I don't find > that my > students have any problems at all with using objects (writing their > own > classes is another story). I discovered last semester that (these) students find graphics VERY appealing, so I wanted to introduce that on day 1. I'd rather have them start off with line([0, 0], [100, 100]) than win = GraphWin() myLine = Line(Point(0, 0), Point(100, 100)) myLine.draw(win) >> If anyone can direct me to a way around the first two problems I >> could, of course, write wrapper functions to deal with the third. > > Yes, it would be very easy to wrap flat functions around my > graphics library > if you restrict yourself to one graphics window. Working on it... Thanks, Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ From drake at lclark.edu Wed Feb 7 02:25:50 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 17:25:50 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> <04179AD1-DE7D-4BBE-943F-8BE0FED21328@lclark.edu> Message-ID: <919EC21C-F3A0-4222-B2F2-50AF3753F5E6@lclark.edu> It's not that I'm going to do procedural first and objects later. The vast majority of these students will never take another programming class. There is also a significant level of math phobia in this course, so anything I can do to make it less complicated is a win. Indeed, they spent the first couple of weeks with LEGO robots... I was under the impression that Python was trying to be "multiparadigm", so you could program in a procedural, OO, or functional style. This doesn't seem to bear out for any but the simplest programs, but I'm hoping I can pretend it's procedural for CS0. Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ On Feb 6, 2007, at 4:58 PM, kirby urner wrote: > On 2/6/07, Peter Drake wrote: I'm planning to > keep things at a very low level throughout the > course. These students aren't ever going to be writing programs more > than ten or twenty lines long, so all of the OO machinery is > unnecessarily confusing. (I am, of course, not trying to start any > kind of paradigm war here; I'm just explaining where I'm coming from.) > > I confess to being overtly suspicious of any programming course > using Python that doesn't dive in to OO. Seems a waste of a good > opportunity to enlighten students as to the state of the art, even if > they're not planning to become programmers. Indeed, some of the > simplest programs one might want to write in Python involve > subclassing something from the standard library and overwriting > a few methods. > > But this isn't to heap criticism on your CS0 in particular. I've seen > any number of CS departments doing this ontogeny recapitulates > phylogeny thing, slogging through procedural code for an entire > semester, before unveiling OO in a second year. I explicitly inveigh > against that practice in my aforementioned screencast "classes > and subclasses". But then, I have a different demographic. My > students are learning mathematics, and need operator overloading > from the get go. How else to implement Vectors in a satisfying > manner, other than by implementing __add__ and/or __mul__? > > Kirby > From kirby.urner at gmail.com Wed Feb 7 04:05:19 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 6 Feb 2007 19:05:19 -0800 Subject: [Edu-sig] Interactive Tkinter graphics under IDLE In-Reply-To: <919EC21C-F3A0-4222-B2F2-50AF3753F5E6@lclark.edu> References: <564F5E7F-1D57-4A2A-97B3-E1E977F6166A@lclark.edu> <200702061623.42765.john.zelle@wartburg.edu> <138CD4CD-4D5D-46C5-9CD7-A3FA19559C8B@lclark.edu> <04179AD1-DE7D-4BBE-943F-8BE0FED21328@lclark.edu> <919EC21C-F3A0-4222-B2F2-50AF3753F5E6@lclark.edu> Message-ID: On 2/6/07, Peter Drake wrote: > > It's not that I'm going to do procedural first and objects later. The > vast majority of these students will never take another programming > class. There is also a significant level of math phobia in this > course, so anything I can do to make it less complicated is a win. > Indeed, they spent the first couple of weeks with LEGO robots... The OO paradigm is at first just a lingo, jargon, way of talking, at first, very oriented around the "dictionary" in Python, as in self.__dict__ and/or module.__dict__. I start with fuzzy animals (and/or not fuzzy, e.g. snakes) when working with younger students, reminding them how natural it is, already, to think in terms of blueprints or templates, then instantiated in the form of these or those "instances of" -- all very embedded in our native grammar, if ya know what I mean. Part of what made OO (ala Smalltalk) such a breakthrough in the first place. > I was under the impression that Python was trying to be > "multiparadigm", so you could program in a procedural, OO, or > functional style. This doesn't seem to bear out for any but the > simplest programs, but I'm hoping I can pretend it's procedural for CS0. It's true that you'll hear that, but just as often hearing "everything is an object in Python" which is even more true of Python than of Java say, cuz even the so-called "primitives" are also dissectable using dir(). One of my favorite "first day" trix is to go dir(1) and then talk about the resulting dump. Basically, a key to Python, plus many other OO languages (Java, Javascript, VB, VFP...) is "dot notation" (other languages might use :: or ->). In explaining how somelist.reverse() "reaches into a list object for its reverse method" I can't help but speak in terms of noun.verb() or thing.action(). dog.bark() or monkey.smile() just come naturally at that point, to where you'd want a Dog and/or Monkey class projected on the Big Screen, for students' collective edification. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070206/0500d36c/attachment.htm From drake at lclark.edu Wed Feb 7 05:01:43 2007 From: drake at lclark.edu (Peter Drake) Date: Tue, 6 Feb 2007 20:01:43 -0800 Subject: [Edu-sig] Procedural front end for Zelle's graphics.py Message-ID: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> Okay, I think I've got it. I will no doubt make changes as the semester wears on, but this should be enough to get me started. -------------- next part -------------- A non-text attachment was scrubbed... Name: graphics2.py Type: text/x-python-script Size: 2241 bytes Desc: not available Url : http://mail.python.org/pipermail/edu-sig/attachments/20070206/32f54bde/attachment.bin -------------- next part -------------- Is anyone else using Python procedurally in an intro course, or is what I'm doing here perverse? Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ From bblais at bryant.edu Wed Feb 7 12:03:58 2007 From: bblais at bryant.edu (Brian Blais) Date: Wed, 07 Feb 2007 06:03:58 -0500 Subject: [Edu-sig] Procedural front end for Zelle's graphics.py In-Reply-To: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> Message-ID: <45C9B21E.2030507@bryant.edu> Peter Drake wrote: > > Is anyone else using Python procedurally in an intro course, or is what > I'm doing here perverse? What you are doing is definitely not perverse, and I strongly disagree with Kirby on this one, *for the audience you are dealing with*. I've taught programming for a number of years, both OO and procedural, and I find that if someone has math phobia, *and* you only have a limited time (like a semester), then OO is way more powerful than you need to get into, and is thus unduly confusing for the students. For those who have had a little programming, OO can make some things very nice. Therefore, I do most of my python teaching procedurally, and leave the OO for the slightly more advanced students. Have a look at some of my projects on http://web.bryant.edu/~bblais/projects.html They include: pynqc: a python wrapper to the LEGO Mindstorms NQC language Vacuum World: a vacuum world simulator (a.la. Norwig's AI book), which is a nice graphical way to introduce programming in Python, simulating a vacuum cleaner let me know if you use these, or have any questions! thanks, Brian Blais -- ----------------- bblais at bryant.edu http://web.bryant.edu/~bblais From vceder at canterburyschool.org Wed Feb 7 15:32:43 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Wed, 07 Feb 2007 09:32:43 -0500 Subject: [Edu-sig] Procedural front end for Zelle's graphics.py In-Reply-To: <45C9B21E.2030507@bryant.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> Message-ID: <45C9E30B.5040306@canterburyschool.org> Brian Blais wrote: > Peter Drake wrote: >> Is anyone else using Python procedurally in an intro course, or is what >> I'm doing here perverse? ... > this one, *for the audience you are dealing with*. I've taught programming for a > number of years, both OO and procedural, and I find that if someone has math phobia, > *and* you only have a limited time (like a semester), then OO is way more powerful > than you need to get into, and is thus unduly confusing for the students. For those > who have had a little programming, OO can make some things very nice. > > Therefore, I do most of my python teaching procedurally, and leave the OO for the > slightly more advanced students. Peter, Brian... +1 (as we say... ;) ) Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From andre.roberge at gmail.com Wed Feb 7 16:30:25 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Wed, 7 Feb 2007 11:30:25 -0400 Subject: [Edu-sig] Procedural front end for Zelle's graphics.py In-Reply-To: <45C9E30B.5040306@canterburyschool.org> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> Message-ID: <7528bcdd0702070730x1179a537hc8f20e825da48c0@mail.gmail.com> On 2/7/07, Vern Ceder wrote: > Brian Blais wrote: > > Peter Drake wrote: > >> Is anyone else using Python procedurally in an intro course, or is what > >> I'm doing here perverse? > ... > > this one, *for the audience you are dealing with*. I've taught programming for a > > number of years, both OO and procedural, and I find that if someone has math phobia, > > *and* you only have a limited time (like a semester), then OO is way more powerful > > than you need to get into, and is thus unduly confusing for the students. For those > > who have had a little programming, OO can make some things very nice. > > > > Therefore, I do most of my python teaching procedurally, and leave the OO for the > > slightly more advanced students. > > Peter, Brian... > > +1 (as we say... ;) ) > +1 from me as well. Andr? > Vern > -- From john.zelle at wartburg.edu Wed Feb 7 17:16:42 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Wed, 7 Feb 2007 10:16:42 -0600 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <45C9E30B.5040306@canterburyschool.org> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> Message-ID: <200702071016.42765.john.zelle@wartburg.edu> On Wednesday 07 February 2007 8:32 am, Vern Ceder wrote: > Brian Blais wrote: > > Peter Drake wrote: > >> Is anyone else using Python procedurally in an intro course, or is what > >> I'm doing here perverse? > > ... > > > this one, *for the audience you are dealing with*. I've taught > > programming for a number of years, both OO and procedural, and I find > > that if someone has math phobia, *and* you only have a limited time (like > > a semester), then OO is way more powerful than you need to get into, and > > is thus unduly confusing for the students. For those who have had a > > little programming, OO can make some things very nice. I think it's important here to differentiate between doing OOP, that is, doing design with classes vs. just using objects. Unlike Kirby, I personally see nothing wrong with going the procedural route with these students, but I don't think that using some objects in this context is particularly confusing to students. I can only make sense of the statement "OO is way more powerful than you need to get into" in the context of teaching OO design (encapsulation, polymorphism, inheritance). Using pre-existing object types requires no more conceptual machinery than function calls, and is really just more procedural programming. Until I point out the distinction (which I do, very early on), the vast majority of students are not the least bit bothered by the "inconsistency" of mixing method calls using dot notation with regular function calls. In my experience, beginning students tend to use whatever operations they're shown in the way that they are shown. To take a concrete example, they see that they can find the length of a list by doing len(someList) and that they can reverse a list by doing someList.reverse(). When they later want to find the length they use len(mylist), and when they want to reverse it, they use mylist.reverse(). It doesn't even occur to them that it "should" be reverse(mylist), because that's not how they were shown the operation. It's only the advanced students who will generalize and wonder about the difference. And when they do, then you can explain that it's really just syntactic sugaring: len(someList) is another way of writing someList.__len__(). As Peter pointed out earlier, you can do pure procedural programming in Python, but restricting yourself to methodless programming quickly limits the interesting (and easy) projects that can be tackled with the rich existing libraries, because the programmers of those libraries have taken advantage of the true power of OO alluded to earlier. The motivation of tackling projects that, say, mine data from the web or manipulate images is more than sufficient payback for whatever (in my experience, very small) challenge is introduced by using (not designing) objects. I'm wondering what others on the list think about this subject. As I look to revising my textbook, one of the things I'm carefully considering is the fact that use of the string library is, if not deprecated, greatly discouraged. In the first edition, I move from functions with numbers to functions with strings as a way of building on students previous experience with "computing" in the context of mathematics. Objects are introduced slightly later through computer graphics examples. If I switch to using string methods, then the object notation will be introduced even sooner. In your opinions, is that a good thing, a bad thing, or doesn't it matter? --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Wed Feb 7 17:19:30 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 08:19:30 -0800 Subject: [Edu-sig] Procedural front end for Zelle's graphics.py In-Reply-To: <45C9B21E.2030507@bryant.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> Message-ID: I think postponing exposure to OO is perverse only in the sense that I find it symptomatic of a holdover K-12 curriculum that specializes in producing math phobic students. My plan to address this situation involves drawing from CS to create a math teaching hybrid that uses Python (or competing language) to teach math concepts, starting around 8th grade if not before. We develop fluency in a computer language *in order to* explore such objects as: rational numbers, integers modulo N, vectors, polynomials, polyhedra... I've prototyped my class in Portland Public Schools (at Winterhaven in particular, for several weeks with 8th graders), but currently teach it as a non-credit elective for high schoolers enrolling in Saturday Academy (saturdayacademy.org), a nonprofit sponsored by Silicon Forest execs interested in employing more local talent in future. My hope for these students is by the time they get to college they'd already be well beyond the CS0 course herein described. None of this is to deny an existing population of casualties of the current curriculum, obsolete infrastructure we're also replacing in the Republic of South Africa with the Mark Shuttleworth Pipeline (also features Python pre age 18 -- again, only with *some* students). Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/ffcb3e26/attachment.html From drake at lclark.edu Wed Feb 7 17:54:02 2007 From: drake at lclark.edu (Peter Drake) Date: Wed, 7 Feb 2007 08:54:02 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <200702071016.42765.john.zelle@wartburg.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> Message-ID: <70F934C7-2129-4A48-BB7A-F17FEE3F0959@lclark.edu> Your philosophy may differ, but I'd like to see control structures explained sooner. You currently don't introduce if for 200 pages. I find that it's hard to come up with interesting assignments without if. (My idea of "interesting assignments" usually leans toward simple games, as in my book "Data Structures and Algorithms in Java".) I'd rather give the students a few simple pieces that they can (with enough practice) fully understand than give them a large library of special-purpose commands. Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ On Feb 7, 2007, at 8:16 AM, John Zelle wrote: > On Wednesday 07 February 2007 8:32 am, Vern Ceder wrote: >> Brian Blais wrote: >>> Peter Drake wrote: >>>> Is anyone else using Python procedurally in an intro course, or >>>> is what >>>> I'm doing here perverse? >> >> ... >> >>> this one, *for the audience you are dealing with*. I've taught >>> programming for a number of years, both OO and procedural, and I >>> find >>> that if someone has math phobia, *and* you only have a limited >>> time (like >>> a semester), then OO is way more powerful than you need to get >>> into, and >>> is thus unduly confusing for the students. For those who have had a >>> little programming, OO can make some things very nice. > > I think it's important here to differentiate between doing OOP, > that is, doing > design with classes vs. just using objects. Unlike Kirby, I > personally see > nothing wrong with going the procedural route with these students, > but I > don't think that using some objects in this context is particularly > confusing > to students. I can only make sense of the statement "OO is way more > powerful > than you need to get into" in the context of teaching OO design > (encapsulation, polymorphism, inheritance). Using pre-existing > object types > requires no more conceptual machinery than function calls, and is > really just > more procedural programming. > > Until I point out the distinction (which I do, very early on), the > vast > majority of students are not the least bit bothered by the > "inconsistency" > of mixing method calls using dot notation with regular function > calls. In my > experience, beginning students tend to use whatever operations > they're shown > in the way that they are shown. To take a concrete example, they > see that > they can find the length of a list by doing len(someList) and that > they can > reverse a list by doing someList.reverse(). When they later want to > find the > length they use len(mylist), and when they want to reverse it, they > use > mylist.reverse(). It doesn't even occur to them that it "should" be > reverse(mylist), because that's not how they were shown the > operation. It's > only the advanced students who will generalize and wonder about the > difference. And when they do, then you can explain that it's really > just > syntactic sugaring: len(someList) is another way of writing > someList.__len__(). > > As Peter pointed out earlier, you can do pure procedural > programming in > Python, but restricting yourself to methodless programming quickly > limits the > interesting (and easy) projects that can be tackled with the rich > existing > libraries, because the programmers of those libraries have taken > advantage of > the true power of OO alluded to earlier. The motivation of tackling > projects > that, say, mine data from the web or manipulate images is more than > sufficient payback for whatever (in my experience, very small) > challenge is > introduced by using (not designing) objects. > > I'm wondering what others on the list think about this subject. As > I look to > revising my textbook, one of the things I'm carefully considering > is the fact > that use of the string library is, if not deprecated, greatly > discouraged. In > the first edition, I move from functions with numbers to functions > with > strings as a way of building on students previous experience with > "computing" > in the context of mathematics. Objects are introduced slightly > later through > computer graphics examples. If I switch to using string methods, > then the > object notation will be introduced even sooner. In your opinions, > is that a > good thing, a bad thing, or doesn't it matter? > > --John > > -- > John M. Zelle, Ph.D. Wartburg College > Professor of Computer Science Waverly, IA > john.zelle at wartburg.edu (319) 352-8360 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From kirby.urner at gmail.com Wed Feb 7 18:02:03 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 09:02:03 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <200702071016.42765.john.zelle@wartburg.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> Message-ID: > > > I'm wondering what others on the list think about this subject. As I look > to > revising my textbook, one of the things I'm carefully considering is the > fact > that use of the string library is, if not deprecated, greatly discouraged. > In > the first edition, I move from functions with numbers to functions with > strings as a way of building on students previous experience with > "computing" > in the context of mathematics. Objects are introduced slightly later > through > computer graphics examples. If I switch to using string methods, then the > object notation will be introduced even sooner. In your opinions, is that > a > good thing, a bad thing, or doesn't it matter? > > --John I agree that even if avoiding defining classes (at first), understanding dot notation is critical to Python and many other languages using that syntax. There's a sense of container and contained, in "drilling down" like in a filesystem, finding resourses *within* an object. In the old days, rational numbers (to take an example) were considered a type of number and members of a set (the set of rational numbers). But what was the relationship of operations, such as addition and multiplication vis-a-vis this set? In the OO paradigm, there's this paradigm class (or type) called the Rational Number class, which contains within it all the "guts" for doing operations, so whereas *instances* Rat(p,q), p,q integers, are akin to our "members of the set", the operational know-how is actually codified in a template or blueprint shared by these instances. But in the computer world, we're not just interested in "types of number" per se, but in "types" more generally, which includes strings, other collections. We model stuff in the real world, such as airplanes, animals, DNA, always using these same concepts of (a) blueprint with guts (methods) and (b) distinct instances sharing these guts. I like starting with Animal types at first because animals already have lots of guts. :-D In my idealized CS0, understanding this paradigm, of objects (things) as instances, of classes as encapsulating and structuring their "guts" (verbs, abilities, powers), is the important thing to get across. Intro courses are characterized by their ability to rise above the petty day to day, to give overview, to survey. Lots of history, lots of (true) war stories. Best if your teacher has plenty of real world experience. Kirby Relevant essays: http://www.4dsolutions.net/ocn/oopalgebra.html http://www.4dsolutions.net/ocn/trends2000.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/029dd076/attachment.htm From pchase at sulross.edu Wed Feb 7 17:45:49 2007 From: pchase at sulross.edu (Peter Chase) Date: Wed, 07 Feb 2007 10:45:49 -0600 Subject: [Edu-sig] [BULK] Re: Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <200702071016.42765.john.zelle@wartburg.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> Message-ID: <45CA023D.60901@sulross.edu> John Zelle wrote: > On Wednesday 07 February 2007 8:32 am, Vern Ceder wrote: > >> Brian Blais wrote: >> >>> Peter Drake wrote: >>> >>>> Is anyone else using Python procedurally in an intro course, or is what >>>> I'm doing here perverse? >>>> >> ... >> >> >>> this one, *for the audience you are dealing with*. I've taught >>> programming for a number of years, both OO and procedural, and I find >>> that if someone has math phobia, *and* you only have a limited time (like >>> a semester), then OO is way more powerful than you need to get into, and >>> is thus unduly confusing for the students. For those who have had a >>> little programming, OO can make some things very nice. >>> > > I think it's important here to differentiate between doing OOP, that is, doing > design with classes vs. just using objects. Unlike Kirby, I personally see > nothing wrong with going the procedural route with these students, but I > don't think that using some objects in this context is particularly confusing > to students. I can only make sense of the statement "OO is way more powerful > than you need to get into" in the context of teaching OO design > (encapsulation, polymorphism, inheritance). Using pre-existing object types > requires no more conceptual machinery than function calls, and is really just > more procedural programming. > > Until I point out the distinction (which I do, very early on), the vast > majority of students are not the least bit bothered by the "inconsistency" > of mixing method calls using dot notation with regular function calls. In my > experience, beginning students tend to use whatever operations they're shown > in the way that they are shown. To take a concrete example, they see that > they can find the length of a list by doing len(someList) and that they can > reverse a list by doing someList.reverse(). When they later want to find the > length they use len(mylist), and when they want to reverse it, they use > mylist.reverse(). It doesn't even occur to them that it "should" be > reverse(mylist), because that's not how they were shown the operation. It's > only the advanced students who will generalize and wonder about the > difference. And when they do, then you can explain that it's really just > syntactic sugaring: len(someList) is another way of writing > someList.__len__(). > > As Peter pointed out earlier, you can do pure procedural programming in > Python, but restricting yourself to methodless programming quickly limits the > interesting (and easy) projects that can be tackled with the rich existing > libraries, because the programmers of those libraries have taken advantage of > the true power of OO alluded to earlier. The motivation of tackling projects > that, say, mine data from the web or manipulate images is more than > sufficient payback for whatever (in my experience, very small) challenge is > introduced by using (not designing) objects. > > I'm wondering what others on the list think about this subject. As I look to > revising my textbook, one of the things I'm carefully considering is the fact > that use of the string library is, if not deprecated, greatly discouraged. In > the first edition, I move from functions with numbers to functions with > strings as a way of building on students previous experience with "computing" > in the context of mathematics. Objects are introduced slightly later through > computer graphics examples. If I switch to using string methods, then the > object notation will be introduced even sooner. In your opinions, is that a > good thing, a bad thing, or doesn't it matter? > > --John > > Good thing. I use Python as a way of introducing concepts without a lot of Java-style overhead. Presumably once they get the ideas (including OOP) we can tackle the monstrous edifices of the official languages. -- Peter From john.zelle at wartburg.edu Wed Feb 7 18:34:48 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Wed, 7 Feb 2007 11:34:48 -0600 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <70F934C7-2129-4A48-BB7A-F17FEE3F0959@lclark.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <200702071016.42765.john.zelle@wartburg.edu> <70F934C7-2129-4A48-BB7A-F17FEE3F0959@lclark.edu> Message-ID: <200702071134.48080.john.zelle@wartburg.edu> On Wednesday 07 February 2007 10:54 am, Peter Drake wrote: > Your philosophy may differ, but I'd like to see control structures > explained sooner. You currently don't introduce if for 200 pages. I > find that it's hard to come up with interesting assignments without > if. (My idea of "interesting assignments" usually leans toward simple > games, as in my book "Data Structures and Algorithms in Java".) Actually, I don't think our philosophies differ all that much. Just to set the record straight, the first control structure in my book is explained on page 15, and the idea of control structures in general is explained in detail on page 39. You're right in that decision structures aren't introduced until around page 200. Everyone has their own pet ordering of the basic topics, and I do have ifs later than lots of folks like to teach them, but the chapters are designed so they can be mixed and matched. Should an instructor want to do ifs earlier (and lots do), that chapter can be used right after Chapt. 2. Although it's hard for me to imagine what "interesting" problems you can solve without understanding the basic data types of numbers and strings. My own approach is to very rapidly get to the graphics in Chapter 5 (I skip quite a bit of chapter 4 on first pass), because students really groove on that. It seems to work, as we put about 100 students per year through this class (it can be used to meet a gen ed math requirement) with a success rate of over 90%. > I'd rather give the students a few simple pieces that they can (with > enough practice) fully understand than give them a large library of > special-purpose commands. My goal early on is to teach algorithmic thinking. That is breaking down a problem into a sequence of discrete steps. You need some vocabulary of "steps" in order to do that. Different vocabularies allow you to solve problems in different domains, but the algormithmic thinking process is every bit as generic as it is later with decisions added. But by all means, do decisions early if the problems you want to tackle require them. The types of problems I use tend to require I/O and loops. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From bblais at bryant.edu Wed Feb 7 19:12:55 2007 From: bblais at bryant.edu (Brian Blais) Date: Wed, 07 Feb 2007 13:12:55 -0500 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <200702071016.42765.john.zelle@wartburg.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> Message-ID: <45CA16A7.5030002@bryant.edu> John Zelle wrote: > I think it's important here to differentiate between doing OOP, that is, doing > design with classes vs. just using objects. Unlike Kirby, I personally see > nothing wrong with going the procedural route with these students, but I > don't think that using some objects in this context is particularly confusing > to students. I can only make sense of the statement "OO is way more powerful > than you need to get into" in the context of teaching OO design > (encapsulation, polymorphism, inheritance). Using pre-existing object types > requires no more conceptual machinery than function calls, and is really just > more procedural programming. I agree entirely. In fact, I use the math module early on (for simple trig) or the random module, each with the dot notation. I don't think the calling syntax is the problem, and as you point out is just like function calls. I don't consider that OOP, even though in the background it is implemented that way. To carry it that far, you'd have to admit that: a=1 is OOP, which I think is a bit far. I consider OOP when you start looking at class definitions and design with classes as you say above. bb -- ----------------- bblais at bryant.edu http://web.bryant.edu/~bblais From bblais at bryant.edu Wed Feb 7 19:59:37 2007 From: bblais at bryant.edu (Brian Blais) Date: Wed, 07 Feb 2007 13:59:37 -0500 Subject: [Edu-sig] meaning of +1 Message-ID: <45CA2199.1060908@bryant.edu> Hello, I am not asking an existential question about the meaning of the integer set, but rather what it means when someone writes in an email on this list, something like: +1 I've never seen this on any other list (other than python lists). Is this just a short hand for "good comment", or is there a deeper meaning or purpose? thanks, bb -- ----------------- bblais at bryant.edu http://web.bryant.edu/~bblais From kirby.urner at gmail.com Wed Feb 7 20:04:09 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 11:04:09 -0800 Subject: [Edu-sig] meaning of +1 In-Reply-To: <45CA2199.1060908@bryant.edu> References: <45CA2199.1060908@bryant.edu> Message-ID: On 2/7/07, Brian Blais wrote: > > Hello, > > I am not asking an existential question about the meaning of the integer > set, but > rather what it means when someone writes in an email on this list, > something like: > > +1 Often seen around the Python community. May be construed as "another vote for..." whereas -1 has the opposite meaning. As you may already know, there's a formal process for proposing enhancements to the Python language and/or surrounding infrastructure. A lot of the lists where you see +1 syntax occuring often will have these so-called PEPs under discussion. edu-sig doesn't have much history around PEPs as most of our discussions are not focussed on changing the language. Python itself is more a fait accompli around here, with a focus on how best to teach it. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/af79e51e/attachment.htm From delza at livingcode.org Wed Feb 7 20:04:54 2007 From: delza at livingcode.org (Dethe Elza) Date: Wed, 7 Feb 2007 11:04:54 -0800 Subject: [Edu-sig] meaning of +1 In-Reply-To: <45CA2199.1060908@bryant.edu> References: <45CA2199.1060908@bryant.edu> Message-ID: On 7-Feb-07, at 10:59 AM, Brian Blais wrote: > Hello, > > I am not asking an existential question about the meaning of the > integer set, but > rather what it means when someone writes in an email on this list, > something like: > > +1 > > I've never seen this on any other list (other than python lists). > Is this just a > short hand for "good comment", or is there a deeper meaning or > purpose? It's shorthand for "I approve and vote in favor of this direction, proposal, critique, or whatever. It is pretty common on lists which discuss the development of open- source software, in order to coordinate loose federations of people and test general consensus. Variations include -1 (don't approve, vote no), +0 (vaguely approve, but don't really care), -0 (vaguely disapprove, but not willing to fight over it), +1000 (I really, really care deeply about this and want it), -1000 (this is a really bad idea that I think will harm the community), etc. HTH --Dethe > > > thanks, > > > bb > > > -- > ----------------- > > bblais at bryant.edu > http://web.bryant.edu/~bblais > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig DETHE ELZA Senior Software Developer dethe.elza at uniserveteam.com From dreed at capital.edu Wed Feb 7 20:45:22 2007 From: dreed at capital.edu (David Reed) Date: Wed, 7 Feb 2007 14:45:22 -0500 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <200702071016.42765.john.zelle@wartburg.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> Message-ID: <4bdc75fc5e806611a69b68af61c40590@capital.edu> On Feb 7, 2007, at 11:16 AM, John Zelle wrote: > On Wednesday 07 February 2007 8:32 am, Vern Ceder wrote: >> Brian Blais wrote: >>> Peter Drake wrote: >>>> Is anyone else using Python procedurally in an intro course, or is >>>> what >>>> I'm doing here perverse? >> >> ... >> >>> this one, *for the audience you are dealing with*. I've taught >>> programming for a number of years, both OO and procedural, and I find >>> that if someone has math phobia, *and* you only have a limited time >>> (like >>> a semester), then OO is way more powerful than you need to get into, >>> and >>> is thus unduly confusing for the students. For those who have had a >>> little programming, OO can make some things very nice. > > I think it's important here to differentiate between doing OOP, that > is, doing > design with classes vs. just using objects. Unlike Kirby, I personally > see > nothing wrong with going the procedural route with these students, but > I > don't think that using some objects in this context is particularly > confusing > to students. I can only make sense of the statement "OO is way more > powerful > than you need to get into" in the context of teaching OO design > (encapsulation, polymorphism, inheritance). Using pre-existing object > types > requires no more conceptual machinery than function calls, and is > really just > more procedural programming. > > Until I point out the distinction (which I do, very early on), the vast > majority of students are not the least bit bothered by the > "inconsistency" > of mixing method calls using dot notation with regular function calls. > In my > experience, beginning students tend to use whatever operations they're > shown > in the way that they are shown. To take a concrete example, they see > that > they can find the length of a list by doing len(someList) and that > they can > reverse a list by doing someList.reverse(). When they later want to > find the > length they use len(mylist), and when they want to reverse it, they use > mylist.reverse(). It doesn't even occur to them that it "should" be > reverse(mylist), because that's not how they were shown the operation. > It's > only the advanced students who will generalize and wonder about the > difference. And when they do, then you can explain that it's really > just > syntactic sugaring: len(someList) is another way of writing > someList.__len__(). > > As Peter pointed out earlier, you can do pure procedural programming in > Python, but restricting yourself to methodless programming quickly > limits the > interesting (and easy) projects that can be tackled with the rich > existing > libraries, because the programmers of those libraries have taken > advantage of > the true power of OO alluded to earlier. The motivation of tackling > projects > that, say, mine data from the web or manipulate images is more than > sufficient payback for whatever (in my experience, very small) > challenge is > introduced by using (not designing) objects. For a CS0 course that is only spending a portion of the semester on Python, it probably makes little difference whether you use a procedural or object oriented approach, but I do agree with John that students learn what you show them first. I think the students can learn to use objects just as easily as they can learn to use procedures. My experience of students writing their own classes also matches John's - the students find that much more difficult. > > I'm wondering what others on the list think about this subject. As I > look to > revising my textbook, one of the things I'm carefully considering is > the fact > that use of the string library is, if not deprecated, greatly > discouraged. In > the first edition, I move from functions with numbers to functions with > strings as a way of building on students previous experience with > "computing" > in the context of mathematics. Objects are introduced slightly later > through > computer graphics examples. If I switch to using string methods, then > the > object notation will be introduced even sooner. In your opinions, is > that a > good thing, a bad thing, or doesn't it matter? > If I were writing it, I would use strings as objects from the beginning and never introduce the string module - might as well get them doing it as they will eventually from the start. Other modules (such as the math module) show them how to use functions. With regard to Peter's comments about decision statements - I cover sections 7.1-7.3 (if/eif/else) after chapter 4. As John points out, with his book you can easily cover them earlier and my students have had no problems with that (I've been using the book since the year before it was officially published). Dave From kirby.urner at gmail.com Wed Feb 7 22:07:02 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 13:07:02 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <4bdc75fc5e806611a69b68af61c40590@capital.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> Message-ID: On 2/7/07, David Reed wrote: > > > > For a CS0 course that is only spending a portion of the semester on > Python, it probably makes little difference whether you use a > procedural or object oriented approach, but I do agree with John that > students learn what you show them first. I think the students can learn > to use objects just as easily as they can learn to use procedures. My > experience of students writing their own classes also matches John's - > the students find that much more difficult. Note that writing one's own class needn't be the entry point. I'll talk about Python's "__rib__ syntax" as internal scaffolding, then introduce... class Dog: def __init__(self, name): self.name = name def __repr__(self): return 'A dog named %s' % self.name ... saying "a dog needs a way to get born, a constructor method, and a way to represent itself to the world, called a 'reper' in Python". Then we'll import Dog from animals.py and instantiate a couple. Then comes the rap about how the *blueprint* or *template* or *class definition* is what's common to all the dog objects, but each gets a special location in memory, to store more "personalized" data, such as a name. In Python, that's a personalized dictionary. >>> od1 = Dog('Rover') >>> od1.__dict__ {'name': 'Rover'} Even the number 1, like a dog, is an object or instance of type Integer. Integer is like the Dog class. A given integer is like a specific dog. >>> id(od1) 11726120 >>> id(Dog) 11794832 >>> type(1) >>> dir(1) ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__'] My my, look at all those __ribs__. But then, snakes have *a lot* of ribs, don't they? The main point being: as with any language, it's easier to develop a reading fluency and a recog vocabulary (of keywords, of design patterns), than it is to develop a writing or speaking fluency and a recall vocabulary, which is what you'll need if they sit you down in front of a blank screen and say "write Python code please." I don't put beginners under that kind of pressure. It's all about developing a *reading* kind of fluency, with all the grammar already checked. Writing comes a bit later, probably involves adding a bark method to our Dog. Here too: no blank screen at first. Modify existing code. Just tweak existing code before you dive in to coding up from scratch. I'm sure many here use similar methods. It's basic to language learning. At one point I could even read Arabic a little, but never could I write it at all well. We might have a Kalb class? (Dog?). >>> dir(Kalb) ['__doc__', '__init__', '__module__', '__repr__'] Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/4716c172/attachment.html From kirby.urner at gmail.com Wed Feb 7 22:12:59 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 13:12:59 -0800 Subject: [Edu-sig] [BULK] Re: Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <45CA023D.60901@sulross.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <45CA023D.60901@sulross.edu> Message-ID: > > > Good thing. I use Python as a way of introducing concepts without a lot > of Java-style overhead. Presumably once they get the ideas (including > OOP) we can tackle the monstrous edifices of the official languages. > -- Peter I've heard of agile vs. system languages i.e. Python, Ruby vs. Java, C#. But whence this word "official"? That's a type I'm not familiar with. Python is the official language of Python Nation, no? -- just as Perl is, of the Republic of Perl. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/2bde4f82/attachment.htm From dreed at capital.edu Wed Feb 7 22:58:48 2007 From: dreed at capital.edu (David Reed) Date: Wed, 7 Feb 2007 16:58:48 -0500 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> Message-ID: <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> On Feb 7, 2007, at 4:07 PM, kirby urner wrote: > On 2/7/07, David Reed wrote: > > For a CS0 course that is only spending a portion of the semester on > Python, it probably makes little difference whether you use a > procedural or object oriented approach, but I do agree with John that > students learn what you show them first. I think the students can > learn > to use objects just as easily as they can learn to use procedures. My > experience of students writing their own classes also matches > John's - > the students find that much more difficult. > > > > Note that writing one's own class needn't be the entry point. I didn't say it was - I just said students find it easier to use an object than write their own. > > The main point being: as with any language, it's easier to develop > a reading fluency > and a recog vocabulary (of keywords, of design patterns), than it > is to develop a > writing or speaking fluency and a recall vocabulary, which is what > you'll need if they > sit you down in front of a blank screen and say "write Python code > please." > Right - we're saying the same thing - it's easier to read code than write to write code. From all your posts I've read over the years I think you need to remember that you seem to be teaching highly motivated high school students who are good at math and thus generally have good problem solving skills. Most of us teaching introductory CS courses and a significant subset of our students do not have very good problems solving skills so our goal in the first course (and I assume this is even more true of CS0 courses, but we don't have a CS0 course) is mainly to develop and improve problem solving skills. The reason I like Python for CS1 (and would for CS0 if I taught such a course) is that the language syntax is simpler and thus lets the students focus on problem solving skills. For a CS0 course I wouldn't care what language paradigm they learn/use - I would just want the students to get an appreciation for algorithms and problem solving. As you mention, your goal for math applications requires operator overloading, but just developing problem solving skills does not require object oriented techniques. For a CS1 course I want to develop problem solving skills but also slowly move them towards writing code using the style/paradigm they will be using in later courses. Thanks to a 7th grade math teacher who introduced us to Basic on a TRS-80, I knew more about programming (note that I did not say I knew more about computer science) by the time I got to 9th grade than most of our students do 2 years later. But again, I was highly motivated and taught myself Z-80 assembly language so I could write programs that run faster than Basic on that machine. I suspect that I was the type of student you see in your teaching, but that is not what most of us see in our CS0/CS1 courses. All a number of us are saying is that one size does not fit all. I suspect what you do works well for the students you teach, but it may not work well for other groups of students. That's what keeps teaching fresh for me - I adjust what I'm doing until I see that the students are getting it. That's why I like teaching at a small school with relatively small classes (20-30 students typically). I can get immediate feedback from a good percentage of the students and determine if I need to try a different technique for explaining the topic. That's next to impossible if you have a classroom of more than 50 students. Dave From kirby.urner at gmail.com Thu Feb 8 00:10:08 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 15:10:08 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> Message-ID: On 2/7/07, David Reed wrote: <> All a number of us are saying is that one size does not fit all. I > suspect what you do works well for the students you teach, but it may > not work well for other groups of students. That's what keeps > teaching fresh for me - I adjust what I'm doing until I see that the > students are getting it. That's why I like teaching at a small school > with relatively small classes (20-30 students typically). I can get > immediate feedback from a good percentage of the students and > determine if I need to try a different technique for explaining the > topic. That's next to impossible if you have a classroom of more than > 50 students. > > Dave My 8th grade PPS class @ Winterhaven involved no pre-screening as to math skills, but neither was it as math-intensive as my Saturday Academy classes, which require no pre-reqs other than algebra, but *do* assume motivated students willing to give up Saturdays to do something geeky. In both groups, some are precocious, others more average in terms of skill. My goal as a teacher is to impart enough skills to make some kind of self steering investigation possible, i.e. they get lectures, but also a lot of "try stuff" time, with me walking around and helping. We use such as stickworks.py, and/or the native VPython API, in addition to core Python. As many have noted here, students love graphics, and when it comes to bang for the buck, I find VPython vastly more motivational than a Tk canvas. I agree with the late Arthur Siegel that VPython is critical to Python's competitive advantage. Ruby is very OpenGL aware, right out the box, and will likely supersede Python in many educational arenas if VPython, or packages of similar capability, are allowed to lie fallow. I understand why he wanted VPython added to the Standard Library. On the other hand, the Standard Library is something of a graveyard/junkyward as well. Anyway, the feedback I'm getting is that the pipeline whereby new geeks get born and nurtured through to a professional real world career (doesn't mean in computer science necessarily) is severely broken right now except in a few relatively utopian settings. The CS faculties tend to blame HS experience, as so many students are already turned off and/or ready only for remedial numeracy courses by the time they enter college. CS0 courses, rather than serving an exciting recruiting function, may serve to further dull the material, turning off even more students (especially the most curious). One prof at a recent Willamette U. panel on this: "whatever you're doing in high school, please stop it" (except he didn't say please). What I call (he's too modest to call it that) "the Mark Shuttleworth Pipeline" (which you've been reading about over the last year, if you've been reading my posts) assumes only a normal average healthy curiosity, not any kind of special genius. A lot of students in South Africa are in open revolt against a "business as usual" education, when it comes to developing their analytical (problem solving) skills. They know, from being close to the bottom of TIMMS, that their only hope of participating as equals in the emerging global high tech economy is in "leap frogging," more than simply imitating. A lot of other countries feel the same way. My investments in screencasting and mathcasting companies (including my own 4D Studios) are in alignment with the peer teaching and home teaching models. CS0 *could* be a helpful puzzle piece, but in many cases it's merely a backwater, something to bypass because too dumbed down, just like the USA's K-12 more generally. I probably sound like a militant compared to most college professors, but I assure you many of my private sector collegues are far more polemical than I, when it comes to pointing out shortcomings in the current curriculum. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/d80c0279/attachment-0001.htm From pchase at sulross.edu Thu Feb 8 00:48:37 2007 From: pchase at sulross.edu (Peter Chase) Date: Wed, 07 Feb 2007 17:48:37 -0600 Subject: [Edu-sig] [BULK] Re: [BULK] Re: Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <45CA023D.60901@sulross.edu> Message-ID: <45CA6555.5080505@sulross.edu> kirby urner wrote: > > > Good thing. I use Python as a way of introducing concepts without > a lot > of Java-style overhead. Presumably once they get the ideas > (including > OOP) we can tackle the monstrous edifices of the official languages. > -- Peter > > > I've heard of agile vs. system languages i.e. Python, Ruby vs. Java, C#. > But whence this word "official"? That's a type I'm not familiar with. > > Python is the official language of Python Nation, no? -- just as Perl is, > of the Republic of Perl. > > Kirby By "official" I mean used in the AP tests. One year everyone is talking C++, then it fades and everyone is talking Java. I suppose I could say the hell with them all and become a Lisp puritan. Peter From dreed at capital.edu Thu Feb 8 01:13:51 2007 From: dreed at capital.edu (David Reed) Date: Wed, 7 Feb 2007 19:13:51 -0500 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> Message-ID: On Feb 7, 2007, at 6:10 PM, kirby urner wrote: > > I probably sound like a militant compared to most college professors, > but I assure you many of my private sector collegues are far more > polemical than I, when it comes to pointing out shortcomings in the > current curriculum. > This is my personal comment and I don't claim to speak for others, but the only thing I find militant is that sometimes it appears to me you ignore what others are saying and talk about your stuff even when it's not particularly related. The question a few others and I were responding to was whether or not it's okay to just do procedural coding and not OO coding in a CS0 course and it felt like you just wanted to repeat the way you introduce your math concepts that we have seen so many times on this list. You did address the issue here: In my idealized CS0, understanding this paradigm, of objects (things) as instances, of classes as encapsulating and structuring their "guts" (verbs, abilities, powers), is the important thing to get across. Intro courses are characterized by their ability to rise above the petty day to day, to give overview, to survey. Lots of history, lots of (true) war stories. Best if your teacher has plenty of real world experience. I (and it appears a few others) respectfully disagree but I'm afraid these and other people's responses get lost when you focus on telling us how you teach math using Python when that was not the original topic/question. I do not think the goal of a CS0 course should be to make the students understand the guts of the OO paradigm. I want to develop problem solving skills - those skills should serve the student well no matter what their major is. If a student takes my CS1 class and never takes another CS course, I at least hope I improved their problem solving skills. I don't expect them to remember the "guts" and details of OO. I do of course expect our majors to understand OO and we will continue to develop those skills in upper level courses. Who knows, 20 years from now there will be probably be some other paradigm than OO that is more commonly used, but I doubt problem solving will ever go out of style. Don't get me wrong - I applaud you for what you do to try to make math more interesting to young kids. I admire your passion and think it's a great use of Python. I just don't think your way is the only way to use Python to teach (and would love to see more discussion of other uses), especially when the course doesn't need to have a math slant. Python's string methods provide lots of possibilities for developing problem solving skills w/o focusing on math concepts. I think you could do a lot in a CS0 course w/o do much math beyond basic mathematics (you at least need to know how to count to understand loops). :-) That might be very appropriate for a CS0 course containing people who are "math phobic". Kirby, you or anyone else are of course free to respond, but this is most likely my last post on the subject as I think we're mainly rehashing things that have already been said on this list. Dave From kirby.urner at gmail.com Thu Feb 8 03:17:38 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 18:17:38 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> Message-ID: On 2/7/07, David Reed wrote: > > > This is my personal comment and I don't claim to speak for others, > but the only thing I find militant is that sometimes it appears to me > you ignore what others are saying and talk about your stuff even when > it's not particularly related. The question a few others and I were > responding to was whether or not it's okay to just do procedural > coding and not OO coding in a CS0 course and it felt like you just > wanted to repeat the way you introduce your math concepts that we > have seen so many times on this list. Yes, I suppose that's a fair criticism. On the other hand, I'm never sure when a new reader might be lurking. To speak more directly to the question, my answer is: no, teaching CS0 while bleeping over OOP is to neglect an important turn in computer science. Like a literature survey course, CS0 should be aimed at providing historical perspective and overview, as well as some enouraging sense of increasing fluency with one or more specific language or languages. I have aimed to show there are easy ways to introduce OOP early, using Python syntax as a guide, that don't require great feats of mental effort on the part of students. My Dog and Monkey show is quite accessible to average 8th graders in public school as I've proved in the field. There's nothing especially "mathematical" about it, even when a dog object eats \ a monkey object, per screencast. Using Python to slog through procedural programming for a semester rather than using it as scaffolding to develop some insights into OOP, including among beginners, is a waste of a good language and a waste of students' time. I'd be ashamed to be associated with any such curriculum. I hope this practice proves short lived. We're in a dark age right now. Lots of crappola. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/15673527/attachment.htm From andre.roberge at gmail.com Thu Feb 8 03:46:17 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Wed, 7 Feb 2007 22:46:17 -0400 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9B21E.2030507@bryant.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> Message-ID: <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> On 2/7/07, kirby urner wrote: > On 2/7/07, David Reed wrote: > > Using Python to slog through procedural programming for a semester > rather than using it as scaffolding to develop some insights into OOP, > including among beginners, is a waste of a good language and a waste > of students' time. I'd be ashamed to be associated with any such > curriculum. I hope this practice proves short lived. We're in a dark age > right now. Lots of crappola. > I disagree. Calculus is an essential tool for Physics. Yet, teaching an introductory calculus-based Physics course for non physicists/engineers would be totally wrong. Instead, people teach algebra-based introductory physics courses - I have taught both. Programming is a tool used in studying computer science - just like math is a tool useful in the study of Physics. OOP is a modern tool used in studying computer science; just like vector-based calculus is a modern tool used in studying Physics. Choosing to use a simple tool (procedural programming, supplemented by relevant usage of "dot notation" with little if any mention of object/classes) so that more applications of computer science, including graphics, can be covered is most likely more appropriate. You wrote: "we're in a dark age right now". Let me agree and take this statement to the extreme. Forget about OOP. We need to start teaching kids about qubits, and the bra and ket notation. This is where the future lies, with quantum computing and quantum cryptography. Furthermore, the notation is *a lot* simpler than the "rib" syntax which you are so fond of, as long as you only deal with finite dimensional spaces. Yet, I would not argue that this would be appropriate for a CS0 course. Students taking a CS0 course have to be able to write simple programs, in various areas (including graphics). There's nothing wrong in teaching procedurally based programming at that level. What is important is to make them *think* ... not to dazzle them with the latest tool. Andr? > Kirby > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > From kirby.urner at gmail.com Thu Feb 8 04:57:44 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 19:57:44 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> Message-ID: On 2/7/07, Andre Roberge wrote: > Programming is a tool used in studying computer science - just like > math is a tool useful in the study of Physics. OOP is a modern tool > used in studying computer science; just like vector-based calculus is > a modern tool used in studying Physics. OOP is a tool for analyzing a problem in terms of objects and their relationships. It's not just a way of writing code, it's a style of thinking. It's also accessible to newbies. To bleep over it, in a course about using computers to solve problems, seems wasteful of a golden opportunity, since Python makes it easy ("working pseudocode" "fits your brain" and all that). > Choosing to use a simple tool (procedural programming, supplemented by > relevant usage of "dot notation" with little if any mention of > object/classes) so that more applications of computer science, > including graphics, can be covered is most likely more appropriate. I sincerely doubt it. You can try to make the case, but nothing I've seen here so far has been persuasive. Graphics are paradigm objects. It's very lazy to revert to procedural techniques in the face of a language that offers so much more. Stick to FORTRAN maybe? > You wrote: "we're in a dark age right now". Let me agree and take > this statement to the extreme. Forget about OOP. We need to start > teaching kids about qubits, and the bra and ket notation. This is > where the future lies, with quantum computing and quantum > cryptography. Furthermore, the notation is *a lot* simpler than the > "rib" syntax which you are so fond of, as long as you only deal with > finite dimensional spaces. Yet, I would not argue that this would > be appropriate for a CS0 course. Your analogies of OO with advanced mathematics, thereby suggesting that OO should be seen as beyond the reach of CS0 is precisely the attitude I disagree with. It's woven into our everyday patterns of thought, OO is, including ideas of inheritance, even polymorphism. What a great opportunity to connect ordinary patterns of thought with a formal, machine-executabe language. What a waste to ignore this opportunity. Students taking a CS0 course have to be able to write simple programs, > in various areas (including graphics). There's nothing wrong in > teaching procedurally based programming at that level. What is > important is to make them *think* ... not to dazzle them with the > latest tool. > > Andr? I feel sorry for students who get suckered into taking such CS0s and wish they wouldn't get their first impressions of Python from such courses. Bad PR for Python Nation the way I see it. Fortunately, not all CS0s are so crummy. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/6f2ace06/attachment.htm From ajudkis at verizon.net Thu Feb 8 06:05:59 2007 From: ajudkis at verizon.net (Andy Judkis) Date: Thu, 08 Feb 2007 00:05:59 -0500 Subject: [Edu-sig] understanding recursion. . . References: Message-ID: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> I teach a "serious computer literacy" course to 10th graders. The course covers some things about how hardware works, how the internet works, what operating systems do, etc. The last part is a 3-4 week intro to Python programming. I've encountered some interesting student behavior and I'm curious to know how those of you who are better and more experienced teachers would suggest handling it. Specifically, I've found that many kids seem to have a natural ability to use recursion, but they don't realize that they're doing it, and they don't understand the implications. Case in point: I give them a trivial "guess the random number" game and they add trivial features to it that require some basic programming concepts. One of the features is to have the program ask the user if he/she wants to play again. My expectation was that they'd write a loop like this: while True: play_game() resp = raw_input("Play again?") if resp == "no": break Instead, what many of them do is to put the logic inside the play_game() routine: def play_game(): . . . . . . resp = raw_input("Play again?") if resp == "yes": play_game() As far as they can tell, this works fine. When I look back on my own experiences, it took me a long time to think recursively, and it would never have occurred to me to code it the way they do. I envy them their natural (if imperfect) grasp of the approach. But they don't have any clue that there's a call stack involved, or that someday this could get them in trouble. I shudder to think about the blank looks that I will get if I try to explain why it could be a problem. So far, I've handled it by pointing out "that's recursion, you can do that but there's a little more to it and if you're interested, ask me or look into it further on your own." I guess that lets me off the hook but it doesn't feel quite right. Other options I can think of are: 1) try to explain it and lose most of the class 2) just say "I don't allow it, I have a good reason, let me know if you want an explanation" Neither of these feels quite right, either. These are bright kids but they have great difficulty understanding things like function parameters and return values, and I really think recursion is beyond them at this point. Anybody have any suggestions or similar experiences? Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ From delza at livingcode.org Thu Feb 8 06:32:28 2007 From: delza at livingcode.org (Dethe Elza) Date: Wed, 7 Feb 2007 21:32:28 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <45C9E30B.5040306@canterburyschool.org> <200702071016.42765.john.zelle@wartburg.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> Message-ID: On 7-Feb-07, at 7:57 PM, kirby urner wrote: > Graphics are paradigm objects. It's very lazy to revert to procedural > techniques in the face of a language that offers so much more. You're starting to lose me kirby. I'm sympathetic and agree that Python makes using (note: not necessarily creating new) object as simple as procedural programming, in part because using objects *is* just procedural programming. There is nothing magical about object in Python, which is part of why it is such a great language and supports many programming styles, including (but not limited to) procedural, functional, object-oriented, logical and declarative. > Stick to FORTRAN maybe? Ad hominem attacks aren't going to convince anyone. >> You wrote: "we're in a dark age right now". Let me agree and take >> this statement to the extreme. Forget about OOP. We need to start >> teaching kids about qubits, and the bra and ket notation. This is >> where the future lies, with quantum computing and quantum >> cryptography. Furthermore, the notation is *a lot* simpler than the >> "rib" syntax which you are so fond of, as long as you only deal with >> finite dimensional spaces. Yet, I would not argue that this would >> be appropriate for a CS0 course. Not until we have the equivalent of Python for quantum computing anyhow %-) > Your analogies of OO with advanced mathematics, thereby suggesting > that OO should be seen as beyond the reach of CS0 is precisely the > attitude I disagree with. I don't see anyone arguing that OO is "beyond the reach" of CS0. I see them arguing that it's only one semester to introduce a *lot* of new concepts, only some of them having to do specifically with programming and computer language notation. Decisions have to be made about what to cover. Sometimes, for some teachers, OO makes the cut in some form or another. But OO is not some magic bullet that *must* be taught in order to learn about computers. Remember what Djikstra (I think) said, "computer science is as much about computers as astronomy is about telescopes." > It's woven into our everyday patterns of thought, OO is, including > ideas > of inheritance, even polymorphism. This is where I disagree most strongly. When OO was introduced it was often taught like this, which resulted in a huge amount of confusion, because what we model with OO has *very little* to do with objects as we normally think of them in the real world. Making that assertion to students can be very misleading. And even if we wanted to make a case for Python objects being in some way similar to real world objects that we're all familiar with: the real world is parallelism: things don't happen in a given order, they're all happening at once. But that doesn't mean we should teach threading or other forms of parallelism in CS0 (unless we're teaching Erlang rather than Python). Actually, Lynn Andrea Stein does propose introducing threads early on in CS101 (http://faculty.olin.edu/~las/2001/07/www.ai.mit.edu/people/ las/papers/cs101-proposal.html), but that's in a CS-majors class at MIT (and in Java). > What a great opportunity to connect ordinary patterns of thought with > a formal, machine-executabe language. What a waste to ignore this > opportunity. It seems to me that "connecting ordinary patterns of thought with a formal, machine-executable language" is exactly most of this thread has been about, and what draws each of us to Python. Whether that involves dot notation or "ribs" from day one is a rather trivial matter of syntax, IMHO. > I feel sorry for students who get suckered into taking such CS0s and > wish they wouldn't get their first impressions of Python from such > courses. This just comes across as sour grapes and more ad hominems. The important thing is to teach the *concepts*, not whether they are strictly OO or even whether they are Python. The syntax is just a means to an end. Python has a rather elegant syntax, which helps to keep it out of the way of the actual material, as opposed to Java where you have to struggle through layers of syntax and mechanisms in order to get even simple things done. And Java's insistence on enforcing all objects all the time just gets in the way when objects aren't what you need. --Dethe You know, Hobbes, some days even my lucky rocketship underpants don't help. --Calvin From kirby.urner at gmail.com Thu Feb 8 07:52:13 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 22:52:13 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <4bdc75fc5e806611a69b68af61c40590@capital.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> Message-ID: On 2/7/07, Dethe Elza wrote: > > > Stick to FORTRAN maybe? > > Ad hominem attacks aren't going to convince anyone. And which hominem was that I wonder? I think going out of one's way to shield students even from dot notation, let alone simple class definitions, is the kind of bastardization of the Python language we don't want to see, for the sake of Python. Could be the kiss of death for an intelligently designed language, to have it used in such circumstances. It's ugly, it's not what Python is about. Why teach rotted out Python under the CS banner or vice versa? In Python "everything is an object". If you're not going to explain that, I don't think you're really teaching Python and shouldn't represent that you are. > > Your analogies of OO with advanced mathematics, thereby suggesting > > that OO should be seen as beyond the reach of CS0 is precisely the > > attitude I disagree with. > > I don't see anyone arguing that OO is "beyond the reach" of CS0. I > see them arguing that it's only one semester to introduce a *lot* of > new concepts, only some of them having to do specifically with > programming and computer language notation. Decisions have to be > made about what to cover. Sometimes, for some teachers, OO makes the > cut in some form or another. But OO is not some magic bullet that > *must* be taught in order to learn about computers. Remember what > Djikstra (I think) said, "computer science is as much about computers > as astronomy is about telescopes." It only takes a few minutes to talk about how Djikstra revolutionized procedural programming by moving us from the spaghetti code era to structured programming. That was a paradigm shift as well and part of a longer story that, in my experience, students enjoy hearing, find edifying. "Object oriented" is such a buzz word, plus is so pervasive in commerce and industry. What does it really mean? Aren't we even going to answer that question? It's a part of the story (not the whole story, but a vital part). I'd have a hard time taking any CS0 seriously that saw fit to cut out *any* mention of OOP. > It's woven into our everyday patterns of thought, OO is, including > > ideas > > of inheritance, even polymorphism. > > This is where I disagree most strongly. When OO was introduced it > was often taught like this, which resulted in a huge amount of > confusion, because what we model with OO has *very little* to do with > objects as we normally think of them in the real world. Making that > assertion to students can be very misleading. Yeah, we definitely disagree on this. Notation like doorbell.ring(), car.filltank() and dog.bark() is still the way to get the ball rolling with beginners I think. Imagine ordinary things, think of what they might do, what attributes they might have. thing.verb() and thing.property -- the essence of dot notation. It's still taught this way for openers. I don't know when you think that's changed. > And even if we wanted to make a case for Python objects being in some > way similar to real world objects that we're all familiar with: the > real world is parallelism: things don't happen in a given order, > they're all happening at once. But that doesn't mean we should teach > threading or other forms of parallelism in CS0 (unless we're teaching > Erlang rather than Python). I definitely think CS0 should include the *concept* of multiple processes and/or threads, with the job of the operating system to divide its attention among them. The idea of a clock, tasks, and priorities -- all very real world (people multi-task), all very accessible. You can talk about threads without actually coding threads, just like you can talk about how GUI programming is more "event driven" than the older style of "menu trees". So much of a good CS0 course (like I had at Princeton) involves storytelling. Get stuff across with examples, with war stories drawn from real life. Not everything mentioned or elucidated has to be front and center in the lab. > Actually, Lynn Andrea Stein does propose introducing threads early on > in CS101 (http://faculty.olin.edu/~las/2001/07/www.ai.mit.edu/people/ > las/papers/cs101-proposal.html), but that's in a CS-majors class at > MIT (and in Java). > > > What a great opportunity to connect ordinary patterns of thought with > > a formal, machine-executabe language. What a waste to ignore this > > opportunity. > > It seems to me that "connecting ordinary patterns of thought with a > formal, machine-executable language" is exactly most of this thread > has been about, and what draws each of us to Python. Whether that > involves dot notation or "ribs" from day one is a rather trivial > matter of syntax, IMHO. Yeah, if it's just about whether "from day one" that's pretty trivial. Day one might be showing 'Warriors of the Net' (cartoon). But if it's about whether you can say you're "teaching Python" when you never mention __init__ (constructor) *at all* during the entire course, then I'd have to say no, you've not really taught Python, just used it as a means to some end. You've avoided the language more than you've bothered to teach it, really. And that's maybe OK (maybe the course really uses other languages more, like Scheme or Ruby), as long as you don't advertise you're "teaching Python" in the course description (that'd be a kind of white lie). >> I feel sorry for students who get suckered into taking such CS0s and >> wish they wouldn't get their first impressions of Python from such >> courses. > This just comes across as sour grapes and more ad hominems. The And your pompous opining comes across how? > important thing is to teach the *concepts*, not whether they are > strictly OO or even whether they are Python. The syntax is just a > means to an end. Python has a rather elegant syntax, which helps to > keep it out of the way of the actual material, as opposed to Java > where you have to struggle through layers of syntax and mechanisms in > order to get even simple things done. And Java's insistence on > enforcing all objects all the time just gets in the way when objects > aren't what you need. > > --Dethe Yeah, but *which* concepts? I think a CS0 that *features* Python as an interesting specimen (a language) but avoids all talk of classes and subclasses, is probably lame. Is it possible for a CS0 to be lame in your book? You don't believe in any ranking or ordering among the CS0s or this world? Personally, I'd prefer as CS course steer clear of Python if the plan is to simply force it to play dumb. Better no Python at all than Python in a bad light. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/95a33f7b/attachment.html From kirby.urner at gmail.com Thu Feb 8 08:04:03 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 7 Feb 2007 23:04:03 -0800 Subject: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py In-Reply-To: References: <69FA3701-1C86-45D9-85C8-EAEEE34BF752@lclark.edu> <939EA460-9650-4AFD-BA1B-91B75987425E@capital.edu> <7528bcdd0702071846g284778d4k3485528ecf9977d1@mail.gmail.com> Message-ID: > > > Is it possible for a CS0 to be lame in your book? You don't believe in > any ranking or ordering among the CS0s [of] this world? > > Personally, I'd prefer [a] CS course steer clear of Python if the plan is > to simply force it to play dumb. Better no Python at all than Python in a > bad light. > > Kirby > > Anyway, I've made my position crystal clear and doubt I can add much to it. I'll stop contributing to this thread for at least a few days. I can always make do with private emails, chuckling with my cliquey friends about all the crummy CS courses out there. Such a dismal picture. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/919eb924/attachment.htm From jeff at taupro.com Thu Feb 8 12:08:22 2007 From: jeff at taupro.com (Jeff Rush) Date: Thu, 08 Feb 2007 05:08:22 -0600 Subject: [Edu-sig] meaning of +1 In-Reply-To: References: <45CA2199.1060908@bryant.edu> Message-ID: <45CB04A6.2010906@taupro.com> Dethe Elza wrote: > On 7-Feb-07, at 10:59 AM, Brian Blais wrote: > >> I am not asking an existential question about the meaning of the >> integer set, but rather what it means when someone writes in an >> email on this list, something like: >> >> +1 >> > It's shorthand for "I approve and vote in favor of this direction, > proposal, critique, or whatever. > > Variations include -1 (don't approve, vote no), +0 (vaguely approve, > but don't really care), -0 (vaguely disapprove, but not willing to > fight over it), +1000 (I really, really care deeply about this and > want it), -1000 (this is a really bad idea that I think will harm the > community), etc. Dethe, thanks for documenting this for me. I hope you don't mind but I've just clipped your text as a legend for a vote we're taking at pycamp.python.org over a name change. Brian, knowing this code is rather important. During the talks selection process for this year's PyCon, the reviewers were supposed to use this code to indicate their degree of support for a talk. Unfortunately, this was implied and no formal meaning of the codes was established. So those who use it a lot on the Python lists followed Dethe's meanings, and others of us used the layman's understanding of +1 is for, +2 is strongly for, etc. and -1 is against, etc. and scratched our heads when we was a +0 or -0. Then when they were tallied, it was believed that those who voted -1 were strongly against a talk when actually they were just not thrilled, inappropriately removing talk contenders. When this was discovered there was no time to revote so manual interpretations/debates were used. Next year we're going to define the codes a bit better for reviewers. So learn the codes... -Jeff From chandrakirti at gmail.com Thu Feb 8 12:15:29 2007 From: chandrakirti at gmail.com (Lloyd Hugh Allen) Date: Thu, 8 Feb 2007 06:15:29 -0500 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> Message-ID: <24d253d90702080315r6ebf8c8cy2db850b511c30860@mail.gmail.com> iirc, the classic would be to compute fibonaccis recursively and watch the system grind to a halt in only a handful of iterations. When googling for "recursive fibonacci", I thought that the last example on the first page http://blogs.msdn.com/ericlippert/archive/2004/05/19/135392.aspx would tell me why I'm a moron, but in fact this page also cites fib as a good way to show recursion gone wrong. Just that we shouldn't.... The comments have decent commentary as well. On 2/8/07, Andy Judkis wrote: > I teach a "serious computer literacy" course to 10th graders. The course > covers some things about how hardware works, how the internet works, what > operating systems do, etc. The last part is a 3-4 week intro to Python > programming. I've encountered some interesting student behavior and I'm > curious to know how those of you who are better and more experienced > teachers would suggest handling it. > > Specifically, I've found that many kids seem to have a natural ability to > use > recursion, but they don't realize that they're doing it, and they don't > understand the implications. Case in point: I give them a trivial "guess > the random number" game and they add trivial features to it that require > some basic programming concepts. One of the features is to have the program > ask the user if he/she wants to play again. My expectation was that they'd > write a loop like this: > > while True: > play_game() > resp = raw_input("Play again?") > if resp == "no": > break > > Instead, what many of them do is to put the logic inside the play_game() > routine: > > def play_game(): > . . . > . . . > resp = raw_input("Play again?") > if resp == "yes": > play_game() > > As far as they can tell, this works fine. When I look back on my own > experiences, it took me a long time to think recursively, and it would never > have occurred to me to code it the way they do. I envy them their natural > (if imperfect) grasp of the approach. But they don't have any clue that > there's > a call stack involved, or that someday this could get them in trouble. I > shudder > to think about the blank looks that I will get if I try to explain why it > could be a problem. So far, I've handled it by pointing out "that's > recursion, > you can do that but there's a little more to it and if you're interested, > ask me or look into it further on your own." I guess that lets me off the > hook > but it doesn't feel quite right. Other options I can think of are: > 1) try to explain it and lose most of the class > 2) just say "I don't allow it, I have a good reason, let me know if you want > an > explanation" > Neither of these feels quite right, either. These are bright kids but they > have > great difficulty understanding things like function parameters and return > values, > and I really think recursion is beyond them at this point. > > Anybody have any suggestions or similar experiences? > > Thanks, > Andy Judkis > Academy of Allied Health and Science > Neptune, NJ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From ajudkis at verizon.net Thu Feb 8 12:23:58 2007 From: ajudkis at verizon.net (Andy Judkis) Date: Thu, 08 Feb 2007 06:23:58 -0500 Subject: [Edu-sig] Using objects early was Procedural front end References: Message-ID: <001001c74b73$a0aca620$0601a8c0@Gandalf> Kirby, in recent posts you made two claims: >That was a paradigm shift as well and part >of a longer story that, in my experience, students enjoy hearing, find >edifying. and: >I have aimed to show there are easy ways to introduce OOP early, using >Python syntax as a guide, that don't require great feats of mental effort >on the part of students. My Dog and Monkey show is quite accessible >to average 8th graders in public school as I've proved in the field. and I was wondering if you would be willing to support them. How do you assess whether or not your students comprehend the material at a level that you consider satisfactory? Anything formal, or just your feeling? What proportion of your kids need to get it for you to be satisfied? The reason I ask is because my 10th graders are well above average but it's quite clear to me that there's -no way- that they can get the material you describe in the time period you are talking about in any useful way. Thanks, Andy From andre.roberge at gmail.com Thu Feb 8 12:34:44 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 8 Feb 2007 07:34:44 -0400 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> Message-ID: <7528bcdd0702080334y2aec9c36y4b5c23607791e433@mail.gmail.com> On 2/8/07, Andy Judkis wrote: > I teach a "serious computer literacy" course to 10th graders. The course > covers some things about how hardware works, how the internet works, what > operating systems do, etc. The last part is a 3-4 week intro to Python > programming. I've encountered some interesting student behavior and I'm > curious to know how those of you who are better and more experienced > teachers would suggest handling it. > > Specifically, I've found that many kids seem to have a natural ability to > use > recursion, but they don't realize that they're doing it, and they don't > understand the implications. [snip]. But they don't have any clue that > there's > a call stack involved, or that someday this could get them in trouble. I > shudder > to think about the blank looks that I will get if I try to explain why it > could be a problem. So far, I've handled it by pointing out "that's > recursion, > you can do that but there's a little more to it and if you're interested, > ask me or look into it further on your own." I guess that lets me off the > hook > but it doesn't feel quite right. Other options I can think of are: > 1) try to explain it and lose most of the class > 2) just say "I don't allow it, I have a good reason, let me know if you want > an > explanation" > Neither of these feels quite right, either. These are bright kids but they > have > great difficulty understanding things like function parameters and return > values, > and I really think recursion is beyond them at this point. > > Anybody have any suggestions or similar experiences? No experience, but you may want to have a look at a little video that I did a while ago on the topic of recursion: http://showmedo.com/videos/video?name=rurple2_recursion_andreR&fromSeriesID=15 (Note that I have found since that the tower of Hanoi can be solved fairly simply using iteration.) Andr? > > Thanks, > Andy Judkis > Academy of Allied Health and Science > Neptune, NJ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From aharrin at luc.edu Thu Feb 8 16:38:44 2007 From: aharrin at luc.edu (Andrew Harrington) Date: Thu, 08 Feb 2007 09:38:44 -0600 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> Message-ID: <45CB4404.1090508@luc.edu> Andy, In the situation that you list, recursion is a natural approach. It has a natural end. there are alternatives, that you may or may not want to take time to mention. I have a problem with introductory students doing a major project before recursion is introduced, and naively having a nasty web of recursive calls in playing a much more complicated game, and then they have no possible way to end the program or see what happened when they made an error. I would not discourage the student in your context. A side comment about "a lot more going on than meets the eye" or "make sure it ends cleanly" or "worth further study to really understand" would not hurt either. Andy Harrington Andy Judkis wrote: > I teach a "serious computer literacy" course to 10th graders. The course > covers some things about how hardware works, how the internet works, what > operating systems do, etc. The last part is a 3-4 week intro to Python > programming. I've encountered some interesting student behavior and I'm > curious to know how those of you who are better and more experienced > teachers would suggest handling it. > > Specifically, I've found that many kids seem to have a natural ability to > use > recursion, but they don't realize that they're doing it, and they don't > understand the implications. Case in point: I give them a trivial "guess > the random number" game and they add trivial features to it that require > some basic programming concepts. One of the features is to have the program > ask the user if he/she wants to play again. My expectation was that they'd > write a loop like this: > > while True: > play_game() > resp = raw_input("Play again?") > if resp == "no": > break > > Instead, what many of them do is to put the logic inside the play_game() > routine: > > def play_game(): > . . . > . . . > resp = raw_input("Play again?") > if resp == "yes": > play_game() > > As far as they can tell, this works fine. When I look back on my own > experiences, it took me a long time to think recursively, and it would never > have occurred to me to code it the way they do. I envy them their natural > (if imperfect) grasp of the approach. But they don't have any clue that > there's > a call stack involved, or that someday this could get them in trouble. I > shudder > to think about the blank looks that I will get if I try to explain why it > could be a problem. So far, I've handled it by pointing out "that's > recursion, > you can do that but there's a little more to it and if you're interested, > ask me or look into it further on your own." I guess that lets me off the > hook > but it doesn't feel quite right. Other options I can think of are: > 1) try to explain it and lose most of the class > 2) just say "I don't allow it, I have a good reason, let me know if you want > an > explanation" > Neither of these feels quite right, either. These are bright kids but they > have > great difficulty understanding things like function parameters and return > values, > and I really think recursion is beyond them at this point. > > Anybody have any suggestions or similar experiences? > > Thanks, > Andy Judkis > Academy of Allied Health and Science > Neptune, NJ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- Andrew N. Harrington Computer Science Department Director of Academic Programs Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From phillip.kent at gmail.com Thu Feb 8 18:06:48 2007 From: phillip.kent at gmail.com (Phillip Kent) Date: Thu, 8 Feb 2007 17:06:48 +0000 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: <45CB4404.1090508@luc.edu> References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> <45CB4404.1090508@luc.edu> Message-ID: <96eebba70702080906k6fd905e5vf90707da51fe038c@mail.gmail.com> It maybe relevant to mention a classic introduction to recursion by Brian Harvey in the books "Computer Science Logo Style".... http://www.cs.berkeley.edu/~bh/v1-toc2.html This page has free download of the book PDF. - Phillip ++++++ Dr Phillip Kent, London, UK mathematics education technology research phillip.kent at gmail.com mobile: 07950 952034 ++++++ "Say it! No ideas but in things" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070208/916e8b40/attachment.htm From kirby.urner at gmail.com Thu Feb 8 20:19:40 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 8 Feb 2007 11:19:40 -0800 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> Message-ID: Andy: But they don't have any clue that there's a call stack involved, or that someday this could get them in trouble. I shudder to think about the blank looks that I will get if I try to explain why it could be a problem. I'd praise those stumbling on recursion, use the opportunity to talk about it more specifically, and about how some languages are based on it rather intensively (others not so much). Greatest Common Divisor may be written both ways: def gcd(a,b): while b: a, b = b, a % b return a or: def gcd(a,b): if b: return gcd(b, a % b) return a But of course if your 10th graders are pathologically math phobic, like so many of their college peers, you'll want to eschew any such examples and deal purely with strings. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070208/3f600ff1/attachment.htm From mtobis at gmail.com Thu Feb 8 21:34:17 2007 From: mtobis at gmail.com (Michael Tobis) Date: Thu, 8 Feb 2007 14:34:17 -0600 Subject: [Edu-sig] PyCon edu-py activities Saturday Message-ID: I have contacted the open space coordinator regarding space for Satruday evening. I am at present inclined to back off presenting a newby lecture for logistic reasons. This should have been planned earlier to fit in with other activities and properly promoted. Rather I'd like to quickly present my approach to the group at our open space session. Please pitch in to improve the content of http://us.pycon.org/TX2007/PyEduto soften us up for whatever point of view you bring to the discussion and to attract more participants. best regards to all Michael Tobis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070208/d1af7fff/attachment-0001.html From vceder at canterburyschool.org Thu Feb 8 21:56:39 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Thu, 08 Feb 2007 15:56:39 -0500 Subject: [Edu-sig] PyCon edu-py activities Saturday In-Reply-To: References: Message-ID: <45CB8E87.6050806@canterburyschool.org> Sounds good... Were you thinking of having dinner *in* the Preston Trail II room? Or in the hotel restaurant? Vern Michael Tobis wrote: > I have contacted the open space coordinator regarding space for Satruday > evening. > > I am at present inclined to back off presenting a newby lecture for > logistic reasons. This should have been planned earlier to fit in with > other activities and properly promoted. Rather I'd like to quickly > present my approach to the group at our open space session. > > Please pitch in to improve the content of > http://us.pycon.org/TX2007/PyEdu to soften us up for whatever point of > view you bring to the discussion and to attract more participants. > > best regards to all > Michael Tobis > > > ------------------------------------------------------------------------ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From mtobis at gmail.com Thu Feb 8 23:49:36 2007 From: mtobis at gmail.com (Michael Tobis) Date: Thu, 8 Feb 2007 16:49:36 -0600 Subject: [Edu-sig] PyCon edu-py activities Saturday In-Reply-To: <45CB8E87.6050806@canterburyschool.org> References: <45CB8E87.6050806@canterburyschool.org> Message-ID: Good q. I don't think we should leave the site. I'll ask the hotel if they are willing to cater in the Preston room and we can take it from there. mt On 2/8/07, Vern Ceder wrote: > Sounds good... > > Were you thinking of having dinner *in* the Preston Trail II room? Or in > the hotel restaurant? > > Vern > > Michael Tobis wrote: > > I have contacted the open space coordinator regarding space for Satruday > > evening. > > > > I am at present inclined to back off presenting a newby lecture for > > logistic reasons. This should have been planned earlier to fit in with > > other activities and properly promoted. Rather I'd like to quickly > > present my approach to the group at our open space session. > > > > Please pitch in to improve the content of > > http://us.pycon.org/TX2007/PyEdu to soften us up for whatever point of > > view you bring to the discussion and to attract more participants. > > > > best regards to all > > Michael Tobis > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > -- > This time for sure! > -Bullwinkle J. Moose > ----------------------------- > Vern Ceder, Director of Technology > Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 > vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 > From matt at schinckel.net Fri Feb 9 00:47:51 2007 From: matt at schinckel.net (Matthew Schinckel) Date: Fri, 9 Feb 2007 10:17:51 +1030 Subject: [Edu-sig] understanding recursion. . . In-Reply-To: References: <000801c74b3e$d33e9ce0$0601a8c0@Gandalf> Message-ID: <2521244f0702081547p590fe6c4rf72a54ce7a5662b9@mail.gmail.com> I used recursion a while ago (in JavaScript) using strings. I don't have the code handy, but I do recall the context. I needed to find the
element that was the parent/grandparent/great-grand-parent of the current element. I didn't know how many levels I needed to go up. To paraphrase it in python: def getParentForm(element): if element.parent == document: return None if type(element.parent) == "FORM": return element.parent return getParentForm(element.parent) Naturally, this is more terse in python than it was in JS! This is a safer form of recursion, as it has a limit to the number of times it is called. This is not a limit placed by my coding, but by the fact that unless the HTML DOM on which it is operating has an infinite number of nested elements, of which this is the last (!), then it will at some stage return either the element that is a form, or None. And the hope is that the scripting language can handle nested calls of at least as many nests as the HTML parser. :) Matt. (I'm new to this list, but I'm planning on teaching python to a final-year-of-high-school class in about 8 weeks time) On 09/02/07, kirby urner wrote: > > > Andy: > > But they don't have any clue that there's a call stack involved, or that > > someday this could get them in trouble. I shudder to think about the > > blank looks that I will get if I try to explain why it could be a problem. > > > I'd praise those stumbling on recursion, use the opportunity to talk about > it more specifically, and about how some languages are based on it rather > intensively (others not so much). > > Greatest Common Divisor may be written both ways: > > def gcd(a,b): > while b: > a, b = b, a % b > return a > > or: > > def gcd(a,b): > if b: > return gcd(b, a % b) > return a > > But of course if your 10th graders are pathologically math phobic, > like so many of their college peers, you'll want to eschew any > such examples and deal purely with strings. > > Kirby > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > -- Matthew Schinckel The Feynman Problem-Solving Algorithm: (1) write down the problem; (2) think very hard; (3) write down the answer. From vceder at canterburyschool.org Fri Feb 9 01:15:34 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Thu, 08 Feb 2007 19:15:34 -0500 Subject: [Edu-sig] PyCon edu-py activities Saturday In-Reply-To: References: <45CB8E87.6050806@canterburyschool.org> Message-ID: <45CBBD26.7060107@canterburyschool.org> The hotel restaurant isn't that inconvenient, so if we have to we can easily do that, although we probably want to give them some idea we're coming. I would agree that going of sight might take more time than we want to spend. Vern Michael Tobis wrote: > Good q. > > I don't think we should leave the site. > > I'll ask the hotel if they are willing to cater in the Preston room > and we can take it from there. > > mt > > > On 2/8/07, Vern Ceder wrote: >> Sounds good... >> >> Were you thinking of having dinner *in* the Preston Trail II room? Or in >> the hotel restaurant? >> >> Vern >> >> Michael Tobis wrote: >> > I have contacted the open space coordinator regarding space for >> Satruday >> > evening. >> > >> > I am at present inclined to back off presenting a newby lecture for >> > logistic reasons. This should have been planned earlier to fit in with >> > other activities and properly promoted. Rather I'd like to quickly >> > present my approach to the group at our open space session. >> > >> > Please pitch in to improve the content of >> > http://us.pycon.org/TX2007/PyEdu to soften us up for whatever point of >> > view you bring to the discussion and to attract more participants. >> > >> > best regards to all >> > Michael Tobis >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Edu-sig mailing list >> > Edu-sig at python.org >> > http://mail.python.org/mailman/listinfo/edu-sig >> >> -- >> This time for sure! >> -Bullwinkle J. Moose >> ----------------------------- >> Vern Ceder, Director of Technology >> Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 >> vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 >> -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From vceder at canterburyschool.org Fri Feb 9 01:29:30 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Thu, 08 Feb 2007 19:29:30 -0500 Subject: [Edu-sig] PyCon edu-py activities Saturday In-Reply-To: <45CBBD26.7060107@canterburyschool.org> References: <45CB8E87.6050806@canterburyschool.org> <45CBBD26.7060107@canterburyschool.org> Message-ID: <45CBC06A.8070600@canterburyschool.org> Sorry about that... I meant going "off site"... wow... it must have been a long day... ;) Vern Vern Ceder wrote: > The hotel restaurant isn't that inconvenient, so if we have to we can > easily do that, although we probably want to give them some idea we're > coming. I would agree that going of sight might take more time than we > want to spend. > > Vern > > Michael Tobis wrote: >> Good q. >> >> I don't think we should leave the site. >> >> I'll ask the hotel if they are willing to cater in the Preston room >> and we can take it from there. >> >> mt >> >> >> On 2/8/07, Vern Ceder wrote: >>> Sounds good... >>> >>> Were you thinking of having dinner *in* the Preston Trail II room? Or in >>> the hotel restaurant? >>> >>> Vern >>> >>> Michael Tobis wrote: >>>> I have contacted the open space coordinator regarding space for >>> Satruday >>>> evening. >>>> >>>> I am at present inclined to back off presenting a newby lecture for >>>> logistic reasons. This should have been planned earlier to fit in with >>>> other activities and properly promoted. Rather I'd like to quickly >>>> present my approach to the group at our open space session. >>>> >>>> Please pitch in to improve the content of >>>> http://us.pycon.org/TX2007/PyEdu to soften us up for whatever point of >>>> view you bring to the discussion and to attract more participants. >>>> >>>> best regards to all >>>> Michael Tobis >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Edu-sig mailing list >>>> Edu-sig at python.org >>>> http://mail.python.org/mailman/listinfo/edu-sig >>> -- >>> This time for sure! >>> -Bullwinkle J. Moose >>> ----------------------------- >>> Vern Ceder, Director of Technology >>> Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 >>> vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 >>> > -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From kirby.urner at gmail.com Fri Feb 9 18:47:28 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 9 Feb 2007 09:47:28 -0800 Subject: [Edu-sig] For classroom use... Message-ID: Here's some field tested code that I think showcases what a student interested in computer graphics might eyeball and run, after some background in the basic syntax. True, there's stuff going on behind the scenes (another module, plus VPython, all well documented). I'll plan to use this with my high schoolers in April. I want them to see what real Python really looks like, to get ideas from, for doing graphics of their own. We also use VRML, maybe just projected on the big screen in front. Kirby """ coupler.py by K. Urner, (gpl) 2007 4dsolutions.net Documentation for Coupler: The Coupler is a space-filling irregular octahedron defined by three mutually orthogonal quadrilaterals: one square and two congruent rhombi. This module constructs these quadri- laterals and displays them in VPython. In the concentric hierarchy, the Coupler's volume = 1 (i.e. is same as tetrahedron's defined by 4 unit-radius CCP balls). http://www.rwgrayprojects.com/synergetics/s09/figs/f86431.html URL for stickworks.py: http://www.4dsolutions.net/ocn/python/stickworks.py Documentation for stickworks.py: http://www.4dsolutions.net/ocn/stickworks.html Relevant VRML worlds by sw dharmraj (see Synergeo on Yahoo!): http://members.westnet.com.au/dharmraj/vrml/coupler.wrl http://members.westnet.com.au/dharmraj/vrml/KmiteCube.wrl See also: Richard Hawkins Digital Archive: http://www.newciv.org/Synergetic_Geometry/ """ from stickworks import Vector, Edge, axes from math import sqrt sqrt2 = sqrt(2) apexd = sqrt2/2.0 # convention nx for -x (negative x) x = Vector((1,0,0)) y = Vector((0,1,0)) nx = Vector((-1,0,0)) ny = Vector((0, -1, 0)) apex = Vector((0, 0, apexd)) napex = Vector((0, 0, -apexd)) class Square (object) : """ Coupler Square Equator in XY plane """ def __init__(self): Edge.color = (1,0,0) self.edges = [Edge(x,y), Edge(y,nx), Edge(nx,ny), Edge(ny,x)] def draw(self): for e in self.edges: e.draw() class Fx (object) : """ Coupler Equator in XZ plane """ def __init__(self): Edge.color = (0,1,0) self.edges = [ Edge(x, apex), Edge(apex, nx), Edge(nx, napex), Edge(napex, x)] def draw(self): for e in self.edges: e.draw() class Fy (object) : """ Coupler Equator in YZ plane """ def __init__(self): self.edges = [ Edge(y, apex), Edge(apex, ny), Edge(ny, napex), Edge(napex, y)] def draw(self): for e in self.edges: e.draw() def test(): """ Draw a Coupler centered at (0,0,0) with XYZ Axes """ # blue axes, please Edge.color = (0,0,1) axes(2,2,2) # create equator objects ofy = Fy() ofx = Fx() osq = Square() # draw the rhombi Edge.color = (0,1,0) ofy.draw() ofx.draw() # draw the square Edge.color = (1,0,0) osq.draw() if __name__ == '__main__': test() -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070209/6db7ce22/attachment.htm From vceder at canterburyschool.org Fri Feb 9 19:24:20 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Fri, 09 Feb 2007 13:24:20 -0500 Subject: [Edu-sig] For classroom use... In-Reply-To: References: Message-ID: <45CCBC54.3000405@canterburyschool.org> kirby urner wrote: > > Here's some field tested code I guess I'm kind of curious as to what you mean by "field tested". The 'field' part I get, of course. But "tested" how? Or I guess I mean "what was the test, and how were the results judged?", if that makes sense... BTW, I'm not questioning the use VPython by any means - I think its got great potential as a way to explore programming. Cheers, Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From drake at lclark.edu Fri Feb 9 20:36:06 2007 From: drake at lclark.edu (Peter Drake) Date: Fri, 9 Feb 2007 11:36:06 -0800 Subject: [Edu-sig] Strange transitive import problem Message-ID: <031AEDCA-3278-4EF5-8934-7D4CC9107C6B@lclark.edu> The graphics2.py file I supplied earlier (http://www.lclark.edu/ ~drake/courses/cs0/graphics2.py) is a procedural front-end for Zelle's graphics.py. If I run the graphics2.py module, everything works fine, and I can issue commands interactively. A problem happens if I write ANOTHER program, say junk.py: from graphics2 import * print "imported graphics2" background("red") When I run this (within IDLE), it hangs trying to import graphics2. There is no error message or processor load, it just hangs. Can anyone explain (or reproduce) this behavior? Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ From kirby.urner at gmail.com Fri Feb 9 20:55:04 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 9 Feb 2007 11:55:04 -0800 Subject: [Edu-sig] For classroom use... In-Reply-To: <45CCBC54.3000405@canterburyschool.org> References: <45CCBC54.3000405@canterburyschool.org> Message-ID: On 2/9/07, Vern Ceder wrote: > > kirby urner wrote: > > > > Here's some field tested code > > I guess I'm kind of curious as to what you mean by "field tested". The > 'field' part I get, of course. But "tested" how? Or I guess I mean "what > was the test, and how were the results judged?", if that makes sense... Fair question. In this case of coupler.py, my field tester is a welder-geometer in New Zealand who got it working and then came back with a VRML world on the same subject. He's studying Python on his own, using Zelle's book, which just arrived. Here're a couple of recent exchanges from a public archive on Yahoo!: ==== > Yes, stickworks.py and coupler.py should both go in site-packages, > but then VPython needs to be installed as well. All you get from > Coupler at the moment is a red and green network of edges, > centered around the XYZ origin, the axes in blue. > > Kirby > Hi Kirby: I have Vpython and with stickworks.py was able to run coupler.py. I did a SpringDAnce VRML of 8 mites with each corner on a cube grid. http://members.westnet.com.au/dharmraj/vrml/KmiteCube.wrl dharmraj --- Re: Drafting another storyboard Kirby > That's trully excellent. So that's a Coupler then, what you did. I was hoping you would like it. I thought a visual model of what you were programming would help > > Each MITE is two blue-yellow arms holding a purple, green spine. true > Same volume as a tetrahedron, inscribed as face diags of that green > 2-frequency cube. true > What you may have done already (if so, please link?) or might > want to do, is said 8 mites each subdivided into two As (left > and right) plus one B (left or right). is this what you mean? http://members.westnet.com.au/dharmraj/vrml/coupler.wrl my new Python book arrived...Python Programming (an introduction to Computer Science) by John Zelle... cheers, sw dharmraj --- > is this what you mean? > > http://members.westnet.com.au/dharmraj/vrml/coupler.wrl > Yes, exactly! I'll add that as a link as well, to coupler.py > > my new Python book arrived...Python Programming (an introduction > to Computer Science) by John Zelle... > > cheers, > sw dharmraj > That's probably the best published book for starting out with Python. Later, maybe check the free online Dive Into Python tutorial, also published by Apress if you want hardcopy. http://www.diveintopython.org/ Kirby BTW, I'm not questioning the use VPython by any means - I think its got > great potential as a way to explore programming. > > Cheers, > Vern Yes, and to explore geometry, like Arthur was doing with Pygeo. As far as measuring student success, it's what they're able to code themselves, using pre-existing code as a basis, that I go by. Each student has Python + VPython + various modules. They save code from week to week and gradually build up a portfolio. They show off their creations when the parents come to pick them up. I asked one of my students to send me his source code for the 3-frequency tetrahedron but he never did. The class itself is written up in my blog, complete with digicam shots of some of the whiteboard content. I'm able to fish up some of that content with the following query: http://worldgame.blogspot.com/search?q=%22saturday+academy%22 You'll find at least one of my worksheets (PDF) used with 8th graders in public school here: http://www.4dsolutions.net/ocn/winterhaven/ But I don't publish actual student responses, which would be a clearer measure of their level of comprehension. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070209/21d4de8a/attachment.html From vceder at canterburyschool.org Fri Feb 9 21:28:52 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Fri, 09 Feb 2007 15:28:52 -0500 Subject: [Edu-sig] For classroom use... In-Reply-To: References: <45CCBC54.3000405@canterburyschool.org> Message-ID: <45CCD984.6030500@canterburyschool.org> Thanks, that does answer my question. For my part, I've also taken to giving an exit survey every time I teach Python, whether to 8th and 9th graders or to teachers. While not really scientific, I've found it very useful in refining approaches. Cheers, Vern kirby urner wrote: > On 2/9/07, *Vern Ceder* > wrote: > > kirby urner wrote: > > > > Here's some field tested code > > I guess I'm kind of curious as to what you mean by "field tested". The > 'field' part I get, of course. But "tested" how? Or I guess I mean "what > was the test, and how were the results judged?", if that makes sense... > > > Fair question. In this case of coupler.py, my field tester is a > welder-geometer in New Zealand who got it working and then > came back with a VRML world on the same subject. > > He's studying Python on his own, using Zelle's book, which > just arrived. > > Here're a couple of recent exchanges from a public archive > on Yahoo!: > > ==== > > > Yes, stickworks.py and coupler.py should both go in site-packages, > > but then VPython needs to be installed as well. All you get from > > Coupler at the moment is a red and green network of edges, > > centered around the XYZ origin, the axes in blue. > > > > Kirby > > > > > Hi Kirby: > I have Vpython and with stickworks.py was able to run coupler.py. > I did a SpringDAnce VRML of 8 mites with each corner on a cube > grid. > > http://members.westnet.com.au/dharmraj/vrml/KmiteCube.wrl > > dharmraj > > --- > > Re: Drafting another storyboard > > > > > Kirby > > That's trully excellent. So that's a Coupler then, what you did. > > I was hoping you would like it. I thought a visual model of what > you were programming would help > > > > > > Each MITE is two blue-yellow arms holding a purple, green spine. > > > true > > > Same volume as a tetrahedron, inscribed as face diags of that green > > 2-frequency cube. > > true > > > > What you may have done already (if so, please link?) or might > > want to do, is said 8 mites each subdivided into two As (left > > and right) plus one B (left or right). > > is this what you mean? > > http://members.westnet.com.au/dharmraj/vrml/coupler.wrl > > > my new Python book arrived...Python Programming (an introduction > to Computer Science) by John Zelle... > > cheers, > sw dharmraj > > > --- > > > is this what you mean? > > > > http://members.westnet.com.au/dharmraj/vrml/coupler.wrl > > > > Yes, exactly! I'll add that as a link as well, to coupler.py > > > > > my new Python book arrived...Python Programming (an introduction > > to Computer Science) by John Zelle... > > > > cheers, > > sw dharmraj > > > > That's probably the best published book for starting out with > Python. Later, maybe check the free online Dive Into Python > tutorial, also published by Apress if you want hardcopy. > > http://www.diveintopython.org/ > > Kirby > > > BTW, I'm not questioning the use VPython by any means - I think its got > great potential as a way to explore programming. > > Cheers, > Vern > > > Yes, and to explore geometry, like Arthur was doing with Pygeo. > > As far as measuring student success, it's what they're able to code > themselves, using pre-existing code as a basis, that I go by. Each student > has Python + VPython + various modules. They save code from week > to week and gradually build up a portfolio. They show off their creations > when the parents come to pick them up. I asked one of my students to > send me his source code for the 3-frequency tetrahedron but he never > did. > > The class itself is written up in my blog, complete with digicam shots > of some of the whiteboard content. I'm able to fish up some of that > content with the following query: > > http://worldgame.blogspot.com/search?q=%22saturday+academy%22 > > You'll find at least one of my worksheets (PDF) used with 8th graders in > public > school here: > > http://www.4dsolutions.net/ocn/winterhaven/ > > But I don't publish actual student responses, which would be a clearer > measure of their level of comprehension. > > Kirby > > > -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137 From jjposner at snet.net Fri Feb 9 21:22:53 2007 From: jjposner at snet.net (John Posner) Date: Fri, 9 Feb 2007 15:22:53 -0500 Subject: [Edu-sig] understanding recursion In-Reply-To: References: Message-ID: <004b01c74c88$144bbe80$e759a8c0@jposner> Andy Judkis wrote: > ... I've found that many kids seem to have a natural ability > to use recursion, but they don't realize that they're doing it, and > they don't understand the implications. > > ... > > def play_game(): > . . . > resp = raw_input("Play again?") > if resp == "yes": > play_game() > My guess, Andy, is that many of the students are not thinking clearly enough to understand the difference between REPETITION and RECURSION. They haven't thoroughly learned the flow-of-control aspect of functions/subroutines. That's not surprising: in real life, kids don't have to formally declare one activity to be finished before they "go to" (heh heh) another activity. IMHO, the kids' first attempt at coding provides an excellent opportunity for you to gently move them from the realm of almost-right "fuzzy" thinking to "crisp" formal algorithmic thinking. > ... My expectation was that they'd write a loop like this: > > while True: > play_game() > resp = raw_input("Play again?") > if resp == "no": > break > Another guess: not many kids will hit upon the "while True ... break" coding scheme on their own. I'd be inclined to let them use this imperfect solution at first: for i in range(1000000): play_game() ... Then you can point out the limitations, inefficiencies, lack of elegance of this solution -- e.g. to quit the game, you have to type Ctrl-C or close the window. Best, John From john.zelle at wartburg.edu Fri Feb 9 22:09:34 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Fri, 9 Feb 2007 15:09:34 -0600 Subject: [Edu-sig] Strange transitive import problem In-Reply-To: <031AEDCA-3278-4EF5-8934-7D4CC9107C6B@lclark.edu> References: <031AEDCA-3278-4EF5-8934-7D4CC9107C6B@lclark.edu> Message-ID: <200702091509.34867.john.zelle@wartburg.edu> Peter, I should have caught this when you posted your file. There is a bizarre import interaction that I am aware of, but can't say that I fully understand regarding my graphics library. It seems that Python imports are in some-way, somewhat atomic, and with the way my graphics library is set up this can produce this deadlock. I have a workaround for you. Move the graphics setup code in your module into a function: def initGraphics(): global root root = z.GraphWin() print "If you can't see the graphics window," print "it's probably at the upper left" print "of your screen, behind this one." Then call this function once at the start of your graphics programs. This is what will now pop up the window. So your "junk" program becomes: from graphics2 import * print "imported graphics2" initGraphics() background("red") If someone has a better understanding of Python module imports and why that causes a problem with my graphics package, I'd love to know how to fix this problem rather than working around it. --John On Friday 09 February 2007 1:36 pm, Peter Drake wrote: > The graphics2.py file I supplied earlier (http://www.lclark.edu/ > ~drake/courses/cs0/graphics2.py) is a procedural front-end for > Zelle's graphics.py. > > If I run the graphics2.py module, everything works fine, and I can > issue commands interactively. > > A problem happens if I write ANOTHER program, say junk.py: > > from graphics2 import * > print "imported graphics2" > background("red") > > When I run this (within IDLE), it hangs trying to import graphics2. > There is no error message or processor load, it just hangs. > > Can anyone explain (or reproduce) this behavior? > > Peter Drake > Assistant Professor of Computer Science > Lewis & Clark College > http://www.lclark.edu/~drake/ > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Fri Feb 9 22:39:27 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 9 Feb 2007 13:39:27 -0800 Subject: [Edu-sig] For classroom use... In-Reply-To: <45CCD984.6030500@canterburyschool.org> References: <45CCBC54.3000405@canterburyschool.org> <45CCD984.6030500@canterburyschool.org> Message-ID: On 2/9/07, Vern Ceder wrote: > > Thanks, that does answer my question. > > For my part, I've also taken to giving an exit survey every time I teach > Python, whether to 8th and 9th graders or to teachers. While not really > scientific, I've found it very useful in refining approaches. > > Cheers, > Vern Yes, exit survey sounds good. Saturday Academy does have each student fill out an Instructor Evaluation Form, plus sends versions home with the parents (optional to mail in). However, as the instructor, I don't get the see these. A staffer shows up to collect them in sealed envelopes upon conclusion of the last class. Students are free to give me feedback to my face of course. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070209/1986b5c2/attachment.htm From delza at livingcode.org Fri Feb 9 23:49:18 2007 From: delza at livingcode.org (Dethe Elza) Date: Fri, 9 Feb 2007 14:49:18 -0800 Subject: [Edu-sig] understanding recursion In-Reply-To: <004b01c74c88$144bbe80$e759a8c0@jposner> References: <004b01c74c88$144bbe80$e759a8c0@jposner> Message-ID: <440BA17C-B405-4AB7-B285-CD683525E689@livingcode.org> Here's my 0.02. Take with a grain of salt, I've been feverish with the flu the last couple of days When the issue comes up, why not step away from the computers and simply draw a stack on the whiteboard? Show how looping stays at the same place in the stack and recursion will eventually overflow the stack. They don't have to understand all the details of why (or why recursion doesn't have that effect in all languages), but a simple picture should give them enough to know why to avoid one over the other. --Dethe "The Brazilian government is definitely pro-law. But if law doesn't fit reality anymore, law has to be changed. That's not a new thing. That's civilisation as usual." --Gilberto Gil, Brazilian Minister of Culture From kirby.urner at gmail.com Sat Feb 10 20:11:27 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 10 Feb 2007 11:11:27 -0800 Subject: [Edu-sig] understanding recursion In-Reply-To: <440BA17C-B405-4AB7-B285-CD683525E689@livingcode.org> References: <004b01c74c88$144bbe80$e759a8c0@jposner> <440BA17C-B405-4AB7-B285-CD683525E689@livingcode.org> Message-ID: A recent thread on recursion math-thinking-l might be of interest. Many pro computer scientists like to teach about it in tandem with Peano Arithmetic (PA) i.e. mathematical induction. http://mail.geneseo.edu/pipermail/math-thinking-l/2007-January/date.html Of course if the students are already math phobic... But the idea here is a CS approach gives you a second chance to get turned on by what turned you off the first time, i.e. those traditional [I'd say antiquated] high school math classes wherein computer languages are strictly forbidden and/or sidelined without comment. Hope yr feelin' better Dethe. Having the flu sucks. Kirby On 2/9/07, Dethe Elza wrote: > > Here's my 0.02. Take with a grain of salt, I've been feverish with > the flu the last couple of days > > When the issue comes up, why not step away from the computers and > simply draw a stack on the whiteboard? Show how looping stays at the > same place in the stack and recursion will eventually overflow the > stack. They don't have to understand all the details of why (or why > recursion doesn't have that effect in all languages), but a simple > picture should give them enough to know why to avoid one over the other. > > --Dethe > > "The Brazilian government is definitely pro-law. But if law doesn't > fit reality anymore, law has to be changed. That's not a new thing. > That's civilisation as usual." --Gilberto Gil, Brazilian Minister of > Culture > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070210/e51dc7ce/attachment.html From kirby.urner at gmail.com Mon Feb 12 08:27:38 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 11 Feb 2007 23:27:38 -0800 Subject: [Edu-sig] Populating the lesson plans database: Squeak -> Python Message-ID: So I'm trying to figure out how much Smalltalk we want to try teaching in the Squeak and eToys units pre Python. My concern is the former may be harder to learn, but some precocious youngsters are going to want to anyway, but then will this make Python "harder" for them, simply because it's "close but different" which could be confusing? I might just be overgeneralizing from my own experience, of living in Italy, picking up some Italian, while taking French in a British then Americanish school, and later Spanish. I found it hard to keep all these Romance languages from fusing in my head. Arabic came later (probably a lost cause in my case). My leaning is towards developing a "Python for Smalltalkers" set of units, which assumes some familiarity with Smalltalk jargon and concepts, such as messages to receivers, complete encapsulation of data, a 'self' keyword, and compares these with Python's, where data is not necessarily so private, and 'self', though used as a placeholder, is *not* a keyword per se (I've seen some Japanese using 'ghost' (smile)). For most middle schoolers, the previous paragraph might read as gibberish, as they're still in Immersion Phase and just like floating around in a fish tank or whatever Alice in Wonderland dream world, interacting with the many exhibits, learning Physics or whatever. They're not yet into the cold hard world of 100% lexical coding where "left brain" is king (just kidding about the king part). But those few who are, like their adult counterparts, might appreciate the bridge literature (screencasts included). Such a literature already exists bridging Python and Scheme for example, down to a Scheme interpreter written in Python (wasn't that Danny Yoo's project?), plus discussions of Scheme's hyper powerful lambda, versus Python's "little lambda" (as in "Mary had a"), not intended for much more than an anonymous inline expression (name your anonymous function Anon if you want it longer?). And of course Python for C programmers was more the original context of the language in the first place (Guido's target demographic was never "children" per se) -- that literature is pretty much complete. Perl coders tend to see Python as a dialect (so similar, yet alien enough to still be considered "a different language"), while Java coders tend to see it as their possible salvation, from a lot of mindless overhead (Bruce Eckel in this category**). But I'm taking my cues from the many Logo -> Squeak -> Python cave paintings I've been exposed to, a well documented sequence, complete with lesson plans database, for ages 8 to 18. So it's the Logo (which Logo?) -> Squeak and Squeak -> Python bridges which most interest me, in terms of collecting citations and/or developing new content. My impression is there're still lots of holes in the Squeak -> Python literature, ready to be filled with new lesson plan filings. Kirby ** http://www.mindview.net/Books/Python/ThinkingInPython.html). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070211/85f84003/attachment.htm From kirby.urner at gmail.com Mon Feb 12 08:37:38 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 11 Feb 2007 23:37:38 -0800 Subject: [Edu-sig] Populating the lesson plans database: Squeak -> Python (reformatted) Message-ID: So I'm trying to figure out how much Smalltalk we want to try teaching in the Squeak and eToys units pre Python. My concern is the former may be harder to learn, but some precocious youngsters are going to want to anyway, but then will this make Python "harder" for them, simply because it's "close but different" which could be confusing? I might just be overgeneralizing from my own experience, of living in Italy, picking up some Italian, while taking French in a British then Americanish school, and later Spanish. I found it hard to keep all these Romance languages from fusing in my head. Arabic came later (probably a lost cause in my case). My leaning is towards developing a "Python for Smalltalkers" set of units, which assumes some familiarity with Smalltalk jargon and concepts, such as messages to receivers, complete encapsulation of data, a 'self' keyword, and compares these with Python's, where data is not necessarily so private, and 'self', though used as a placeholder, is *not* a keyword per se (I've seen some Japanese using 'ghost' (smile)). For most middle schoolers, the previous paragraph might read as gibberish, as they're still in Immersion Phase and just like floating around in a fish tank or whatever Alice in Wonderland dream world, interacting with the many exhibits, learning Physics or whatever. They're not yet into the cold hard world of 100% lexical coding where "left brain" is king (just kidding about the king part). But those few who are, like their adult counterparts, might appreciate the bridge literature (screencasts included). Such a literature already exists bridging Python and Scheme for example, down to a Scheme interpreter written in Python (wasn't that Danny Yoo's project?), plus discussions of Scheme's hyper powerful lambda, versus Python's "little lambda" (as in "Mary had a"), not intended for much more than an anonymous inline expression (name your anonymous function Anon if you want it longer?). And of course Python for C programmers was more the original context of the language in the first place (Guido's target demographic was never "children" per se) -- that literature is pretty much complete. Perl coders tend to see Python as a dialect (so similar, yet alien enough to still be considered "a different language"), while Java coders tend to see it as their possible salvation, from a lot of mindless overhead (Bruce Eckel in this category**). But I'm taking my cues from the many Logo -> Squeak -> Python cave paintings I've been exposed to, a well documented sequence, complete with lesson plans database, for ages 8 to 18. So it's the Logo (which Logo?) -> Squeak and Squeak -> Python bridges which most interest me, in terms of collecting citations and/or developing new content. My impression is there're still lots of holes in the Squeak -> Python literature, ready to be filled with new lesson plan filings. Kirby ** http://www.mindview.net/Books/Python/ThinkingInPython.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070211/3d8e4659/attachment.html From jjposner at snet.net Mon Feb 12 17:10:21 2007 From: jjposner at snet.net (John Posner) Date: Mon, 12 Feb 2007 11:10:21 -0500 Subject: [Edu-sig] understanding recursion Message-ID: <016001c74ec0$4c06a620$e759a8c0@jposner> Kirby offered Euclid's Algorithm as an example of a recursive function: > def gcd(a,b): > if b: > return gcd(b, a % b) > return a This example *is* wondrous for demonstrating recursion, because it's so elegant and terse. But IMHO, these qualities make it less than ideal for *teaching* recursion. In particular, the terminal case is implied instead of defined: "if b == 0, then return a as the GCD of the original numbers". Here's an implementation that makes more pedagogical sense to me: def gcd(x,y): # terminal case: # smaller goes into larger evenly, or # smaller has been whittled down to 1 if x % y == 0 or y == 1: return y # recursive case: # smaller does not goes into larger evenly # GCD must go into the _remainder_ evenly else: return gcd(y, x % y) Sure, including the "y == 1" case as a separate test might be overdoing it a bit (but it does eliminate one recursion). Another problem (both with Kirby's implementation and mine) is that you "get lucky": if the user specifies the smaller number and the larger number in the "wrong" order, the algorithm magically swaps them for the next recursion. When tackling other recursion problems, students probably won't be able to count on such luck. -John From drake at lclark.edu Mon Feb 12 17:59:27 2007 From: drake at lclark.edu (Peter Drake) Date: Mon, 12 Feb 2007 08:59:27 -0800 Subject: [Edu-sig] Strange transitive import problem In-Reply-To: <200702091509.34867.john.zelle@wartburg.edu> References: <031AEDCA-3278-4EF5-8934-7D4CC9107C6B@lclark.edu> <200702091509.34867.john.zelle@wartburg.edu> Message-ID: <7B337970-3216-4975-868E-2ABD50FC3948@lclark.edu> I tried just tacking all of my procedural wrappers on to the end of your file so there would be no transitive import. Surprisingly, that didn't work. The trick you mention below DOES work, and I'll use that as a workaround. A clue, then: it's not the transitive importing that causes the problem, it's the importing of a file that calls GraphWin(). Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/ On Feb 9, 2007, at 1:09 PM, John Zelle wrote: > Peter, > > I should have caught this when you posted your file. There is a > bizarre import > interaction that I am aware of, but can't say that I fully understand > regarding my graphics library. It seems that Python imports are in > some-way, > somewhat atomic, and with the way my graphics library is set up > this can > produce this deadlock. I have a workaround for you. Move the > graphics setup > code in your module into a function: > > def initGraphics(): > global root > root = z.GraphWin() > > print "If you can't see the graphics window," > print "it's probably at the upper left" > print "of your screen, behind this one." > > Then call this function once at the start of your graphics > programs. This is > what will now pop up the window. So your "junk" program becomes: > > from graphics2 import * > print "imported graphics2" > initGraphics() > background("red") > > If someone has a better understanding of Python module imports and > why that > causes a problem with my graphics package, I'd love to know how to > fix this > problem rather than working around it. > > --John > > > On Friday 09 February 2007 1:36 pm, Peter Drake wrote: >> The graphics2.py file I supplied earlier (http://www.lclark.edu/ >> ~drake/courses/cs0/graphics2.py) is a procedural front-end for >> Zelle's graphics.py. >> >> If I run the graphics2.py module, everything works fine, and I can >> issue commands interactively. >> >> A problem happens if I write ANOTHER program, say junk.py: >> >> from graphics2 import * >> print "imported graphics2" >> background("red") >> >> When I run this (within IDLE), it hangs trying to import graphics2. >> There is no error message or processor load, it just hangs. >> >> Can anyone explain (or reproduce) this behavior? >> >> Peter Drake >> Assistant Professor of Computer Science >> Lewis & Clark College >> http://www.lclark.edu/~drake/ >> >> >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig at python.org >> http://mail.python.org/mailman/listinfo/edu-sig > > -- > John M. Zelle, Ph.D. Wartburg College > Professor of Computer Science Waverly, IA > john.zelle at wartburg.edu (319) 352-8360 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From holbert.13 at osu.edu Mon Feb 12 17:48:52 2007 From: holbert.13 at osu.edu (Richard Holbert) Date: Mon, 12 Feb 2007 11:48:52 -0500 Subject: [Edu-sig] understanding recursion In-Reply-To: <016001c74ec0$4c06a620$e759a8c0@jposner> References: <016001c74ec0$4c06a620$e759a8c0@jposner> Message-ID: <45D09A74.3010908@osu.edu> Here's another example of recursion: def is_a_palindrome(t): # check to see if t is a palindrome if (len(t) >= 2): return (t[0] == t[-1]) and is_a_palindrome(t[1:-1]) else: # t is either a single character, or empty string return True From kirby.urner at gmail.com Mon Feb 12 18:33:13 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 09:33:13 -0800 Subject: [Edu-sig] Populating the lesson plans database: Squeak -> Python In-Reply-To: <200702120756.l1C7uFs4030243@theraft.openend.se> References: <200702120756.l1C7uFs4030243@theraft.openend.se> Message-ID: On 2/11/07, Laura Creighton wrote: << snip >> > But again, the problem was that somebody had taught me that something > was _always true_ when the correct statement would be to say that > _this is how we speak of it in this particular language community, > but other communities do it differently_. > > So I'm a firm member of the 'give them as many languages as they > are willing to learn' crowd, at any age. > > my 0.10 euros, > Laura I like your answer Laura. You're in effect reminding students that we have many namespaces (a concept integral to Python), and the very same word *need not* mean the very same thing across namespaces. And thanks to dot notation, we have was to encapsulate and insulate, to counter name collisions. Something *like* dot notation, or dot notation itself, would be welcome in philosophy, is my position on wittgenstein-dialognet, precisely because philosophers are always saying things like "if you don't mean what *I* mean by 'gravity', why not call it 'shmavity' instead?" Computer science offers a more elegant solution. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/d2c7d328/attachment.htm From kirby.urner at gmail.com Mon Feb 12 19:59:49 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 10:59:49 -0800 Subject: [Edu-sig] understanding recursion In-Reply-To: <016001c74ec0$4c06a620$e759a8c0@jposner> References: <016001c74ec0$4c06a620$e759a8c0@jposner> Message-ID: > > > Another problem (both with Kirby's implementation and mine) is that you > "get > lucky": if the user specifies the smaller number and the larger number in > the "wrong" order, the algorithm magically swaps them for the next > recursion. When tackling other recursion problems, students probably won't > be able to count on such luck. > > -John Yes I agree that that's fun, about the automatic swapping. Also, it shouldn't escape note that *all* of these recursive solutions, from elegant to more transparent, seem harder to grok than the non-recursive version first given, which I credit to Guido. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/65cc7b6f/attachment.html From john.zelle at wartburg.edu Mon Feb 12 20:23:27 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Mon, 12 Feb 2007 13:23:27 -0600 Subject: [Edu-sig] Strange transitive import problem In-Reply-To: <7B337970-3216-4975-868E-2ABD50FC3948@lclark.edu> References: <031AEDCA-3278-4EF5-8934-7D4CC9107C6B@lclark.edu> <200702091509.34867.john.zelle@wartburg.edu> <7B337970-3216-4975-868E-2ABD50FC3948@lclark.edu> Message-ID: <200702121323.27229.john.zelle@wartburg.edu> Hi Peter, You have identified the crux of the matter. Basically what happens is that the import apparently locks the interpreter so that the graphics thread does not get a chance to run (import is atomic?). So any call into the graphics library (like creating a GraphWin) deadlocks, since the call cannot return until the thread runs, and the thread won't run until the import is complete. I could "fix" this by having my graphics package delay the thread launch until the first graphics call is made. But that means _every_ graphics operation will have to check to see if the thread has been launched yet. Even if that's not a big efficiency issue (I'm not sure), it feels too ad hoc to me, so I've resisted doing it. I may resort to that in the next release. By the way, I personally would pair the initGraphics() with a closeGraphics() operation that closes the window clean up at the end. --John On Monday 12 February 2007 10:59 am, Peter Drake wrote: > I tried just tacking all of my procedural wrappers on to the end of > your file so there would be no transitive import. Surprisingly, that > didn't work. The trick you mention below DOES work, and I'll use that > as a workaround. > > A clue, then: it's not the transitive importing that causes the > problem, it's the importing of a file that calls GraphWin(). > > Peter Drake > Assistant Professor of Computer Science > Lewis & Clark College > http://www.lclark.edu/~drake/ > > On Feb 9, 2007, at 1:09 PM, John Zelle wrote: > > Peter, > > > > I should have caught this when you posted your file. There is a > > bizarre import > > interaction that I am aware of, but can't say that I fully understand > > regarding my graphics library. It seems that Python imports are in > > some-way, > > somewhat atomic, and with the way my graphics library is set up > > this can > > produce this deadlock. I have a workaround for you. Move the > > graphics setup > > code in your module into a function: > > > > def initGraphics(): > > global root > > root = z.GraphWin() > > > > print "If you can't see the graphics window," > > print "it's probably at the upper left" > > print "of your screen, behind this one." > > > > Then call this function once at the start of your graphics > > programs. This is > > what will now pop up the window. So your "junk" program becomes: > > > > from graphics2 import * > > print "imported graphics2" > > initGraphics() > > background("red") > > > > If someone has a better understanding of Python module imports and > > why that > > causes a problem with my graphics package, I'd love to know how to > > fix this > > problem rather than working around it. > > > > --John > > > > On Friday 09 February 2007 1:36 pm, Peter Drake wrote: > >> The graphics2.py file I supplied earlier (http://www.lclark.edu/ > >> ~drake/courses/cs0/graphics2.py) is a procedural front-end for > >> Zelle's graphics.py. > >> > >> If I run the graphics2.py module, everything works fine, and I can > >> issue commands interactively. > >> > >> A problem happens if I write ANOTHER program, say junk.py: > >> > >> from graphics2 import * > >> print "imported graphics2" > >> background("red") > >> > >> When I run this (within IDLE), it hangs trying to import graphics2. > >> There is no error message or processor load, it just hangs. > >> > >> Can anyone explain (or reproduce) this behavior? > >> > >> Peter Drake > >> Assistant Professor of Computer Science > >> Lewis & Clark College > >> http://www.lclark.edu/~drake/ > >> > >> > >> > >> _______________________________________________ > >> Edu-sig mailing list > >> Edu-sig at python.org > >> http://mail.python.org/mailman/listinfo/edu-sig > > > > -- > > John M. Zelle, Ph.D. Wartburg College > > Professor of Computer Science Waverly, IA > > john.zelle at wartburg.edu (319) 352-8360 > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Mon Feb 12 21:28:53 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 12:28:53 -0800 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) Message-ID: Some of you old timers may recall a project in May, 2004 to implement Wolfram's minimalist cellular automaton experiments using a Tk canvas and/or PIL. As I recall, John showed us how to speed it up a whole lot by passing some 'False' parameter in the GraphWin call. However, now that I'm testing the code, in preparation for this post, lo these many years later (on a faster computer in a different version of Python (2.5)), and with a newly downloaded graphics.py, I'm seeing those rows of the Mayan Pyramid, associated with Wolfram's "Rule 30" [1], run across the screen like some raster beam on an ultra slow TV. http://mail.python.org/pipermail/edu-sig/2004-May/003866.html In any case, the code isn't all the beautiful, could be streamlined, but consists of nks.py atop two possible Canvas objects, one in Tk, one in PIL (Python's Imaging Library -- could be a jpeg). http://www.4dsolutions.net/ocn/python/nks.py <-- Wolfram's rules 0-255 (computed) http://www.4dsolutions.net/ocn/python/canvas1.py <- PIL canvas http://www.4dsolutions.net/ocn/python/canvas2.py <- Tk canvas Kirby PS: I haven't tested the PIL version for 2.5 yet, seein' as all the recent traffic has been about using Tk. PPS: this code isn't procedural though, may not be suitable for CS0 within the United States (a math phobic distopia, except in patches) [1] http://mathworld.wolfram.com/Rule30.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/45ffa58d/attachment-0001.html From rmalouf at mail.sdsu.edu Mon Feb 12 22:09:31 2007 From: rmalouf at mail.sdsu.edu (Rob Malouf) Date: Mon, 12 Feb 2007 13:09:31 -0800 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: References: Message-ID: On Feb 12, 2007, at 12:28 PM, kirby urner wrote: > PPS: this code isn't procedural though, may not be suitable for CS0 > within the United States (a math phobic distopia, except in patches) Yeah, Kirby, we get it. Can we move on now? I'll confess -- I teach Python, and I don't introduce object-oriented design until the second semester (and even then I leave it as an option). I have my reasons for doing it that way, and it's got nothing to do with concerns about math phobia. Got a problem with that? Given that you know nothing about my students, my teaching goals, or our overall curriculum, what makes you think you're entitled to an opinion about my syllabus? --- Rob Malouf Department of Linguistics and Asian/Middle Eastern Languages San Diego State University From kirby.urner at gmail.com Mon Feb 12 22:13:18 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 13:13:18 -0800 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: References: Message-ID: On 2/12/07, Rob Malouf wrote: > > On Feb 12, 2007, at 12:28 PM, kirby urner wrote: > > PPS: this code isn't procedural though, may not be suitable for CS0 > > within the United States (a math phobic distopia, except in patches) > > Yeah, Kirby, we get it. Can we move on now? No. I'm at liberty to stick some editorializing in a PPS now and then. The rest was straight CS with out of the box Python? What's your problem? A little defensive are we? I'll confess -- I teach Python, and I don't introduce object-oriented > design until the second semester (and even then I leave it as an > option). I have my reasons for doing it that way, and it's got > nothing to do with concerns about math phobia. Got a problem with > that? Given that you know nothing about my students, my teaching Yeah I do, I think it sucks. So? Got a problem with that? goals, or our overall curriculum, what makes you think you're > entitled to an opinion about my syllabus? I'm entitled to opinions about any syllabus under the sun, just as you are. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/a4732ad5/attachment.html From glingl at aon.at Mon Feb 12 23:29:54 2007 From: glingl at aon.at (Gregor Lingl) Date: Mon, 12 Feb 2007 23:29:54 +0100 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: References: Message-ID: <45D0EA62.4050901@aon.at> kirby urner schrieb: > > Some of you old timers may recall a project in May, 2004 to implement > Wolfram's minimalist cellular automaton experiments using a Tk canvas > and/or PIL. > > As I recall, John showed us how to speed it up a whole lot by passing > some 'False' parameter in the GraphWin call. > > However, now that I'm testing the code, in preparation for this post, lo > these many years later (on a faster computer in a different version of > Python (2.5)), and with a newly downloaded graphics.py, I'm seeing > those rows of the Mayan Pyramid, associated with Wolfram's "Rule 30" [1], > run across the screen like some raster beam on an ultra slow TV. Hi Kirby and all, I'm not sure if I'm adding something useful or intersting at all, because I'm currently following these threads only very superficially. I just wanted to demonstrate, that the use of a simple canvas3.py - which uses Tkinter directly - can also speed up your ultra slow TV considerably. See attachments. (nks2.py has only the import statement and the last line of the next() method added to nks.py. You can delete the last one if you don't want to watch the pyramid growing) Regards, Gregor Lingl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: canvas3.py Url: http://mail.python.org/pipermail/edu-sig/attachments/20070212/b890ea9a/attachment.pot -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nks2.py Url: http://mail.python.org/pipermail/edu-sig/attachments/20070212/b890ea9a/attachment.asc From kirby.urner at gmail.com Mon Feb 12 23:51:21 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 14:51:21 -0800 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: <45D0EA62.4050901@aon.at> References: <45D0EA62.4050901@aon.at> Message-ID: On 2/12/07, Gregor Lingl wrote: Hi Kirby and all, > I'm not sure if I'm adding something useful or intersting at all, > because I'm > currently following these threads only very superficially. I just wanted > to demonstrate, that the use of a simple canvas3.py - which uses Tkinter > directly - can also speed up your ultra slow TV considerably. Hey, that works great. I've uploaded canvas3.py with attribution and the newer version of nks.py, with a tie-back to this thread. I wonder how many intro level CS courses do anything with Wolframs NKS and/or cellular automata more generally. Is there a lot of Squeak stuff on this? Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/8f54a290/attachment.html From john.zelle at wartburg.edu Tue Feb 13 03:33:57 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Mon, 12 Feb 2007 20:33:57 -0600 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: References: Message-ID: <200702122033.57771.john.zelle@wartburg.edu> Kirby (and others), I've had a number of questions lately about the slowness of my graphics library. I've noticed that some programs run well under Linux (my development platform) but run very sluggishly under Windows. Was your testing on Windows? Just curious. If you do get a chance to try your code on both Linux and Windows, I'd like to know if you notice much difference. When I get some time (won't hapen until summer) I might have to dig in and try to address these performance issues on non-Linux platforms. If anyone has any thoughts on the source of this discrepancy, I'd love to hear them. --John On Monday 12 February 2007 2:28 pm, kirby urner wrote: > Some of you old timers may recall a project in May, 2004 to implement > Wolfram's minimalist cellular automaton experiments using a Tk canvas > and/or PIL. > > As I recall, John showed us how to speed it up a whole lot by passing > some 'False' parameter in the GraphWin call. > > However, now that I'm testing the code, in preparation for this post, lo > these many years later (on a faster computer in a different version of > Python (2.5)), and with a newly downloaded graphics.py, I'm seeing > those rows of the Mayan Pyramid, associated with Wolfram's "Rule 30" [1], > run across the screen like some raster beam on an ultra slow TV. > > http://mail.python.org/pipermail/edu-sig/2004-May/003866.html > > In any case, the code isn't all the beautiful, could be streamlined, but > consists of nks.py atop two possible Canvas objects, one in Tk, one > in PIL (Python's Imaging Library -- could be a jpeg). > > http://www.4dsolutions.net/ocn/python/nks.py <-- Wolfram's rules 0-255 > (computed) > http://www.4dsolutions.net/ocn/python/canvas1.py <- PIL canvas > http://www.4dsolutions.net/ocn/python/canvas2.py <- Tk canvas > > Kirby > > PS: I haven't tested the PIL version for 2.5 yet, seein' as all the recent > traffic has been about using Tk. > > PPS: this code isn't procedural though, may not be suitable for CS0 > within the United States (a math phobic distopia, except in patches) > > [1] http://mathworld.wolfram.com/Rule30.html -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Tue Feb 13 06:01:18 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 21:01:18 -0800 Subject: [Edu-sig] More on graphics with graphics.py (Zelle's) In-Reply-To: <200702122033.57771.john.zelle@wartburg.edu> References: <200702122033.57771.john.zelle@wartburg.edu> Message-ID: On 2/12/07, John Zelle wrote: > > Kirby (and others), > > I've had a number of questions lately about the slowness of my graphics > library. I've noticed that some programs run well under Linux (my > development > platform) but run very sluggishly under Windows. Was your testing on > Windows? Just curious. If you do get a chance to try your code on both > Linux > and Windows, I'd like to know if you notice much difference. When I get > some > time (won't hapen until summer) I might have to dig in and try to address > these performance issues on non-Linux platforms. If anyone has any > thoughts > on the source of this discrepancy, I'd love to hear them. > > --John Yeah, right on. I was using WinXP for the nks.py + canvas2.py + graphics.py test, and getting every Rectangle triggering a canvas update, thereby slowing the rasterization. I copied the same .py files to my Ubuntu box, and there's a delay, while the entire canvas is populated behind the scenes, and then the Mayan Pyramid pops up, already complete, just as it should. Gregor's straight Tk version in canvas3.py doesn't update per Rectangle on WinXP, when I comment out the canvas.update line per his notes. I tried for like an hour to figure out where the canvas refresh was occuring from your graphics.py and couldn't track it. Your __autoflush method looks good and I could detect no calls to Tk's root.update(). Appears to be a thorny problem. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/918aa60d/attachment.html From rmalouf at mail.sdsu.edu Tue Feb 13 06:31:09 2007 From: rmalouf at mail.sdsu.edu (Rob Malouf) Date: Mon, 12 Feb 2007 21:31:09 -0800 Subject: [Edu-sig] Python outside computer science Message-ID: <45D14D1D.7050501@mail.sdsu.edu> To turn things in a more constructive direction, let me start what I hope will be a new discussion... Most of what goes on on this list takes as a starting point that the primary goal is to teach Python programming, or programming in general, or computer science, or something in that vein. I'm sure there are a lot of people in my position, though, who use Python in teaching but aren't really teaching Python. I teach linguistics, and everything I cover in class is must serve the overall goal of educating linguists. Python is a useful tool, but that's all it is (for us), and it's just one of many tools we use. Given limited class time, I'm afraid that if I have to choose between either including something that will make my students better linguists or will make them better programmers, programming will lose. I guess you could say that in class we use Python like physical scientists use Matlab -- more as an application than as a programming language. Python is widely used in traditionally non-computational fields (linguistics, biology, geography), so I'm sure there's a sizeable community of people who use Python in this way. So, if any of you are out there... what have you found works well? What doesn't? What textbooks do you use (if any)? I find that most of the standard intro Python texts aren't suitable for me. Zelle's book, for instance, is great in a lot of respects, but it's got too much emphasis on graphics for me to use it. Not that that stuff isn't interesting and useful, it's just that it would be too much of a detour from my primary learning objectives. I've been using Gauld's book, but the student's don't seem enthusiastic about it. What books are the biologists using? Another thing I'm wondering about is how multi-course sequences are set up. Here at SDSU our computational linguistics M.A. program nominally takes four semesters, three semesters of coursework and one semester of thesis writing. We've got a lot of specialized material to cover in that time. Plus, students often come in with zero background in computation or math (or, often, linguistics), so we've got a fair bit of remedial work to do to get them up to speed. And, to make things even more complicated, non-specialists also take computational linguistics courses, so it's not unusual for me to have, say, a high school English teacher going for a multi-cultural education certificate in my one of my classes. In fact, I depend on that happening to meet my minimum enrollment numbers, which means I can't afford to drive off potential students who don't really want to spend a term learning to program (not that they're *afraid* of programming, just that that's not what they choose to spend 15 weeks of their life doing). So, given the constraints, the way we've structured things involves very little time devoted purely to teaching Python or programming. I spend maybe a third of a term on Python in the first semester in a course that covers a lot of other computational tools and methods. Then throughout the more advanced courses we sneak in Python concepts here and there, as needed to address problems that come up, so by the end of two years the hope is students will have absorbed enough programming knowledge for them to get a job. Of course, the alternative is just to take a semester out at the beginning and devote it to teaching Python, before we move on to the linguistics. We could possibly join forces with other Pythonic departments on campus to solve the minimum enrollment problems, though that mean some of the more advanced material would have to be cut from the end of the sequence to make it fit in three semesters. How do other non-CS computational programs work? What are some of your experiences? --- Rob Malouf Department of Linguistics and Asian/Middle Eastern Languages San Diego State University From suri2119 at yahoo.com Tue Feb 13 07:06:26 2007 From: suri2119 at yahoo.com (surafel teshome) Date: Mon, 12 Feb 2007 22:06:26 -0800 (PST) Subject: [Edu-sig] Edu-sig Digest, Vol 43, Issue 20 In-Reply-To: Message-ID: <250912.48843.qm@web51902.mail.yahoo.com> thanks a lot for your lecture. ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front From kirby.urner at gmail.com Tue Feb 13 07:46:27 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 12 Feb 2007 22:46:27 -0800 Subject: [Edu-sig] Python outside computer science In-Reply-To: <45D14D1D.7050501@mail.sdsu.edu> References: <45D14D1D.7050501@mail.sdsu.edu> Message-ID: On 2/12/07, Rob Malouf wrote: > > To turn things in a more constructive direction, let me start what I > hope will be a new discussion... If I might be permitted to riff off your queries re our snake and computational linguistics, I want to mention that Jason Cunliffe and I, both contributors to this list, plus we met in New York that time, were (still are?) enamoured of 'Who Is Fourier?' by the LEX Institute, a language teaching academy, with an interesting philosophy we needn't go into too much in this post. Flash forward: have you seen O'Reilly's 'Head First' series and its use of icons, sidebars, jokes, diagrams, different type faces, more icons? Way more "right brained" than traditional CS books, by a long shot, but just as technical and deep (into Java mostly). We've asked Tim about a "Head First" about Python, but the word back, at least then, was we had too small a footprint as a nation (he has these publisher maps he projects at OSCON) to merit such a sophisticated and expensive undertaking. We all still dream of it though. LEX Institute treats mathematics *as a language* and the "story" of this book is language students wanting to analyze the relative frequencies of certain vowel sounds in spoken Japanese, and needing to gather this information directly from sound waves if possible. That led them to Fourier Analysis and a need to teach themselves about it, using human language learning principles, applied to learning maths. In my view, using visuals, including screencasts (OK, so we're getting beyond print media here), we should be able to communicate the gist of Python's *grammar* in mere minutes, with no threat of a follow-up test if such content is non-germane to the course. Maybe a future Ubuntu distro will simply include some of these Python teaching clips on the DVD? Makes sense to me. *We* will make the OO paradigm seem easy, using trivial-to-get cartoons. To me, that's a kind of a minimalist way of explaining the "everything is an object" slogan, a way to get a sense of Python's "algebra" (its design). I have no problem with students not "majoring" in Python, or any computer language. But skating through these grammar sections could be fun, engaging, non-threatening, and take only minutes. For example, my 'classes and subclasses' clip, only 6 minutes 41 seconds, in my Python for Math Teachers series (a collection of roughly 10 clips so far). Such clips by others could be projected to a computational linguistics class for like a total of 20 minutes one random day, as a token nod, if nothing else, to one of many languages you're looking at and computing with (Python). Show 'Warriors of the Net' as well while you're at it (??) to make sure your students know the basics of TCP/IP? Even those who live and breath it, probably won't mind an 8 minute cartoon on TCP/IP (OK, maybe it's 15, I forget). It's a language that computes too, no? Not properly a topic? Kirby Book highlighted: Who Is Fourier?: http://www.amazon.com/Who-Fourier-Transnational-College-Tokyo/dp/0964350408 Jason waxing eloquent thereon: http://mail.python.org/pipermail/edu-sig/2001-October/001788.html LEX Institute: http://www.lexhippo.gr.jp/english/organization/index.html References in my Blogs: Python for Math Teachers: http://controlroom.blogspot.com/2007/01/python-for-math-teachers.html Brainstorming about Pedagogy: http://worldgame.blogspot.com/2005/01/brainstorming-about-pedagogy.html TCP/IP: http://controlroom.blogspot.com/2006/06/tcpip-for-gnubees.html Background Reading: Computational Linguistics: http://en.wikipedia.org/wiki/Computational_linguistics -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070212/148c70a4/attachment.html From lac at openend.se Tue Feb 13 09:33:11 2007 From: lac at openend.se (Laura Creighton) Date: Tue, 13 Feb 2007 09:33:11 +0100 Subject: [Edu-sig] Python outside computer science In-Reply-To: Message from Rob Malouf of "Mon, 12 Feb 2007 21:31:09 PST." <45D14D1D.7050501@mail.sdsu.edu> References: <45D14D1D.7050501@mail.sdsu.edu> Message-ID: <200702130833.l1D8XBBB014331@theraft.openend.se> In a message of Mon, 12 Feb 2007 21:31:09 PST, Rob Malouf writes: >To turn things in a more constructive direction, let me start what I >hope will be a new discussion... >[...] What books are the biologists using? Andrew Dalke has been writing his own course materials for teaching python to biologists and biochemists in South Africa (and maybe other places too, I forget about that.) He is dalke at dalkescientific.com and would probably send you all his stuff if you asked him nicely. We sat up at my house one night trying to figure out what would be the best way to introduce python and ended up with 'string processing' -- or language processing in general. So 'check to see if your name is in a file --- to check the long form of your name. What if the first and last name are on different lines of the file? -- What if your name is misspelled? things like that to make the lessons grow harder. Then you move to extracting useful things from web pages. Relevant things like: 'Have the tickets for the Bruce Springsteen concert gone on sale yet?' :-) Then you get to 'here is a string that represents a protein' -- and so on to a problem domain that the students are familiar with. This, by the way, is for the students that don't know how to program. When Andrew is dealing with people who already do 'how to set up a turbo gears sever' and how to integrate 'this mess we have over here' with 'that mess some other folks have over there' is standard. And I am doing all of this from memory, and my memory of him telling me how it went, rather than having been there myself, so I probably have some of the details wrong. Drop him a line; he's very friendly. Laura From peter at mapledesign.co.uk Tue Feb 13 11:26:36 2007 From: peter at mapledesign.co.uk (Peter Bowyer) Date: Tue, 13 Feb 2007 10:26:36 +0000 Subject: [Edu-sig] Python outside computer science In-Reply-To: References: <45D14D1D.7050501@mail.sdsu.edu> Message-ID: <20070213102646.DDDC31E400E@bag.python.org> At 06:46 13/02/2007, kirby urner wrote: >Flash forward: have you seen O'Reilly's 'Head First' series and >its use of icons, sidebars, jokes, diagrams, different type faces, >more icons? Way more "right brained" than traditional CS books, >by a long shot, but just as technical and deep (into Java mostly). >We've asked Tim about a "Head First" about Python, but the >word back, at least then, was we had too small a footprint as >a nation (he has these publisher maps he projects at OSCON) >to merit such a sophisticated and expensive undertaking. We >all still dream of it though. Is there anything to stop us/someone copying this style of book, and producing one for Python? Peter -- Maple Design - Web design and application development http://www.mapledesign.co.uk +44 (0)845 123 8008 From delza at livingcode.org Tue Feb 13 14:59:02 2007 From: delza at livingcode.org (Dethe Elza) Date: Tue, 13 Feb 2007 05:59:02 -0800 Subject: [Edu-sig] Python outside computer science In-Reply-To: <200702130833.l1D8XBBB014331@theraft.openend.se> References: <45D14D1D.7050501@mail.sdsu.edu> <200702130833.l1D8XBBB014331@theraft.openend.se> Message-ID: On 13-Feb-07, at 12:33 AM, Laura Creighton wrote: > We sat up at my house one night trying to figure out what would be > the best way to introduce python and ended up with 'string > processing' -- > or language processing in general. Apropos of this, there is David Mertz' Text Processing in Python, which has a nice introductory chapter (at the back) and covers a lot of ground. Downsides: I think it covers Python 2.3, so it is getting a bit dated now, it doesn't cover explicitly linguistics-oriented libraries such as WordNet or the Natural Language Toolkit. Upsides: Available in physical form or for free via the web[1]. Articles covering WordNet[2] (Stephen Figgins) and Natural Language Toolkit[3] (Mertz again) can be used to supplement. [1] http://gnosis.cx/TPiP/ [2] http://www.onlamp.com/pub/a/python/2000/11/15/pythonnews.html [3] http://www-128.ibm.com/developerworks/linux/library/l-cpnltk.html I hope that helps. Thanks, Rob for starting this thread. It's good to hear that Python is being used so widely (part of the point of Python is to get out of your way and let you focus on what you're *really* interested in, rather than having to learn Computer Science first). I'll be interested in hearing any success (or other) stories. --Dethe Things fall apart. The Centre cannot hold. -- W. B. Yeats From kirby.urner at gmail.com Tue Feb 13 18:51:17 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 13 Feb 2007 09:51:17 -0800 Subject: [Edu-sig] Python outside computer science In-Reply-To: <45d19263.5b9b705d.4f5a.ffffebb4SMTPIN_ADDED@mx.google.com> References: <45D14D1D.7050501@mail.sdsu.edu> <45d19263.5b9b705d.4f5a.ffffebb4SMTPIN_ADDED@mx.google.com> Message-ID: On 2/13/07, Peter Bowyer wrote: > > At 06:46 13/02/2007, kirby urner wrote: > >Flash forward: have you seen O'Reilly's 'Head First' series and > >its use of icons, sidebars, jokes, diagrams, different type faces, > >more icons? Way more "right brained" than traditional CS books, > >by a long shot, but just as technical and deep (into Java mostly). > >We've asked Tim about a "Head First" about Python, but the > >word back, at least then, was we had too small a footprint as > >a nation (he has these publisher maps he projects at OSCON) > >to merit such a sophisticated and expensive undertaking. We > >all still dream of it though. > > Is there anything to stop us/someone copying this style of book, and > producing one for Python? > > Peter No nothing, and I think 'Head First' is a trend setter. But of course we of the OSCON tribe would feel glad if the O'Reilly name were on the cover, means we still matter on maps that we care about. A cheap rip off wouldn't feel so good. Not that those are the only two alternatives. Multimedia publishing is no one's monopoly, and many publishers besides O'Reilly already have promising track records with Pythonic titles (though I don't really like the ones that overpad with the very same XML poopka, regardless of language, just to thicken the books, make 'em appear meaty. 'Python in a Nutshell' is at the other end of the spectrum, somewhat thick, but spare, lean and clean. It's not a teaching text though, so much as a reference). Myself, I'm focusing on the anime we want around Python, like a cartoon snake slithering into view showing off __rib__ syntax, going in to split screen views with source code in a stepper, coupled with animal behavior in some 4D++ environment (e.g. Panda 3D). On the one hand, source code, on the other hand, Sims. What we'll be sharing with adults, not just children, under the CP4E banner. To this end, I've voluntarily sunk a lot of my after tax time and energy into startup think tanks, such as Wanderers and the Portland Knowledge Lab (the latter named after a London version I visited last April, stole the idea from (hi Phillip)). Another thread we've shared here on edu-sig is around "rich data structures." I don't know how much need you'd have for 100 nouns and/or verbs in a lookup table, columns being the different human languages, but I'd think there'd be similar wheels you'd not want to have to reinvent, over and over. Do you use any SQL? College professors, banding together on open source principles (already deeply engrained in the culture, as scholarship ethics), oughta be able to divvy the labor and build up a relevant stash of Pythonic data sets pronto, in whatever the science and/or humanity. Just having the planets, with their distances from the Sun, relative radii, in a freely downloadable Python dictionary of tuples say, would be a boon to middle schools across the land. That data could be bundled with such as my orbits.py, to generate VPython animations. http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/orbits.py A final relevant thread I can think of, is 'suMerian', a mnemonic for how the antiquities have made it still cool to learn so-called "dead languages" (a basis for promotion). Computer science is a relatively new discipline, compared to teaching ancient Greek or Latin or whatever, but has this emerging challenge of either needing to groom future generations of so-called "dead language" programmers, OR try to tell industry why it should pay to have perfectly good source code rewritten, simply because no one teaches M any more (hence the capital M in 'suMerian'). Put another way, there's still a market for FORTRAN coders, even FORTRAN compiler optimizers. I've schmoozed with such people at OSCON, know they exist in the flesh. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070213/f7678921/attachment.htm From mtobis at gmail.com Thu Feb 15 02:29:39 2007 From: mtobis at gmail.com (Michael Tobis) Date: Wed, 14 Feb 2007 19:29:39 -0600 Subject: [Edu-sig] Python outside computer science In-Reply-To: <45D14D1D.7050501@mail.sdsu.edu> References: <45D14D1D.7050501@mail.sdsu.edu> Message-ID: Ray Pierrehumbert is using Python to teach undergraduate courses in atmospheric science (a survey of climate physics) at the University of Chicago, and is writing a book based on it. Ray tells me his publisher did not allow any Python in the text, so he had to write pseudocode in the text, but Python packages implementing everything he suggests will be included as a download. I suppose pseduocode means leaving out the colons... Anyway, in answer to your specific question, Ray devotes a few lectures to Python near the beginning of the term and that's it. It may be the case that University of Chicago science undergrads are better prepared than others, and the problems they examine probably use relatively simple data structures and algorithms. (There's no call for recursion, for instance.) I've filled in for Ray on the Python lectures sometimes. Two years ago about half the students had never written any code in any language, but this year only two of them had never written any code. I'm not sure if this helps you very much, except to reaffirm that Python is useful in studying other disciplines with an algorithmic component. It's pretty much being used in this case as a direct replacement for Matlab. mt On 2/12/07, Rob Malouf wrote: > > To turn things in a more constructive direction, let me start what I > hope will be a new discussion... > > Most of what goes on on this list takes as a starting point that the > primary goal is to teach Python programming, or programming in general, > or computer science, or something in that vein. I'm sure there are a > lot of people in my position, though, who use Python in teaching but > aren't really teaching Python. I teach linguistics, and everything I > cover in class is must serve the overall goal of educating linguists. > Python is a useful tool, but that's all it is (for us), and it's just > one of many tools we use. Given limited class time, I'm afraid that if > I have to choose between either including something that will make my > students better linguists or will make them better programmers, > programming will lose. > > I guess you could say that in class we use Python like physical > scientists use Matlab -- more as an application than as a programming > language. Python is widely used in traditionally non-computational > fields (linguistics, biology, geography), so I'm sure there's a sizeable > community of people who use Python in this way. So, if any of you are > out there... what have you found works well? What doesn't? What > textbooks do you use (if any)? I find that most of the standard intro > Python texts aren't suitable for me. Zelle's book, for instance, is > great in a lot of respects, but it's got too much emphasis on graphics > for me to use it. Not that that stuff isn't interesting and useful, > it's just that it would be too much of a detour from my primary learning > objectives. I've been using Gauld's book, but the student's don't seem > enthusiastic about it. What books are the biologists using? > > Another thing I'm wondering about is how multi-course sequences are set > up. Here at SDSU our computational linguistics M.A. program nominally > takes four semesters, three semesters of coursework and one semester of > thesis writing. We've got a lot of specialized material to cover in > that time. Plus, students often come in with zero background in > computation or math (or, often, linguistics), so we've got a fair bit of > remedial work to do to get them up to speed. And, to make things even > more complicated, non-specialists also take computational linguistics > courses, so it's not unusual for me to have, say, a high school English > teacher going for a multi-cultural education certificate in my one of my > classes. In fact, I depend on that happening to meet my minimum > enrollment numbers, which means I can't afford to drive off potential > students who don't really want to spend a term learning to program (not > that they're *afraid* of programming, just that that's not what they > choose to spend 15 weeks of their life doing). > > So, given the constraints, the way we've structured things involves very > little time devoted purely to teaching Python or programming. I spend > maybe a third of a term on Python in the first semester in a course that > covers a lot of other computational tools and methods. Then throughout > the more advanced courses we sneak in Python concepts here and there, as > needed to address problems that come up, so by the end of two years the > hope is students will have absorbed enough programming knowledge for > them to get a job. Of course, the alternative is just to take a > semester out at the beginning and devote it to teaching Python, before > we move on to the linguistics. We could possibly join forces with other > Pythonic departments on campus to solve the minimum enrollment problems, > though that mean some of the more advanced material would have to be cut > from the end of the sequence to make it fit in three semesters. How do > other non-CS computational programs work? What are some of your > experiences? > > --- > Rob Malouf > Department of Linguistics and Asian/Middle Eastern Languages > San Diego State University > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070214/b69bbe54/attachment.htm From igor at tamarapatino.org Thu Feb 15 03:51:09 2007 From: igor at tamarapatino.org (Igor TAmara) Date: Wed, 14 Feb 2007 21:51:09 -0500 Subject: [Edu-sig] Translation of video "Introducing python" to spanish Message-ID: Spanish version of message at the bottom - Versi?n en espa?ol al final Hi, this is to let you know that the translation[1] of the "Introducing python" video has just been reviewed, it was done by the students[2] of Gimnasio Fidel Cano[3](High School) located at Bogot?, we hope it can be useful for spanish-speaking people. 1.https://www.gfc.edu.co/traduccion/TradVideoPython/Complete 2 .https://www.gfc.edu.co/traduccion/AsignacionTranscripcionyTraduccionVideoModalidadOnce 3.http://www.gfc.edu.co/ We started using python three years ago and are really happy about using it, because the students can focus more on solving and creating than bothered with compiling and understanding of things that usually distract them and don't let them see quick results. The students have published some work done using wxwindows and zope[4],[5],[6] 4.http://www.gfc.edu.co/colegio/proyectos/spt/2004/index.php 5.http://www.gfc.edu.co/colegio/proyectos/spt/2005/index.php 6.http://www.gfc.edu.co/colegio/proyectos/spt/2006/index.php We do know that putting the subtitles to the video is another task and we don't know if there is libre software available out there to do that on linux Debian, the operating system we use. Greetings... --------------------------------- Hola, hemos publicado una traducci?n[1] del video "Introducing python" revisada, fue hecha por estudiantes[2] del Gimnasio Fidel Cano[3] en Bogot?, esperamos que pueda ser de utilidad para los hispanoparlantes. 1.https://www.gfc.edu.co/traduccion/TradVideoPython/Complete 2 .https://www.gfc.edu.co/traduccion/AsignacionTranscripcionyTraduccionVideoModalidadOnce 3.http://www.gfc.edu.co/ Comenzamos a usar python hace 3 a?os y estamos muy contentos con ?l, porque los estudiantes pueden enfocarse en resolver y crear en lugar de molestarse con procesos de compilaci?n o entender cosas que usualmente los distraen y no les permiten ver resultados r?pidos. Los estudiantes han publicado algunos trabajos hechos con ayuda de librer?a wxwindows y zope. 4.http://www.gfc.edu.co/colegio/proyectos/spt/2004/index.php 5.http://www.gfc.edu.co/colegio/proyectos/spt/2005/index.php 6.http://www.gfc.edu.co/colegio/proyectos/spt/2006/index.php Sabemos que colocar subt?tulos al video es otra tarea y no sabemos si hay software libre para hacerlo en linux(Debian) el sistema operativo que utilizamos. Saludos... -- --- http://igor.tamarapatino.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070214/b7cc7585/attachment.html From kirby.urner at gmail.com Thu Feb 15 20:38:12 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 15 Feb 2007 11:38:12 -0800 Subject: [Edu-sig] design pattern with data Message-ID: In the source code below, almost all that's special about subclasses is their respective data, which are initialized from globals. Both the constructor and self representer (a VPython draw, not a __repr__ in this case) are inherited from a Tetrahedron superclass. http://www.4dsolutions.net/ocn/python/quantamods.py How might this be useful in a math learning context? There's a quickie conversion going on, twixt two coordinate systems, with one vector's .xyz attribute an argument to the next vector's initializer. That'd be one thing to focus on (object translation). Caveats: I'm using arguments provided by a collaborator. Although I've got a lot of faith in 'em, I'm just taking 'em as given (assumed true). The output is visual (VPython) and to my eye the results were quite believable. However, in pure Chakovians, with (1,0,0,0)(0,1,0,0)(0,0,1,0) and (0,0,0,1) as my four vertices, I'd be sorely tempted to anchor my A modules (+/-) as at least two of those 24. On the other hand, I'm also quite focused on the Coupler as 8 MITEs meeting at the origin (0,0,0,0) with As and Bs permuting accordingly (lots of ways to go). Sorry about all the jargon, for those not trained in slogging through this namespace. I call it "gnu math" and teach it with Python. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070215/726989ca/attachment.htm From kirby.urner at gmail.com Fri Feb 16 20:06:38 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 16 Feb 2007 11:06:38 -0800 Subject: [Edu-sig] More Pipeline News Message-ID: Appended: a cut 'n paste from Math Forum, fixing one typo. Posted here cuz of the reference to South Africa, home of kusasa.org and the Shuttleworth pipeline (Logo -> Squeak -> Python). On the Logo -> Squeak front, I'm seeing a lot of activity in robotics, making a Squeak front end for controlling robodogs, other kid friendly cuties, e.g.: http://www.bioloid.info/tiki/tiki-index.php?page=MicroRaptor That's good, cuz the Logo and GvR type IDEs, involving controlling an avatar, need to blend towards Immersion Phase (Squeak, Sims, ActiveWorlds...). In the meantime, the Kay Group is thinking to reinvent the wheel and implement the whole show in like just 20K lines of code, intended for pedagogical purposes (not just pie in the sky). http://irbseminars.intel-research.net/AlanKayNSF.pdf More power to 'em, though of course OLPC isn't waiting for that project to finish (I doubt Kay would want it to -- kids need Net access today -- tomorrow is not soon enough). And besides, we already have Python. Kirby Onward: ========== > Part two: how are they going to do it? Can you > you give us a hint as to how the choices will be > presented, under your scenario, and how the children > will choose? > > Haim > Je me souviens Just to butt in, but why not use the present tense? Why all this future tense nonsense? MPG was saying the Net is one promising way we're offering choice (remember choice?), and I'm agreeing, saying our students are choosing even now, even today, to read this and not that, to study this and not that (life is short and you've got to prioritize). Take, for example, the Freedom Toasters now spread across 16 cities in South Africa: brightly colored kiosks where you stick in your blank DVD or CD and then choose from a menu what to burn (LinuxUser & Developer #68, pg. 61). There's choice involved, especially if you just have the one blank CD (can't just grab everything). The canard I'm tired of hearing is that we have to wait for some big wheels to turn, in New York or Detroit or someplace, before choice becomes a reality. At least in *some* regions of the country, we *already* have choice and yes, kids are doing much of the choosing. http://mathforum.org/kb/thread.jspa?threadID=1534429&tstart=15 Kirby From kirby.urner at gmail.com Mon Feb 19 02:26:10 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 18 Feb 2007 17:26:10 -0800 Subject: [Edu-sig] Opencourseware: Perfect Numbers with Generators Message-ID: Author: Kirby Urner Subjects: CS0, Pythonic Mathematics, Python for Math Teachers Originating Academy: Saturday Academy (saturdayacademy.org) Originating Course: Pythonic Mathematics: from Fibonaccis to Fractals Major Reference: http://www.4dsolutions.net/ocn/perfectnumbers.html """ Sequence generator expressions Usage (one of many): >>> from euclidix36 import mersennes, perfects >>> perfects.next() 6 >>> perfects.next() 28 >>> perfects.next() 496 >>> perfects.next() 8128 >>> perfects.next() 33550336 >>> mersennes.next() 131071 >>> mersennes.next() 524287 >>> mersennes.next() 2147483647L """ # http://www.research.att.com/~njas/sequences/A000043 mersennep = [2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203, 2281, 3217, 4253, 4423, 9689, 9941, 11213, 19937, 21701, 23209, 44497, 86243, 110503, 132049, 216091, 756839, 859433, 1257787, 1398269, 2976221, 3021377, 6972593, 13466917] # ... # http://www.research.att.com/~njas/sequences/A000668 mersennes = (pow(2,p) - 1 for p in mersennep ) # http://www.research.att.com/~njas/sequences/A000396 perfects = (m*(m+1)//2 for m in mersennes) """ For discussion: Explain why mersennes.next() doesn't return the first Mersenne prime, when used after three invocations of the perfects generator expression (see Usage above). Answer: because the perfects generator expression has already advanced the mersennes generator. Is the converse of Euclid's IX:36 true, i.e. if a number is perfect, then is it necessarily some Mth triangular number, where M is a Mersenne prime? Answer: only if the perfect number is even. It's not yet known if any perfects are odd: http://primes.utm.edu/mersenne/index.html http://mathworld.wolfram.com/OddPerfectNumber.html """ From tom.hoffman at gmail.com Mon Feb 19 07:31:44 2007 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Mon, 19 Feb 2007 01:31:44 -0500 Subject: [Edu-sig] Python Bridge for Breve Message-ID: <92de6c880702182231u3471e422jc98689db504b26e7@mail.gmail.com> While trying to learn how to use the Breve templating language, I noticed that you can now use Python code in the Breve 3-d simulation environment, which I'd found to be attractive and impressive on my Mac a few years ago, but doesn't want to work on my laptop running Ubuntu today. see http://www.spiderland.org/node/3246 --Tom From mtobis at gmail.com Mon Feb 19 20:58:52 2007 From: mtobis at gmail.com (Michael Tobis) Date: Mon, 19 Feb 2007 13:58:52 -0600 Subject: [Edu-sig] edu-dinner Message-ID: I just talked to the Marriott; they are perfectly OK doing room service into the Preston Trail II room. One of us staying at the hotel can collect cash from all interested and put it on a credit card. I am willing to do this. So I suggest we combine dinner and our meeting in the Preston Room Saturday Night They are also sending me a banquet menu and I'll look into it, but I think it would be easier with room service for everyone to get what they want. Any objections? If not please consider this a plan. See you Saturday 7 PM! Michael Tobis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070219/7c444931/attachment.htm From jeff at elkner.net Mon Feb 19 21:19:41 2007 From: jeff at elkner.net (Jeffrey Elkner) Date: Mon, 19 Feb 2007 20:19:41 +0000 Subject: [Edu-sig] [edupython] edu-dinner In-Reply-To: Message-ID: <20070219201941.25807.1872458375.divmod.quotient.27487@ohm> I added the time (7 pm) and a sign-up list for the dinner on the PyEdu wiki page: http://us.pycon.org/TX2007/PyEdu jeff elkner On Mon, 19 Feb 2007 13:58:52 -0600, Michael Tobis wrote: >I just talked to the Marriott; they are perfectly OK doing room service into >the Preston Trail II room. One of us staying at the hotel can collect cash >from all interested and put it on a credit card. I am willing to do this. > >So I suggest we combine dinner and our meeting in the Preston Room Saturday >Night > >They are also sending me a banquet menu and I'll look into it, but I think >it would be easier with room service for everyone to get what they want. > >Any objections? If not please consider this a plan. See you Saturday 7 PM! > >Michael Tobis From drake at lclark.edu Mon Feb 19 21:13:11 2007 From: drake at lclark.edu (Peter Drake) Date: Mon, 19 Feb 2007 12:13:11 -0800 Subject: [Edu-sig] Problem with mouse clicks Message-ID: <95C45848-7DC1-4F2F-97FA-B948D8AC0F5D@lclark.edu> I just had my students write this program in my CS0 class: from graphics import * graphics() while 0 < 1: click = mouse() x = click[0] y = click[1] oval([x-10, y-10], [x+10, y+10]) (Note that graphics is Zelle's version with my procedural wrappers appended, http://www.lclark.edu/~drake/courses/cs0/graphics.py) Usually (but, frustratingly, not every run), the mouse clicks are offset, so the circles appear some distance above and to the left of where they should. Has anyone else run into this? Is there an explanation or workaround? Peter Drake http://www.lclark.edu/~drake/ From ianb at colorstudy.com Tue Feb 20 00:30:18 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 19 Feb 2007 17:30:18 -0600 Subject: [Edu-sig] edu-dinner In-Reply-To: References: Message-ID: <45DA330A.8080700@colorstudy.com> Michael Tobis wrote: > I just talked to the Marriott; they are perfectly OK doing room service > into the Preston Trail II room. One of us staying at the hotel can > collect cash from all interested and put it on a credit card. I am > willing to do this. > > So I suggest we combine dinner and our meeting in the Preston Room > Saturday Night > > They are also sending me a banquet menu and I'll look into it, but I > think it would be easier with room service for everyone to get what they > want. Room service seems expensive. Last year they were really relaxed about using the space (e.g., people brought in some six packs and hung out until after midnight). Maybe we could get delivery from someplace local? (If so, maybe we can get a recommendation from someone in the area.) -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From jeff at taupro.com Tue Feb 20 04:24:10 2007 From: jeff at taupro.com (Jeff Rush) Date: Mon, 19 Feb 2007 21:24:10 -0600 Subject: [Edu-sig] edu-dinner In-Reply-To: <45DA330A.8080700@colorstudy.com> References: <45DA330A.8080700@colorstudy.com> Message-ID: <45DA69DA.7030709@taupro.com> Ian Bicking wrote: > Michael Tobis wrote: >> I just talked to the Marriott; they are perfectly OK doing room service >> into the Preston Trail II room. One of us staying at the hotel can >> collect cash from all interested and put it on a credit card. I am >> willing to do this. >> >> So I suggest we combine dinner and our meeting in the Preston Room >> Saturday Night >> >> They are also sending me a banquet menu and I'll look into it, but I >> think it would be easier with room service for everyone to get what they >> want. > > Room service seems expensive. Last year they were really relaxed about > using the space (e.g., people brought in some six packs and hung out > until after midnight). Maybe we could get delivery from someplace > local? (If so, maybe we can get a recommendation from someone in the area.) You can find the hotel's bar (subset of restaurant) menu (last year's prices) at: http://us.pycon.org/Addison/HotelFood-Bar There will be a 8.25% sales tax and a 22% service charge, I'm pretty sure. The hotel insists on doing all the catering themselves. But if people want to get take-out and bring it back, we expect that might be fine. There is also a cool restaurant down the street from the hotel, called the Magic Time Machine. http://magictimemachine.com/ Their menu is online and they can take reservations, but you'll need an accurate headcount, which is a problem with BoFs. Having the hotel cater is definitely the less work approach albeit more expensive. Also having it in the hotel means you can listen to edu talks while eating - not possible in a restaurant. I wonder what would happen if individually people went to the bar, ordered their food to go and showed up in Preston Trail to eat it. -Jeff From ianb at colorstudy.com Tue Feb 20 05:57:33 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 19 Feb 2007 22:57:33 -0600 Subject: [Edu-sig] edu-dinner In-Reply-To: <45DA69DA.7030709@taupro.com> References: <45DA330A.8080700@colorstudy.com> <45DA69DA.7030709@taupro.com> Message-ID: <45DA7FBD.5030303@colorstudy.com> Jeff Rush wrote: > Ian Bicking wrote: >> Michael Tobis wrote: >>> I just talked to the Marriott; they are perfectly OK doing room >>> service into the Preston Trail II room. One of us staying at the >>> hotel can collect cash from all interested and put it on a credit >>> card. I am willing to do this. >>> >>> So I suggest we combine dinner and our meeting in the Preston Room >>> Saturday Night >>> >>> They are also sending me a banquet menu and I'll look into it, but I >>> think it would be easier with room service for everyone to get what >>> they want. >> >> Room service seems expensive. Last year they were really relaxed >> about using the space (e.g., people brought in some six packs and hung >> out until after midnight). Maybe we could get delivery from someplace >> local? (If so, maybe we can get a recommendation from someone in the >> area.) > > You can find the hotel's bar (subset of restaurant) menu (last year's > prices) at: > > http://us.pycon.org/Addison/HotelFood-Bar > > There will be a 8.25% sales tax and a 22% service charge, I'm pretty sure. Those prices aren't too bad. > The hotel insists on doing all the catering themselves. But if people > want to get take-out and bring it back, we expect that might be fine. Yeah; it wouldn't be the conference organizing any of it, just some individuals. I think people got pizza delivered last year, if I remember correctly. There's nothing to cater really -- this isn't a formal event with a head count or anything. > There is also a cool restaurant down the street from the hotel, called > the Magic Time Machine. > > http://magictimemachine.com/ > > Their menu is online and they can take reservations, but you'll need an > accurate headcount, which is a problem with BoFs. Having the hotel > cater is definitely the less work approach albeit more expensive. Also > having it in the hotel means you can listen to edu talks while eating - > not possible in a restaurant. I would like having it at the hotel. > I wonder what would happen if individually people went to the bar, > ordered their food to go and showed up in Preston Trail to eat it. Would they mind us carrying plates around? I don't know. Probably if we told them where we were taking them they wouldn't care too much. But if we can organize takeout or delivery that would be great. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From mpaul at bhusd.k12.ca.us Tue Feb 20 06:19:25 2007 From: mpaul at bhusd.k12.ca.us (Michel Paul) Date: Mon, 19 Feb 2007 21:19:25 -0800 Subject: [Edu-sig] understanding recursion Message-ID: <3D142BFDEDAC8D46A40F4EA0B36D1F351D700C@MAIL.bhusd.k12.ca.us> I'd like to share an idea that occurred to me awhile back. It's a problem one can pose prior to discussing any specific programming language. Given two black-box functions prev(n) and next(n), along with conditional reasoning and the typical math comparison operators, define arithmetic. So for example, visualizing the translation of a segment [a, b] on a number line, we could define difference(a, b) in this way: difference(a, b): if b = 0 ---> a if b > 0 ---> difference(prev(a), prev(b)) if b < 0 ---> difference(next(a), next(b)) Or, we could make the base case: if a = b ---> 0 (if a and b are equal, then there is no difference) and get a slightly different definition. Understand that this was a pseudo-code style I was using prior to having seen Python. Imagine my joy when I then found Python! The important thing in these exercises is that we can't use our typical arithmetic operators of +, -, *, /, as we are DEFINING them! And in the act of defining them, we naturally have to think recursively, as we haven't been given any looping constructs. I must say - it was Scheme that initially inspired me to think like this. (That, and the fact that I have frequently found myself without a functional lab at the beginning of the school year! Seriously, it has been unbelievable.) I think this is a good kind of exercise for both CS and math students. And this is what made me fall in love with Python right away - the fact that I could do this kind of stuff: zero = [] def next(n): return [n] def prev(n): return n[0] one = next(zero) two = next(one) four = next(next(two)) three = prev(four) In Python, this stuff will RUN! I was ecstatic for days because of this. Of course, given this implementation we are restricted to the Naturals - but that's OK. The Naturals is a good place to start! We then have to think about how to implement other kinds of number. I think that constructing this kind of understanding is something we would want kids to do. There could be a lot of history integrated there. We can also extend the exercise to define > and <. So, given only prev(n), next(n), equality, and conditional reasoning, define arithmetic! I realize this might seem really remote and abstract for most high school students, but I actually think it's something they COULD and SHOULD grapple with. Exercises like this contain lots of good math AND CS simultaneously. I mean, consider a high school student who could articulate FROM SCRATCH their understanding of the various kinds of number in a simple computational syntax. Seems to me that would meet all kinds of concerns regarding standards. Sincerely, Michel Paul ================================================== "Shall I tell you what it is to know? To say you know when you know, and to say you do not when you do not, that is knowledge." - Confucius ================================================== From kirby.urner at gmail.com Tue Feb 20 07:05:08 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 19 Feb 2007 22:05:08 -0800 Subject: [Edu-sig] understanding recursion In-Reply-To: <3D142BFDEDAC8D46A40F4EA0B36D1F351D700C@MAIL.bhusd.k12.ca.us> References: <3D142BFDEDAC8D46A40F4EA0B36D1F351D700C@MAIL.bhusd.k12.ca.us> Message-ID: > The important thing in these exercises is that we can't use our typical arithmetic > operators of +, -, *, /, as we are DEFINING them! I think a Pythoneer will twistedly think at this point is: why do you say "can't use" we can can just *redefine* __add__, __sub__, other __ribs__, to suit, get whatever meanings for those typical arithmetic operators you like. > And in the act of defining them, we naturally have to think recursively, as we > haven't been given any looping constructs. But in Python, we have been, given looping constructs (it's a VHLL ya know, not an assembly language like Scheme and/or MMIX). Kirby From tom.hoffman at gmail.com Tue Feb 20 07:20:14 2007 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Tue, 20 Feb 2007 01:20:14 -0500 Subject: [Edu-sig] edu-dinner In-Reply-To: References: Message-ID: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> On 2/19/07, Michael Tobis wrote: > Any objections? If not please consider this a plan. See you Saturday 7 PM! My only concern is that "Hands on with the OLPC" is Saturday at 8:00, so I imagine many of us will be ducking out for that. --Tom From krstic at solarsail.hcs.harvard.edu Tue Feb 20 07:39:19 2007 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?B?SXZhbiBLcnN0acSH?=) Date: Tue, 20 Feb 2007 01:39:19 -0500 Subject: [Edu-sig] edu-dinner In-Reply-To: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> References: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> Message-ID: <45DA9797.20608@solarsail.hcs.harvard.edu> Tom Hoffman wrote: > My only concern is that "Hands on with the OLPC" is Saturday at 8:00, > so I imagine many of us will be ducking out for that. Was the plan to do the edu-sig meeting after dinner in the same room? If not, perhaps we can do the OLPC meeting at 8 in the same room, as a continuation of the edu-sig dinner. I presume there's considerable overlap in interest. -- Ivan Krsti? | GPG: 0x147C722D From jeff at taupro.com Tue Feb 20 11:42:08 2007 From: jeff at taupro.com (Jeff Rush) Date: Tue, 20 Feb 2007 04:42:08 -0600 Subject: [Edu-sig] edu-dinner In-Reply-To: <45DA9797.20608@solarsail.hcs.harvard.edu> References: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> <45DA9797.20608@solarsail.hcs.harvard.edu> Message-ID: <45DAD080.4050509@taupro.com> Ivan Krsti? wrote: > Tom Hoffman wrote: >> My only concern is that "Hands on with the OLPC" is Saturday at 8:00, >> so I imagine many of us will be ducking out for that. > > Was the plan to do the edu-sig meeting after dinner in the same room? If > not, perhaps we can do the OLPC meeting at 8 in the same room, as a > continuation of the edu-sig dinner. I presume there's considerable > overlap in interest. The last main talk ends at 6:55pm. If dinner could be started at 7pm instead of 8pm, and the OLPC demo started at 8pm, in the dinner room or another, it might work for both audiences. But we don't want to crowd out other edu presentations after dinner. -Jeff From krstic at solarsail.hcs.harvard.edu Tue Feb 20 11:49:21 2007 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?B?SXZhbiBLcnN0acSH?=) Date: Tue, 20 Feb 2007 05:49:21 -0500 Subject: [Edu-sig] edu-dinner In-Reply-To: <45DAD080.4050509@taupro.com> References: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> <45DA9797.20608@solarsail.hcs.harvard.edu> <45DAD080.4050509@taupro.com> Message-ID: <45DAD231.7080304@solarsail.hcs.harvard.edu> Jeff Rush wrote: > If dinner could be started at 7pm > instead of 8pm, and the OLPC demo started at 8pm, in the dinner room or > another, it might work for both audiences. Yeah, this is what I was thinking. -- Ivan Krsti? | GPG: 0x147C722D From mpaul at bhusd.k12.ca.us Tue Feb 20 15:54:23 2007 From: mpaul at bhusd.k12.ca.us (Michel Paul) Date: Tue, 20 Feb 2007 06:54:23 -0800 Subject: [Edu-sig] understanding recursion Message-ID: <3D142BFDEDAC8D46A40F4EA0B36D1F351D7016@MAIL.bhusd.k12.ca.us> >why do you say "can't use" we can can just *redefine* Oh, definitely. I agree. We certainly can and SHOULD have students learn to redefine what we mean by various operators. In saying "can't use" I don't mean "can't EVER use". : ) I just mean within the scope of this exercise. Again, I initially meant this to be an exercise PRIOR to studying any particular language. I think it's a good kind of math/CS exercise to have to analyze what we mean by simple integer operations that we normally take for granted, and this analysis naturally introduces recursion. And I think it nicely blends in with ultimately redefining these operations for other data structures. >But in Python, we have been, given looping constructs Right. Again, I just mean within the scope of the exercise. Along this line, here's an interesting thing regarding GCF - suppose we have so far ONLY defined what we mean by greaterThan, lessThan, and difference. With ONLY those definitions in place, we can define GCF: gcf(a, b): if a = b ---> a if greaterThan(a, b) ---> gcf(difference(a, b), b) if lessThan(a, b) ---> gcf(a, difference(b, a)) We can define gcf prior to defining division or mod. I think that's kind of interesting. But certainly, outside the scope of this set of exercises, it makes sense to use looping constructs, and Guido's gcf is pure beauty. -----Original Message----- From: kirby urner [mailto:kirby.urner at gmail.com] Sent: Mon 02/19/07 10:05 PM To: Michel Paul Cc: edu-sig at python.org; Jane Wortman; Lee Morris Subject: Re: [Edu-sig] understanding recursion > The important thing in these exercises is that we can't use our typical arithmetic > operators of +, -, *, /, as we are DEFINING them! I think a Pythoneer will twistedly think at this point is: why do you say "can't use" we can can just *redefine* __add__, __sub__, other __ribs__, to suit, get whatever meanings for those typical arithmetic operators you like. > And in the act of defining them, we naturally have to think recursively, as we > haven't been given any looping constructs. But in Python, we have been, given looping constructs (it's a VHLL ya know, not an assembly language like Scheme and/or MMIX). Kirby From kirby.urner at gmail.com Tue Feb 20 20:00:59 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 20 Feb 2007 11:00:59 -0800 Subject: [Edu-sig] understanding recursion In-Reply-To: <3D142BFDEDAC8D46A40F4EA0B36D1F351D7016@MAIL.bhusd.k12.ca.us> References: <3D142BFDEDAC8D46A40F4EA0B36D1F351D7016@MAIL.bhusd.k12.ca.us> Message-ID: On 2/20/07, Michel Paul wrote: << snip >> > We can define gcf prior to defining division or mod. I think that's kind of > interesting. But certainly, outside the scope of this set of exercises, it > makes sense to use looping constructs, and Guido's gcf is pure beauty. Those moving to the post calculator math class format will likely register gcf when the discussion advances from N, Z to Q, if that's the standard (N, Z, Q, R, C is the sequence of number types I'm most used to teaching, expect to persist, though some might do Q -> Z and/or combine C with an approach to vectors).[1] With Q (rational numbers) you get a need for "lowest terms" and hence for gcfs. Reduced p/q come as "relatively prime" unless q is 1, in which case p/q is likewise in Z (int). So if it's Python we're using, we'll want to construct and/or import some Rational Number type (not a built-in, unlike in some languages), with all the methods for adding, multiplying, inverting spelled out in some detail.[2] Letting a fraction type accept fractions as inputs (as numerator and denominator, thence to be simplified), adds the potential for an intriguing side trip into another deep topic: continued fractions.[3] We're also seeding the soup with more mature ideas about the set of primes versus the set of composites, including that of "uncrackable composite". Just because you can't factor (n, m), doesn't mean you can't reduce n/m to lowest terms, thanks to gcf (Euclid's). The old grade school way of doing a gcf, with factor trees and in-common primes, actually "doesn't scale well" (we have lots of stories at this point, building up to RSA).[4] According to this blueprint, students have become familiar with Python's operator overloading as a part of ordinary algebra, as the "ordinary algebra" of earlier generations (up to and including the calculator era) has at long last been superseded with something more useful.[5] Kirby [1] combining vector field with C:{(a, b)} http://www.4dsolutions.net/cgi-bin/py2html.cgi?script=/ocn/python/orbits.py (next stop: quaternions?) [2] some typical Fraction code in Python: http://www.4dsolutions.net/ocn/python/functions.html [3] http://www.cut-the-knot.org/do_you_know/fraction.shtml [4] http://www.4dsolutions.net/ocn/rsa.html [5] http://www.4dsolutions.net/ocn/cp4e.html From andre.roberge at gmail.com Tue Feb 20 23:47:33 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Tue, 20 Feb 2007 18:47:33 -0400 Subject: [Edu-sig] Pycon talk: advice? Message-ID: <7528bcdd0702201447u1749c416kb6efdf9be1136aa7@mail.gmail.com> Hi everyone, I have a question for you... I've just finished going through the first draft of my Pycon talk "out loud" to ensure that I didn't talk for too long and find out that I could easily stretch it to one hour... while I only intend to talk for 25 minutes at the most, making sure there is time for questions. Here's a "revised" outline of what my talk could include 1. Defining/demo-ing what is meant by an interactive tutorial (i.e. executing Python code from Firefox). 2. Why VLAM? (Very Little Added Markup) - with simple examples 3. Features of the embedded Python interpreter * including support for input()/raw_input() :-) 4. The new editor. 5. Built-in graphics support (drawings and plots) 6. Doctests as a learning tool. 7. Launching an external applications (2 quick examples) 8. Demo of the new "crunchyfier" - point and click to add VLAM I also need to demonstrate Johannes' latest work which simplify the graphics support, extend input/raw_input, simplifies communication between the browser and the Python backend and is generally a much better approach. Another topic I probably need to slip in there is the issue of security. A feature I will most likely not cover at all is the user customization (style [css] and language [i.e. English and French at the moment). Now comes the question :-) Does anyone have any suggestion/preference as to which topic(s) I should spend more time on? Andr? From andre.roberge at gmail.com Tue Feb 20 23:53:20 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Tue, 20 Feb 2007 18:53:20 -0400 Subject: [Edu-sig] PEP accepted Message-ID: <7528bcdd0702201453s5d1b0854y2c264f2d0e47f7be@mail.gmail.com> Simple input built-in in Python 3000 has been accepted. Details are here: http://www.python.org/dev/peps/pep-3111/ The next step is the actual implementation which I have foolishly volunteered to do. Andr? From radenski at studypack.com Wed Feb 21 13:55:19 2007 From: radenski at studypack.com (Atanas Radenski) Date: Wed, 21 Feb 2007 04:55:19 -0800 Subject: [Edu-sig] "Python First" summer workshop Message-ID: <20070221045519.ict5os3jwgssows4@webmail.studypack.com> A summer workshop "Python First: A Lab-Based Digital Introduction to Computer Science" will be held at Chapman University, Orange, California, June 18-21, 2007. Registration is now open. For more information and to register visit: http://www.chapman.edu/wcls/MathCS/sWorkshop/Python/default.asp Respectfully, Atanas Radenski mailto:radenski at studypack.com http://studypack.com mailto:radenski at chapman.edu http://www1.chapman.edu/~radenski From mtobis at gmail.com Wed Feb 21 15:53:14 2007 From: mtobis at gmail.com (Michael Tobis) Date: Wed, 21 Feb 2007 08:53:14 -0600 Subject: [Edu-sig] edu-dinner In-Reply-To: <45DAD231.7080304@solarsail.hcs.harvard.edu> References: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> <45DA9797.20608@solarsail.hcs.harvard.edu> <45DAD080.4050509@taupro.com> <45DAD231.7080304@solarsail.hcs.harvard.edu> Message-ID: I think we'd all be thrilled to have an OLPC (One Laptop Per Child) presentation as part of edupython. This would involve: moving the presentation to the Preston Trail II room at 8 PM else: moving edupython to the room where OLPC is currently scheduled Which should it be? mt On 2/20/07, Ivan Krsti? wrote: > > Jeff Rush wrote: > > If dinner could be started at 7pm > > instead of 8pm, and the OLPC demo started at 8pm, in the dinner room or > > another, it might work for both audiences. > > Yeah, this is what I was thinking. > > -- > Ivan Krsti? | GPG: 0x147C722D > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070221/d00a630d/attachment.htm From krstic at solarsail.hcs.harvard.edu Wed Feb 21 16:59:09 2007 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?B?SXZhbiBLcnN0acSH?=) Date: Wed, 21 Feb 2007 10:59:09 -0500 Subject: [Edu-sig] edu-dinner In-Reply-To: References: <92de6c880702192220w30472e53u54a249b7ebf7622e@mail.gmail.com> <45DA9797.20608@solarsail.hcs.harvard.edu> <45DAD080.4050509@taupro.com> <45DAD231.7080304@solarsail.hcs.harvard.edu> Message-ID: <45DC6C4D.4060903@solarsail.hcs.harvard.edu> Michael Tobis wrote: > I think we'd all be thrilled to have an OLPC (One Laptop Per Child) > presentation as part of edupython. This would involve: > moving the presentation to the Preston Trail II room at 8 PM This is fine with me, as long as edu-sig doesn't have something else scheduled for the same time already, which is what I was trying to say in my original message. Cheers, -- Ivan Krsti? | GPG: 0x147C722D From winstonw at stratolab.com Fri Feb 23 03:23:58 2007 From: winstonw at stratolab.com (Winston Wolff) Date: Thu, 22 Feb 2007 21:23:58 -0500 Subject: [Edu-sig] PEP accepted In-Reply-To: <7528bcdd0702201453s5d1b0854y2c264f2d0e47f7be@mail.gmail.com> References: <7528bcdd0702201453s5d1b0854y2c264f2d0e47f7be@mail.gmail.com> Message-ID: Yeah, wonderful. Thanks Andr?. > The next step is the actual implementation which I have foolishly > volunteered to do. Perhaps you can adapt the Python 2.5 version? Winston Wolff winstonw at stratolab.com (646) 827-2242 On Feb 20, 2007, at 5:53 PM, Andre Roberge wrote: > Simple input built-in in Python 3000 > > has been accepted. Details are here: > > http://www.python.org/dev/peps/pep-3111/ > > The next step is the actual implementation which I have foolishly > volunteered to do. > > Andr? > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From andre.roberge at gmail.com Fri Feb 23 18:38:08 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 23 Feb 2007 13:38:08 -0400 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon Message-ID: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> I just attended a great talk on OLPC. I thought I should share my first reactions with folks not fortunate enough to be able to attend. BTW, if anyone feels this is a bit of an abuse of this list, feel free to let me know (I won't be offended). I recognize that these are not well polished notes and perhaps should rather find their way on my blog. The first part was about school and learning - great stuff. Goal: changing the way kids learn (no mention as this point about laptops). Art would have been pleasantly surprised. This was done in a "non-preachy" way, unlike the way some home-schooling advocates present their stuff. (no offense meant to anyone on this list). A big chunk of the talk dealt with technical/hardware issues - all done in a very relevant way, but not exactly relevant for edu-sig. Some excellent reasons were given as to why Python was chosen as *the* development language. There is actually a button on the keyboard which is meant to "display the source"; click on it and you're presented with the actual Python source code used to run the application being viewed/used. The user can then modify the source (like smalltalk I guess, like Paul F. [?] sometimes mentions on this list) and run the modified version. One open issue (as I understand it) is that of finding the "best practice" for plugins. The idea is that the core programs should be as small as possible but easy to extend via plugins. I thought that there already was a "well known and best way" to design plugins - and it was on my list of things to learn about (to eventually incorporate rurple within crunchy). There is a real need to have more people involved in the development. This project presents a real opportunity to "make a real difference" to a lot of kids out there. Overall, I was extremely impressed with the talk - it was a job well done and a fantastic start to the conference. Andr? From kirby.urner at gmail.com Fri Feb 23 18:48:47 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 23 Feb 2007 09:48:47 -0800 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> Message-ID: Thanks for the update Andr?. At Pycons I've attended @ GWU in DC, we were promised screencasts at least if the speaker signed a waiver allowing it. Was it your impression that this keynote will have an URL, maybe has one already? I was unaware of the 'view source' button. Must be a different brand. Kirby From andre.roberge at gmail.com Fri Feb 23 18:54:20 2007 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 23 Feb 2007 13:54:20 -0400 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> Message-ID: <7528bcdd0702230954h937a757v562147fea3e080f6@mail.gmail.com> As far as I know, there will be some screencasts/recordings available. I haven't seen a link to the slides so far and was planning to find out. On 2/23/07, kirby urner wrote: > Thanks for the update Andr?. > > At Pycons I've attended @ GWU in DC, we were promised screencasts at least > if the speaker signed a waiver allowing it. > > Was it your impression that this keynote will have an URL, maybe has one > already? > > I was unaware of the 'view source' button. Must be a different brand. > > Kirby > From vceder at canterburyschool.org Fri Feb 23 19:28:13 2007 From: vceder at canterburyschool.org (Vern Ceder) Date: Fri, 23 Feb 2007 13:28:13 -0500 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> Message-ID: <45DF323D.6060809@canterburyschool.org> I would second Andre's assessment. It just may have been one of the best keynotes of any PyCon, whatever you think of OLPC. And I think most people in the room ended up with a pretty positive feeling for what the OLPC folks want to do. Vern Andre Roberge wrote: > I just attended a great talk on OLPC. I thought I should share my > first reactions with folks not fortunate enough to be able to attend. > > BTW, if anyone feels this is a bit of an abuse of this list, feel free > to let me know (I won't be offended). I recognize that these are not > well polished notes and perhaps should rather find their way on my > blog. > > > The first part was about school and learning - great stuff. Goal: > changing the way kids learn (no mention as this point about laptops). > Art would have been pleasantly surprised. This was done in a > "non-preachy" way, unlike the way some home-schooling advocates > present their stuff. (no offense meant to anyone on this list). > > A big chunk of the talk dealt with technical/hardware issues - all > done in a very relevant way, but not exactly relevant for edu-sig. > > Some excellent reasons were given as to why Python was chosen as *the* > development language. There is actually a button on the keyboard > which is meant to "display the source"; click on it and you're > presented with the actual Python source code used to run the > application being viewed/used. The user can then modify the source > (like smalltalk I guess, like Paul F. [?] sometimes mentions on this > list) and run the modified version. > > One open issue (as I understand it) is that of finding the "best > practice" for plugins. The idea is that the core programs should be > as small as possible but easy to extend via plugins. I thought that > there already was a "well known and best way" to design plugins - and > it was on my list of things to learn about (to eventually incorporate > rurple within crunchy). > > There is a real need to have more people involved in the development. > This project presents a real opportunity to "make a real difference" > to a lot of kids out there. > > Overall, I was extremely impressed with the talk - it was a job well > done and a fantastic start to the conference. > > Andr? > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From francois.schnell at gmail.com Fri Feb 23 23:07:10 2007 From: francois.schnell at gmail.com (francois schnell) Date: Fri, 23 Feb 2007 23:07:10 +0100 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> Message-ID: <13a83ca10702231407m1f8afc3fve84b5518539696bc@mail.gmail.com> Thanks Andre for the update I really appreciate. I hope someone recorded that if so it looks like it should appear in the future on this page (items): http://us.pycon.org/zope/talks/2007/fri/track3/004/talkDetails I'm also hoping your talk for crunchy will be recorded. It would also be a good occasion to have an interview with Ron Stephens for the Python 411 podcast (I'm sure he will be interested). francois On 2/23/07, Andre Roberge wrote: > > I just attended a great talk on OLPC. I thought I should share my > first reactions with folks not fortunate enough to be able to attend. > > BTW, if anyone feels this is a bit of an abuse of this list, feel free > to let me know (I won't be offended). I recognize that these are not > well polished notes and perhaps should rather find their way on my > blog. > > > The first part was about school and learning - great stuff. Goal: > changing the way kids learn (no mention as this point about laptops). > Art would have been pleasantly surprised. This was done in a > "non-preachy" way, unlike the way some home-schooling advocates > present their stuff. (no offense meant to anyone on this list). > > A big chunk of the talk dealt with technical/hardware issues - all > done in a very relevant way, but not exactly relevant for edu-sig. > > Some excellent reasons were given as to why Python was chosen as *the* > development language. There is actually a button on the keyboard > which is meant to "display the source"; click on it and you're > presented with the actual Python source code used to run the > application being viewed/used. The user can then modify the source > (like smalltalk I guess, like Paul F. [?] sometimes mentions on this > list) and run the modified version. > > One open issue (as I understand it) is that of finding the "best > practice" for plugins. The idea is that the core programs should be > as small as possible but easy to extend via plugins. I thought that > there already was a "well known and best way" to design plugins - and > it was on my list of things to learn about (to eventually incorporate > rurple within crunchy). > > There is a real need to have more people involved in the development. > This project presents a real opportunity to "make a real difference" > to a lot of kids out there. > > Overall, I was extremely impressed with the talk - it was a job well > done and a fantastic start to the conference. > > Andr? > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070223/e461af01/attachment.htm From pdfernhout at kurtz-fernhout.com Sat Feb 24 01:20:44 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 23 Feb 2007 19:20:44 -0500 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> Message-ID: <45DF84DC.2060003@kurtz-fernhout.com> I doubt this key and related process works anything like Smalltalk, based on what you describe, though I have not seen it in action. In Smalltalk, you can *easily* modify the source of a small part of a running program (including most windows callbacks [except for blocks on some systems]) and have the changes affect the running program (so no restart is required). For small programs this is not that noticeable, but if you are developing a large complex application, where it can sometimes take minutes to get the program back to the state you are testing for (especially if it needs to process large amounts of data), or where exceptions may be hard to repeat, this can be a *huge* time saver. So to when you are working on a large application which is always running 24X7 (large financial and simulation and embedded and server projects are often like this). This "edit and continue" support is much more fine grained and easier to use than reloading Python modules, even with the variants I and others have created. Also, if you get an exception in most Smalltalk, you can modify the offending code right there and then and restart just the method, retaining the entire calling history and values for the call such as it was like the exception never happened, without needing to restart the entire program (try that in Python. :-) That is why I feel that Smalltalk programming all other things being equal is several times more productive than Python. Of course, all things are not always equal, so libraries, other programmer's familiarity with C syntax, installed interpreters, relevant libraries, licensing, and so on effect the decision. That is why I use Python and typically feel more productive *overall* than working in a typical Smalltalk despite knowing that when I actually do write and debug my own code that effort by itself is much less productive otherwise than doing the equivalent in Smalltalk (if all other things were equal, which they are not, especially typically in relation to licensing, which may change). Well, I'll say Python's indentational syntax is also a big plus which I prefer over Smalltalk's, while I otherwise prefer Smalltalk's keyword syntax for being more self-documenting. :-). Anyway, there is no inherent reason Python can not do what Smalltalk does -- although it might require some minor changes to the VM to debug and restart exceptions; Python just does not do it, I suspect in part because key Pythoneers may just not understand what they are missing and think module reloading is the same thing. :-) I predict if Guido added this one set of related features to Python, it would be a very short time before everyone wondered how they lived without it before. :-) However, it would also need to interact with the difference between a system hosted in files and one hosted in an image, so that part of it would be somewhat harder to manage that the internal mechanics. Thanks in any case for the report! --Paul Fernhout Andre Roberge wrote: > Some excellent reasons were given as to why Python was chosen as *the* > development language. There is actually a button on the keyboard > which is meant to "display the source"; click on it and you're > presented with the actual Python source code used to run the > application being viewed/used. The user can then modify the source > (like smalltalk I guess, like Paul F. [?] sometimes mentions on this > list) and run the modified version. From kirby.urner at gmail.com Sat Feb 24 04:17:28 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 23 Feb 2007 19:17:28 -0800 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <45DF84DC.2060003@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> Message-ID: On 2/23/07, Paul D. Fernhout wrote: > Anyway, there is no inherent reason Python can not do what Smalltalk does > -- although it might require some minor changes to the VM to debug and > restart exceptions; Python just does not do it, I suspect in part because > key Pythoneers may just not understand what they are missing and think > module reloading is the same thing. :-) I predict if Guido added this one > set of related features to Python, it would be a very short time before > everyone wondered how they lived without it before. :-) You may be right, although if I understand your aright, it's neither the syntax nor semantics of Python that are at issue, but the IDE and its ability to permit debugging on the fly, using thrown exceptions as restart points of some kind. Sounds cool. Don't have to wait for Guido, might be able to retrofit it for earlier Pythons. Kirby From kirby.urner at gmail.com Sat Feb 24 04:20:49 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 23 Feb 2007 19:20:49 -0800 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <45DF323D.6060809@canterburyschool.org> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF323D.6060809@canterburyschool.org> Message-ID: On 2/23/07, Vern Ceder wrote: > I would second Andre's assessment. It just may have been one of the best > keynotes of any PyCon, whatever you think of OLPC. And I think most > people in the room ended up with a pretty positive feeling for what the > OLPC folks want to do. > > Vern I haven't met anyone "anti" OLPC, just some who've felt their plans to further computerize the curriculum were not on hold while we waited for such hardware to materialize. Mark Shuttleworth for example. The forward progress of that South African process was in no way contingent upon the success of failure (e.g. perpetual postponement) of the projected OLPC result (one laptop per child). For example, given TuxLabs, shared equipment, it's already possible to do Squeak-based robotics or whatever. Kirby From andreas.raab at gmx.de Sat Feb 24 08:20:10 2007 From: andreas.raab at gmx.de (Andreas Raab) Date: Fri, 23 Feb 2007 23:20:10 -0800 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <45DF84DC.2060003@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> Message-ID: <45DFE72A.4020308@gmx.de> Paul D. Fernhout wrote: > This "edit and continue" support is much more fine grained and > easier to use than reloading Python modules, even with the variants I and > others have created. Where can I find out more about these variants and what they do? We are currently trying to enable a workflow that centers around a life environment and these issues become important for us. Are there any other life environments (besides Patapata which I have looked at) that are worth studying? Cheers, - Andreas From pdfernhout at kurtz-fernhout.com Sat Feb 24 15:35:00 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 24 Feb 2007 09:35:00 -0500 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: <45DFE72A.4020308@gmx.de> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45DFE72A.4020308@gmx.de> Message-ID: <45E04D14.7040105@kurtz-fernhout.com> Andreas- Here is one post on this issue with code I made previously for Jython: "ReloaderWindow 0.2 (improvements to selective reloading)" http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html This is a different (earlier) approach than for PataPata (PataPata uses prototypes and overriding __getattr__) and the linked code works with regular Python classes. The important thing to understand is that a Python VM manages a world of objects somewhat like a Smalltalk image, lumping all the objects from all the loaded modules into the same objectspace. You can just reference some of them (typically classes) by the way the current hierarchical Python namespace is set up. When you reload a module, it creates completely new class objects which just happen to have the same name as the old one and the namespace now points to those new objects (sort of like if every time you changed a method in Smalltalk the SystemDictionary Smalltalk was made to point to entirely new classes, leaving the old ones floating, which would obviously be a silly thing to do). So any existing instances of original classes point still to the old classes (which are no longer referenceable from the namespace). The various approaches try to get around this in various ways, such as in my approach above by loading a changed module into a temporary namespace and then copying the methods from it on top of the old classes. Also, things get a little more complicate than that, since Python often uses method pointers, equivalent in some way to Smalltalk blocks, to hook up GUI systems. So even if you keep the class the same and replace the methods, your running GUI window typically has bindings by reference to the old overwritten functions. So, as this approach I outlines does, you need to also keep the shell of the old functions and just overwrite what they actually do -- Kind of like if you kept CompiledMethods around and just overwrote their code. It's an awkward way to do things. Now, obviously, Smalltalk sometimes fails at updating GUIs when you tie actions to blocks, where recompiling methods produces new blocks (a big problem in older VisualWorks apps, not sure of the current status of VisualWorks or Squeak). Of course, in Smalltalk you could make the block call a method using a selector, which as least gives you a point of intervention. Similarly in Python, if you modify code which the bound function references, that newer code will be called by the old function's code as dispatch works differently depending whether you have a function pointer as opposed to an inline reference to another function in a Python function. In Python, I can get around this by wrapping any function pointer I give to a GUI callback using an object (like Java :-) where the callback then calls by name. PataPata did some of that internally, though obviously it adds extra layers of overhead to every GUI call, plus the programmer had to proactively add a wrapper, making code uglier, and so on. In Python, people often build specific hooks into their application to explicitly reload modules, including sometimes closing and reopening only one window inside a large application, to try to make the best of this. There are other attempts to do a more selective reloading like the approach I give above. Consider for example: "[Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances" http://mail.python.org/pipermail/patches/2005-September/018060.html There is some discussion at that link of the issue. And a reference there to another approach: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 From the first patch link: "Brett and I work at the same company. He made this patch because we were wasting hundreds of hours debugging reload problems or just quitting the application and restarting. I've been using this patch now for 3 months. It has saved our company hundreds of man-hours and we didn't have to change one line of existing code to make it work. If the community doesn't want to use it, I'm fine with that. I just want to make sure that you fully understand what you are giving up." I'm not sure what the disposition of that patch is. But, you can see from the responses there is a bit of a cultural problem here getting the value of the idea across. I did not look at the patch, but from the description I wonder if it still might suffer from the issue of allowing identities for functions to change (and so GUIs with actions previously linked to functions would still use the old behavior). There is also a more subtle issue for module reloading. Smalltalk is essentially a declarative language, while Python is essentially an imperative language (maybe there is a better word?). Essentially, compiling a Smalltalk class has no side effects (other than perhaps defining the class). But a Python module on loading can produce lots of side effects from defining metaclasses to affect future class loading to executing random bits of code (sort of like Forth in this sense). So, only modules without these side effects can be easily reloaded. Consider for example what if your module makes a singleton instance of something -- when you reload it, should it make a new singleton instance and leave the other one to still perhaps be used by old instances, or should the singleton instance get upgraded to the new class? Just one of many issues that happen when you are using Python's textual module reloading paradigm. Ideally, when you change a method in a text file you probably almost always want only that specific method to change with everything else being left alone. But that breaks the Python paradigm. Still, even with this problem, easier class reloading like I outlined above still gets you great value when developing new code, especially if you slightly alter how you layout your new modules with this limitation in mind. But reloading older code may present you with problems -- making maintenance using this technique harder. --Paul Fernhout Andreas Raab wrote: > Paul D. Fernhout wrote: > >>This "edit and continue" support is much more fine grained and >>easier to use than reloading Python modules, even with the variants I and >>others have created. > > Where can I find out more about these variants and what they do? We are > currently trying to enable a workflow that centers around a life > environment and these issues become important for us. Are there any > other life environments (besides Patapata which I have looked at) that > are worth studying? From pdfernhout at kurtz-fernhout.com Sat Feb 24 15:39:21 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 24 Feb 2007 09:39:21 -0500 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> Message-ID: <45E04E19.4000502@kurtz-fernhout.com> There may be one major semantical issue, in terms of the meaning of side effects when loading a module (e.g. defining singletons, opening files, etc.) which is hard to deal with generically with Python. You can deal with is specifically in how you write your own code, but that is not a general solution. See my previous note to Andreas for more details, including a related Python patch someone submitted in 2005. --Paul Fernhout kirby urner wrote: > On 2/23/07, Paul D. Fernhout wrote: > > >>Anyway, there is no inherent reason Python can not do what Smalltalk does >>-- although it might require some minor changes to the VM to debug and >>restart exceptions; Python just does not do it, I suspect in part because >>key Pythoneers may just not understand what they are missing and think >>module reloading is the same thing. :-) I predict if Guido added this one >>set of related features to Python, it would be a very short time before >>everyone wondered how they lived without it before. :-) > > > You may be right, although if I understand your aright, it's neither > the syntax nor semantics of Python that are at issue, but the IDE and > its ability to permit debugging on the fly, using thrown exceptions as > restart points of some kind. Sounds cool. Don't have to wait for > Guido, might be able to retrofit it for earlier Pythons. From kirby.urner at gmail.com Sat Feb 24 18:12:35 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 24 Feb 2007 09:12:35 -0800 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <45E04E19.4000502@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> Message-ID: On 2/24/07, Paul D. Fernhout wrote: > There may be one major semantical issue, in terms of the meaning of side > effects when loading a module (e.g. defining singletons, opening files, > etc.) which is hard to deal with generically with Python. You can deal > with is specifically in how you write your own code, but that is not a > general solution. Not sure I follow yet. A module loads top to bottom, with lower defs premised on those previously mentioned. Is that what you mean? Once everything is loaded, it's more like a __dict__, i.e. the namespace of the module of accessible, either via dot notation, or directly if the names are top level. > See my previous note to Andreas for more details, including a related > Python patch someone submitted in 2005. > > --Paul Fernhout I'll wait for the IDE that passes muster as a "what you meant". In no such IDE is forthcoming, I'm not inclined to blame Python the language yet, as your improvements sound tangential to the design concepts. So far. Maybe I'm missing something, so keep persuading me if you like. Kirby From lac at openend.se Sat Feb 24 19:12:19 2007 From: lac at openend.se (Laura Creighton) Date: Sat, 24 Feb 2007 19:12:19 +0100 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: Message from Andreas Raab of "Fri, 23 Feb 2007 23:20:10 PST." <45DFE72A.4020308@gmx.de> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45DFE72A.4020308@gmx.de> Message-ID: <200702241812.l1OICJsM032632@theraft.openend.se> In a message of Fri, 23 Feb 2007 23:20:10 PST, Andreas Raab writes: >Paul D. Fernhout wrote: >> This "edit and continue" support is much more fine grained and >> easier to use than reloading Python modules, even with the variants I a >nd >> others have created. > >Where can I find out more about these variants and what they do? We are >currently trying to enable a workflow that centers around a life >environment and these issues become important for us. Are there any >other life environments (besides Patapata which I have looked at) that >are worth studying? > >Cheers, > - Andreas PyPy made a release last week. http://codespeak.net/pypy/dist/pypy/doc/news.html release 1.0 (coming next month) may be of even more interest to you. Remember that this is bleeding edge computer science research, not something we suggest you use in production right away. in particular greenlets http://codespeak.net/py/dist/greenlet.html may be of interest to you. We don't have an 'edit and continue' interface to pypy yet, but that is exactly what we are doing internally, so by my reckoning, at any rate, it would not be hard to add. EU project winds up in March. No cool new ideas are going to go in until April, because we are going to have the damndest time getting all we promised done on time ... PyPy has its own mailing list http://codespeak.net/mailman/listinfo/pypy-dev and pypy developers hang out on the irc channel #pypy on freenode. That is a better place to discuss pypy than here. Laura Creighton From kirby.urner at gmail.com Sat Feb 24 19:40:07 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 24 Feb 2007 10:40:07 -0800 Subject: [Edu-sig] Partial Sums using List Comprehensions Message-ID: I've appending a posting (of mine) from another group, because of the Python syntax it contains: a list comprehension giving partial sums. So often in math, we want to do that, or in simple grocery store arithmetic, or statistics, where what interests is a list of cumulative sums, running totals. Now an interesting way to date yourself is if you have a "cringe reflex" when you see: >>> halfoctas = [sum(manylayers[0:x]) for x in range(1,21)] when you realize the *same totals* are starting over for every member of the list, i.e. we're not capitalizing on having already added 18 numbers, when going to the 19th -- we start all over. What a waste of perfectly good ADDs, right? If you're old school assembler with limited RAM (8K sound like a lot?) your reflex will be to cache those totals and run screaming from any VHLL (very high level language) that doesn't mirror your sense of memory/clock economy. But in Python, is in other VHLLs such as J, it's economy of syntax, and therefore conceptual economy in the programmer's own brain, that we're seeking, less so a perfectly optimized fleet of electrons through the CPU's adder. We waste "clock cycles" with wild abandon, because most computers just sit there wasting clock cycles anyway -- that's what they have, in magnificent abundance (*way* too much time on their hands). Programmers, on the other hand, have busy lives and need to get on with learning their sums. List comprehension syntax is easy to master and any decent Python course gets into it quickly (within the first hour, during an overview pass?). And that's the tradeoff in electronics: pushing the busy work onto the machines, freeing up our own minds for more interesting challenges. But you still need old school type thinkers, for when memory really does get to be tight (which it still does, in many knowledge domains, e.g. climatology). Also you could just go: >>> def halfoctas(n): return [sum([x*x for x in range(1, n+1)][0:i]) for i in range(1, n+1)] >>> halfoctas(10) [1, 5, 14, 30, 55, 91, 140, 204, 285, 385] >>> halfoctas(20) [1, 5, 14, 30, 55, 91, 140, 204, 285, 385, 506, 650, 819, 1015, 1240, 1496, 1785, 2109, 2470, 2870] but that's a lot less transparent I think. Or write it as a generator -- don't have to specify n in that case (just invoke .next() without limit). Kirby ========================= Re: School Boycott --- In synergeo at yahoogroups.com, "Alan Michelson" wrote: > As you can see, there hasn't been as much discussion about the > half-coupler as there was about the octant (they both have the same > volume ? one-sixth of the cube!) > Yeah, you're doing good work. And every school child gets at least a tactile and/or visual gander at the Egyptian variety, especially if getting brainwashed with Biblical stories, in which Pharoh is bound to come in (and go out). So "half octahedron" is no unfamiliar concept. Nor should be the ball packing corresponding thereto, beginning with a plane of XY spheres, surmounted by another "down in the valleys", and another, and so on, tapering right up to a tippy top apex ball -- maybe it makes more sense to begin from there, excavating as you grow the base. We're talking about the sum of consecutive squares of course, and so in Python: >>> def layers(n): return n**2 >>> manylayers = [layers(n) for n in range(1, 21)] >>> halfoctas = [sum(manylayers[0:i]) for i in range(1,21)] >>> halfoctas [1, 5, 14, 30, 55, 91, 140, 204, 285, 385, 506, 650, 819, 1015, 1240, 1496, 1785, 2109, 2470, 2870] Then we cut and paste the first few into the Encyclopedia of Integer Sequences and voila: http://www.research.att.com/~njas/sequences/A000330 > > I mean, why aren't we teaching this stuff? There's no coherent > > opposition, just mindless inertia. A boycott might help us focus. ... Kirby From kirby.urner at gmail.com Sat Feb 24 20:02:42 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 24 Feb 2007 11:02:42 -0800 Subject: [Edu-sig] Interface of Tomorrow Message-ID: More interface of tomorrow eye candy: http://www.fastcompany.com/video/general/perceptivepixel.html Note "Python" commercial. Kirby From pdfernhout at kurtz-fernhout.com Sun Feb 25 03:03:58 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 24 Feb 2007 21:03:58 -0500 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> Message-ID: <45E0EE8E.7090709@kurtz-fernhout.com> kirby urner wrote: > On 2/24/07, Paul D. Fernhout wrote: > >>There may be one major semantical issue, in terms of the meaning of side >>effects when loading a module (e.g. defining singletons, opening files, >>etc.) which is hard to deal with generically with Python. You can deal >>with [it] specifically in how you write your own code, but that is not a >>general solution. > > > Not sure I follow yet. A module loads top to bottom, with lower defs > premised on > those previously mentioned. Is that what you mean? Once everything is loaded, > it's more like a __dict__, i.e. the namespace of the module of > accessible, either > via dot notation, or directly if the names are top level. To step back for a minute, the fundamental problem here is that for whatever reason a programmer wants to modify just one method of an already loaded Python class (which came from a textual module which was loaded already), save the change somewhere so it can be reloaded later (overwriting part of the textual module?), and also have the program start using the new behavior for existing instances without any other side effects arising from recompiling this one change. In practice, this is trivial to do in almost any Smalltalk system; it is hard if not impossible to do in any widely used Python IDE or program (even when a Python shell is embedded). Unfortunately, the paradigm used by every Python IDE I've tried is to reload an entire textual module (or more typically, entire program) at a time for even the slightest change to one function. Embedded Python shells generally allow you to redefine a function if you have a copy of the code, but they offer no way to save the code. Most Smalltalks uses a different paradigm, where code is presented to the user one function at a time in a browser and is compiled one function at a time. Yes, there are cases where people "filein" Smalltalk code defining a complex program, but such fileins are generally considered an *interchange* format, not a preferred program representation for editing unlike as is usually the case with Python. Consider the meaning of an arbitrary piece of Python code near the bottom of a textual module. Essentially, you have no idea what it means if the original author has used some Python bells and whistles. For example, he or she could have defined a metaclass where every nested "def" under a class was converted to, say, an uppercase string and stored under a key that was the numerical hash of the function name (with no functions actually defined for that class perhaps). The specific metaclass behavior may even hinge on the current state of a global which has been modified several times during the course of loading the module. So essentially, you have no way of knowing for sure what any apparent Python code really means by isolated inspection. And because any module can run any arbitrary Python code, without actually running the Python program (or doing the equivalent analysis), you can never be sure what side effects loading a module has. Now, Smalltalk has metaclasses too, but in practice, because of the way code is presented to the user and edited and recompiled one method/function at a time, the context makes fairly clear what is going to happen when that snippet of code you just changed is compiled. The big difference is really the effective unit of compilation -- the complex module in Python or the simple method/function in Smalltalk. Now, this is rarely a problem the *first* time a module is loaded, but it generally becomes a problem when a module is *reloaded*. If you only treated as module as an *interchange* format, and then modified the live classes using a tool which only works on regular classes (like PataPata does), there is no need to reload the module, so this potential problem related to parsing a modules meaning via an IDE tool remains only potential, and also avoided is the possibility reloading a module might have side effects. (In practice, anything still depends on mapping from a function back to its source text, and this may go wrong for various reasons... :-) Naturally, this kind of major redefinition is rarely done, and it would create lots of confusion, but it is possible, so IDE tools that do not support it are incomplete. This is a perrenial problem with, say, C, where you can make all sorts of macros and so never know just exactly what arbitrary C code out of context does (see the obfuscated code contests...). And it means that you can't get a simple one-to-one mapping of a section of a file that looks like it defines a function and an actual function reliably without analyzing the entire program. Yes, 99.99% of the time Python code does the obvious thing, but it is not 100% certain. The same is true for Forth -- in theory any isolated snippet of Forth can mean anything, since it is trivially easy to modify how the compiler interprets text -- something that make Forth very powerful but at the same time potentially very confusing for a code maintainer. I don't have the link offhand, but a while back I came across a blog post suggesting you tend to either have a powerful language or powerful tools -- but not at the same time (except perhaps for Smalltalk :-). That is because if the language is very flexible, it becomes almost impossible to write IDE tools that can keep up with it in all its generality. Now, since almost all Python code is written in a straightforward manner, one can still make such tools and find them useful. But likely there will aways be gotchas in such systems as long as they tie their operation closely to the notion of compiling one module at a time, compared to Smalltalk which ties itself to compiling one method/function at a time. One of the things PataPata tried to do, and succeeded to some extent, was breaking the link between reloading a textual module and modifying a running Python program, yet it was still able to use a textual Python module as both an interchange format and also an image format (something even no Smalltalk has done to my knowledge, as all Smalltalk images I know of are binary, not human editable text). One idea I have wanted to try for Python but never got around to it is to create a Smalltalk-like browser and build and modify classes on the fly by changing their objects and compiling only individual functions as they are changed; I could store the textual representation of functions in a repository with version control. Then, I could also still use Python modules as an interchange format, sort of like PataPata did but without prototypes. You would lose some of the generality of coding in Python (setting globals in a module and such) but you would essentially have a somewhat Smalltalk like environment to mess with (ignoring restarting from exceptions, which is very important in Smalltalk development, where much code ends up being written in the debugger as often as not; I'm not sure whether that part could be simulated with plain Python or whether it would require a VM change). --Paul Fernhout From guido at python.org Sun Feb 25 05:41:27 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 24 Feb 2007 22:41:27 -0600 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: <45E0EE8E.7090709@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> Message-ID: On 2/24/07, Paul D. Fernhout wrote: > kirby urner wrote: > > On 2/24/07, Paul D. Fernhout wrote: > > > >>There may be one major semantical issue, in terms of the meaning of side > >>effects when loading a module (e.g. defining singletons, opening files, > >>etc.) which is hard to deal with generically with Python. You can deal > >>with [it] specifically in how you write your own code, but that is not a > >>general solution. > > > > > > Not sure I follow yet. A module loads top to bottom, with lower defs > > premised on > > those previously mentioned. Is that what you mean? Once everything is loaded, > > it's more like a __dict__, i.e. the namespace of the module of > > accessible, either > > via dot notation, or directly if the names are top level. > > To step back for a minute, the fundamental problem here is that for > whatever reason a programmer wants to modify just one method of an already > loaded Python class (which came from a textual module which was loaded > already), save the change somewhere so it can be reloaded later > (overwriting part of the textual module?), and also have the program start > using the new behavior for existing instances without any other side > effects arising from recompiling this one change. In practice, this is > trivial to do in almost any Smalltalk system; it is hard if not impossible > to do in any widely used Python IDE or program (even when a Python shell > is embedded). > > Unfortunately, the paradigm used by every Python IDE I've tried is to > reload an entire textual module (or more typically, entire program) at a > time for even the slightest change to one function. Embedded Python shells > generally allow you to redefine a function if you have a copy of the code, > but they offer no way to save the code. Most Smalltalks uses a different > paradigm, where code is presented to the user one function at a time in a > browser and is compiled one function at a time. Yes, there are cases where > people "filein" Smalltalk code defining a complex program, but such > fileins are generally considered an *interchange* format, not a preferred > program representation for editing unlike as is usually the case with Python. > > Consider the meaning of an arbitrary piece of Python code near the bottom > of a textual module. Essentially, you have no idea what it means if the > original author has used some Python bells and whistles. For example, he > or she could have defined a metaclass where every nested "def" under a > class was converted to, say, an uppercase string and stored under a key > that was the numerical hash of the function name (with no functions > actually defined for that class perhaps). The specific metaclass behavior > may even hinge on the current state of a global which has been modified > several times during the course of loading the module. So essentially, you > have no way of knowing for sure what any apparent Python code really means > by isolated inspection. And because any module can run any arbitrary > Python code, without actually running the Python program (or doing the > equivalent analysis), you can never be sure what side effects loading a > module has. Now, Smalltalk has metaclasses too, but in practice, because > of the way code is presented to the user and edited and recompiled one > method/function at a time, the context makes fairly clear what is going to > happen when that snippet of code you just changed is compiled. The big > difference is really the effective unit of compilation -- the complex > module in Python or the simple method/function in Smalltalk. > > Now, this is rarely a problem the *first* time a module is loaded, but it > generally becomes a problem when a module is *reloaded*. If you only > treated as module as an *interchange* format, and then modified the live > classes using a tool which only works on regular classes (like PataPata > does), there is no need to reload the module, so this potential problem > related to parsing a modules meaning via an IDE tool remains only > potential, and also avoided is the possibility reloading a module might > have side effects. (In practice, anything still depends on mapping from a > function back to its source text, and this may go wrong for various > reasons... :-) > > Naturally, this kind of major redefinition is rarely done, and it would > create lots of confusion, but it is possible, so IDE tools that do not > support it are incomplete. This is a perrenial problem with, say, C, where > you can make all sorts of macros and so never know just exactly what > arbitrary C code out of context does (see the obfuscated code > contests...). And it means that you can't get a simple one-to-one mapping > of a section of a file that looks like it defines a function and an actual > function reliably without analyzing the entire program. Yes, 99.99% of the > time Python code does the obvious thing, but it is not 100% certain. The > same is true for Forth -- in theory any isolated snippet of Forth can mean > anything, since it is trivially easy to modify how the compiler interprets > text -- something that make Forth very powerful but at the same time > potentially very confusing for a code maintainer. I don't have the link > offhand, but a while back I came across a blog post suggesting you tend to > either have a powerful language or powerful tools -- but not at the same > time (except perhaps for Smalltalk :-). That is because if the language is > very flexible, it becomes almost impossible to write IDE tools that can > keep up with it in all its generality. > > Now, since almost all Python code is written in a straightforward manner, > one can still make such tools and find them useful. But likely there will > aways be gotchas in such systems as long as they tie their operation > closely to the notion of compiling one module at a time, compared to > Smalltalk which ties itself to compiling one method/function at a time. > > One of the things PataPata tried to do, and succeeded to some extent, was > breaking the link between reloading a textual module and modifying a > running Python program, yet it was still able to use a textual Python > module as both an interchange format and also an image format (something > even no Smalltalk has done to my knowledge, as all Smalltalk images I know > of are binary, not human editable text). > > One idea I have wanted to try for Python but never got around to it is to > create a Smalltalk-like browser and build and modify classes on the fly by > changing their objects and compiling only individual functions as they are > changed; I could store the textual representation of functions in a > repository with version control. Then, I could also still use Python > modules as an interchange format, sort of like PataPata did but without > prototypes. You would lose some of the generality of coding in Python > (setting globals in a module and such) but you would essentially have a > somewhat Smalltalk like environment to mess with (ignoring restarting from > exceptions, which is very important in Smalltalk development, where much > code ends up being written in the debugger as often as not; I'm not sure > whether that part could be simulated with plain Python or whether it would > require a VM change). > > --Paul Fernhout # xreload.py. """Alternative to reload(). This works by executing the module in a scratch namespace, and then patching classes, methods and functions. This avoids the need to patch instances. New objects are copied into the target namespace. """ import imp import sys import types def xreload(mod): """Reload a module in place, updating classes, methods and functions. Args: mod: a module object Returns: The (updated) input object itself. """ # Get the module name, e.g. 'foo.bar.whatever' modname = mod.__name__ # Get the module namespace (dict) early; this is part of the type check modns = mod.__dict__ # Parse it into package name and module name, e.g. 'foo.bar' and 'whatever' i = modname.rfind(".") if i >= 0: pkgname, modname = modname[:i], modname[i+1:] else: pkgname = None # Compute the search path if pkgname: # We're not reloading the package, only the module in it pkg = sys.modules[pkgname] path = pkg.__path__ # Search inside the package else: # Search the top-level module path pkg = None path = None # Make find_module() uses the default search path # Find the module; may raise ImportError (stream, filename, (suffix, mode, kind)) = imp.find_module(modname, path) # Turn it into a code object try: # Is it Python source code or byte code read from a file? # XXX Could handle frozen modules, zip-import modules if kind not in (imp.PY_COMPILED, imp.PY_SOURCE): # Fall back to built-in reload() return reload(mod) if kind == imp.PY_SOURCE: source = stream.read() code = compile(source, filename, "exec") else: code = marshal.load(stream) finally: if stream: stream.close() # Execute the code im a temporary namespace; if this fails, no changes tmpns = {} exec(code, tmpns) # Now we get to the hard part oldnames = set(modns) newnames = set(tmpns) # Add newly introduced names for name in newnames - oldnames: modns[name] = tmpns[name] # Delete names that are no longer current for name in oldnames - newnames - set(["__name__"]): del modns[name] # Now update the rest in place for name in oldnames & newnames: modns[name] = _update(modns[name], tmpns[name]) # Done! return mod def _update(oldobj, newobj): """Update oldobj, if possible in place, with newobj. If oldobj is immutable, this simply returns newobj. Args: oldobj: the object to be updated newobj: the object used as the source for the update Returns: either oldobj, updated in place, or newobj. """ if type(oldobj) is not type(newobj): # Cop-out: if the type changed, give up return newobj if hasattr(newobj, "__reload_update__"): # Provide a hook for updating return newobj.__reload_update__(oldobj) if isinstance(newobj, types.ClassType): return _update_class(oldobj, newobj) if isinstance(newobj, types.FunctionType): return _update_function(oldobj, newobj) if isinstance(newobj, types.MethodType): return _update_method(oldobj, newobj) # XXX Support class methods, static methods, other decorators # Not something we recognize, just give up return newobj def _update_function(oldfunc, newfunc): """Update a function object.""" oldfunc.__doc__ = newfunc.__doc__ oldfunc.__dict__.update(newfunc.__dict__) oldfunc.func_code = newfunc.func_code oldfunc.func_defaults = newfunc.func_defaults # XXX What else? return oldfunc def _update_method(oldmeth, newmeth): """Update a method object.""" # XXX What if im_func is not a function? _update_function(oldmeth.im_func, newmeth.im_func) return oldmeth def _update_class(oldclass, newclass): """Update a class object.""" # XXX What about __slots__? olddict = oldclass.__dict__ newdict = newclass.__dict__ oldnames = set(olddict) newnames = set(newdict) for name in newnames - oldnames: setattr(oldclass, name, newdict[name]) for name in oldnames - newnames: delattr(oldclass, name) for name in oldnames & newnames - set(["__dict__", "__doc__"]): setattr(oldclass, name, newdict[name]) return oldclass -- --Guido van Rossum (home page: http://www.python.org/~guido/) From andreas.raab at gmx.de Sun Feb 25 06:46:20 2007 From: andreas.raab at gmx.de (Andreas Raab) Date: Sat, 24 Feb 2007 21:46:20 -0800 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> Message-ID: <45E122AC.2050709@gmx.de> Guido van Rossum wrote: > # xreload.py. > > """Alternative to reload(). > > This works by executing the module in a scratch namespace, and then > patching classes, methods and functions. This avoids the need to > patch instances. New objects are copied into the target namespace. > """ Sweeeet! Thanks a zillion. Cheers, - Andreas From radenski at studypack.com Sun Feb 25 15:10:51 2007 From: radenski at studypack.com (Atanas Radenski) Date: Sun, 25 Feb 2007 06:10:51 -0800 Subject: [Edu-sig] Python in a paper on languages for introductory programming Message-ID: <20070225061051.vbhdqb5edckgk8og@webmail.studypack.com> A recent paper entitled "An objective comparison of languages for teaching introductory programming" - by Linda Manilla and Michael de Raadt - praises Python as a beginner's language: http://www.it.uu.se/research/group/upcerg/Publications/proceedingsKoliCalling2006/research2.pdf A comparison is outlined in Section 3, Table 2 in the above paper. The volume that contains the paper was just announced on the ACM-SIGSE list. It can be found here: http://www.it.uu.se/research/group/upcerg/Publications/proceedingsKoliCalling2006 Atanas -- Atanas Radenski mailto:radenski at studypack.com http://studypack.com mailto:radenski at chapman.edu http://www1.chapman.edu/~radenski From francois.schnell at gmail.com Sun Feb 25 17:06:59 2007 From: francois.schnell at gmail.com (francois schnell) Date: Sun, 25 Feb 2007 17:06:59 +0100 Subject: [Edu-sig] Ren'Py and Visual Novels games Message-ID: <13a83ca10702250806uf73fb0el28c9c1df17eaa209@mail.gmail.com> Hello, What about visual novels ? according to a Wikipedia article [1]: """ A visual novel is an interactive fiction game featuring mostly static graphics, usually with anime-style art. As the name might suggest, they resemble mixed-media novels or tableau vivant stage plays. Visual novels are classified as a sub-genre of adventure games, referred to as AVGs in Japan. Visual novels are especially prevalent in Japan, where they make up nearly 70% of PC games released. """ This kind of game are still rare in the EU and US market but they are now coming with title like "Phoenix Wright" [2] and "Hotel Dusk" [3] for the Nintendo GBA and/or DS. I'm not myself a regular 'user' of these games but they could be interesting to consider : - they encourage reading (but in a colorful and multimedia context which helps comprehension) - the kid read at their own pace - it's also often possible to integrate minigames in the Visual Novel itself - user interaction is usually required with different endings Obviously for kids the best educational and fun part is to actual make their own Visual Novel (possibly in a collaborative way): - imagine a story to share if possible with different choices - learn to draw (characters ?) or take pictures of landscapes/scenes/characters or use existing contents - use/create some sound/music - share it with other kids Few hours ago while browsing pygame.org I stumble on Ren'Py framework that I didn't noticed before (they've released a new version - 0.6 - few days ago). See www.renpy.org. I've tested the Demo novel (which explain how it works in a Visual Novel itself) and looked at the website, I like: - very neat end result and nice UI to select, load or edit the script of a Visual Novel - Open Source and Multiplateforme and Python/Pygame based - possibility to include directly some Python code in the easy to learn Ren'Py scripts (a '$' prefix for a single line or 'python:' for a block of code) - possibility to integrate pygame minigames in the novel (there's a Pong game in the Demo novel) - good documentation, cookbook, etc - distribution tool of the visual novels - lively community on their forum I've also noticed someone in the forum 'remaking' a chapter of the original "Phoenix Wright" (with Ren'Py and some Python extras) : it looks to me very near to the quality of the original Nintendo version (with items and people management tool also nicely integrated).[4] So far I like what I've seen :) francois [1] http://en.wikipedia.org/wiki/Visual_novels [2] http://en.wikipedia.org/wiki/Phoenix_Wright [3] http://www.wired.com/news/columns/0,72702-0.html?tw=wn_columns_6 [4] http://lemmasoft.renai.us/forums/viewtopic.php?t=1767&postdays=0&postorder=asc&highlight=wright&start=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070225/07d23eb6/attachment.html From pdfernhout at kurtz-fernhout.com Sun Feb 25 18:01:54 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 25 Feb 2007 12:01:54 -0500 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> Message-ID: <45E1C102.4050706@kurtz-fernhout.com> "Oh, what a giveaway! Did you hear that? Did you hear that, eh? That's what I'm on about!" :-) This xreload module Guido supplies is similar to the approach I used for Jython in my earlier link. http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html If you look at that thread, I acknowledge Michael Spencer as having supplied some of the more sophisticated reload logic which is similar to what Guido has posted here (not sure where Michael got it from of course, nor where Guido got xreload from). See Michael's first related post here: http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html Notice xreload's update is much smaller than the one I made with Michael's additional inspiration and ideas: http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html In some ways, xreload's is better by including a general "Provide a hook for updating" concept. However xreload just ignores what to do with top level objects like lists or dicts -- xreload apparently throws away the updates to them. Notice it is not recursive -- for example does it handle nested classes? I'm not sure of all the reasons for the other differences -- it was tricky code I admit I never fully understood how to write thoroughly, mucking about with Python/Jython internals I only hazily understood. And even for the reload code I supplied, it is not always clear what to do with changes to top level objects -- do you want to update them or replace them? If you do update them, how deeply do you want the update to go? Notice xreload still has sections with comments like "Not something we recognize, just give up" (that's throwing away changes to top level lists and dicts and singletons and such), or "Cop-out: if the type changed, give up", and it can not handle in general the issue of side effects I mentioned (e.g. is a singleton instance recreated?). And of course you can't use it to restart an exception after making a change (though it is perhaps a piece of that puzzle). It does however deal with updating pointers to existing function as far as I can tell (so previously set GUI callbacks will still call the old code) -- and does it in the same way the previous code linked to did (e.g. oldfunc.func_code = newfunc.func_code). So, the xreload module Guido supplies is nifty piece of code to have (assuming Python licensed?). Using it properly will make you more productive. However, it still requires building hooks into your application explicitly to call it for each module of interest; the Jython version I supplied includes a brief GUI control window listing all modules which could be made to work similarly under wx or tk. Still, elegant as it is (including the reload hook), even xreload does not handle all the important cases -- just (forgive me :-) the *easy* ones. When Guido supplies an xrestart.py :-) python 2.5 code module that lets you restart exceptions after having modified one of the functions in the stack trace, then I will admit it is something I have never seen before in Python and be suitably impressed. Is it even possible without modifying the VM? :-) There will remain the semantic problem of what to do with top level objects, but as I said, one can avoid that somewhat by just never expecting to reload an entire module at a time -- so using the core of these ideas to reload a method or class (which is what reload does, as it does not update other globals than code related ones). And then, a next bigger step is getting both xreload and xrestart (or related code) into general use into common Python IDEs like IDLE or PyDev. Otherwise, how is a beginner ever going to understand why you would want this xreload piece of code, or how it works, or when to use it? It's one thing to have a bit of code that suggest how something can be done -- it is another to weave an idea throughout a community and a set of application implementations. And the prevalence of those ideas of fine grained changes and fixing code using the debugger and then restarting is a big reason Smalltalk coders are more productive than Python coders, all other things being equal (which of course they are not given licensing, availability, libraries, community, and so on, which is why I use Python instead of Smalltalk. Can't stop pining for the fjords, I guess. :-). One impressive thing about the Python design which I liked from all this was how Python separates the notion of execution code from a pointer reference. That is what makes all these reloading tricks possible. And my hat goes off to Guido for having included the extra level of indirection which makes this feasible. I can hope that generality and late bindingness might also make possible restarting an exception without VM changes. --Paul Fernhout Guido van Rossum wrote: > On 2/24/07, Paul D. Fernhout wrote: >>To step back for a minute, the fundamental problem here is that for >>whatever reason a programmer wants to modify just one method of an already >>loaded Python class (which came from a textual module which was loaded >>already), save the change somewhere so it can be reloaded later >>(overwriting part of the textual module?), and also have the program start >>using the new behavior for existing instances without any other side >>effects arising from recompiling this one change. In practice, this is >>trivial to do in almost any Smalltalk system; it is hard if not impossible >>to do in any widely used Python IDE or program (even when a Python shell >>is embedded). > > # xreload.py. > > """Alternative to reload(). > > This works by executing the module in a scratch namespace, and then > patching classes, methods and functions. This avoids the need to > patch instances. New objects are copied into the target namespace. > """ > > import imp > import sys > import types > > > def xreload(mod): > """Reload a module in place, updating classes, methods and functions. > > Args: > mod: a module object > > Returns: > The (updated) input object itself. > """ > # Get the module name, e.g. 'foo.bar.whatever' > modname = mod.__name__ > # Get the module namespace (dict) early; this is part of the type check > modns = mod.__dict__ > # Parse it into package name and module name, e.g. 'foo.bar' and 'whatever' > i = modname.rfind(".") > if i >= 0: > pkgname, modname = modname[:i], modname[i+1:] > else: > pkgname = None > # Compute the search path > if pkgname: > # We're not reloading the package, only the module in it > pkg = sys.modules[pkgname] > path = pkg.__path__ # Search inside the package > else: > # Search the top-level module path > pkg = None > path = None # Make find_module() uses the default search path > # Find the module; may raise ImportError > (stream, filename, (suffix, mode, kind)) = imp.find_module(modname, path) > # Turn it into a code object > try: > # Is it Python source code or byte code read from a file? > # XXX Could handle frozen modules, zip-import modules > if kind not in (imp.PY_COMPILED, imp.PY_SOURCE): > # Fall back to built-in reload() > return reload(mod) > if kind == imp.PY_SOURCE: > source = stream.read() > code = compile(source, filename, "exec") > else: > code = marshal.load(stream) > finally: > if stream: > stream.close() > # Execute the code im a temporary namespace; if this fails, no changes > tmpns = {} > exec(code, tmpns) > # Now we get to the hard part > oldnames = set(modns) > newnames = set(tmpns) > # Add newly introduced names > for name in newnames - oldnames: > modns[name] = tmpns[name] > # Delete names that are no longer current > for name in oldnames - newnames - set(["__name__"]): > del modns[name] > # Now update the rest in place > for name in oldnames & newnames: > modns[name] = _update(modns[name], tmpns[name]) > # Done! > return mod > > > def _update(oldobj, newobj): > """Update oldobj, if possible in place, with newobj. > > If oldobj is immutable, this simply returns newobj. > > Args: > oldobj: the object to be updated > newobj: the object used as the source for the update > > Returns: > either oldobj, updated in place, or newobj. > """ > if type(oldobj) is not type(newobj): > # Cop-out: if the type changed, give up > return newobj > if hasattr(newobj, "__reload_update__"): > # Provide a hook for updating > return newobj.__reload_update__(oldobj) > if isinstance(newobj, types.ClassType): > return _update_class(oldobj, newobj) > if isinstance(newobj, types.FunctionType): > return _update_function(oldobj, newobj) > if isinstance(newobj, types.MethodType): > return _update_method(oldobj, newobj) > # XXX Support class methods, static methods, other decorators > # Not something we recognize, just give up > return newobj > > > def _update_function(oldfunc, newfunc): > """Update a function object.""" > oldfunc.__doc__ = newfunc.__doc__ > oldfunc.__dict__.update(newfunc.__dict__) > oldfunc.func_code = newfunc.func_code > oldfunc.func_defaults = newfunc.func_defaults > # XXX What else? > return oldfunc > > > def _update_method(oldmeth, newmeth): > """Update a method object.""" > # XXX What if im_func is not a function? > _update_function(oldmeth.im_func, newmeth.im_func) > return oldmeth > > > def _update_class(oldclass, newclass): > """Update a class object.""" > # XXX What about __slots__? > olddict = oldclass.__dict__ > newdict = newclass.__dict__ > oldnames = set(olddict) > newnames = set(newdict) > for name in newnames - oldnames: > setattr(oldclass, name, newdict[name]) > for name in oldnames - newnames: > delattr(oldclass, name) > for name in oldnames & newnames - set(["__dict__", "__doc__"]): > setattr(oldclass, name, newdict[name]) > return oldclass > From eric.frost at mp2kmag.com Sun Feb 25 18:57:00 2007 From: eric.frost at mp2kmag.com (Eric Frost) Date: Sun, 25 Feb 2007 11:57:00 -0600 Subject: [Edu-sig] Training or cert Message-ID: I might be taking a job for which there is a need for some python programming, I'm decent at it but no export. I'm sure this question has been asked before but is there some on-line training course leading to a "certificate of completion" so I prove at least a minimal level of Python knowledge instead of just saying "yeah, I know Python". The only thing I've found is this BrainBench but it's 1.5 -- http://www.brainbench.com/xml/bb/common/testcenter/taketest.xml?testId=443 Any other recommendation? Thanks! Eric http://www.xmlelves.com/community From kirby.urner at gmail.com Sun Feb 25 20:58:55 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 25 Feb 2007 11:58:55 -0800 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: <45E1C102.4050706@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> Message-ID: > One impressive thing about the Python design which I liked from all this > was how Python separates the notion of execution code from a pointer > reference. That is what makes all these reloading tricks possible. And my > hat goes off to Guido for having included the extra level of indirection > which makes this feasible. I can hope that generality and late bindingness > might also make possible restarting an exception without VM changes. > > --Paul Fernhout > You might want to raise your ideas on the IronPython list as well. As you know from vast Jython experience, there's no one Python VM, but any number, depending on which people decide which system language to use for that purpose. So far, C, Java and C# have been among the primary choices, but maybe those cell phones are using something else. I've seen demos of the Microsoft debugger stepping through Python then switching to C# as it follows the source to a deeper layer, then back out to Python again. But I don't recall if the IDE permitted editing on the fly or not, if paused at exceptions. Kirby From guido at python.org Sun Feb 25 21:25:11 2007 From: guido at python.org (Guido van Rossum) Date: Sun, 25 Feb 2007 14:25:11 -0600 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: <45E1C102.4050706@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> Message-ID: On 2/25/07, Paul D. Fernhout wrote: > This xreload module Guido supplies is similar to the approach I used for > Jython in my earlier link. > http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html > If you look at that thread, I acknowledge Michael Spencer as having > supplied some of the more sophisticated reload logic which is similar to > what Guido has posted here (not sure where Michael got it from of course, > nor where Guido got xreload from). See Michael's first related post here: > http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html I think I was inspired by something I heard someone say about Twisted's rebuild (?) module. But I've never seen the code. > Notice xreload's update is much smaller than the one I made with Michael's > additional inspiration and ideas: > http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html Well it needs work. The version I checked into the py3k branch is a bit better and I hope to continue to develop it there. > In some ways, xreload's is better by including a general "Provide a hook > for updating" concept. However xreload just ignores what to do with top > level objects like lists or dicts -- xreload apparently throws away the > updates to them. No it just replaces the whole object. I was just punting on this; what are the required semantics? > Notice it is not recursive -- for example does it handle > nested classes? This was an omission. The svn version is, and should handle nested classes just fine. > I'm not sure of all the reasons for the other differences > -- it was tricky code I admit I never fully understood how to write > thoroughly, mucking about with Python/Jython internals I only hazily > understood. And even for the reload code I supplied, it is not always > clear what to do with changes to top level objects -- do you want to > update them or replace them? If you do update them, how deeply do you want > the update to go? Right. I offer clean if limited semantics so you can write your code to work with it -- and a hook so you can extend it. A registration mechanism keyed on the class could easily be added (or using generic functions :-). > Notice xreload still has sections with comments like "Not something we > recognize, just give up" (that's throwing away changes to top level lists > and dicts and singletons and such), No it throws away the old version. > or "Cop-out: if the type changed, give > up", and it can not handle in general the issue of side effects I > mentioned (e.g. is a singleton instance recreated?). And of course you > can't use it to restart an exception after making a change (though it is > perhaps a piece of that puzzle). It does however deal with updating > pointers to existing function as far as I can tell (so previously set GUI > callbacks will still call the old code) -- and does it in the same way the > previous code linked to did (e.g. oldfunc.func_code = newfunc.func_code). There just is no way to handle *all* possibilities. How would you handle renamings? > So, the xreload module Guido supplies is nifty piece of code to have > (assuming Python licensed?). Using it properly will make you more > productive. However, it still requires building hooks into your > application explicitly to call it for each module of interest; the Jython > version I supplied includes a brief GUI control window listing all modules > which could be made to work similarly under wx or tk. The GUI part isn't supposed to be included. There's also the issue of what to do with dependencies; if x imports y, and y is reloaded, x probably needs to be reloaded too... > Still, elegant as it is (including the reload hook), even xreload does not > handle all the important cases -- just (forgive me :-) the *easy* ones. > > When Guido supplies an xrestart.py :-) python 2.5 code module that lets > you restart exceptions after having modified one of the functions in the > stack trace, then I will admit it is something I have never seen before in > Python and be suitably impressed. Is it even possible without modifying > the VM? :-) It is impossible because we don't know whether the exception has a handler (an except block that traps it) until we've bubbled all the way up. I suggest it's pointless to try to emulate every single common lisp feature in Python. The resulting language would *be* common lisp and nobody would want it. > There will remain the semantic problem of what to do with top level > objects, but as I said, one can avoid that somewhat by just never > expecting to reload an entire module at a time -- so using the core of > these ideas to reload a method or class (which is what reload does, as it > does not update other globals than code related ones). You seem to be building a whole body of misunderstandings on this one misconception. > And then, a next bigger step is getting both xreload and xrestart (or > related code) into general use into common Python IDEs like IDLE or PyDev. Well that's up to the IDE authors right? [Irrelevant paragraph snipped] > One impressive thing about the Python design which I liked from all this > was how Python separates the notion of execution code from a pointer > reference. Can you clarify this for someone who is not familiar with Smalltalk? (Your habit of explaining every idea by comparing it to how that idea was implemented in Smalltalk doesn't help the audience understand you -- you're preaching to the choir when you do that, and the rest of the congregation is lost.) > That is what makes all these reloading tricks possible. And my > hat goes off to Guido for having included the extra level of indirection > which makes this feasible. I can hope that generality and late bindingness > might also make possible restarting an exception without VM changes. Why do you care about avoidung VM changes? The VM changes (incrementally) at each minor Python release. --Guido > --Paul Fernhout > > Guido van Rossum wrote: > > On 2/24/07, Paul D. Fernhout wrote: > >>To step back for a minute, the fundamental problem here is that for > >>whatever reason a programmer wants to modify just one method of an already > >>loaded Python class (which came from a textual module which was loaded > >>already), save the change somewhere so it can be reloaded later > >>(overwriting part of the textual module?), and also have the program start > >>using the new behavior for existing instances without any other side > >>effects arising from recompiling this one change. In practice, this is > >>trivial to do in almost any Smalltalk system; it is hard if not impossible > >>to do in any widely used Python IDE or program (even when a Python shell > >>is embedded). > > > > # xreload.py. > > > > """Alternative to reload(). > > > > This works by executing the module in a scratch namespace, and then > > patching classes, methods and functions. This avoids the need to > > patch instances. New objects are copied into the target namespace. > > """ > > > > import imp > > import sys > > import types > > > > > > def xreload(mod): > > """Reload a module in place, updating classes, methods and functions. > > > > Args: > > mod: a module object > > > > Returns: > > The (updated) input object itself. > > """ > > # Get the module name, e.g. 'foo.bar.whatever' > > modname = mod.__name__ > > # Get the module namespace (dict) early; this is part of the type check > > modns = mod.__dict__ > > # Parse it into package name and module name, e.g. 'foo.bar' and 'whatever' > > i = modname.rfind(".") > > if i >= 0: > > pkgname, modname = modname[:i], modname[i+1:] > > else: > > pkgname = None > > # Compute the search path > > if pkgname: > > # We're not reloading the package, only the module in it > > pkg = sys.modules[pkgname] > > path = pkg.__path__ # Search inside the package > > else: > > # Search the top-level module path > > pkg = None > > path = None # Make find_module() uses the default search path > > # Find the module; may raise ImportError > > (stream, filename, (suffix, mode, kind)) = imp.find_module(modname, path) > > # Turn it into a code object > > try: > > # Is it Python source code or byte code read from a file? > > # XXX Could handle frozen modules, zip-import modules > > if kind not in (imp.PY_COMPILED, imp.PY_SOURCE): > > # Fall back to built-in reload() > > return reload(mod) > > if kind == imp.PY_SOURCE: > > source = stream.read() > > code = compile(source, filename, "exec") > > else: > > code = marshal.load(stream) > > finally: > > if stream: > > stream.close() > > # Execute the code im a temporary namespace; if this fails, no changes > > tmpns = {} > > exec(code, tmpns) > > # Now we get to the hard part > > oldnames = set(modns) > > newnames = set(tmpns) > > # Add newly introduced names > > for name in newnames - oldnames: > > modns[name] = tmpns[name] > > # Delete names that are no longer current > > for name in oldnames - newnames - set(["__name__"]): > > del modns[name] > > # Now update the rest in place > > for name in oldnames & newnames: > > modns[name] = _update(modns[name], tmpns[name]) > > # Done! > > return mod > > > > > > def _update(oldobj, newobj): > > """Update oldobj, if possible in place, with newobj. > > > > If oldobj is immutable, this simply returns newobj. > > > > Args: > > oldobj: the object to be updated > > newobj: the object used as the source for the update > > > > Returns: > > either oldobj, updated in place, or newobj. > > """ > > if type(oldobj) is not type(newobj): > > # Cop-out: if the type changed, give up > > return newobj > > if hasattr(newobj, "__reload_update__"): > > # Provide a hook for updating > > return newobj.__reload_update__(oldobj) > > if isinstance(newobj, types.ClassType): > > return _update_class(oldobj, newobj) > > if isinstance(newobj, types.FunctionType): > > return _update_function(oldobj, newobj) > > if isinstance(newobj, types.MethodType): > > return _update_method(oldobj, newobj) > > # XXX Support class methods, static methods, other decorators > > # Not something we recognize, just give up > > return newobj > > > > > > def _update_function(oldfunc, newfunc): > > """Update a function object.""" > > oldfunc.__doc__ = newfunc.__doc__ > > oldfunc.__dict__.update(newfunc.__dict__) > > oldfunc.func_code = newfunc.func_code > > oldfunc.func_defaults = newfunc.func_defaults > > # XXX What else? > > return oldfunc > > > > > > def _update_method(oldmeth, newmeth): > > """Update a method object.""" > > # XXX What if im_func is not a function? > > _update_function(oldmeth.im_func, newmeth.im_func) > > return oldmeth > > > > > > def _update_class(oldclass, newclass): > > """Update a class object.""" > > # XXX What about __slots__? > > olddict = oldclass.__dict__ > > newdict = newclass.__dict__ > > oldnames = set(olddict) > > newnames = set(newdict) > > for name in newnames - oldnames: > > setattr(oldclass, name, newdict[name]) > > for name in oldnames - newnames: > > delattr(oldclass, name) > > for name in oldnames & newnames - set(["__dict__", "__doc__"]): > > setattr(oldclass, name, newdict[name]) > > return oldclass > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From pdfernhout at kurtz-fernhout.com Mon Feb 26 00:25:01 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 25 Feb 2007 18:25:01 -0500 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> Message-ID: <45E21ACD.4000906@kurtz-fernhout.com> Guido van Rossum wrote: >>In some ways, xreload's is better by including a general "Provide a hook >>for updating" concept. However xreload just ignores what to do with top >>level objects like lists or dicts -- xreload apparently throws away the >>updates to them. > > > No it just replaces the whole object. I was just punting on this; what > are the required semantics? You're right; I read this wrong. The point about required semantics for global objects when reloading their modules is that there are none. As you say, one might imagine different situations requiring different effects when you reload a module. Perhaps you could make a pragma directive, or define a reload hook like you set up, but even then the need might vary depending on how you are developing (i.e. is the point of the reload because you changed a method or because you changed that specific global data structure?). The point is that reloading an entire module forces you to think about this -- reloading just a method lets you ignore the problem. > There just is no way to handle *all* possibilities. How would you > handle renamings? Selectively in the IDE? :-) > The GUI part isn't supposed to be included. There's also the issue of > what to do with dependencies; if x imports y, and y is reloaded, x > probably needs to be reloaded too... Yes -- another reason not to want to reload an entire module if it can be avoided. Although in practice, this seems a bigger problem when doing a regular reload rather than when doing an xreload type thing (since other modules which are handing onto the classes get the new behavior). >>Still, elegant as it is (including the reload hook), even xreload does not >>handle all the important cases -- just (forgive me :-) the *easy* ones. >> >>When Guido supplies an xrestart.py :-) python 2.5 code module that lets >>you restart exceptions after having modified one of the functions in the >>stack trace, then I will admit it is something I have never seen before in >>Python and be suitably impressed. Is it even possible without modifying >>the VM? :-) > > > It is impossible because we don't know whether the exception has a > handler (an except block that traps it) until we've bubbled all the > way up. OK, impossible as things are now. Why not keep the stack of internal objects (exception handlers?) around somehow so that after you have bubbled up, you can present that stack of objects to the debugger? The point is not to go into the debugger on every exception. The point is that when you are debugging you can make changes -- either while stepping, or when an otherwise unhanded exception occurs. Essentially, think of it as a having default exception handler that throws you into the debugger at the point the exception is created (but before any related handling is done, like in finally clauses). I don't know the CPython internals on exception handling, so I do not know what would be easy to do. Perhaps you can not look up the stack of exception handlers to see if anyone would catch it without processing each handler's finally clause first? And even if you can, you would still need to hold that entire exception processing stack around so that if someone closes the debugger window (or entire application) without restarting the exception those finally clauses get done. It may require adding an entire level of abstraction to exception handling if it is impossible now? Also, in the case of Smalltalk, one can always add a "Self halt" that throws an exception for sure which almost certainly reaches the debugger. It is common to create a method function with just "self halt" and when that is called, then fill out the method in the debugger. Coding in the debugger is an entirely different style of software development. Sometimes it is very nice. http://www.google.com/search?hl=en&q=smalltalk+%22coding+in+the+debugger%22 Again, for small programs this may not matter, but when writing, say, a simulation which may run for hours, having to restart when you get an unhanded exception (like from a minor typo) can really harm productivity. >>One impressive thing about the Python design which I liked from all this >>was how Python separates the notion of execution code from a pointer >>reference. > > > Can you clarify this for someone who is not familiar with Smalltalk? > (Your habit of explaining every idea by comparing it to how that idea > was implemented in Smalltalk doesn't help the audience understand you > -- you're preaching to the choir when you do that, and the rest of the > congregation is lost.) Smalltalk has a separation too of behavior (a method) from invocation using a "selector" or name of a method by sending a message -- I was just thinking how much better this was, than, say C, where a function's actual code location is tightly tied to the pointer to the function. So you can't take a C function pointer and just assign new code to it. > >>That is what makes all these reloading tricks possible. And my >>hat goes off to Guido for having included the extra level of indirection >>which makes this feasible. I can hope that generality and late bindingness >>might also make possible restarting an exception without VM changes. > > > Why do you care about avoidung VM changes? The VM changes > (incrementally) at each minor Python release. Just so everyone (especially *me* :-) can use start using it right now, including in older versions of Python (like 2.4 etc.). Of course, I would have to break that bad habit I've gotten into of restarting the program every time I make a change -- and it's hard to break that habit, even when I use a supplemental tool that lets me reload Jython modules selectively -- I keep thinking -- I did not have to restart. :-) Still, even with all this, if you are making a GUI and modify the function that defines the window, you generally still need to close and open the window again. So there remain limits (unless you move to GUIs defined interactively like Morphic or PataPata). Just talking about getting most of the benefit. --Paul Fernhout From lac at openend.se Mon Feb 26 01:54:15 2007 From: lac at openend.se (Laura Creighton) Date: Mon, 26 Feb 2007 01:54:15 +0100 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: Message from "Paul D. Fernhout" of "Sun, 25 Feb 2007 18:25:01 EST." <45E21ACD.4000906@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> <45E21ACD.4000906@kurtz-fernhout.com> Message-ID: <200702260054.l1Q0sFdh008803@theraft.openend.se> Speakingf as swho has maintained a smalltalk interpreter ... In a message of Sun, 25 Feb 2007 18:25:01 EST, "Paul D. Fernhout" writes: > >> Why do you care about avoidung VM changes? The VM changes >> (incrementally) at each minor Python release. > >Just so everyone (especially *me* :-) can use start using it right now, >including in older versions of Python (like 2.4 etc.). > >Of course, I would have to break that bad habit I've gotten into of >restarting the program every time I make a change -- and it's hard to >break that habit, even when I use a supplemental tool that lets me reload > >Jython modules selectively -- I keep thinking -- I did not have to >restart. :-) > >Still, even with all this, if you are making a GUI and modify the functio >n >that defines the window, you generally still need to close and open the >window again. So there remain limits (unless you move to GUIs defined >interactively like Morphic or PataPata). Just talking about getting most >of the benefit. > Ah, because its we have tons of legacy Smalltalk code that was really well and truly built with the idea that the VM would never change and we could play tricks on its bytecode forever. Lots of us did strage and wonderfukl things and now no change to the byte code, no matter how reasonable on the surface, will break many things. Stuff that just got stored that weay bwecause, 'why not' and now is stuck in the space that is between 'officially sanctioned' and 'used commonly' for various va?lues of common. Its enough tomake smalltalk hackers want to make changes in the language as never is to change the bytecode. Because everbody as matters is making their own hacks with live-but-modified bytecode. Laura From lac at openend.se Mon Feb 26 01:55:44 2007 From: lac at openend.se (Laura Creighton) Date: Mon, 26 Feb 2007 01:55:44 +0100 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: Message from Laura Creighton of "Mon, 26 Feb 2007 01:54:15 +0100." <200702260054.l1Q0sFdh008803@theraft.openend.se> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> <45E21ACD.4000906@kurtz-fernhout.com> <200702260054.l1Q0sFdh008803@theraft.openend.se> Message-ID: <200702260055.l1Q0ti6V009545@theraft.openend.se> In a message of Mon, 26 Feb 2007 01:54:15 +0100, Laura Creighton writes: > >Speakingf as swho has maintained a smalltalk interpreter ... > >In a message of Sun, 25 Feb 2007 18:25:01 EST, "Paul D. Fernhout" writes: > > >> >>> Why do you care about avoidung VM changes? The VM changes >>> (incrementally) at each minor Python release. >> >>Just so everyone (especially *me* :-) can use start using it right now, >>including in older versions of Python (like 2.4 etc.). >> >>Of course, I would have to break that bad habit I've gotten into of >>restarting the program every time I make a change -- and it's hard to >>break that habit, even when I use a supplemental tool that lets me reloa >d >> >>Jython modules selectively -- I keep thinking -- I did not have to >>restart. :-) >> >>Still, even with all this, if you are making a GUI and modify the functi >o >>n >>that defines the window, you generally still need to close and open the >>window again. So there remain limits (unless you move to GUIs defined >>interactively like Morphic or PataPata). Just talking about getting most > >>of the benefit. >> > >Ah, because its we have tons of legacy Smalltalk code that was >really well and truly built with the idea that the VM would never >change and we could play tricks on its bytecode forever. Lots of >us did strage and wonderfukl things and now no change to the >byte code, no matter how reasonable on the surface, will break >many things. Stuff that just got stored that weay bwecause, >'why not' and now is stuck in the space that is between >'officially sanctioned' and 'used commonly' for various >va?lues of common. > >Its enough tomake smalltalk hackers want to make changes in the >language as never is to change the bytecode. Because everbody >as matters is making their own hacks with live-but-modified bytecode. > >Laura I forgot -- getting rid of this was one of the joys of squeak .... From guido at python.org Tue Feb 27 01:30:40 2007 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Feb 2007 18:30:40 -0600 Subject: [Edu-sig] [Python-3000] Pre-PEP: Simple input built-in in Python 3000 In-Reply-To: References: <7528bcdd0612220545u147f07a4gb476dd43733dfe46@mail.gmail.com> <7528bcdd0702191032n4347e8c8p6987553deb9be445@mail.gmail.com> <45DAFEDE.4030109@gmail.com> <7528bcdd0702200901r62f8cc4fu7ea7f1e59725e4b6@mail.gmail.com> Message-ID: We implemented this at today's sprint. Andre wrote the transformations for the 2to3 tools, I copied the raw_input() implementation from the trunk back into the p3yk branch. Thanks Andre for your efforts in writing the PEP, pushing for its implementation, and writing the transformations! --Guido On 2/20/07, Guido van Rossum wrote: > Consider the PEP accepted. > > Regarding the conversion, please do use the sandbox/2to3 framework. > Write me if you have trouble understanding the many examples already > in fixes/. > > On 2/20/07, Andre Roberge wrote: > > On 2/20/07, Guido van Rossum wrote: > > > Why do you want this *before* PyCon? It would be much easier to do > > > this as part of the Py3k sprint. > > > > > > > My main interest was to have, prior to Pycon, the PEP recorded as > > such; it had been close to 2 months since the last post on this issue > > on the list. > > > > As for the actual work, I'd be willing to volunteer to write the > > required code (with test cases) that could be use to do the conversion > > input(...) -> eval(input(...)) > > raw_input(...) -> input(...) > > > > Unfortunately, I will not be participating in any sprints. > > > > Andr? > > > > > > > > > On 2/20/07, Nick Coghlan wrote: > > > > Andre Roberge wrote: > > > > > Any possibility that (some of) the following can be done before Pycon? > > > > > Respectfully yours, > > > > > Andr? Roberge > > > > > > > > I've added the PEP as 3111. I made a few small modifications (and > > > > committed it directly as Accepted) based on Guido's comments in this thread. > > > > > > > > The actual change still needs to be made, though. > > > > > > > > Cheers, > > > > Nick. > > > > > > > > -- > > > > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > > > > --------------------------------------------------------------- > > > > http://www.boredomandlaziness.org > > > > _______________________________________________ > > > > Python-3000 mailing list > > > > Python-3000 at python.org > > > > http://mail.python.org/mailman/listinfo/python-3000 > > > > Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org > > > > > > > > > > > > > -- > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From john.zelle at wartburg.edu Tue Feb 27 16:28:38 2007 From: john.zelle at wartburg.edu (John Zelle) Date: Tue, 27 Feb 2007 09:28:38 -0600 Subject: [Edu-sig] [Python-3000] Pre-PEP: Simple input built-in in Python 3000 In-Reply-To: References: <7528bcdd0612220545u147f07a4gb476dd43733dfe46@mail.gmail.com> Message-ID: <200702270928.38243.john.zelle@wartburg.edu> Thank you to Andre, Guido, and all those who pushed for this! Your efforts are appreciated! --John On Monday 26 February 2007 6:30 pm, Guido van Rossum wrote: > We implemented this at today's sprint. Andre wrote the transformations > for the 2to3 tools, I copied the raw_input() implementation from the > trunk back into the p3yk branch. Thanks Andre for your efforts in > writing the PEP, pushing for its implementation, and writing the > transformations! > > --Guido > > On 2/20/07, Guido van Rossum wrote: > > Consider the PEP accepted. > > > > Regarding the conversion, please do use the sandbox/2to3 framework. > > Write me if you have trouble understanding the many examples already > > in fixes/. > > > > On 2/20/07, Andre Roberge wrote: > > > On 2/20/07, Guido van Rossum wrote: > > > > Why do you want this *before* PyCon? It would be much easier to do > > > > this as part of the Py3k sprint. > > > > > > My main interest was to have, prior to Pycon, the PEP recorded as > > > such; it had been close to 2 months since the last post on this issue > > > on the list. > > > > > > As for the actual work, I'd be willing to volunteer to write the > > > required code (with test cases) that could be use to do the conversion > > > input(...) -> eval(input(...)) > > > raw_input(...) -> input(...) > > > > > > Unfortunately, I will not be participating in any sprints. > > > > > > Andr? > > > > > > > On 2/20/07, Nick Coghlan wrote: > > > > > Andre Roberge wrote: > > > > > > Any possibility that (some of) the following can be done before > > > > > > Pycon? Respectfully yours, > > > > > > Andr? Roberge > > > > > > > > > > I've added the PEP as 3111. I made a few small modifications (and > > > > > committed it directly as Accepted) based on Guido's comments in > > > > > this thread. > > > > > > > > > > The actual change still needs to be made, though. > > > > > > > > > > Cheers, > > > > > Nick. > > > > > > > > > > -- > > > > > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > > > > > --------------------------------------------------------------- > > > > > http://www.boredomandlaziness.org > > > > > _______________________________________________ > > > > > Python-3000 mailing list > > > > > Python-3000 at python.org > > > > > http://mail.python.org/mailman/listinfo/python-3000 > > > > > Unsubscribe: > > > > > http://mail.python.org/mailman/options/python-3000/guido%40python.o > > > > >rg > > > > > > > > -- > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Tue Feb 27 16:39:59 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 27 Feb 2007 07:39:59 -0800 Subject: [Edu-sig] [Python-3000] Pre-PEP: Simple input built-in in Python 3000 In-Reply-To: <200702270928.38243.john.zelle@wartburg.edu> References: <7528bcdd0612220545u147f07a4gb476dd43733dfe46@mail.gmail.com> <200702270928.38243.john.zelle@wartburg.edu> Message-ID: On 2/27/07, John Zelle wrote: > Thank you to Andre, Guido, and all those who pushed for this! Your efforts are > appreciated! > > --John > Yeah, likewise congrats, even though I devil's advocated against it as I recall. Kirby From racter at gmail.com Tue Feb 27 21:00:32 2007 From: racter at gmail.com (jake elliott) Date: Tue, 27 Feb 2007 14:00:32 -0600 Subject: [Edu-sig] chicago hackmeeting 003 : lateral education Message-ID: hello python edu siggers, apologies if you have seen this information on another channel i'm reaching out for interest in developing the third chicago hackmeeting - a collaboratively wiki-programmed conference slated for march 16,17,18 @ daisychain [dai5ychain.net] in pilsen.chicago.il.us. This hackmeeting is loosely themed around ( processes | projects | practices ) of ( punk | lo-fi | bbs | irc | scriptkiddy ) training+education+skill-sharing. education as a component of a radical social practice + mashing up (h)ac(k)ademics. in other words - would love to host conversations+presentations+workshops on unschooling/electronic_constructivist/etc tactics employed in the projects discussed on this listserv, and of course detailed examination of the projects themselves. the wiki we(|you)'re using to organize the weekend: http://hackmeetingwiki.dai5ychain.net/Hackmeeting003 if you are not in chicago but still have an idea for a discussion/workshop/presentation, propose it on the wiki + someone in chicago will try to pick it up and facilitate it! best, jake From kirby.urner at gmail.com Tue Feb 27 23:35:28 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 27 Feb 2007 14:35:28 -0800 Subject: [Edu-sig] chicago hackmeeting 003 : lateral education In-Reply-To: References: Message-ID: > in other words - would love to host > conversations+presentations+workshops on > unschooling/electronic_constructivist/etc tactics employed in the > projects discussed on this listserv, and of course detailed > examination of the projects themselves. Sounds like fun jake, might dive in to your wiki. Whereas our family studied the unschooling literature, having been on the inside as a math teacher myself, I empathize with my embattled peers, still on the front lines, still not allowed to use Python, not even to teach basic algebra (!?). How unfree, how dummydum DarkAges [tm]. So to help my embattled peers, I just threw together this little screencast, some pro Python propaganda for the masses, so-called: Blurb: You're trying to persuade your peers or administrative higher ups that your plans to integrate Python and math teaching are strictly in accordance with traditional best practices. Strategy: show how the basics of algebra, such as the definition and composition of functions, are faithfully communicated in the Python command line, with work saved between sessions. Students will be building portfolios -- which is what we're already encouraging. Low resolution (faster download) version: http://video.google.com/videoplay?docid=-5074650591675526366 Higher rez (slower download) version: http://www.4dsolutions.net/ocn/python/pycalc/pycalc.html Running time: 4 mins 12 secs. Kirby