From urnerk at qwest.net Wed Aug 3 01:01:49 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Tue, 2 Aug 2005 19:01:49 -0400 Subject: [Edu-sig] From Kirby at OSCON Message-ID: <380-2200582223149446@M2W055.mail2web.com> Greetings edu-siggers -- I'm posting from OSCON 2005. If you want to watch over my shoulder, my highly personalized angle on events is being chronicled (by me) @ Grain of Sand (my blog). http://worldgame.blogspot.com/ -- good conference so far, though it really starts tomorrow (we're in the tutorial/workshop frame). Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From urnerk at qwest.net Thu Aug 4 01:42:33 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Wed, 3 Aug 2005 19:42:33 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk Message-ID: <380-22005833234233883@M2W065.mail2web.com> My presentation: I had tech support fiddling with sound during the opening, while I browsed my presentation manager's source code for a minute or two -- didn't get into it as deeply as I'd have liked, but hey, it's on the web. The sound problem was soon solved. Then I launched into the slides, with an interruption at slide 9 to go out on the web and run both Springie and Fluidiom. My general theme: thanks to open source and design science, our school's ability to collaborate has become vastly easier and more effective over the years. I covered a lot of material using a sort of frenetic pin-ball/scatter- gun approach, using the slides as a guide: the nationless Fuller Projection, Rick's dome program, tensegrity, elastic interval geometry, octet truss, sphere packing, quadrays, Grunch of Giants, intellectual property, education reform, making a difference. A bit too manic for my taste (45 minutes isn't much time). The people who came to the table afterwards seemed seriously into learning more, especially with regard to providing kids with a better education. One guy asked what planet I was from. At one point in my talk, I predicted we'd soon have open source repositories of downloadable audio/video clips, which kids'd pull down to their computer desktops, mix with new content, and reupload back to the servers (the same process used with software today, but applied to making video). Schools like ours could harness this economy to foment the production of more relevant educational materials. [ the above is an excerpt from my longer blog entry of today ] -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From ajsiegel at optonline.net Thu Aug 4 04:45:17 2005 From: ajsiegel at optonline.net (Arthur) Date: Wed, 03 Aug 2005 22:45:17 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <380-22005833234233883@M2W065.mail2web.com> Message-ID: <0IKO00KB9FO5P500@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On Kirby wrote - > > At one point in my talk, I predicted we'd soon have open source > repositories of downloadable audio/video clips, which kids'd pull down to > their computer desktops, mix with new content, and reupload back to the > servers (the same process used with software today, but applied to making > video). Schools like ours could harness this economy to foment the > production of more relevant educational materials. > Having proved (to myself) I could shut up here for a month - I will comment. Predictably - I am afraid Open source versus closed source seems to me somewhere around number 8 on the list of issues in respect to assessing worthwhile technologically derived/connected "educational materials", versus worthless such materials, versus actively destructive such materials. Where might a self-proclaimed intelligent person go to discuss with other such persons 1 through 7, without the diversion of 8? Is there an 8 don't make it right crowd to plug into? Art From urnerk at qwest.net Thu Aug 4 07:24:31 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 3 Aug 2005 22:24:31 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKO00KB9FO5P500@mta5.srv.hcvlny.cv.net> Message-ID: <20050804052437.EC2141E4008@bag.python.org> > Open source versus closed source seems to me somewhere around number 8 on > the list of issues in respect to assessing worthwhile technologically > derived/connected "educational materials", versus worthless such > materials, versus actively destructive such materials. For me, it's more a matter of putting tools in the hands of a next generation, knowing in advance that a *lot* of what they'll come up with I'll consider of questionable quality. But who made me the judge? I'm entitled to my opinions, yes, but many times I'm not especially trying to have an opinion on a specific Sourceforge or Freshmeat asset; I'm content to trust the judgment of others. More important is to lower barriers to access, which is where open source comes in. It's about dealing cards to whomever wants to sit at our table. If they play their hands badly, that's another issue. Like, what if Microsoft had won, and every Chinese kid really *did* have to pay in hard currency, per EULA, for a copy of Windows? How many would grow up to be programmers? But now they have legal alternatives: Linux, FreeBSD, OpenSolaris. That's a major twist in evolution, not just petty politics. You seem to think your main role is a thumbs up thumbs down kind of role, whereas I'm more just asking myself what it'd take to lower the barriers to more kids being able to make their own television -- not just sit as passive viewers. I don't think it's healthy how we bombard kids with our so-called "commercial messages" and yet don't really arm them to fight back with their own views and experiences, even if that just means thinking critically, questioning authority. 'Mad Magazine' was on the right track -- a kind of early/prototypical 'Head First Into...' (O'Reilly series), or like the title 'Questioning Culture for Dummies.' > Where might a self-proclaimed intelligent person go to discuss with other > such persons 1 through 7, without the diversion of 8? > I'd be open to your listing range(7), i.e. [0,1,2,3,4,5,6]. > Is there an 8 don't make it right crowd to plug into? > > Art > failure to parse sentence reading "Is there an 8 don't make it right crowd to plug into?" Kirby From ajsiegel at optonline.net Thu Aug 4 15:50:54 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 04 Aug 2005 09:50:54 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKO00H09N0VT3M0@mta22.srv.hcvlny.cv.net> Message-ID: <0IKP00HU5AH9YCRI@mta9.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > > Where might a self-proclaimed intelligent person go to discuss with > other > > such persons 1 through 7, without the diversion of 8? > > > > I'd be open to your listing range(7), i.e. [0,1,2,3,4,5,6]. First let me address number 8, positively. Because I am positive that open source is a significant and important + mark. Barry Warsaw has a blog with one entry: Learning by Breaking http://www.artima.com/weblogs/viewpost.jsp?thread=5477 Open source software is eminently breakable - and therefore eminently suitable for learning. But the prospect of making this an effective selling point - no matter how saliently true it might be under a particular circumstance - is so daunting as to seem foolhardy. And I keep coming of against that - what seems true seems foolhardy to pursue. So I tend to fall back on an instinct to fight to call a halt to the process in its entirety. Art From ajsiegel at optonline.net Thu Aug 4 19:06:08 2005 From: ajsiegel at optonline.net (ajsiegel@optonline.net) Date: Thu, 04 Aug 2005 13:06:08 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKP00HU5AH9YCRI@mta9.srv.hcvlny.cv.net> References: <0IKO00H09N0VT3M0@mta22.srv.hcvlny.cv.net> <0IKP00HU5AH9YCRI@mta9.srv.hcvlny.cv.net> Message-ID: Kirby , Bottom line - and it sounds like a terrible thing to say - I am disturbed by your enthusiasm on these subjects. Because I am continually feeling myself asked to accept enthusiasm as a replacement for jugment - in the area of technology and education. Enthusiam may be necessary, but it certainly is not sufficient. I am not voting up or down. I am trying to be an enthusiastic vote for skepticism on these matters. Because that, frankly, is where I perceive the hole in the politic to be - at least at the moment. Can we provide future generations with the realistic possiblity of pursuing *all* options. Let's say we are on the same side. The side of options. The option of concluding that technology is unimportant in the educational process is the one I see closing fastest and most irretrievably. So I concern myself with its advocacy. At least until there is something more reasonable and substantial to discuss. I think I state this concern fairly, reasonably - and sometimes - even without hysteria. But I think I am nonetheless sounding somehow strange. Which I find strange. Art "One of my foreign colleagues gives classes on the esthetics of programming. I advised him to throw away the overhead projector and return to the blackboard. It made him find again the joy of teaching". Edsger Dijkstra From urnerk at qwest.net Fri Aug 5 06:36:47 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 4 Aug 2005 21:36:47 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKP00HU5AH9YCRI@mta9.srv.hcvlny.cv.net> Message-ID: <20050805043654.029051E4009@bag.python.org> > So I tend to fall back on an instinct to fight to call a halt to the > process in its entirety. > > Art > OK, we agree it's important (open source). But I didn't mention selling anything. Just a prediction that these archival video resources might become available, perhaps initially for sale to schools as DVD sets. Other selling might be in the form of studio reputation (what some of the graphics design shops gain in terms of exposure, to potentially paying clients), or in the form of product placement (e.g. many of the math vids might feature TI calculators, or other relevant artifacts e.g. geodesic domes). Kirby From urnerk at qwest.net Fri Aug 5 07:10:09 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 4 Aug 2005 22:10:09 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: Message-ID: <20050805051016.A62641E404A@bag.python.org> > Kirby , > > Bottom line - > > and it sounds like a terrible thing to say - > > I am disturbed by your enthusiasm on these subjects. > Hey that's really OK. "It is permitted to feel disturbed," as some benevolent dictator might say. > Because I am continually feeling myself asked to accept enthusiasm as a > replacement for jugment - in the area of technology and education. > Note that I attempt to provide a lot of context for my own judgments, in my blogs for example. It's pretty clear, in a lot of cases, how I arrive at this or that position. I am what's known as a prolific publisher in cyberspace. > Enthusiam may be necessary, but it certainly is not sufficient. > > I am not voting up or down. > > I am trying to be an enthusiastic vote for skepticism on these matters. > Because that, frankly, is where I perceive the hole in the politic to be - > at least at the moment. > "These matters" is pretty vague, you must admit. It seemed like we were debating whether the attribute "open source" was important in the education sector, and you suggested we rank it about 8th. I might have agreed, as my blog entry was about OSCON, the Open Source Conference (and my Fuller School presentation therein), so of course I was harping on the open source software (OSS) connection, even if it's not really so central. But I think for other reasons (other than the fact this was OSCON) that the open source attribute *is* higher than 8 on the list. Because for kids, affordability is a big variable in the equation, and translates to access. Waiting for the Bill and Melinda Gates Foundation to bring Windows within reach may just not be good enough -- the wait is too long. Your years as a young impressionable, able to learn at wildly accelerated rates, are flying by, and you need exposure to the relevant reading materials and command line shells immediately. That's where open source comes in. Put another way, I think "open source" has always been the way of true scholarship. Scholars deeply believe in crediting sources, not plagiarizing, not fobbing off the hard work of others as one's own. That's true in the open source culture as well. But on the other hand, people didn't work that hard to then *not* have their contributions used. People *want* their hard work to make a difference. So scholars freely avail themselves of the scholarship of others. We help ourselves to one another's offerings while acknowledging our indebtedness. The community of scholars is very much the progenitor of this 21st century culture of free and open source. The chief institution of scholars: the library. What does a library morph into when its assets are digital, i.e. unlimited copies are obtainable without decay? You get an ongoing service, a source. Users aren't "borrowers" in the same sense as in the paper book era, where a failure to return deprived other readers of opportunity. However, users may still "give back" to the service by contributing their own value-added, i.e. the fruits of their own labor (i.e. private capital). > Can we provide future generations with the realistic possiblity of > pursuing *all* options. > > Let's say we are on the same side. The side of options. > > The option of concluding that technology is unimportant in the educational > process is the one I see closing fastest and most irretrievably. We need a definition of technology before we go much further with this. Paper is a technology, and not a trivial one. The infrastructure behind paper is huge. Might we have education without paper? Let's say the answer is yes. How about ball games? Most schools feature those. Aren't balls technology? I say they are. You may think this is all trivial nitpicking, but I say not. Education should prepare kids to survive and thrive in the environments they're choosing. If I'm going to thrive in a fishing village, I'd better learn to mend the nets, judge currents, steer by the stars and so on. If I'm in a highly urbanized environment, I'd better learn to read bus schedules, fill out forms. If both my parents go to OSCON every year, I might want to learn a computer language just because I want to stay in their world -- because I like it, enjoy the people, think "hey, this is my tribe." > So I concern myself with its advocacy. At least until there is something > more reasonable and substantial to discuss. > I think we have many issues at least as reasonable and substantial to discuss. Whether education should feature any technology at all I would rank below whether this technology should be open source, in importance (that's in my own inbox -- your ordering may differ, apparently does). > I think I state this concern fairly, reasonably - and sometimes - even > without hysteria. > > But I think I am nonetheless sounding somehow strange. > > Which I find strange. > > Art It is sounding strange, in part because you're not doing the work to define technology. What should I picture? Why would you target computers so narrowly, as if they're the only technical objects in the room? Many classrooms have aquariums. Why not target them instead? Let's talk about gold fish. If a kid has a cell phone, then the school should help the kid learn how to use it effectively, even how to program it. If it's an established fact that I have a computer, am curious about it, want to learn more about what I might do with it, then I say I have a right to expect my school to assist me (I shouldn't have to rely on the Hillsboro Police Department, although it's willingness to assist has been welcome). If the school says "shut up about computers, we're going at our own pace, covering only topics *we* think are important" then I say I should have a better selection of schools to choose from, and/or of teachers within the school. That too is my right. Kirby From ajsiegel at optonline.net Fri Aug 5 13:12:55 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 05 Aug 2005 07:12:55 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKQ0036YH0XS410@mta20.srv.hcvlny.cv.net> Message-ID: <0IKQ0004LXTOEA50@mta5.srv.hcvlny.cv.net> > From: Kirby Urner [mailto:urnerk at qwest.net] > But I think for other reasons (other than the fact this was OSCON) that > the > open source attribute *is* higher than 8 on the list. Because for kids, > affordability is a big variable in the equation, and translates to access. > Waiting for the Bill and Melinda Gates Foundation to bring Windows within > reach may just not be good enough -- the wait is too long. Again - major disconnect. Worrying about affordability implies we have already concluded that access to this stuff - in providing good education - matters much. Gates, the Open Source movement, politicians of various stripes are fighting over credit for providing this access, massively. All hands on deck for a massive redirection of resources (not necessarily $), focus, and energy. But I keep thinking we missed a step. Understanding why it matters, and what of importance we are going to accomplish (and sacrifice) by wiring up to every school desk. Are you concerned about the potential for centralization and bureaucratization and dehumanization of our schools and education as a likely outcome of this process. Why the hell not? Why the hell not? Art From ajsiegel at optonline.net Fri Aug 5 13:38:29 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 05 Aug 2005 07:38:29 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKQ0004LXTOEA50@mta5.srv.hcvlny.cv.net> Message-ID: <0IKQ00GNOZ0SHR00@mta8.srv.hcvlny.cv.net> > -----Original Message----- > From: Arthur [mailto:ajsiegel at optonline.net] > > Are you concerned about the potential for centralization and > bureaucratization and dehumanization of our schools and education as a > likely outcome of this process. I actually feel our (smug on this point) friends in Europe are particularly vulnerable on this point. And partly because they are likely to achieve *more* success than here in the standardization of the bureaucracy and the schools around Open Source infrastructure. Combined with the fact that standardization and bureaucratization seems less culturally anathema than it tends to be here. I am sure Laura agrees ;) Art From urnerk at qwest.net Fri Aug 5 17:31:05 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Fri, 5 Aug 2005 11:31:05 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk Message-ID: <380-2200585515315242@M2W049.mail2web.com> >Again - major disconnect. Worrying about affordability implies we have >already concluded that access to this stuff - in providing good education - >matters much. But who is this "we"? My point is many kids of high school age and younger have already decided they want to be computer virtuosos of one kind or another. Looking at all these geeks slinging laptops, I could think of them as weapons I suppose, but a much better analogy is musical instruments. We're musicians in a way. Indeed, the discipline we call "programming" owes quite a bit to player pianos and other mechanized players. Gibson Guitars is a sponsor of OSCON this year. Big booth, guitars as prizes, awarded on stage. Think of the piano forte, a major piece of technology, and how it's figured in the education process over the last couple centuries. It was a part of the education of elites, often young girls. However, due to access/affordability issues, it was never widespread. But electronics is a very different story. The barriers to entry are much lower. >But I keep thinking we missed a step. Understanding why it matters, and what >of importance we are going to accomplish (and sacrifice) by wiring up to >every school desk. > >Are you concerned about the potential for centralization and >bureaucratization and dehumanization of our schools and education as a >likely outcome of this process. > >Why the hell not? > >Why the hell not? > >Art As I've said before, I don't think there's any stopping this technology tsunami that's upon us (putting it that way makes it sound like a disaster). What we can do is manage and adapt to change, not stop it altogether. I think we're on an evolutionary trajectory that's ultimately about improving living standards around the world, ending death by starvation and yadda yadda. In other words, I'm up beat about this technology's potential. But yes, I do worry about abuse. I worry about weaponization, where we could have had a civilian Renaissance. As a Fuller Schooler, I'm always looking for ways to bring the military on board, such that these ancient hierarchies see a way forward, not a dead end. When people with lots of weapons and training in violence feel cornered, it tends to not be a pretty picture. Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From ajsiegel at optonline.net Sat Aug 6 15:09:07 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 06 Aug 2005 09:09:07 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk Message-ID: <0IKS00FNOXVFF320@mta5.srv.hcvlny.cv.net> Kirby writes: """ As I've said before, I don't think there's any stopping this technology tsunami that's upon us (putting it that way makes it sound like a disaster). What we can do is manage and adapt to change, not stop it altogether. I think we're on an evolutionary trajectory that's ultimately about improving living standards around the world, ending death by starvation and yadda yadda. In other words, I'm up beat about this technology's potential. """ I take you as having found the word "tsunami" as appropriate, not meaning something bringing disaster - but certainly meaning something which is so powerful as to be unstoppable and beyond control. If that is true - and I am not disputing that directly - it is true only to the extent the roll out is in a form that is unthreatening to the interests of the world-as-it-is and the power-structures-as-they-are. Of course. Which - from my comfortable seat - is not a disaster. But - were I hungry - I don't know how I would feel about the touting of 3D/MP3 players with changeable skins, as a step toward my salvation. Art From ajsiegel at optonline.net Sat Aug 6 15:48:42 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 06 Aug 2005 09:48:42 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKS00FNOXVFF320@mta5.srv.hcvlny.cv.net> Message-ID: <0IKS00G12ZPB74XE@mta7.srv.hcvlny.cv.net> > > Kirby writes: > > """ > I think we're on an evolutionary trajectory that's ultimately > about improving living standards around the world, ending death by > starvation and yadda yadda. > """ Though I don't believe that I have ever heard to state this explicitly before, I knew somehow that this is exactly what you believe. And that you take the proliferation of digital technology as a Sign. I, on the other hand, have no fucking idea where the course of events is leading us, no sense of having a basis to know, and am scared by people who think they know. Art From urnerk at qwest.net Mon Aug 8 00:56:54 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 7 Aug 2005 15:56:54 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKS00FNOXVFF320@mta5.srv.hcvlny.cv.net> Message-ID: <20050807225702.270D31E4005@bag.python.org> > But - were I hungry - I don't know how I would feel about the touting of > 3D/MP3 players with changeable skins, as a step toward my salvation. > > Art Hungry to get dealt into the game. On the Math Forum, I'm already suggesting having a cell phone on one's person is every child's right. Kirby From urnerk at qwest.net Mon Aug 8 01:09:05 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 7 Aug 2005 16:09:05 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKS00G12ZPB74XE@mta7.srv.hcvlny.cv.net> Message-ID: <20050807230912.691E61E4005@bag.python.org> Art: > And that you take the proliferation of digital technology as a Sign. > Not just digital technology and not just recent technology. Looking at the short curve of humanity to date, I'd say we're a species cut out to use tools in a big way. We have big brains, lots of smarts, and not much strength in hardware, beyond that of an ape (actually I've heard less than most apes of similar size). > I, on the other hand, have no fucking idea where the course of events is > leading us, no sense of having a basis to know, and am scared by people > who think they know. > > Art Just look in the rear view mirror and ask if technology has been of net benefit along our shared highway to this point. If yes, why shouldn't present trends continue? If no, what fork in the road would you prefer we'd have taken? Kirby From ajsiegel at optonline.net Mon Aug 8 14:15:45 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 08 Aug 2005 08:15:45 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKV00GFFKB54O50@mta19.srv.hcvlny.cv.net> Message-ID: <0IKW00DY6KQI9S80@mta8.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > Just look in the rear view mirror and ask if technology has been of net > benefit along our shared highway to this point. If yes, why shouldn't > present trends continue? If no, what fork in the road would you prefer > we'd > have taken? Evolution is a trial and error process. Considering the nature of the curve that tracks our history on the planet, and the development of the kind of technology which we are referring to, there is nothing to be learned by a look in the rear view mirror. More important then being equipped with the ability to develop tools, is our ability to use reason. *That* is what evolution has provided us with as our survival tool. Talk of an inevitable tsunami in an admission that there is something afoot that is beyond the control of our reason. I am unready to make that admission. Art From ajsiegel at optonline.net Mon Aug 8 18:25:56 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 08 Aug 2005 12:25:56 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk Message-ID: <42F78794.6020908@optonline.com> >>/ But - were I hungry - I don't know how I would feel about the touting of />/> 3D/MP3 players with changeable skins, as a step toward my salvation. />/> />/> Art / >Hungry to get dealt into the game. On the Math Forum, I'm already >suggesting having a cell phone on one's person is every child's right. >Kirby Suggest away. And what do you see in the rear view mirror that suggests to you that you are not in the realm of folly. Art From urnerk at qwest.net Mon Aug 8 17:54:59 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 8 Aug 2005 08:54:59 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKW00DY6KQI9S80@mta8.srv.hcvlny.cv.net> Message-ID: <20050808155508.D2DCF1E4005@bag.python.org> > Evolution is a trial and error process. > > Considering the nature of the curve that tracks our history on the planet, > and the development of the kind of technology which we are referring to, > there is nothing to be learned by a look in the rear view mirror. > I would not eagerly seek advice from someone who discounts all lessons of the past. > More important then being equipped with the ability to develop tools, is > our ability to use reason. *That* is what evolution has provided us with > as our survival tool. > Reason is a tool. > Talk of an inevitable tsunami in an admission that there is something > afoot that is beyond the control of our reason. > > I am unready to make that admission. > > Art I'd prefer to look at the world as a vast disaster zone in which a tsunami has already hit. Just look at the devastation. Now let's do something to restore a livable world. Kirby From urnerk at qwest.net Mon Aug 8 18:15:16 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 8 Aug 2005 09:15:16 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <42F78794.6020908@optonline.com> Message-ID: <20050808161525.D9E641E4005@bag.python.org> > Suggest away. > > And what do you see in the rear view mirror that suggests to you that you > are not in the realm of folly. > > Art I see fewer kids getting lost, more calls to 911, better communications with peers, better networking. I see an infrastructure emerging that will support tomorrows Internet. I also see exponential curves in cell phone use, suggesting my goal is not out of alignment with current trends. And what suggests to you that you're not in the realm of folly, a guy who discounts the past entirely? Kirby From ajsiegel at optonline.net Mon Aug 8 20:04:08 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 08 Aug 2005 14:04:08 -0400 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <0IKW00K7KVTIKIJ0@mta17.srv.hcvlny.cv.net> References: <0IKW00K7KVTIKIJ0@mta17.srv.hcvlny.cv.net> Message-ID: <42F79E98.7030802@optonline.com> Kirby Urner wrote: >And what suggests to you that you're not in the realm of folly, a guy who >discounts the past entirely? > > You see a devastated planet, then suggest I am discounting the past by critiquing an agenda whose implimentation is dependant upon a massive conversion to Altruism. I believe reason, and a reasoned look at the past, would allow us to do better than that. Art From urnerk at qwest.net Mon Aug 8 20:30:21 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 8 Aug 2005 11:30:21 -0700 Subject: [Edu-sig] Postmortem of my OSCON talk In-Reply-To: <42F79E98.7030802@optonline.com> Message-ID: <20050808183030.332B01E4005@bag.python.org> > Kirby Urner wrote: > > >And what suggests to you that you're not in the realm of folly, a guy who > >discounts the past entirely? > > > > > You see a devastated planet, then suggest I am discounting the past by > critiquing an agenda whose implimentation is dependant upon a massive > conversion to Altruism. I've said nothing about any massive conversion to Altruism. In my blog I write: """ Old timer do-it-yourselfers may be suspicious of this new do-it-together work ethic. They worry about communism or some other failure-prone altruism, per Larry's allusions last night: the People's Republic of Perl slide; his cast of cartoon spies, at least one of whom (cute chick) was no doubt Russian (Larry himself identified with the Chinese guy). I think today's keynotes would prove reassuring to these worry warts: this is unbridled capitalism at work, in the ancient sense of "using your head" (Latin root) as a private individual, as free as your peers to collaborate, to partner, to take risks and reap rewards -- and as willing to make it all work. """ > I believe reason, and a reasoned look at the past, would allow us to do > better than that. > > Art You contradict yourself. A second ago, this technology was without precedent and the past was no guide. Plus you've claimed to have no clue about where we're going (and you're scared by people who do). Now you invoke the past and say we'll need some massive conversion to some ism to go where I think we're going -- as if you knew something all of a sudden. Funny. Kirby From gvwilson at cs.utoronto.ca Tue Aug 9 15:13:22 2005 From: gvwilson at cs.utoronto.ca (Greg Wilson) Date: Tue, 09 Aug 2005 09:13:22 -0400 Subject: [Edu-sig] software skills course Message-ID: Hi, I'm working with support from the Python Software Foundation to develop an open source course on basic software development skills for people with backgrounds in science and engineering. I have a beta version of the course notes ready for review, and would like to pull in people in sci&eng to look it over and give me feedback. If you know anyone who fits this bill (particularly people who might be interested in following along with a trial run of the course this fall), I'd be grateful for pointers. Thanks, Greg Wilson From cyberweb at rocketmail.com Tue Aug 9 23:04:52 2005 From: cyberweb at rocketmail.com (CyberWeb Consulting) Date: Tue, 9 Aug 2005 14:04:52 -0700 (PDT) Subject: [Edu-sig] ANN: Python training, Aug 29-31, San Francisco Message-ID: <20050809210453.45766.qmail@web30704.mail.mud.yahoo.com> hi all, just wanted to announce our next public Python course, a 3-day intensive training session held near the San Francisco airport at the end of this month. Secondary and post-secondary (students and) educators get a 50% discount off the regular course fee of $1095US. this discount is described further in the FAQ at the website below. if you're going to be teaching Python this coming school year, this will prep you for it. the only real prerequisite is that you are familiar with at least one other high-level programming language like BASIC, Pascal, Java, C++, etc. for more info and registration, go to http://cyberwebconsulting.com (click "Python training"). the full course annoucenment is below. please sign up quickly as there are only 10 more open spots! let me know if you have any questions. thanks, -wesley What: Python Programming I: Introduction to Python When: August 29-31, 2005 Where: San Francisco, CA, USA Already know Java, Perl, C/C++, JavaScript, PHP, or TCL/Tk, but want to learn Python because you've been hearing about how Google, Yahoo!, Industrial Light & Magic, Red Hat, Zope, NASA, and IronPort are using this object-oriented, open source applications and systems development language? Python is rapidly gaining momentum worldwide and seeing more new users each year. While similar to those other languages, Python differentiates itself with a robust yet simple-as-VB syntax which allows for shorter development time and improved group collaboration. Need to get up-to-speed with Python as quickly as possible? Come join us in beautiful Northern California the week before Labor Day. We are proud to announce another rigorous Python training event taught by software engineer and "Core Python Programming" author, Wesley Chun. This is an intense introduction to Python programming geared towards those who have some proficiency in another high-level language. Topics include: * Python's Objects and Memory Model * Data Types, Operators, and Methods * Errors and Exception Handling * Files and Input/Output * Functions and Functional Programming * Modules and Packages * Classes, Methods, and Class Instances * Callable and Executable Objects This course will take place daily August 29-31, 2005 (Monday through Wednesday, 9am - 5pm) in San Bruno, CA, right near the San Francisco International Airport at the: Staybridge Suites San Francisco Airport 1350 Huntington Ave San Bruno, CA 94066 650-588-0770 This venue provides free shuttles to/from the airport and has easy access to public transit (BART, CalTrain, SamTrans) to help you get all over the Bay Area. Afterwards, feel free to enjoy the holiday weekend in the greatest city by the Bay... bring your families!! Sign up quickly as we can only take 15-20 enrollees! For more information and registration, just go to http://cyberwebconsulting.com and click on the "Python Training" link. If you have any questions, feel free to contact us at cyberweb-at-rocketmail.com. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2001 http://www.corepython.com wesley.j.chun :: cyberweb at rocketmail.com cyberweb.consulting :: silicon.valley, ca http://www.cyberwebconsulting.com From urnerk at qwest.net Wed Aug 10 23:02:59 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 10 Aug 2005 14:02:59 -0700 Subject: [Edu-sig] ANN: Python training, Aug 29-31, San Francisco In-Reply-To: <20050809210453.45766.qmail@web30704.mail.mud.yahoo.com> Message-ID: <20050810211022.5F3C01E4004@bag.python.org> > each year. While similar to those other languages, Python > differentiates itself with a robust yet simple-as-VB syntax which ^^^^^^^^^^^^ Ouch. :-D Kirby From urnerk at qwest.net Sat Aug 13 17:44:02 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sat, 13 Aug 2005 08:44:02 -0700 Subject: [Edu-sig] software skills course In-Reply-To: Message-ID: <20050813154410.152611E400B@bag.python.org> Thanks for letting us look over your shoulder Greg. I'm glad we're getting the benefit of PSF support for open source Python-related curricula -- a very important endeavor IMO. Kirby > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Greg Wilson > Sent: Tuesday, August 09, 2005 6:13 AM > To: edu-sig at python.org > Subject: Re: [Edu-sig] software skills course > > Hi, > > I'm working with support from the Python Software Foundation to develop > an open source course on basic software development skills for people > with backgrounds in science and engineering. I have a beta version of > the course notes ready for review, and would like to pull in people > in sci&eng to look it over and give me feedback. If you know anyone > who fits this bill (particularly people who might be interested in > following along with a trial run of the course this fall), I'd be > grateful for pointers. > > Thanks, > Greg Wilson > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From andre.roberge at gmail.com Wed Aug 17 00:05:53 2005 From: andre.roberge at gmail.com (=?ISO-8859-1?Q?Andr=E9_Roberge?=) Date: Tue, 16 Aug 2005 19:05:53 -0300 Subject: [Edu-sig] software skills course In-Reply-To: References: Message-ID: Greg Wilson wrote: > Hi, > > I'm working with support from the Python Software Foundation to develop > an open source course on basic software development skills for people > with backgrounds in science and engineering. I have a beta version of > the course notes ready for review, and would like to pull in people > in sci&eng to look it over and give me feedback. If you know anyone > who fits this bill (particularly people who might be interested in > following along with a trial run of the course this fall), I'd be > grateful for pointers. > > Thanks, > Greg Wilson I would be interested in being a reviewer; I might even be fool enough to volunteer to translating the course in French! Andr? Roberge From denise.hartley at gmail.com Wed Aug 17 18:59:22 2005 From: denise.hartley at gmail.com (D. Hartley) Date: Wed, 17 Aug 2005 09:59:22 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 25, Issue 11 In-Reply-To: References: Message-ID: <8daabe56050817095969066587@mail.gmail.com> Greg, I would be interested in being a reviewer, if you still need them. ~Denise On 8/17/05, edu-sig-request at python.org wrote: > Send Edu-sig mailing list submissions to > edu-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/edu-sig > or, via email, send a message with subject or body 'help' to > edu-sig-request at python.org > > You can reach the person managing the list at > edu-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Edu-sig digest..." > > > Today's Topics: > > 1. Re: software skills course (Andr? Roberge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Aug 2005 19:05:53 -0300 > From: Andr? Roberge > Subject: Re: [Edu-sig] software skills course > To: edu-sig at python.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Greg Wilson wrote: > > Hi, > > > > I'm working with support from the Python Software Foundation to develop > > an open source course on basic software development skills for people > > with backgrounds in science and engineering. I have a beta version of > > the course notes ready for review, and would like to pull in people > > in sci&eng to look it over and give me feedback. If you know anyone > > who fits this bill (particularly people who might be interested in > > following along with a trial run of the course this fall), I'd be > > grateful for pointers. > > > > Thanks, > > Greg Wilson > I would be interested in being a reviewer; I might even be fool enough > to volunteer to translating the course in French! > > Andr? Roberge > > > > ------------------------------ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > End of Edu-sig Digest, Vol 25, Issue 11 > *************************************** > From urnerk at qwest.net Thu Aug 18 02:47:32 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 17 Aug 2005 17:47:32 -0700 Subject: [Edu-sig] software skills course In-Reply-To: Message-ID: <20050818004742.C09B71E4003@bag.python.org> Howdy Andr? -- I just sent the following email to pydotorg in hopes of getting back in the harness re the edu-sig page at the site. As you see, my primary motivation is to get RUR-PLE linked, for other educators to find. My apologies for being neglectful on this score up to now. Kirby --- -----Original Message----- From: Kirby Urner [mailto:urnerk at qwest.net] Sent: Wednesday, August 17, 2005 5:44 PM To: 'pydotorg at python.org'; 'pydotorg-owner at python.org' Subject: Need to renew credentials for web site maintenance Greetings Barry et al -- I'd like to renew my ability to maintain ./sigs/edu-sig. Specifically, http://rur-ple.sourceforge.net/ deserves a link. Was I dreaming or did we move from CVS to Subversion awhile back?? If so, I've lost my secrets on that score. In any case, 'cvs update' (from cygwin in Windows) no longer works, nor can I even access the pydotorg mail list archive (the first place I looked, hoping to dig back through). I *am* a subscriber here, and hence get the daily deluge of spam. I hope that earns me at least the rank of "slogger" and that someone of higher rank will assist me in getting back in the groove. Thanks in advance, Kirby urnerk at qwest.net urnerk at python.org From andre.roberge at gmail.com Thu Aug 18 03:35:10 2005 From: andre.roberge at gmail.com (=?ISO-8859-1?Q?Andr=E9_Roberge?=) Date: Wed, 17 Aug 2005 22:35:10 -0300 Subject: [Edu-sig] software skills course In-Reply-To: <20050818004742.C09B71E4003@bag.python.org> References: <20050818004742.C09B71E4003@bag.python.org> Message-ID: Kirby Urner wrote: > Howdy Andr? -- > > I just sent the following email to pydotorg in hopes of getting back in the > harness re the edu-sig page at the site. As you see, my primary motivation > is to get RUR-PLE linked, for other educators to find. > > My apologies for being neglectful on this score up to now. > > Kirby > Thanks! :-) Andr? From urnerk at qwest.net Sat Aug 20 02:29:59 2005 From: urnerk at qwest.net (Kirby Urner) Date: Fri, 19 Aug 2005 17:29:59 -0700 Subject: [Edu-sig] Design patterns Message-ID: <20050820003201.5E37F1E4004@bag.python.org> I?ve been thinking that a good way to introduce program design might involve objects of type Triangle, i.e. instances of the Triangle class. >>> mytri = Triangle(3,4,5) >>> mytri.area 6.0 >>> mytri.C 90.0 Now isn?t it true that 3 sides uniquely determine a triangle *except* some triangles have handedness, and if they're not allowed to flip on the griddle, you can have two of the same edge lengths (e.g. 3-4-5) that can't be made to have the same orientation? We might learn about such asymmetries by playing Tetris. The "L" pieces come in two varieties. Anyway, here's a design question: do we want to compute the angles and store them as properties at the time of construction, i.e. in the init? Or do we want to make getAngles() a method? Compromise: call _getAngles from the init. The advantage of always running a method is you always use the a,b and c of the moment, so if these change e.g. mytri.a = 7, then getAngles() will take that change into account. If angles A,B and C are computed from a, b, c in the constructor and saved as instance variables, then a subsequent change to b must force a change to A,B and C, as well as in area and perimeter. We could do this in more than one way. Which way is best? I think we might go for a class that lets users modify a,b and c as properties, but doesn't encourage direct access to A,B and C. Angles are a result of the sides, but we don't go in the other direction. Trying to set mytri.A would raise an exception. However, even with sides, we need to patrol for violations of triangular inequality. No two lengths are allowed to sum to less than the third length, and if they exactly equal it, then two of the angles are 0, one is 180, and area is 0. Here's a version that uses the getAngles() and getArea() approach. A,B,C aren't saved as instance variables at all, but as references in a dictionary that gets returned, but is not saved in the object. It still needs an underunder repr. class Triangle: def __init__(self, a,b,c): "Construct a triangle" if (c > a + b) or (a > b + c) or (b > a + c): raise Exception("Illegal edges") self.a = a self.b = b self.c = c def getArea(self): "Heron's Forumula" s = 0.5 * (self.a + self.b + self.c) return math.sqrt( s * (s - self.a) * (s - self.b) * (s - self.c) ) def getAngles(self): a,b,c = self.a, self.b, self.c # for brevity angles = {} # empty dictionary A = math.acos((-a**2 + b**2 + c**2)/(2.0*b*c) ) B = math.acos(( a**2 - b**2 + c**2)/(2.0*a*c) ) C = math.acos(( a**2 + b**2 - c**2)/(2.0*a*b) ) angles['A'] = round(math.degrees(A),5) angles['B'] = round(math.degrees(B),5) angles['C'] = round(math.degrees(C),5) return angles Kirby -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.13/78 - Release Date: 8/19/2005 From ajsiegel at optonline.net Sat Aug 20 04:15:41 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 19 Aug 2005 22:15:41 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <20050820003201.5E37F1E4004@bag.python.org> Message-ID: <0ILI006B30YKV8U6@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Kirby Urner > Sent: Friday, August 19, 2005 8:30 PM > To: edu-sig at python.org > Subject: [Edu-sig] Design patterns > > Anyway, here's a design question: do we want to compute the angles and > store them as properties at the time of construction, i.e. in the init? PyGeo emphasizes dynamism. So on the one hand I am anxious - for performance reasons - to push as much processing as I can into __init__. IOW, start-up time for a construction is much less a concern than the responsiveness when there is change, i.e. when a point of the construction is picked and moved and all the implications of that move needs be determined and all elements affected by it redrawn. And exactly for the same reason, there are clear constraints as to what I can in fact put in __init__. Everything intended to be dynamic needs to be in methods calculated on the fly. What I end up with to get decent performance is a patterns of registration. Part of __init__ for any element is a process with registers it on a chain of dependencies, so that when a point is in fact picked and moved the point knows what other elements of the construction depend - directly and indirectly - on its position and only those elements are recalced and redrawn. The moral of the story is, I think, it depends on what in more precise terms you are trying to do. The great fun of building PyGeo has been that I always had a pretty clear idea of what I was trying to do. Given that, it seemed a process of simply discovering the way to do it. That is as opposed to inventing the way to do it. The way to do it was pretty much dictated by the intent of the project, and was more and less sitting there. I have just needed to find it. Art From Scott.Daniels at Acm.Org Sat Aug 20 04:31:27 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Fri, 19 Aug 2005 19:31:27 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <20050820003201.5E37F1E4004@bag.python.org> References: <20050820003201.5E37F1E4004@bag.python.org> Message-ID: Kirby Urner wrote: > I?ve been thinking that a good way to introduce program design might involve > objects of type Triangle, i.e. instances of the Triangle class. > Anyway, here's a design question: do we want to compute the angles and > store them as properties at the time of construction, i.e. in the init? Or > do we want to make getAngles() a method? Compromise: call _getAngles from > the init. Here's how to do the angles in 2.4 w/ properties: class Triangle(object): def __init__(self, a,b,c): "Construct a triangle" if (c >= a + b) or (a >= b + c) or (b >= a + c): raise ValueError("Illegal edges: %s/%s/%s" % (a, b, c)) self.a = a self.b = b self.c = c def area(self): "Heron's Formula" s = 0.5 * (self.a + self.b + self.c) return math.sqrt( s * (s - self.a) * (s - self.b) * (s - self.c)) @property def A(self): return math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) @property def B(self): return math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) @property def C(self): return math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) Now you can do: t = Triangle(3,4,5) t.c, math.degrees(t.C) t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C) t.b = t.c = 3 t.c, math.degrees(t.C) t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C) This takes advantage of the fact that property with a single parameter defines only the "get value" accessor, and makes setting or deleting the property illegal. -- Scott David Daniels Scott.Daniels at Acm.Org From urnerk at qwest.net Sat Aug 20 07:28:05 2005 From: urnerk at qwest.net (Kirby Urner) Date: Fri, 19 Aug 2005 22:28:05 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: Message-ID: <20050820053135.3ED061E4004@bag.python.org> > Now you can do: > > t = Triangle(3,4,5) > t.c, math.degrees(t.C) > t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C) > t.b = t.c = 3 > t.c, math.degrees(t.C) > t.a/math.sin(t.A), t.b/math.sin(t.B), t.c/math.sin(t.C) > > This takes advantage of the fact that property with a single parameter > defines only the "get value" accessor, and makes setting or deleting > the property illegal. > > -- Scott David Daniels > Scott.Daniels at Acm.Org Totally excellent Scott. Thank you. Kirby From ajsiegel at optonline.net Sun Aug 21 14:49:09 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 08:49:09 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: Message-ID: <0ILK00FQBOYBO3XP@mta6.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > > Here's how to do the angles in 2.4 w/ properties: > > > @property > def A(self): > return math.acos((-self.a**2 + self.b**2 + self.c**2) > / (2.0 * self.b * self.c)) Hmmm... We seem to be saying that @property works out-of-the box as a decorator in 2.4 - at least where we want read only properties. I can only assume that this is more of a side-effect of the introduction of decorators, than a feature fully designed into the language. Which is not to say that it is not a fortunate side effect. But it is unfortunate combo for me - since I never fully understood the purpose of properties, and don't fully get the mechanics of decorators. My most important points of confusion: What beyond sugar for leaving off a "()" when trying to retrieve a value from a method are we accomplishing by using properties? I have tended to look at properties mostly an accommodation to those coming from other languages which have something similar, but never as something that was core to Python or a Pythonic approach to things. Am I missing something fundamental? and Am I correct that the use of property as a "built-in" decorator is not designed into the language - at least in the same way that @classmethod has been? What would it take to create a @property decorator that allows one to set as well as get? Would we want to? Art From ajsiegel at optonline.net Sun Aug 21 16:33:45 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 10:33:45 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILK00FQBOYBO3XP@mta6.srv.hcvlny.cv.net> Message-ID: <0ILK00H4NTSHR5Y7@mta9.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Arthur > > What beyond sugar for leaving off a "()" when trying to retrieve a value > from a method are we accomplishing by using properties? I have tended to > look at properties mostly an accommodation to those coming from other > languages which have something similar, but never as something that was > core > to Python or a Pythonic approach to things. Am I missing something > fundamental? The searching I do on this point only confirms to me that my own confusion is well shared - perhaps indicating this to be an area not totally OT for this forum. Ray Hettinger's "How-To Guide for Descriptors" http://users.rcn.com/python/download/Descriptor.htm covers properties, but the use case given is extremely unsatisfying - essentially offering a situation where a fundamental design change has been made to a program in mid-stream, and since properties were used in the initial design, the change can be made with little refactoring. Somehow I don't expect a programming language to accommodate the possibility of a midstream change in a programs design/intentions of the kind cited here. New design, and the expectation would be to need to recode to the new design. All within bounds, of course. OOP, I think, does try to address this issue to a reasonable degree. But the properties use case in this article is, to my intuition, a stretch beyond those reasonable bounds. I can't believe that a language or coding style intended to accommodate the range of possibilities for the kind of fundamental midstream redesign referenced in this use case could lead anywhere else but to some kind of madness. The fact is that I do use properties to a limited degree in PyGeo - the actual implementation of properties being trivial enough. Much less trivial is the why and when. The brain dead use of properties in PyGeo being definitely on my list for refactoring. Just not sure whether I should be consistent in avoiding them, or consistently using them, or when is which and which is when. Art From urnerk at qwest.net Sun Aug 21 18:14:32 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 21 Aug 2005 09:14:32 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILK00H4NTSHR5Y7@mta9.srv.hcvlny.cv.net> Message-ID: <20050821163614.6EC6D1E4004@bag.python.org> Hi Arthur -- Yes, decorator syntax isn't designed to integrate with properties quite the same way. All a decorator does is run the subsequently defined function f2 through the f1 in @f1, rebinding f2 to the returned output of f1. E.g. 'f2 = f1(f2)' and '@f1; def f2(): pass' amount to the same thing. The non-decorator version of Triangle, with properties, might be: >>> import math >>> class Triangle(object): def __init__(self, a,b,c): "Construct a triangle" if (c >= a + b) or (a >= b + c) or (b >= a + c): raise ValueError("Illegal edges: %s/%s/%s" % (a, b, c)) self.a = a self.b = b self.c = c def getArea(self): "Heron's Formula" s = 0.5 * (self.a + self.b + self.c) return math.sqrt( s * (s - self.a) * (s - self.b) * (s - self.c)) def getA(self): return math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) def getB(self): return math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) def getC(self): return math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) A = property(getA, doc='Angle A in radians') B = property(getB, doc='Angle B in radians') C = property(getC, doc='Angle C in radians') area = property(getArea, doc="Triangle's area") >>> mytri = Triangle(3,4,5) >>> math.degrees(mytri.C) 90.0 >>> math.degrees(mytri.A) 36.86989764584402 >>> mytri.area = 6 Traceback (most recent call last): File "", line 1, in -toplevel- mytri.area = 6 AttributeError: can't set attribute Alex Martelli's example in 'Python in a Nutshell' is similar: a rectangle's area is computed on the fly (pg. 85). Note that defining attributes in this way doesn't mean we only find out an attribute is really a property much further along in the code (everything is expressed in one line) -- which was the problem decorators addressed i.e. a long function def might obscure the fact that we're defining a classmethod (the older f1 = classmethod(f1) had to come at the end). >>> help(Triangle) # now get us this useful section in the documentation: | ---------------------------------------------------------------------- | Properties defined here: | | A | Angle A in radians | | = getA(self) | | B | Angle B in radians | | = getB(self) | | C | Angle C in radians | | = getC(self) | | area | Triangle's area | | = getArea(self) | Heron's Formula | | ---------------------------------------------------------------------- I think it's fine to call it "syntactic sugar" when we make object attributes call their associated accessors and mutators behind the scenes. Conceptually, we're giving the user of the class a simpler API while giving ourselves as programmers a lot of control over what triggers what. It's easy to think of angles and area as attributes, even if we don't allow them to be set except through changes to edges. Why should we force a user to remember what's a method and what's not, given edges, angles and area (could add perimeter too). A weakness in the above design: we only check for violations of triangle inequality in the constructor, yet allow changes to a,b,c through the API. Kirby From Scott.Daniels at Acm.Org Sun Aug 21 19:33:12 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun, 21 Aug 2005 10:33:12 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILK00H4NTSHR5Y7@mta9.srv.hcvlny.cv.net> References: <0ILK00FQBOYBO3XP@mta6.srv.hcvlny.cv.net> <0ILK00H4NTSHR5Y7@mta9.srv.hcvlny.cv.net> Message-ID: Arthur wrote: >>What beyond sugar for leaving off a "()" when trying to retrieve a value >>from a method are we accomplishing by using properties? I have tended to >>look at properties mostly an accommodation to those coming from other >>languages which have something similar, but never as something that was >>core >>to Python or a Pythonic approach to things. Am I missing something >>fundamental? > > > The searching I do on this point only confirms to me that my own confusion > is well shared - perhaps indicating this to be an area not totally OT for > this forum. > > Ray Hettinger's "How-To Guide for Descriptors" > > http://users.rcn.com/python/download/Descriptor.htm > > covers properties, but the use case given is extremely unsatisfying - > essentially offering a situation where a fundamental design change has been > made to a program in mid-stream, and since properties were used in the > initial design, the change can be made with little refactoring. I'd propose two reasons why properties are so successful. The first explanation comes from eXtreme Programming. One big goal of XP is to stop wasting time doing "big design up front." I've spent enough time in companies where long design meetings (months) produced huge design documents. The documents themselves had a tendency to look like everything was nailed down, while not really answering a lot of questions that had to be solved when writing the code. The length of time spent producing the document, and the general unavailability of the group that wrote it (they typically moved into other committees to write other design documents), led to an increasingly rigid design that reflected neither discoveries or innovations from the coders nor changes in requirements (or at least our understanding of those requirements). XP can be seen as a reaction to that problem. The second explanation is much lower level. In O-O code, there is a distinction between interface and implementation. Essentially, the interface to an object is how the object behaves from a user of that object's point of view. The implementation is how that object accomplishes its behavior. When you separate these concerns, you can more likely keep a programs complexity (in the sense of debugging/ extending) from growing exponentially with the number of lines of code. Properties let you to hide the trade-off between accessing a stored value and computing it on the fly. Without properties, the interface to classes that want to reserve the access/calculate tradeoff must use the Java-like "getVar" functions to fetch any values that might be calculated. > What would it take to create a @property decorator that allows one > to set as well as get? Would we want to? def writeprop(viewvar): '''decorator makes a property from access and a write method''' def view(self): return getattr(self, viewvar) def buildprop(writemethod): return property(view, writemethod) return buildprop Triangle as an example: import math class BaseTriangle(object): @classmethod def check(klass, a, b, c): '''Check three lengths for suitability as triangle sides''' if a >= b + c: raise ValueError, 'Too long: %s >= %s + %s' % (a, b, c) if a <= abs(b - c): raise ValueError, 'Too short: %s <= abs(%s - %s)' % (a, b,c) def __init__(self, a, b, c): self.check(a, b, c) self._a = a self._b = b self._c = c self._reset() def __repr__(self): return '%s(%s, %s, %s)' % (self.__class__.__name__, self.a, self.b, self.c) def _reset(self): '''Called whenever the sides of the triangle change''' pass @writeprop('_a') def a(self, v): self.check(v, self.b + self.c) self._a = v self._reset() @writeprop('_b') def b(self, v): self.check(v, self.a, self.c) self._b = v self._reset() @writeprop('_c') def c(self, v): self.check(v, self.a, self.b) self._c = v self._reset() # One kind of triangle with angles: class Triangle(BaseTriangle): @property def perimeter(self): return self.a + self.b + self.c @property def area(self): "Heron's Formula" s = 0.5 * self.perimeter return math.sqrt(s * (s - self.a) * (s - self.b) * (s - self.c)) @property def A(self): return math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) @property def B(self): return math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) @property def C(self): return math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) # Another kind of triangle with angles: class Triangle2(BaseTriangle): def _reset(self): self.perimeter = self.a + self.b + self.c s = 0.5 * self.perimeter self.area = math.sqrt(s * (s - self.a) *(s - self.b) * (s - self.c)) self.A = math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) self.B = math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) self.C = math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Sun Aug 21 20:26:23 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 14:26:23 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILK00HWXZG6OX30@mta25.srv.hcvlny.cv.net> Message-ID: <0ILL00G1G4K4QRI2@mta9.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > A weakness in the above design: we only check for violations of triangle > inequality in the constructor, yet allow changes to a,b,c through the API. Among my list of unsupportable theories is one to the effect that any attempt to build a truly OOP hierarchy of geometric objects requires one to get to geometric fundamentals and that requires one to get down to projective ideas. Apparently there is in OOP theory a nearly irresolvable paradox of the relation of the circle to an ellipse in a OOP hierarchy. But from a projective point of view they are only the same object, viewed from different perspectives, i.e. they are projectively equivalent. So attempting to distinguish them as different levels of some hierarchy is bound to be problematic. It's really a geometric problem disguised as a programming one. IOW, attempting to fit these objects into an OOP hierarchy chain can only be an attempt to fit a round ellipse into a square circle, or vice versa ;) PyGeo has a Triangle object, inherited from the Plane object. It exists mostly for drawing purposes, as the portion of the plane enclosed by the infinite lines connecting any 3 points. Since all Triangles are projectively equivalent, in the context of PyGeo there is little to be gained by saying much of anything about any particular triangle - and little is. Art From urnerk at qwest.net Sun Aug 21 21:01:55 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 21 Aug 2005 12:01:55 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: Message-ID: <20050821190611.670D11E409E@bag.python.org> Scott: > def writeprop(viewvar): > '''decorator makes a property from access and a write method''' > def view(self): > return getattr(self, viewvar) > def buildprop(writemethod): > return property(view, writemethod) > return buildprop > Pretty fancy Scott and again, highly worthy of study. An element in this design pattern is using a function (writeprop) to build the decorator function (buildprop) that'll transform the following def (e.g. def c). Scott used the same technique when he enhanced my hypertoon program (a VPython cartoon generator) with decorator syntax. @f1(args) def f2: pass uses f1(args) to build a function which then takes f2 as its argument, rebinding the result to f2, i.e. f2 = (f1(args))(f2), where f1(args) by itself returns a callable. In this case, buildprop returns a curried property function (curried in that the 'view' method is already bound, defined in terms of getattr). The decorator returns a function the effect of which is equivalent to 'c = property(view, c)' i.e. c-the-function goes in as buildprop's writemethod and is rebound to make c a property. > @writeprop('_c') > def c(self, v): > self.check(v, self.a, self.b) > self._c = v > self._reset() Here's a similar base triangle class without the decorators: class BaseTriangle2(object): @classmethod def check(klass, a, b, c): '''Check three lengths for suitability as triangle sides''' if a >= b + c: raise ValueError, 'Too long: %s >= %s + %s' % (a, b, c) if a <= abs(b - c): raise ValueError, 'Too short: %s <= abs(%s - %s)' % (a, b,c) def __init__(self, a, b, c): self.check(a, b, c) self._a = a self._b = b self._c = c self._reset() def __repr__(self): return '%s(%s, %s, %s)' % (self.__class__.__name__, self.a, self.b, self.c) def _reset(self): '''Called whenever the sides of the triangle change''' pass def _seta(self, v): self.check(v, self.b, self.c) # fixed typo in original self._a = v self._reset() def _setb(self, v): self.check(v, self.a, self.c) self._b = v self._reset() def _setc(self, v): self.check(v, self.a, self.b) self._c = v self._reset() def _geta(self): return self._a def _getb(self): return self._b def _getc(self): return self._c a = property(_geta, _seta) b = property(_getb, _setb) c = property(_getc, _setc) Kirby From ajsiegel at optonline.net Sun Aug 21 21:09:42 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 15:09:42 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: Message-ID: <0ILL000EN6KBWDW3@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > > I'd propose two reasons why properties are so successful. > > The first explanation comes from eXtreme Programming. One big goal of > XP is to stop wasting time doing "big design up front." Then my situation is a bit ironic. What I don't seem to have realized - at least to my own satisfaction - is some rational scheme for the use of properties. They are used - somewhere in the range from haphazardly to intuitively. So I am left to refactor working code to give some scheme to my use of properties. And since this refactoring is coming at a fairly late stage of design, I don't feel the same need to leave my XP options open to the extent that I might had I thought more thoroughly about the use of properties earlier in the process. So where I come out on the use of properties now might not be the same as where I would have come out at some different point. Why do I find this unsatisfying? As an API matter, I find myself liking the clue that "()" provides as to whether one is accessing something designed be determined dynamically. So I find myself leaning towards the option of making the use of properties go away in PyGeo. Art From urnerk at qwest.net Sun Aug 21 21:27:11 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 21 Aug 2005 12:27:11 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL00G1G4K4QRI2@mta9.srv.hcvlny.cv.net> Message-ID: <20050821192721.B2AD41E4004@bag.python.org> > PyGeo has a Triangle object, inherited from the Plane object. It exists > mostly for drawing purposes, as the portion of the plane enclosed by the > infinite lines connecting any 3 points. Since all Triangles are > projectively equivalent, in the context of PyGeo there is little to be > gained by saying much of anything about any particular triangle - and > little > is. > > > Art Good point about all triangles being equivalent given projection. In nailing down the angles, we've inadvertently defined a fourth vertex: the point of view. Given we're talking four vertices, we should maybe rename our class Tetrahedron ;-D. A transformation that has no impact on angles, is scaling. A feature I'd like to add to the Triangle sub/class is scalability -- using operator overloading why not? Here a design question is: should mytri * 3 change mytri, or should it return a new object. My preference is for the latter, since we can always rebind mytri to the output of __mul__. Should I also define __div__ while I'm at it? class Triangle2(BaseTriangle): def _reset(self): self.perimeter = self.a + self.b + self.c s = 0.5 * self.perimeter self.area = math.sqrt(s * (s - self.a) *(s - self.b) * (s - self.c)) self.A = math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) self.B = math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) self.C = math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) def __mul__(self, scalar): a = self.a * scalar b = self.b * scalar c = self.c * scalar return Triangle2(a,b,c) __rmul__ = __mul__ >>> reload(trig) >>> from trig import Triangle2 as Tri >>> mytri = Tri(3,4,5) >>> mytri = mytri * 3 >>> mytri.area 54.0 >>> mytri.a 9 >>> math.degrees(mytri.C) 90.0 Other enhancements: I could add xyz coordinates as read-only, but have translation, rotation and scale methods (this last already defined) make them change. Having xyz coordinates will allow me to feed triangle objects to draw objects, e.g. for output to VPython, POV-Ray, VRML or what-have-we. Kirby From ajsiegel at optonline.net Sun Aug 21 22:13:15 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 16:13:15 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL001SV7DDM0W0@mta22.srv.hcvlny.cv.net> Message-ID: <0ILL006T69I8CDG4@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > > Good point about all triangles being equivalent given projection. In > nailing down the angles, we've inadvertently defined a fourth vertex: the > point of view. Given we're talking four vertices, we should maybe rename > our class Tetrahedron ;-D. Good solution - as it leaves open the question as to where is the triangle and where is the point of view ;) Though when we add another dimension, all tetras are projectively equivalent. Part of why I can't adjust to a focus on a tetra that happens to be regular in some way. Art From urnerk at qwest.net Sun Aug 21 22:31:45 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 21 Aug 2005 13:31:45 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL006T69I8CDG4@mta5.srv.hcvlny.cv.net> Message-ID: <20050821203156.25F5B1E4004@bag.python.org> > Though when we add another dimension, all tetras are projectively > equivalent. Part of why I can't adjust to a focus on a tetra that happens > to be regular in some way. > > Art > Well, another way of putting it is: all tetrahedra are the same regular one, except not because of viewpoints. Kirby From Scott.Daniels at Acm.Org Sun Aug 21 22:30:25 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun, 21 Aug 2005 13:30:25 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL000EN6KBWDW3@mta5.srv.hcvlny.cv.net> References: <0ILL000EN6KBWDW3@mta5.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > > As an API matter, I find myself liking the clue that "()" provides as to > whether one is accessing something designed be determined dynamically. In general I agree with that sentiment. > I find myself leaning towards the option of making the use of properties go > away in PyGeo. If you want to keep anything as properties, I'd keep the ones those properties with the least dynamic nature. --Scott David Daniels Scott.Daniels at Acm.Org From urnerk at qwest.net Sun Aug 21 22:41:43 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 21 Aug 2005 13:41:43 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL000EN6KBWDW3@mta5.srv.hcvlny.cv.net> Message-ID: <20050821204618.178A61E4004@bag.python.org> > Why do I find this unsatisfying? > I think part of the picture is you're coding for yourself i.e. your APIs are used internally by your own code. Refactoring *everything* is always a possibility. Suppose you'd already published a Triangle class API and then discovered you needed more dynamism. The property feature lets you sneak in some methods without changing the already-published API and breaking client code. A lot of these lessons about robust software development come from group or community efforts. Some aspects of Python maybe don't much excite you because you're primarily a solo coder (as am I much of the time). Kirby From ajsiegel at optonline.net Mon Aug 22 02:55:59 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 21 Aug 2005 20:55:59 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL00HF0B0XGNP1@mta25.srv.hcvlny.cv.net> Message-ID: <0ILL0062OMLHD0C3@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > > A lot of these lessons about robust software development come from group > or > community efforts. Some aspects of Python maybe don't much excite you > because you're primarily a solo coder (as am I much of the time). I guess. Though I can't say I find there to be much consensus out there about what language features truly make for robust software development from group or community efforts. Python itself can be thought of as a robust community effort - in C, which itself probably pre-dates/ignores much of the lessons of what is necessary for such effort. Java seems obsessed with these kinds of concerns - which is why I do in fact find coding in it as a solo as a kind of foolishness. OTOH, I find code readability absolutely satisfying, even without an expectation that anyone else will in fact be reading it. Whatever. Art From urnerk at qwest.net Mon Aug 22 19:08:42 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 22 Aug 2005 10:08:42 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILL0062OMLHD0C3@mta5.srv.hcvlny.cv.net> Message-ID: <20050822172012.BEF011E4008@bag.python.org> > I guess. > > Though I can't say I find there to be much consensus out there about what > language features truly make for robust software development from group or > community efforts. There's a long history of coders seeking consensus, but not arriving at any set in stone answers (no carved tablets at the Smithsonian), in part because the backdrop is always shifting, in terms of languages and technologies. The design patterns movement is the latest chapter in the series, drawing inspiration from that 'pattern language' book beloved by the architects, and followed by a big splash by the Gang of Four (an allusion to recent Chinese political history). O'Reilly's 'Head First Design Patterns' is one of the most pedagogically sophisticated in this tradition to date (I'm still somewhat awed by it, though I've heard others express a wish for still greater content density): http://www.oreilly.com/catalog/hfdesignpat/ We had the structured programming revolution, which tossed out the GOTOs, and the object oriented revolution. Under the hood, we've been moving to virtual machine platforms with their own byte code languages. This paradigm has taken over at Microsoft and places (i.e. .NET). Python is one of these VM languages, as are Java and C# (the latter being system languages, less agile, yet very necessary, as implementation languages for Python itself among other things). > Python itself can be thought of as a robust community > effort - in C, which itself probably pre-dates/ignores much of the lessons > of what is necessary for such effort. Java seems obsessed with these kinds > of concerns - which is why I do in fact find coding in it as a solo as a > kind of foolishness. And now we have IronPython in C#. C is like clay -- it can be anything you want it to be if you're good at it, which Guido and friends are (I'm not -- I enter the picture as an xBase coder, working up the dBase II, III, IV, FoxPro fish ladder (we've always had an interactive 'dot prompt,' which is why Python's >>> seems so natural to us (there're other FoxPro geeks out there, bending a Python framework into a familiar shape (named Dabo), as I learned at Pycon in DC last March [1]))). The object orientation was always there in Python, but user-defined classes were originally 2nd class citizens. Getting them to be top level, unifying types and classes, has been a long haul saga within the Python community. I'm still a bit hazy myself on how to subclass some of the primitive types. Where do you store the value? I appreciated getting a history lesson on Python's origins and early evolution from Guido himself in Sweden, where he talked to a packed upper floor room full of mostly newbies (EuroPython had a friendly newbie track). > OTOH, I find code readability absolutely satisfying, even without an > expectation that anyone else will in fact be reading it. > > Whatever. > > Art I'm glad to hear it, as I do expect PyGeo code will be eyeballed by many more newbies as time goes on, ready to get their feet wet as strangers in a strange land. Your coding style will be an early influence on these little penguins. One of the challenges I had @ OSCON was how to talk about Elastic Interval Geometry (EIG) as inspired by Kenneth Snelson and others, without being off topic. Because the best open source EIG apps are written in Java (Springie and Fluidiom), and the best closed source offering (Alan's SpringDance) is in Delphi. My solution: write the presentation manager itself in Python, such that at any given moment, even if the slides were showing Java creations, the screen itself would be Python + Pygame driven (I also went out over the Internet to demo the Java applets live, but only for a few minutes). This strategy worked well IMO (plus I got positive feedback from people in the audience who came up to me during the rest of the conference). My code, though somewhat quirky (look at the weird way I pass parameters -- inside a parameters object), isn't especially crash prone, does what it's supposed to do.[2] I too am an influence, and fortunately just one of many (my stuff should be part of a balanced diet). Kirby [1] http://mybizmo.blogspot.com/2005/03/pycon-2005.html [2] http://www.4dsolutions.net/ocn/oscon2005.html From chuck at freshsources.com Mon Aug 22 21:43:17 2005 From: chuck at freshsources.com (Chuck Allison) Date: Mon, 22 Aug 2005 13:43:17 -0600 Subject: [Edu-sig] Design patterns In-Reply-To: <20050822172012.BEF011E4008@bag.python.org> References: <0ILL0062OMLHD0C3@mta5.srv.hcvlny.cv.net> <20050822172012.BEF011E4008@bag.python.org> Message-ID: <13510634239.20050822134317@freshsources.com> Hello Kirby, Since this discussion has swerved a little, I'd like to pose a query. I've been using patterns since 1995 and am teaching a course starting Wednesday (a full semester course) on Design Patterns using the Heads First book. My query: do you have any ideas you might proffer for programming assignments? I'd like to give a handful of programming assignments throughout the semester that aren't as short and cutesy as what's in the book. Any ideas would be greatly appreciated! Monday, August 22, 2005, 11:08:42 AM, you wrote: KU> There's a long history of coders seeking consensus, but not arriving at any KU> set in stone answers (no carved tablets at the Smithsonian), in part because KU> the backdrop is always shifting, in terms of languages and technologies. KU> The design patterns movement is the latest chapter in the series, drawing KU> inspiration from that 'pattern language' book beloved by the architects, and KU> followed by a big splash by the Gang of Four (an allusion to recent Chinese KU> political history). O'Reilly's 'Head First Design Patterns' is one of the KU> most pedagogically sophisticated in this tradition to date (I'm still KU> somewhat awed by it, though I've heard others express a wish for still KU> greater content density): KU> http://www.oreilly.com/catalog/hfdesignpat/ KU> We had the structured programming revolution, which tossed out the GOTOs, KU> and the object oriented revolution. Under the hood, we've been moving to KU> virtual machine platforms with their own byte code languages. This paradigm KU> has taken over at Microsoft and places (i.e. .NET). Python is one of these KU> VM languages, as are Java and C# (the latter being system languages, less KU> agile, yet very necessary, as implementation languages for Python itself KU> among other things). -- Best regards, Chuck From ajsiegel at optonline.net Tue Aug 23 14:59:56 2005 From: ajsiegel at optonline.net (Arthur) Date: Tue, 23 Aug 2005 08:59:56 -0400 Subject: [Edu-sig] Design patterns Message-ID: <0ILO006E5ES2CYW4@mta5.srv.hcvlny.cv.net> >> I guess. >> >> Though I can't say I find there to be much consensus out there about what >> language features truly make for robust software development from group >> or community efforts. >There's a long history of coders seeking consensus, but not arriving at any >set in stone answers (no carved tablets at the Smithsonian), in part >because the backdrop is always shifting, in terms of languages and >technologies. Interesting to read Paul Graham's article "The Hundred-Year Language" which - as noted in the article heading - was derived from his keynote at PyCon 2003. http://www.paulgraham.com/hundred.html """ Languages evolve slowly because they're not really technologies. Languages are notation. """ In his mind, (and I think in yours as well) computer languages are more like mathematical notation than a form of technology. And as such, evolution is slower - not at the pace of the changes in the underlying technology. Though certainly not uninfluenced by those developments. The most important technological development he seems to point to is the increasing raw power and speed of processors, which allow languages to design away from a preoccupation with performance issues. He thinks - though without great confidence in his intuition here - that Java is an example of a language headed down a dead-end evolutionary path. Than so must too be C#. Despite having some understanding that it must be annoying to hear high-fallutin theory from someone at my level in this domain, I persist. And it seems to me that the evolutionary successful language will include in its approach clear and concise constraints on its ambitions. If I am understanding "properties" mostly correctly, and in fact their reason for being is to allow for a fundamental midstream redesign of a program without alteration of that program's API, I am thinking something to the effect that it is only possible to do the impossible in half-measures, and half-measures are only half-measures and who wants to work in an environment of half-measures. I don't think mathematical notation, for example, includes the concept of the half-measure. Whatever. Art From Scott.Daniels at Acm.Org Tue Aug 23 19:13:27 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue, 23 Aug 2005 10:13:27 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILO006E5ES2CYW4@mta5.srv.hcvlny.cv.net> References: <0ILO006E5ES2CYW4@mta5.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > If I am understanding "properties" mostly correctly, and in fact their > reason for being is to allow for a fundamental midstream redesign of a > program without alteration of that program's API, I am thinking something to > the effect that it is only possible to do the impossible in half-measures, > and half-measures are only half-measures and who wants to work in an > environment of half-measures. > > I don't think mathematical notation, for example, includes the concept of > the half-measure. OK, how about this explanation. If I am providing software support to a group of scientists running experiments, I can give them an API and the fastest-to-write code that passes tests. Once I've done that, they can get to work using the software while I go about the work of making the software more reasonably designed and responding to efficiency problems that they actually encounter. We use the API as a "treaty point" -- they stick to using it, and I stick to providing it. This structure can also be used to provide the "for free work-alike" and the "pricey efficient" versions. Properties allows me to determine later (perhaps after watching how they actually use the API) whether I should precalculate the triangle angles, recalculate them each time, or find an even fancier version where I compute them each the first time on demand and re-use those results, invalidating the angles whenever a side is changed. If I have to make those design decisions up front, I have to assume a pattern of use. If I wait until I have actual users, I can get real statistics on how the use the API. We decouple our work this way. --Scott David Daniels Scott.Daniels at Acm.Org From Scott.Daniels at Acm.Org Tue Aug 23 19:16:58 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue, 23 Aug 2005 10:16:58 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <13510634239.20050822134317@freshsources.com> References: <0ILL0062OMLHD0C3@mta5.srv.hcvlny.cv.net> <20050822172012.BEF011E4008@bag.python.org> <13510634239.20050822134317@freshsources.com> Message-ID: Chuck Allison wrote: > Since this discussion has swerved a little, I'd like to pose a query. > I've been using patterns since 1995 and am teaching a course starting > Wednesday (a full semester course) on Design Patterns using the Heads > First book. My query: do you have any ideas you might proffer for > programming assignments? I'd like to give a handful of programming > assignments throughout the semester that aren't as short and cutesy > as what's in the book. Any ideas would be greatly appreciated! What subject and to whom? If programming and/or CS, I'd be tempted to give a chain of assignments where the requirements swerve, showing the value of malleability in code design. --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Tue Aug 23 20:08:32 2005 From: ajsiegel at optonline.net (ajsiegel@optonline.net) Date: Tue, 23 Aug 2005 14:08:32 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: References: <0ILO006E5ES2CYW4@mta5.srv.hcvlny.cv.net> Message-ID: ----- Original Message ----- From: Scott David Daniels > If I wait until I have actual users, I can get > real statistics on how the use the API. We decouple our work this > way. But in my look of it, properties are a "solution" to one of a nearly infinite set of these kinds of possibilites. And in that sense a half-measure. Certainly many areas will remain where our API and our design are irretrievably coupled. All I can try to do is offer the perspective of of a mid-brow developer, who tries. Again, in the case of the development of PyGeo - and willing to refactor until the cows come home - the solutions to problems seemed to be mostly a process of discovery. When I found a better way to do something than I had before, I knew it was better and I knew why it was better. And Python as a languagfe and as as disclipline seemed more than cooperative as a partner, and guide in the process. "Properties" being a rare distraction. Art From urnerk at qwest.net Wed Aug 24 01:29:33 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 23 Aug 2005 16:29:33 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <13510634239.20050822134317@freshsources.com> Message-ID: <20050823232943.DDA471E4003@bag.python.org> > -----Original Message----- > From: Chuck Allison [mailto:chuck at freshsources.com] > Sent: Monday, August 22, 2005 12:43 PM > To: Kirby Urner > Cc: 'Arthur'; 'Scott David Daniels'; edu-sig at python.org > Subject: Re[2]: [Edu-sig] Design patterns > > Hello Kirby, > > Since this discussion has swerved a little, I'd like to pose a query. > I've been using patterns since 1995 and am teaching a course starting > Wednesday (a full semester course) on Design Patterns using the Heads > First book. My query: do you have any ideas you might proffer for > programming assignments? I'd like to give a handful of programming > assignments throughout the semester that aren't as short and cutesy > as what's in the book. Any ideas would be greatly appreciated! Hi Chuck -- You could throw out ideas for big projects that Python has gotten used for: a) air traffic control and b) languages training for the military c) some other example only you know about (like El Fish) (or are you teaching this as a Java class and just lurk with snake charmers for ideas -- like I might do in a Ruby conference full of gem smiths). In case 'a)' there's a backend database to consult, and a Tk canvas object for showing airplanes along their vectors, converging/diverging from airport termini. In case 'b)', Python was glue around the game engine, knitting to a speech recognizer that'd give feedback as to how a soldier/player was doing using Arabic in Iraq (e.g. 'game over' if things were going badly -- like if a cuss word was said). I draw both of these examples from Pycon in March 2005, though I could have chosen other examples from EuroPython or OSCON, also events on my calendar this year. Probably an important design pattern common to both of these applications is MVC (model-view-controller). A key design pattern ideal is loose coupling without losing coupling i.e. you want to stay connected, but you don't want to overdo it, in case you want to recombine the various components down the road. MVC would let us swap in a different database on the back, and only have to teach the model about it, while the controllers and outputted views would go against the same API and use the same markup (or whatever). That being said, I think cutesy, short (even sexy) programs *are* what's needed in an intro design patterns course, since it's the *patterns* that matter, not industrial strength vertical market source code, crufted with 10,001 years of specific knowledge domain content (like the stuff I do for RHDS/MDRC -- clinical data around heart procedures, and tons more pattern language where that came from (not being an MD, I never had to learn much of it)). But I haven't seen your syllabus and don't know where in the curriculum your particular course fits in. I'm simply extrapolating from my own position, and our circumstances may not match (e.g. you probably didn't spend most of the day mixing wood stains and applying them to wood products -- like, welcome to Oregon/SiliconForest). Kirby From urnerk at qwest.net Wed Aug 24 02:06:39 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 23 Aug 2005 17:06:39 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILO006E5ES2CYW4@mta5.srv.hcvlny.cv.net> Message-ID: <20050824000649.55AEC1E4003@bag.python.org> > In his mind, (and I think in yours as well) computer languages are more > like mathematical notation than a form of technology. And as such, > evolution is slower - not at the pace of the changes in the underlying > technology. However I'm sometimes in the mood to not draw this line between notation and technology, looking at language as technology, as tools. And yes, different technologies evolve at different rates. Bucky kept saying the lead time from prototype to mainstream was a key variable, and in electronics might be about 3 years, whereas in housing it might be at least 10 if not more. So he figured housing prototypes in the 1940s might pan out in the 1960s, and to some extent they did (and didn't). Plus he kept making prototypes, as did his students (J. Baldwin and Joe Clinton come to mind). > > Though certainly not uninfluenced by those developments. The most > important technological development he seems to point to is the > increasing raw power and speed of processors, which allow languages > to design away from a preoccupation with performance issues. However it's also important that, given this opportunity for faster physical cycling, per the silicon chip computer, software engineers were able to rise to the occasion and give us VHLLs like Python, i.e. were able to take advantage of those extra fast cycles and yet still make the language parsable and machine friendly enough for a CPU (which is ultimately nothing more than a fast arithmetical/logical unit, no matter how fast it goes). > He thinks - though without great confidence in his intuition here - that > Java is an example of a language headed down a dead-end evolutionary path. > Than so must too be C#. > A language has a half life. Big expensive systems that aren't broken don't need to be replaced, only tinkered with, so you have this long aftermarket for language skills, even when the language itself is "officially" dead. FORTRAN is a good example. At the OSCON/Stonehenge party this year, Jeff Zucker (a Perl saint) and I met up with a FORTRAN guy who to this day works on optimizing FORTRAN compilers, to run more effectively against today's chips. Because lots of big fancy computer models still perform useful service and make heavy use of FORTRAN. > Despite having some understanding that it must be annoying to hear > high-fallutin theory from someone at my level in this domain, I persist. > > And it seems to me that the evolutionary successful language will include > in its approach clear and concise constraints on its ambitions. > So far you haven't said anything I disagree with. Just adding emphasis: software had to meet the integrated chip designers at least half way, and computer languages aim for a layer in a long term archeology that could include working bits for centuries, if not millennia -- just as centuries old math notation still expresses algorithms in useful form today (your original point). > If I am understanding "properties" mostly correctly, and in fact their > reason for being is to allow for a fundamental midstream redesign of a > program without alteration of that program's API, I am thinking something > to the effect that it is only possible to do the impossible in half- > measures, and half-measures are only half-measures and who wants to work > in an environment of half-measures. In Java, you should probably work out ahead of time if you want to use private variables cloaked in protective getters/setters, so that you might continue fiddling with the guts indefinitely, even as your users experience and enjoy a simple attributes-based API that hardly ever changes (like the front panel on a TV: channel and volume, yet no tubes inside (not even a picture tube these days)). In Python, you have more liberty to wrap what used to be a simple attribute in a property, and so maybe don't have to hard code so many design decisions up front. Java coders may be more likely to practice "defensive programming" than Python coders and make everything private and method-protected up front. This philosophy is manifest throughout the language (with its private, protected, and public attributes -- whereas in C++ you also have friends [1]). Some say Python is a "consenting adults" language, with permissions by convention vs. enforced by a nanny compiler (I'm not saying the latter can't be a nice experience also). > I don't think mathematical notation, for example, includes the concept of > the half-measure. > > Whatever. > > Art For me, non-executing math notation needn't be enshrined as the ideal. So much about math involves insulating one's self from having to deal with real world complexity (only to discover it later, one hopes in some manageable form). Computer languages ventured off into the wild west and took on whatever features we needed to do real time accommodation of client wishes. So I'm not nostalgic for the good old days, before we had computer science. I don't pine for a "math rules" world, wherein more machine oriented languages are second class and pitiable. There's nothing pitiable about a Perl, Ruby or Python. They're just tools that do what they're supposed to. They're not here to whine about not being mere "math notations" as if that would be an improvement. Kirby [1] http://www.faqts.com/knowledge_base/view.phtml/aid/24762/fid/163 From ajsiegel at optonline.net Wed Aug 24 03:10:24 2005 From: ajsiegel at optonline.net (Arthur) Date: Tue, 23 Aug 2005 21:10:24 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILP0056O9N549D0@mta18.srv.hcvlny.cv.net> Message-ID: <0ILP001SMCLP7IHP@mta1.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > They're not here to whine about not being mere "math notations" as if that > would be an improvement. That's one way to attempt to characterize my point - or Graham's point, for that matter. Except that it of course misses the point. And is a bit obnoxious. The usual. My target, if anything, is not Python - but the pressure on it to be more Java and C# like. But more to my point is the fact that I don't expect my programming language to solve the problem of decoupling my API from my code. Because I don't expect it to be a solvable problem. Seems to me to make more sense if my programming language provides the environment for deriving concrete solutions to defined problems. And project management tools (and human beings interacting with human beings) manage phase-in and change. Whatever. Art From chuck at freshsources.com Wed Aug 24 03:19:20 2005 From: chuck at freshsources.com (Chuck Allison) Date: Tue, 23 Aug 2005 19:19:20 -0600 Subject: [Edu-sig] Design patterns In-Reply-To: <20050823232943.DDA471E4003@bag.python.org> References: <13510634239.20050822134317@freshsources.com> <20050823232943.DDA471E4003@bag.python.org> Message-ID: <1526159895.20050823191920@freshsources.com> Hello Kirby, Thanks for this good input (you too, Scott). My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html. I like your point about cutesy having its place. I just don't see a way to use what's in HFDP as the basis for a programming assignment, but maybe it will come after a few days. As a professor, I like having my ducks in a row a priori, but that's not happening this first time around. Since I teach 3 upper division courses, I'm just a little nervous about having time to invent sufficient material. I was just hoping someone had had a similar teaching experience I could "borrow" from. All comments appreciated. Thanks again. Tuesday, August 23, 2005, 5:29:33 PM, you wrote: >> -----Original Message----- >> From: Chuck Allison [mailto:chuck at freshsources.com] >> Sent: Monday, August 22, 2005 12:43 PM >> To: Kirby Urner >> Cc: 'Arthur'; 'Scott David Daniels'; edu-sig at python.org >> Subject: Re[2]: [Edu-sig] Design patterns >> >> Hello Kirby, >> >> Since this discussion has swerved a little, I'd like to pose a query. >> I've been using patterns since 1995 and am teaching a course starting >> Wednesday (a full semester course) on Design Patterns using the Heads >> First book. My query: do you have any ideas you might proffer for >> programming assignments? I'd like to give a handful of programming >> assignments throughout the semester that aren't as short and cutesy >> as what's in the book. Any ideas would be greatly appreciated! KU> Hi Chuck -- KU> You could throw out ideas for big projects that Python has gotten used for: KU> a) air traffic control and KU> b) languages training for the military KU> c) some other example only you know about (like El Fish) KU> (or are you teaching this as a Java class and just lurk with snake charmers KU> for ideas -- like I might do in a Ruby conference full of gem smiths). KU> In case 'a)' there's a backend database to consult, and a Tk canvas object KU> for showing airplanes along their vectors, converging/diverging from airport KU> termini. KU> In case 'b)', Python was glue around the game engine, knitting to a speech KU> recognizer that'd give feedback as to how a soldier/player was doing using KU> Arabic in Iraq (e.g. 'game over' if things were going badly -- like if a KU> cuss word was said). KU> I draw both of these examples from Pycon in March 2005, though I could have KU> chosen other examples from EuroPython or OSCON, also events on my calendar KU> this year. KU> Probably an important design pattern common to both of these applications is KU> MVC (model-view-controller). A key design pattern ideal is loose coupling KU> without losing coupling i.e. you want to stay connected, but you don't want KU> to overdo it, in case you want to recombine the various components down the KU> road. MVC would let us swap in a different database on the back, and only KU> have to teach the model about it, while the controllers and outputted views KU> would go against the same API and use the same markup (or whatever). KU> That being said, I think cutesy, short (even sexy) programs *are* what's KU> needed in an intro design patterns course, since it's the *patterns* that KU> matter, not industrial strength vertical market source code, crufted with KU> 10,001 years of specific knowledge domain content (like the stuff I do for KU> RHDS/MDRC -- clinical data around heart procedures, and tons more pattern KU> language where that came from (not being an MD, I never had to learn much of KU> it)). KU> But I haven't seen your syllabus and don't know where in the curriculum your KU> particular course fits in. I'm simply extrapolating from my own position, KU> and our circumstances may not match (e.g. you probably didn't spend most of KU> the day mixing wood stains and applying them to wood products -- like, KU> welcome to Oregon/SiliconForest). KU> Kirby KU> _______________________________________________ KU> Edu-sig mailing list KU> Edu-sig at python.org KU> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck From Scott.Daniels at Acm.Org Wed Aug 24 03:27:53 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue, 23 Aug 2005 18:27:53 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILP001SMCLP7IHP@mta1.srv.hcvlny.cv.net> References: <0ILP0056O9N549D0@mta18.srv.hcvlny.cv.net> <0ILP001SMCLP7IHP@mta1.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > ... more to my point is the fact that I don't expect my programming language > to solve the problem of decoupling my API from my code. Because I don't > expect it to be a solvable problem. I don't know if I'm beating a dead horse, but I don't claim properties solves the problem of decoupling an API from its current implementation. I do claim it provides another tool to express a properly decoupled API. --Scott David Daniels Scott.Daniels at Acm.Org From Scott.Daniels at Acm.Org Wed Aug 24 03:39:51 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue, 23 Aug 2005 18:39:51 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <1526159895.20050823191920@freshsources.com> References: <13510634239.20050822134317@freshsources.com> <20050823232943.DDA471E4003@bag.python.org> <1526159895.20050823191920@freshsources.com> Message-ID: Chuck Allison wrote: > My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html. > One thing I've always wanted to see if the class is small enough: Groups shuffling other group's previous layers, and providing feedback (but not grades) to the original group. It is always a shock the first time you see someone else trying to use code you thought was clear. The reason for no grades is to eliminate the "grade race gaming" among groups. A good MVC exercise is a "fairy chess" (e.g. kriegspiel) server and clients. A sample sequence of constraints: (1) single game (2) single game with observers (3) game with observers w/o enough info to "cheat" by players. (4) multi-game server. --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Wed Aug 24 12:36:10 2005 From: ajsiegel at optonline.net (Arthur) Date: Wed, 24 Aug 2005 06:36:10 -0400 Subject: [Edu-sig] Design patterns In-Reply-To: Message-ID: <0ILQ00GGV2SFWI7K@mta1.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > Arthur wrote: > > ... more to my point is the fact that I don't expect my programming > language > > to solve the problem of decoupling my API from my code. Because I don't > > expect it to be a solvable problem. > > I don't know if I'm beating a dead horse, but I don't claim properties > solves the problem of decoupling an API from its current implementation. > I do claim it provides another tool to express a properly decoupled > API. Yup. You're beating a dead horse. Everything I can find about properties in Java and C# relate it to encapsulation and data hiding. Everything I can find about Python relate that the language does not attempt to support encapsulation and data hiding in the Java and C# sense. I might be a dead horse who is dead wrong, but the issue about how properties fit into Python is certainly not straightforward in the least, and responding as if it were is grossly unfair - to the question raised. Art From urnerk at qwest.net Wed Aug 24 16:52:36 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 24 Aug 2005 07:52:36 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <1526159895.20050823191920@freshsources.com> Message-ID: <20050824145245.55D261E4003@bag.python.org> > -----Original Message----- > From: edu-sig-bounces+urnerk=qwest.net at python.org [mailto:edu-sig- > bounces+urnerk=qwest.net at python.org] On Behalf Of Chuck Allison > Sent: Tuesday, August 23, 2005 6:19 PM > To: Kirby Urner > Cc: edu-sig at python.org > Subject: Re: [Edu-sig] Design patterns > > Hello Kirby, > > Thanks for this good input (you too, Scott). My syllabus is at > http://uvsc.freshsources.com/html/cns_439r.html. I like your point > about cutesy having its place. I just don't see a way to use what's in > HFDP as the basis for a programming assignment, but maybe it will come > after a few days. As a professor, I like having my ducks in a row a > priori, but that's not happening this first time around. Since I teach > 3 upper division courses, I'm just a little nervous about having time > to invent sufficient material. I was just hoping someone had had a > similar teaching experience I could "borrow" from. All comments > appreciated. Thanks again. Hi Chuck -- I don't have HFDP in front if me, but if it does MVC at all, I can imagine using the Triangle we've been discussing as a model, then adding viewer and controller objects, making the triangle change in some way (controlling it), while displaying (viewing it). Here's some code, which as yet doesn't actually make use of VPython -- but that's where it's going. Note that my viewer expects to work with a 'shape' object, which is supposed to have attributes verts (a dictionary of labeled vertices) and edges (a list of vertex pairs, using those labels). Since my triangle object wasn't written that way, I subclass a Triangle2 as TriAdapter, solely for the purpose of making it behave like a shape. Kirby === # uses code already/recently posted to this list for BaseTriangle class Triangle2(BaseTriangle): """ Model """ @property def coords(self): return {'A':self._pA, 'B':self._pB, 'C':self._pC} def _reset(self): a,b,c = self.a, self.b, self.c # for brevity self.perimeter = a + b + c s = 0.5 * self.perimeter self.area = math.sqrt(s * (s - a)*(s - b)*(s - c)) self.A = math.acos((-a**2 + b**2 + c**2)/(2.0*b*c)) self.B = math.acos(( a**2 - b**2 + c**2)/(2.0*a*c)) self.C = math.acos(( a**2 + b**2 - c**2)/(2.0*a*b)) self._pA = (0.0, 0.0, 0.0) self._pB = (a , 0.0, 0.0) self._pC = ((a**2 + b**2 - c**2)/(2.0*a), math.sqrt((-a+b+c)*(a-b+c)*(a+b-c)*(a+b+c))/(2*a), 0.0) def __mul__(self, scalar): a = self.a * scalar b = self.b * scalar c = self.c * scalar return self.__class__(a,b,c) __rmul__ = __mul__ class TriAdapter(Triangle2): """ Make a triangle work like a Shape, i.e. add edges and verts attributes """ def __init__(self, a,b,c): Triangle2.__init__(self, a,b,c) self.edges = [('A','B'),('B','C'),('C','A')] @property def verts(self): return self.coords class Pulser(object): """ A controller: makes a shape bigger in steps, then smaller, back to original """ def __init__(self, shape, viewer): self.shape = shape self.viewer = viewer def run(self): for i in range(15): self.viewer.display(self.shape) self.shape = self.shape * 1.1 for i in range(16): self.viewer.display(self.shape) self.shape = self.shape * (1/1.1) class Vpyview(object): """ A viewer: view using VPython -- very unfinished """ def display(self, shape): self._showverts(shape.verts) self._showedges(shape.edges) def _showedges(self, edges): # stub method for e in edges: print e def _showverts(self, verts): # stub method for v in verts: print v, verts[v] def main(): """ Main call sequence -- maybe loop through random triangles eventually """ theviewer = Vpyview() theshape = TriAdapter(3,3,3) pulser = Pulser(theshape, theviewer) pulser.run() From urnerk at qwest.net Wed Aug 24 18:33:57 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 24 Aug 2005 09:33:57 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <0ILQ00GGV2SFWI7K@mta1.srv.hcvlny.cv.net> Message-ID: <20050824163406.06E551E4003@bag.python.org> > I might be a dead horse who is dead wrong, but the issue about how > properties fit into Python is certainly not straightforward in the least, > and responding as if it were is grossly unfair - to the question raised. > > Art I think use cases were described, and demonstrated, in which the property feature made sense, e.g. we wanted an attributes-based API into our triangle object, but sometimes the results were computed on the fly. Martelli shows this same use case with a rectangle object (Python in a Nutshell, pg. 85). As for using decorator syntax to define properties, Scott has shown how this might be done. However, this approach is entirely optional. Python coders may flag private attributes and methods with _ and __, with the latter causing name mangling based on class name: >>> class Foo(object): def __hidden(self): pass >>> dir(Foo) ['_Foo__hidden'...] Kirby From urnerk at qwest.net Wed Aug 24 18:42:04 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 24 Aug 2005 09:42:04 -0700 Subject: [Edu-sig] Design patterns In-Reply-To: <20050824145245.55D261E4003@bag.python.org> Message-ID: <20050824164217.25A4C1E4003@bag.python.org> > Here's some code, which as yet doesn't actually make use of VPython -- but > that's where it's going. > And here's where it (the code) went. Very minimal, at this point but enough to get VPython actually doing something with the triangle. A student could start with this code and start adding stuff e.g. make it more colorful, add defaults (e.g. radius), cycle through random triangles in main() -- using a try loop to catch illegals -- and so on. Kirby === class Vpyview(object): """ A viewer: view using VPython """ def __init__(self): self._garbage = [] def display(self, shape): self._garbagecollect() self._showverts(shape.verts) self._showedges(shape.edges, shape.verts) time.sleep(.1) def _garbagecollect(self): for g in self._garbage: g.visible = 0 def _showedges(self, edges, verts): for e in edges: v0 = vector(verts[e[0]]) v1 = vector(verts[e[1]]) edge = cylinder(pos=v0, axis=v1-v0, radius = 0.1) self._garbage.append(edge) def _showverts(self, verts): for v in verts: v0 = vector(verts[v]) sph = sphere(pos=v0, radius=0.1) self._garbage.append(sph) from visual import * import time def main(): """ Main call sequence """ thescene = display(title='MVC Demo', center=(0,0,0), background=(.5, .5, .5)) thescene.autoscale = 0 theviewer = Vpyview() theshape = TriAdapter(3,3,3) pulser = Pulser(theshape, theviewer) pulser.run() From ajsiegel at optonline.net Thu Aug 25 14:36:12 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 25 Aug 2005 08:36:12 -0400 Subject: [Edu-sig] Design Patents Message-ID: <0ILS00FQH30UO33W@mta6.srv.hcvlny.cv.net> >I think use cases were described, and demonstrated, in which the property >feature made sense, e.g. we wanted an attributes-based API into our >triangle object, but sometimes the results were computed on the fly. And I notice that without the use of properties, that which is computed on the fly is identified as such. So that properties allow us to have an API that which is unrevealing on this matter. I am not excited yet. Yes, I think I understand. *With* properties we can change our mind after our API is set in stone and nobody will notice or need to adjust. So that properties and their use case encourage us to release less revealing API's all the time, to cover ourselves in the event we set our API in stone prematurely. I don't like properties. And certainly no more so from what I have learned from this attempt at getting more clarity about them. And like to think my naivety on this kind of matter is a purposeful naivety. Art From urnerk at qwest.net Thu Aug 25 16:19:34 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 25 Aug 2005 07:19:34 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILS00FQH30UO33W@mta6.srv.hcvlny.cv.net> Message-ID: <20050825141945.599141E4072@bag.python.org> > >I think use cases were described, and demonstrated, in which the property > >feature made sense, e.g. we wanted an attributes-based API into our > >triangle object, but sometimes the results were computed on the fly. > > And I notice that without the use of properties, that which is computed on > the fly is identified as such. So that properties allow us to have an API > that which is unrevealing on this matter. I am not excited yet. Yes, you weren't excited by some other software engineer's design. But that's different from not seeing a use case (one would hope). I don't want my user to care what's "on the fly" in my triangle. I want to use attributes for all read-only properties. Simple and to the point. Adding () here and not there just clutters the space with irrelevant detail. I'll tell my user to look at the source code if said user cares that much about what's "on the fly." > Yes, I think I understand. *With* properties we can change our mind after > our API is set in stone and nobody will notice or need to adjust. > That was another use case, not identical to the first (i.e. the case of just wanting to use attributes, which could easily have been based on properties right from the start, i.e. there need be no after thoughts). > So that properties and their use case encourage us to release less > revealing API's all the time, to cover ourselves in the event we set > our API in stone prematurely. > They help us craft less cluttered and stupid APIs yes. Your idea to have () every so often, because it's on the fly -- I don't want that. My triangle is not that dumb 'n ugly, sorry (Python supports more than one aesthetic). > I don't like properties. > I do. > And certainly no more so from what I have learned from this attempt at > getting more clarity about them. > > And like to think my naivety on this kind of matter is a purposeful > naivety. > > Art You're welcome to your opinions. Sometimes you whine when it seems your opinions are taken for what they're worth though, which *sometimes* (not all the time) ain't much in my book. Kirby From ajsiegel at optonline.net Thu Aug 25 16:33:25 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 25 Aug 2005 10:33:25 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILS007MU7SPRR10@mta14.srv.hcvlny.cv.net> Message-ID: <0ILS00G238FU0D20@mta9.srv.hcvlny.cv.net> > From: Kirby Urner [mailto:urnerk at qwest.net] > You're welcome to your opinions. Sometimes you whine when it seems your > opinions are taken for what they're worth though, which *sometimes* (not > all > the time) ain't much in my book. We are in agreement. That is precisely when I whine. But there are times, in my view, where a na?ve view is quite worthy of expression, provided it is recognized as such. I believe I both recognize when I am presenting a na?ve view, and when such a view is worthy of expression. So I find that rejecting it as na?ve is fundamentally unresponsive. Art From ajsiegel at optonline.net Thu Aug 25 16:43:48 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 25 Aug 2005 10:43:48 -0400 Subject: [Edu-sig] Design Patterns Message-ID: <0ILS00G3T8X41QD7@mta8.srv.hcvlny.cv.net> > -----Original Message----- > From: Arthur [mailto:ajsiegel at optonline.com] > > So I find that rejecting it as na?ve is fundamentally unresponsive. Just to add - I would feel my approach - no question - more misplaced most other places. But think Guido's ability to retain a sense of naivety in the midst of the highly technical underpinning of his task is largely what makes Python what it is. So I don't feel as off topic or off base as perhaps I should. Apologies. Art From urnerk at qwest.net Thu Aug 25 16:45:43 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 25 Aug 2005 07:45:43 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILS00G238FU0D20@mta9.srv.hcvlny.cv.net> Message-ID: <20050825144554.D7C411E400C@bag.python.org> > So I find that rejecting it as na?ve is fundamentally unresponsive. > > Art > However in this case I don't think your views were rejected as na?ve. On the contrary, your views permeated a sophisticated discussion of use cases, and design patterns more generally (s'been a rich thread) plus Scott sort of liked your using () to connote dynamism (I didn't). The tone was always peer to peer. And we came out in different places re properties, which is fine. I'm not going to change my ways just because of peer group considerations -- I'm not that feckless. Kirby From urnerk at qwest.net Thu Aug 25 17:00:49 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 25 Aug 2005 08:00:49 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILS00G3T8X41QD7@mta8.srv.hcvlny.cv.net> Message-ID: <20050825150101.AC7921E400C@bag.python.org> > So I don't feel as off topic or off base as perhaps I should. > > Apologies. > > Art I don't feel you've been off topic or off base at all in this thread (nor really that much in general). The considerations you have about properties were worth raising. My point is I don't think your contribution was dismissed. On the contrary, use cases were presented, e.g. a Triangle with an attributes-only API. You've said since that you'd prefer a subtle namespace in which callables denote "on the fly" computing, whereas non-callables suggest more static or basic attributes of Triangles. That's all fine and good, but notice we're not dismissing your proposal by calling it na?ve, let alone off topic. No, in my case, I've given thought to your preferences, as I would to those of a peer professional, and then thought "but I like properties and will continue using them, plus encourage my students to consider using them in their own code." That's where I came out. Different place. And so it is among professional programmers. It's clear to me that you and I have very different world views. That makes our discussions more interesting. I *enjoy* your exotic other-worldliness. Makes mine more palatable as well. :-D Kirby From andre.roberge at gmail.com Thu Aug 25 18:00:22 2005 From: andre.roberge at gmail.com (=?ISO-8859-1?Q?Andr=E9_Roberge?=) Date: Thu, 25 Aug 2005 13:00:22 -0300 Subject: [Edu-sig] Design Patterns In-Reply-To: <20050825150101.AC7921E400C@bag.python.org> References: <0ILS00G3T8X41QD7@mta8.srv.hcvlny.cv.net> <20050825150101.AC7921E400C@bag.python.org> Message-ID: Disclaimer: I haven't followed this thread as closely as I should. Picking up on a few words from the discussion (namely "triangle" and "properties"). When I think of a real life triangle, I can describe it in terms of various "properties", such as: the length of each of its three sides, its area, the three internal angles, its perimeter, etc. Of course, most of these properties are interdependent. If I want to refer to a triangle property using the "dot" notation, I want to write: triangle.area triangle.perimeter triangle.shortest_side triangle.longest_side etc. Now, imaging taking a program similar to "Paint" and drawing a triangle. Then change it somewhat (by flipping it, lengthening one side, etc). [Unlike "paint", our program keeps track of objects' nodes.] Suppose I am lengthening one side from 100 horizontal pixels to 120 horizontal pixels (looking at the status bar where such information is displayed). When I change one value, others may change too. When I change one value, I am first and foremost interested about that particular value ... I don't want to have to think of what other values ("properties") may need to change. --- Now, back to computer programming Python properties make it possible to think of all of an object's attribute on an equal footing (given an appropriate design for the class to which the object belong). Without properties, I have to distinguish between values that can be assigned directly and those that must be computed. Of course, a lot of work has to be done behind the scene to keep things consistent. Java's "recommended" way would be to use a set method for assignment and a get method for retrieval (with the same required work done behind the scene). I find Python's properties much more elegant (and simpler for the end user) than having a whole bunch of get_this() set_that() to use. Andr? From urnerk at qwest.net Thu Aug 25 18:45:42 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 25 Aug 2005 09:45:42 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: Message-ID: <20050825164600.594D41E4031@bag.python.org> Hi Andre -- If you scroll back, you'll see I was specifying a triangle object in which sides a,b,c were passed to a constructor, *and* could be respecified on the fly, thereby changing the triangle. A validator made sure the proposed triangle was legal (triangle inequality not violated). Other than that, just go ahead and respecify a,b,c at will: >>> ok = Triange(3,4,5) >>> ok # whatever __repr__ > >>> ok.b = 3 >>> ok > So it went from right to isosceles just there, thanks to rebinding of side b. However, *only* sides could be respecified in this way. That was the game. Think of it as an abcTriangle. This design has its limitations and shouldn't always be used. It's handy when that's what you want. Angles A,B,C and xyz coordinates pA, pB, pC turned out to be consequent read-only values, but I decided to make them work like attributes from the user's point of view. You could get them, but not set them (directly). Down the road, I might add scale(), rotate() and translate() methods. These would be callables and expect arguments -- except I've already implemented scale() a different way, using __mul__: >>> newok = ok * 3 >>> newok Kirby From ajsiegel at optonline.net Fri Aug 26 04:51:10 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 25 Aug 2005 22:51:10 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILS00MC39PH3OY0@mta22.srv.hcvlny.cv.net> Message-ID: <0ILT00CDY6LED2C6@mta8.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > I *enjoy* your exotic other-worldliness. Other than what, I'm wondering ;) Art From ajsiegel at optonline.net Fri Aug 26 15:19:53 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 26 Aug 2005 09:19:53 -0400 Subject: [Edu-sig] "Model syntax changed" (was Design Patterns) Message-ID: <0ILT00L2KZPDRDLB@mta7.srv.hcvlny.cv.net> >Suppose you'd already published a Triangle class API and then discovered >you needed more dynamism. The property feature lets you sneak in some >methods without changing the already-published API and breaking client >code. >A lot of these lessons about robust software development come from group or >community efforts. Some aspects of Python maybe don't much excite you >because you're primarily a solo coder (as am I much of the time). Not claiming this is directly counter to the above, but it is interesting in this context to look at something happening on the ground, re: Django "Model syntax changed" http://www.djangoproject.com/weblog/2005/aug/25/modelsyntax/ """ This is the first really big community-driven improvement to Django, and it's been awesome to see it come to fruition. Thanks, guys! """ Art From ajsiegel at optonline.net Fri Aug 26 17:30:17 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 26 Aug 2005 11:30:17 -0400 Subject: [Edu-sig] Python is not Java Message-ID: <0ILU001M35QM1BH9@mta9.srv.hcvlny.cv.net> Yeah for naivety! In the pretty widely discussed article: "Python Is Not Java" http://dirtsimple.org/2004/12/python-is-not-java.html """ Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well. In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. """ Guido's example for properties in the "classic" "Unifying types and classes in Python 2.2" Begins to shed some light for me on the Pythonic use case for properties - when something quite specific needs to be triggered by an access to or attempt to set what is otherwise a regular attribute - in this case a constraint on setting x. http://www.python.org/2.2.2/descrintro.html#property class C(object): def __init__(self): self.__x = 0 def getx(self): return self.__x def setx(self, x): if x < 0: x = 0 self.__x = x x = property(getx, setx) I'm quite OK with properties - with this narrowly defined use case in mind. Anyway -*I* feel like this discussion led me somewhere. Art From Scott.Daniels at Acm.Org Fri Aug 26 20:54:07 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Fri, 26 Aug 2005 11:54:07 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <20050825144554.D7C411E400C@bag.python.org> References: <0ILS00G238FU0D20@mta9.srv.hcvlny.cv.net> <20050825144554.D7C411E400C@bag.python.org> Message-ID: Kirby Urner wrote: >>So I find that rejecting it as na?ve is fundamentally unresponsive. >>Art > > However in this case I don't think your views were rejected as na?ve. On > the contrary, your views permeated a sophisticated discussion of use cases, > and design patterns more generally (s'been a rich thread) plus Scott sort of > liked your using () to connote dynamism (I didn't). This is close to what I meant. I dislike properties that don't behave as if they were attributes. That is, I'd like two accesses to the same property of a particular object to return the same value until the object has been "changed," and I don't like read access to a property to be a "real" change. There are three exceptions I allow in my personal aesthetic: * debugging code: All's fair for this case. Properties are _golden_ for allowing tracking things into a lot of code without changing that code. * instrumentation: Measurements can be accumulated about behavior, but shouldn't interact with normal operation. * performance: Achieving the same results with different performance is often the whole point of systems programming style programming. --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Sat Aug 27 00:24:33 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 26 Aug 2005 18:24:33 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: Message-ID: <0ILU00649OXCV8KH@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > > This is close to what I meant. I dislike properties that don't behave > as if they were attributes. Not exactly sure what that means. Seems there is a lot to this topic. I get to the fact that there is a Uniform Access Principle - with some authority behind it. """ The Uniform Access Principle, as published in Bertrand Meyer's Object-Oriented Software Construction, states that "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." It is described further with "Although it may at first appear just to address a notational issue, the Uniform Access principle is in fact a design rule which influences many aspects of object-oriented design and the supporting notation. It follows from the Continuity criterion; you may also view it as a special case of Information Hiding." """ I guess I am intuitively anti-Meyerist. And am hoping he is quite wrong in the assessment that "information hiding" is a base requirement for information science. ;) Kirby seems comfortable in the Meyerist camp. But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python sentiments. So am having trouble with my Meyerist Python friend's stance. Art From urnerk at qwest.net Sat Aug 27 07:52:41 2005 From: urnerk at qwest.net (Kirby Urner) Date: Fri, 26 Aug 2005 22:52:41 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILU00649OXCV8KH@mta7.srv.hcvlny.cv.net> Message-ID: <20050827055250.306BC1E4003@bag.python.org> > Kirby seems comfortable in the Meyerist camp. > I think you might be reading something too sinister into "information hiding" and are therefore against it. The brutal real world truth is the client wants an API that works today, but will complain if it doesn't deliver tomorrow, even if specs shift in the mean time. A lot of programming arises from this dual use: freedom to use now, freedom to change it under the hood later. Properties help insert a layer between mutable programmer code and a slick API that clients like and want to keep using. It's a matter of keeping a favorite notation relatively static, thereby insulating users from messy inner details. That's *one* meaning of information hiding, and I think a benign one. My world assumes you have access to source code. Information hiding is relative to something. If you have no source code at all, then it's all hidden, and so what's the point of even talking about what's hidden or not? > But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python > sentiments. So am having trouble with my Meyerist Python friend's stance. > > Art I think you're espousing an open source ethic, but maybe confuse the purpose of properties with something "information hiding" needn't mean. It could just mean a notational integrity that insulates programmers from other programmers. It's like wearing business suits or casual dress. We don't want to keep adjusting our eyeballs from one freakazoid API to another. Just give us a uniform integrated control panel please, and do your behind the scenes work behind the scenes (but let us peek if we get curious). Kirby From lac at strakt.com Sat Aug 27 12:52:20 2005 From: lac at strakt.com (Laura Creighton) Date: Sat, 27 Aug 2005 12:52:20 +0200 Subject: [Edu-sig] Design Patterns In-Reply-To: Message from Arthur of "Fri, 26 Aug 2005 18:24:33 EDT." <0ILU00649OXCV8KH@mta7.srv.hcvlny.cv.net> References: <0ILU00649OXCV8KH@mta7.srv.hcvlny.cv.net> Message-ID: <200508271052.j7RAqK17013421@theraft.strakt.com> In a message of Fri, 26 Aug 2005 18:24:33 EDT, Arthur writes: >And am hoping he is quite wrong in the assessment that "information hiding" >is a base requirement for information science. ;) He is quite correct, but 'hiddenness' is not an infinite human good, such as health. It is quite possible to hide too much. Whether 'having things work like magic' is a good thing or not is always a tricky judgement call. >Kirby seems comfortable in the Meyerist camp. > >But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python >sentiments. So am having trouble with my Meyerist Python friend's stance >. > >Art My guess is that you think that properties violate 'Explicit is better than implicit.' In the example in http://www.python.org/2.2.3/descrintro.html#property where x is restricted to positive values. >>> a = C() >>> a.x = 10 >>> print a.x 10 >>> a.x = -10 >>> print a.x 0 # I think that Art thinks this is too much magic >>> a.setx(12) >>> print a.getx() 12 >>> One nice thing about overwriting __getattr__ and __setattr__ is that when you are done you have something that fairly shrieks 'black magic here'. Properties look innocuous. Some people go quite nuts with them, and use them whenever possible, as if there was something wrong with simple assignment in the first place. Worst of all, they are easy enough to use that all the would-be-Nannies in the world can trivially write code to prevent you doing what they think is unwise. This is most irritating when you are wiser -- or more imaginative than they are. This bit us the other day. Somebody naively thought that not allowing certain variables to be set to zero would be a swell way to avoid divide by zero errors. The problem is that the natural idiom used all over the codebase is: x = fast-way-to-solve-the-equation-works-most-of-the-time(**argv) if x is 0: # too bad x = do-it-the-hard-and-slow-way(**argv) He stuck his property in, and all over campus people started getting weird mysterious errors. People who tried to debug it and suddenly found out that _assignment_ 'wasn't working' concluded that '_Python_ was broken'. Their mental model of 'how computer languages work' doesn't include properties. Laura From ajsiegel at optonline.net Sat Aug 27 15:23:05 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 09:23:05 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <200508271052.j7RAqK17013421@theraft.strakt.com> Message-ID: <0ILV00GFHUINNHY0@mta3.srv.hcvlny.cv.net> > -----Original Message----- > From: Laura Creighton [mailto:lac at strakt.com] > One nice thing about overwriting __getattr__ and __setattr__ is > that when you are done you have something that fairly shrieks > 'black magic here'. Properties look innocuous. Some people go quite > nuts with them, and use them whenever possible, as if there was > something wrong with simple assignment in the first place. Yes. Yes. And in that way can be a bit of a trap to those of us feeling our way. A trap I find I fell into a bit. Which = in essence - is why I thought a discussion of the subject pertinent. I have disagreed with an aspect of Python design, which in IMO consciously obscures functions and concepts related to the copying of objects. Guido seems to feel strongly that too much visibility here encourages overuse by novices. Maybe true. But I think the lesson inherent in "copy" is worth the risk. IMO, the degree of visibility of properties is a clearer case of this kind of issue. Less upside to it. Art From ajsiegel at optonline.net Sat Aug 27 15:37:38 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 09:37:38 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILV0024Q9NU68W0@mta16.srv.hcvlny.cv.net> Message-ID: <0ILV001KSV6VD2WQ@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > > > Kirby seems comfortable in the Meyerist camp. > > > > I think you might be reading something too sinister into "information > hiding" and are therefore against it. I did put a ;) after my comment on information hiding - taking the opportunity to be a bit glib, and knowing it. But still to me, OOP theory is just that - theory. In certain domains, it may be the best we have - so we go with it. In other circumstances, every decision can be purposeful and specific to the problem at hand, and the actual and concrete can overrule the theoretical. It's a matter of knowing where one is in a specific circumstance, I guess. Separating these matters in an educational setting is more than problematic. Art From ajsiegel at optonline.net Sat Aug 27 16:08:01 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 10:08:01 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <200508271052.j7RAqK17013421@theraft.strakt.com> Message-ID: <0ILV00CUIWLIVB51@mta1.srv.hcvlny.cv.net> > -----Original Message----- > From: Laura Creighton [mailto:lac at strakt.com] > > My guess is that you think that properties violate 'Explicit is better > than implicit.' Not exactly. More like I think that it encourages "theory", and I appreciate Python as a-a-theoretical. The counter argument is that Python is so a-theoretical as to not be opposed to the imposition, with it, of any theoretical approach a practitioner might find appropriate or want to explore. And properties fit in there somewhere. Art From ajsiegel at optonline.net Sat Aug 27 16:56:19 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 10:56:19 -0400 Subject: [Edu-sig] FW: [Visualpython-users] Visualpython 3.2.1 for Mac OSX 10.4 now in Fink Message-ID: <0ILV00FG1YTZQQ92@mta6.srv.hcvlny.cv.net> -----Original Message----- From: visualpython-users-admin at lists.sourceforge.net [mailto:visualpython-users-admin at lists.sourceforge.net] On Behalf Of Martin Costabel Sent: Saturday, August 27, 2005 9:49 AM To: Visualpython-users Subject: [Visualpython-users] Visualpython 3.2.1 for Mac OSX 10.4 now in Fink There is now a Fink package for vpython version 3.2.1. If you have Fink installed on Mac OSX 10.4 (Tiger) and the unstable tree enabled, you can get it via: fink selfupdate fink install visual-py23 This will download and build vpython and all necessary prerequisites. It doesn't build a special version of gcc, apparently the ones that are in OSX 10.4.2 and Xcode-tools-2.1 are good enough (or at least I didn't come across the bugs they still may have). There are actually 2 variants, visual-py23 and visual-py24. Which one you want to install depends mainly on the versions of the dependencies you perhaps already have installed: python, numarray, numeric. Both variants can be installed simultaneously, there are no conflicts, and the dependencies are chosen and built automatically. The binary executables are called vpython2.3 and vpython2.4, respectively. When fink asks you at the beginning of the build process to choose whether you want to install boost1.32-py23 or boost1.32-py24, you can choose either one if you have the corresponding version of Fink's python installed, they are identical. If you don't have Fink's python installed yet, choose the version that corresponds to the version of visual you are going to install, or otherwise you will end up building two versions of python. This is no problem, however, except for compilation time, both versions of python coexist peacefully (not both variants of boost1.32-pyXY, however). -- Martin ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Visualpython-users mailing list Visualpython-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/visualpython-users From urnerk at qwest.net Sat Aug 27 17:19:17 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sat, 27 Aug 2005 08:19:17 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILV001KSV6VD2WQ@mta7.srv.hcvlny.cv.net> Message-ID: <20050827151927.5475E1E4003@bag.python.org> > Separating these matters in an educational setting is more than > problematic. > > Art In an educational setting, I use analogies. Think of interacting with a waiter in a restaurant. Your expectation is you name the foods and drinks you want, and after a period of time, those items arrive at your table. Later still, you pay for it all plus leave a tip. That's the API. But in some restaurants, the waiter is proud to memorize your order, and writes nothing. In some, the order is written down, but punched into a computer and the bill comes as a machine-printed slip. In most restaurants, the food is prepared in a kitchen not visible to customers. In others, it's prepared right in front of you, behind a counter, while you watch. Customers come to restaurants fully expecting to use the waiter API. But they may have little insight into the nuts and bolts of how this API is wired up behind the scenes. Maybe the waiter is part time. Maybe the cook lives in Hoboken. These details, though real, are "hidden" from the customers (but may come out in conversation). Furthermore, the inner workings may change. A new computerized checkout device is installed. Waiters need to be retrained, but not customers. The API is the same. In my MVC example, the Viewer expected a 'shape' object to support a specific API: verts and edges needed to be available as attributes. class Vpyview(object): """ A viewer: view using VPython """ def display(self, shape): self._garbagecollect() self._showverts(shape.verts) self._showedges(shape.edges, shape.verts) time.sleep(.1) But my Model class (a Triangle) defined neither per se. The information was there, but the API was not in accordance with the Viewer's needs. Presumably this Viewer is used with other shapes (polyhedra even!) and we don't want to write exceptional code just around triangles -- that'd get messy in a hurry. My solution, in this case, was to subclass Triangle2 and supply the missing attributes in the subclass. In the case of edges, this was a static list, defined once and for all in the constructor. In the case of verts, I used a property, so that the Viewer could just ask for verts (not a callable) and so that a triangle could quickly figure coords (also a property) behind the scenes. The upshot: shape.verts, in the eyes of the viewer, is simply a dictionary of xyz tuples with vertex label keys. class Triangle2(BaseTriangle): """ Model """ ... @property def coords(self): return {'A':self._pA, 'B':self._pB, 'C':self._pC} def _reset(self): ... self._pA = (0.0, 0.0, 0.0) self._pB = (a , 0.0, 0.0) self._pC = ((a**2 + b**2 - c**2)/(2.0*a), math.sqrt((-a+b+c)*(a-b+c)*(a+b-c)*(a+b+c))/(2*a), 0.0) class TriAdapter(Triangle2): """ Make a triangle work like a Shape, i.e. add edges and verts attributes """ def __init__(self, a,b,c): Triangle2.__init__(self, a,b,c) self.edges = [('A','B'),('B','C'),('C','A')] @property def verts(self): return self.coords Why allow coords and verts to be properties? Because these triangles are themselves mutable and the vertices may change position, even if how they're connected (the edges) doesn't change. Could I have gotten by without properties? Sure, but the code wouldn't have any easier to read or understand, or use. I'd still need to recompute everything when an edge was resized. This seems a real world enough example to get the point across: an API is like a contract, and once it's engrained, you may want to write adapters rather than tear into working code. Adapters aren't the same as properties, but they're another piece of the theory/nomenclature, and their implementation may *include* using properties. Another real world example: you go to a foreign country and the electrical sockets are different. Your appliance would work, if only you could plug it in. Do we go out and buy wire cutters, strip off the plug and attach a new one? No, hardly. We go out and buy an adapter, or bring one with us (like I did to Gothenburg). OO has adapters too, and properties may be a part of that. OO is about objects and the analogies are with objects in reality. Do we have properties in reality? You go to a bank and withdraw cash from your ATM. You (not you personally, because you know better) may imagine banks have big vaults full of cash, but actually they've loaned out the deposits and carry rather little cash. They may need to borrow from a different bank to cover your withdrawal. Do you need to care? No. You just want the ATM API to work as usual. "Information hiding" means sparing me the details. In an open source world, I might be able to see those details if I really cared about them. In the case of a private bank, fat chance. "Information hiding" in the sense of keeping secrets doesn't get invented with OO theory and gutting OO theory and/or Python of concepts and tools because you don't like secrecy is not a good solution -- we want and need those tools. Passing legislation requiring more transparency in banking is where what you might focus. You want a better API for monitoring the banks. And that API might make use of properties behind the scenes. Kirby From ajsiegel at optonline.net Sat Aug 27 17:41:11 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 11:41:11 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILV00GPIZW66E80@mta12.srv.hcvlny.cv.net> Message-ID: <0ILW001NN0WS1AI1@mta9.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > "Information hiding" means sparing me the details. In an open source > world, > I might be able to see those details if I really cared about them. In the > case of a private bank, fat chance. Yes, we are at the core of some considerable sensitivity in my (other) world. And yes, we are touching upon emotion and politics as well as API design. Pausch advocates exposing folks to a 3d API that spares the user the need to understand what "rotate" and "translate" means to everybody else in the known world working in 3d. I disagree, to say the least. There is not a theory adequate to settle our disagreement. We end up, as Laura says (I think), only able to make judgment calls as to what is and what is not appropriate as to what to expose and what not to expose, depending on what we are trying to accomplish. Judgment calls are to me a-theoretical. I think I understand the basic theory - and reserve to the right to do little more than take it under advisement. Art From ajsiegel at optonline.net Sat Aug 27 18:31:13 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 12:31:13 -0400 Subject: [Edu-sig] Design Patterns Message-ID: <0ILW006R638GD095@mta5.srv.hcvlny.cv.net> >In my MVC example, the Viewer expected a 'shape' object to support a >specific API: verts and edges needed to be available as attributes. Let me try to practice better what I think I am preaching and follow your lead in making the discussion more concrete and less theoretical. I have a line segment - defined as the segment connecting 2 points. The interface allows the points to be picked and moved. The line segment has a length. I choose line.getLength() as my API which I feel idiomatically expresses in Python that we are calculating the length as it happens to be when the call is made. I could quite easily wrap it in a property function and have a line.length attribute - but find it less expressive. Am I - in fact - violating the Uniform Access Principal. If I am, am I violating good programming practice? If I am in violation of the UAP principal, but not in violation of good programming practice - what are the bounds of the UAP principal. And how do we teach that? If I am not violating the Uniform Access Principal how do we express on what basis I am not? Art From Scott.Daniels at Acm.Org Sat Aug 27 23:44:12 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sat, 27 Aug 2005 14:44:12 -0700 Subject: [Edu-sig] Design Patterns In-Reply-To: <0ILW006R638GD095@mta5.srv.hcvlny.cv.net> References: <0ILW006R638GD095@mta5.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > I have a line segment - defined as the segment connecting 2 points. The > interface allows the points to be picked and moved. > > The line segment has a length. I choose line.getLength() as my API .... > Am I - in fact - violating the Uniform Access Principal. > If I am, am I violating good programming practice? OK, my take is no -- you are choosing an API. My strongest reaction has to do with your wish to deny me the ability to make another choice; API design is an art, not a science, and not engineering. The whole API is what you should evaluate. I am certain we cannot produce a set of rules that guarantee a good API, not can we provide rules to avoid a bad API. > If I am not violating the Uniform Access Principal how do we express on what > basis I am not? This to me has to do with the set of calls in your API. It is hard to say with a coordinates and length API, it is easier with something richer like triangles, rectangles, and polygons. The length of the sides of all of those things should show up the same way; either as attributes or method calls. Variations between polygons and triangles, for example, would make me think you are letting your implementation show through too much. --Scott David Daniels Scott.Daniels at Acm.Org From ajsiegel at optonline.net Sun Aug 28 00:36:09 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 18:36:09 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: Message-ID: <0ILW006XBK4EV6L6@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > My strongest reaction has > to do with your wish to deny me the ability to make another choice If that is a reference to my opinion about the visibility of the built-in property function, and its real world impact... if I thought my opinion had would likely have impact, I would likely think about it harder ;) Art From ajsiegel at optonline.net Sun Aug 28 00:42:03 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 27 Aug 2005 18:42:03 -0400 Subject: [Edu-sig] Design Patterns In-Reply-To: Message-ID: <0ILW0064DKECWQY3@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Scott David Daniels > > If I am not violating the Uniform Access Principal how do we express on > what > > basis I am not? > > This to me has to do with the set of calls in your API. Yes but according to the Uniform Access Principle: "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." My API is designed exactly and explicitly to betray this. That *is* my API. Art From peter at mapledesign.co.uk Wed Aug 31 11:53:18 2005 From: peter at mapledesign.co.uk (Peter Bowyer) Date: Wed, 31 Aug 2005 10:53:18 +0100 Subject: [Edu-sig] Writing books/manuals containing code Message-ID: <6.2.3.4.0.20050830235909.03e9f758@127.0.0.1> Hi, I have just started writing a course manual to introduce students to programming. There are going to be lots of code examples, and I was wondering: is there a way to insert the code into the document from external files, so I can test all the files and make sure the code works, even if I edit it? In Microsoft Word I can embed a file as an object, but the file's contents does not show in the document. My example programs are then broken down and I go through it line-by-line. Again, is there any way to insert these single lines of code without copying and pasting from the main block? I'm using Microsoft Word 2000, which is also making referencing code hard. I am open to suggestions of other programs, alhtough I'd prefer not to have to learn and write Docbook/LaTeX by hand. Finally, is there a way to syntax highlight python code before putting it into MS Word? Thanks, Peter -- Maple Design - quality web design and programming http://www.mapledesign.co.uk From nico at tekNico.net Wed Aug 31 12:43:03 2005 From: nico at tekNico.net (Nicola Larosa) Date: Wed, 31 Aug 2005 12:43:03 +0200 Subject: [Edu-sig] Writing books/manuals containing code In-Reply-To: <6.2.3.4.0.20050830235909.03e9f758@127.0.0.1> References: <6.2.3.4.0.20050830235909.03e9f758@127.0.0.1> Message-ID: > I have just started writing a course manual to introduce students to > programming. There are going to be lots of code examples, and I was > wondering: is there a way to insert the code into the document from > external files, so I can test all the files and make sure the code > works, even if I edit it? In Microsoft Word I can embed a file as an > object, but the file's contents does not show in the document. You want Leo ( http://leo.sourceforge.net/ ). It is a versatile outliner that lets one compose documents including references to external files, that are automatically tracked. It's a very powerful "literate programming" tool (also known as "executable documentation"). > My example programs are then broken down and I go through it > line-by-line. Again, is there any way to insert these single lines > of code without copying and pasting from the main block? This is harder, and arguably less useful, since your comment text will have to be revised anyway, when you change those lines. > I'm using Microsoft Word 2000, which is also making referencing code > hard. I am open to suggestions of other programs, alhtough I'd > prefer not to have to learn and write Docbook/LaTeX by hand. No Word, no Docbook, no LaTex (but output in those formats, if you need it). You want Docutils ( http://docutils.sourceforge.net/ ), with ReStructured Text markup, much simpler than those alternative. It is well integrated within Leo via plugins. > Finally, is there a way to syntax highlight python code before > putting it into MS Word? There are a number of Python syntax highlighting libraries out there, it depends on the output format needed. I would avoid Word, if at all possible, and if you value your peace of mind. :-) -- Nicola Larosa - nico at tekNico.net My god carries a hammer. Your god died nailed to a tree. Any questions? -- maxpublic on Slashdot, July 2005 From peter at mapledesign.co.uk Wed Aug 31 14:30:52 2005 From: peter at mapledesign.co.uk (Peter Bowyer) Date: Wed, 31 Aug 2005 13:30:52 +0100 Subject: [Edu-sig] Writing books/manuals containing code In-Reply-To: References: <6.2.3.4.0.20050830235909.03e9f758@127.0.0.1> Message-ID: <6.2.3.4.0.20050831132931.037f20d8@127.0.0.1> At 11:43 31/08/2005, Nicola Larosa wrote: >You want Leo ( http://leo.sourceforge.net/ ). It is a versatile outliner >that lets one compose documents including references to external files, >that are automatically tracked. It's a very powerful "literate programming" >tool (also known as "executable documentation"). Do you have any .leo files doing this that you can share, or links to documentation? I've been reading Leo's site and googling, and still don't understand enough to make the program work. >No Word, no Docbook, no LaTex (but output in those formats, if you need it). > >You want Docutils ( http://docutils.sourceforge.net/ ), with ReStructured >Text markup, much simpler than those alternative. It is well integrated >within Leo via plugins. That sounds good. Peter -- Maple Design - quality web design and programming http://www.mapledesign.co.uk From nico at tekNico.net Wed Aug 31 15:18:49 2005 From: nico at tekNico.net (Nicola Larosa) Date: Wed, 31 Aug 2005 15:18:49 +0200 Subject: [Edu-sig] Writing books/manuals containing code In-Reply-To: <6.2.3.4.0.20050831132931.037f20d8@127.0.0.1> References: <6.2.3.4.0.20050830235909.03e9f758@127.0.0.1> <6.2.3.4.0.20050831132931.037f20d8@127.0.0.1> Message-ID: >> You want Leo ( http://leo.sourceforge.net/ ). It is a versatile outliner >> that lets one compose documents including references to external files, >> that are automatically tracked. It's a very powerful "literate programming" >> tool (also known as "executable documentation"). > Do you have any .leo files doing this that you can share, or links to > documentation? There's lots of examples and docs on the site, maybe even too many. :-) It surely takes some study at the beginning. I'd say, start from the tutorials, and just take your time. > I've been reading Leo's site and googling, and still > don't understand enough to make the program work. Instead of just reading, try running the program, and studying its examples from within. -- Nicola Larosa - nico at tekNico.net My god carries a hammer. Your god died nailed to a tree. Any questions? -- maxpublic on Slashdot, July 2005