Mailman 3 August 2005 - Edu-sig

Re: [Edu-sig] Design Patterns
by Arthur Aug. 25, 2005

Aug. 25, 2005

> -----Original Message----- > From: Arthur [mailto:ajsiegel@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

3 3

Design Patents
by Arthur Aug. 25, 2005

Aug. 25, 2005

>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

2 1

Re: [Edu-sig] Design patterns
by Arthur Aug. 24, 2005

Aug. 24, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@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

4 8

Re: [Edu-sig] Design patterns
by Arthur Aug. 24, 2005

Aug. 24, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@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

3 3

Design patterns
by Arthur Aug. 24, 2005

Aug. 24, 2005

>> 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

4 3

Design patterns
by Kirby Urner Aug. 21, 2005

Aug. 21, 2005

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

3 11

Re: [Edu-sig] Design patterns
by Arthur Aug. 21, 2005

Aug. 21, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@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

2 1

Re: [Edu-sig] Design patterns
by Arthur Aug. 21, 2005

Aug. 21, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@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

2 1

Re: [Edu-sig] software skills course
by Greg Wilson Aug. 18, 2005

Aug. 18, 2005

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

3 4

Re: [Edu-sig] Edu-sig Digest, Vol 25, Issue 11
by D. Hartley Aug. 17, 2005

Aug. 17, 2005

Greg, I would be interested in being a reviewer, if you still need them. ~Denise On 8/17/05, edu-sig-request(a)python.org <edu-sig-request(a)python.org> wrote: > Send Edu-sig mailing list submissions to > edu-sig(a)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(a)python.org > > You can reach the person managing the list at > edu-sig-owner(a)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 <andre.roberge(a)gmail.com> > Subject: Re: [Edu-sig] software skills course > To: edu-sig(a)python.org > Message-ID: <ddtnv9$mq0$1(a)sea.gmane.org> > 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(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > End of Edu-sig Digest, Vol 25, Issue 11 > *************************************** >

1 0