Mailman 3 September 2005 - Edu-sig

quantum instance
by Arthur Sept. 17, 2005

Sept. 17, 2005

Me > >> Would we have flatted the area method before properties, through the >> __getattr__ mechanism. Were properties put into the language to make it >> more convenient for us to do this kind of thing - *as a way of >> encouraging this kind of pattern*. I think you - implicated or >> explicitly - think yes. I think I explicitly think no. John > >I don't understand how you can say "no" to this. Properties exist >precisely to make it simpler to call methods through attribute access >syntax, period. My instinct is that, pre-properties, most programmers >would not have resorted to the __getattr__ magic for these simple cases; >they would just provide a method-call API (as I did for my graphics >library). With properties, I would probably now take the other route. And I don't understand how you can't understand that. Sometimes we just disagree, it seems. The version of Python I run - Python 2.4 (#60, Nov 30 2004, 11:49:19) - discourages me from writing extra code for the purpose of revealing less. It comes with no "properties" exception of which I am aware. I guess we all have our own sense of elegance, and the properties discussion leads me to believe that there is more than one version of Python 2.4 (#60, Nov 30 2004, 11:49:19) floating around. Which is as it should be. And as it should be taught it should be, it seems to me. And don't expect that you disagree with *that*. Art

2 1

pyGame tutor for high school students wanted
by edusig.20.schellenberg＠spamgourmet.com Sept. 16, 2005

Sept. 16, 2005

Hi there, I am teaching an introduction to computer science at a high school level, and have given my students freedom to choose to create pretty much whatever they would like for a final project in the course. A group of 3 of my obviously keen and talented programmers came up to me wondering whether they could create a simple RPG type game using Python, and I suggested they take a look into pyGame. Now, I don't have any experience with pyGame myself, and so I am looking for someone who would be willing to tutor them via email as they undertake this project from now until the beginning of January. Anyone willing to help along some aspiring computer programmers? Thanks, Dan -- Dan Schellenberg High school computer science/math teacher

2 1

Re: [Edu-sig] pyGame tutor for high school students wanted
by Laura Creighton Sept. 16, 2005

Sept. 16, 2005

I'd try that question on the pygame mailing list, or its gatewayed newsgroup. http://www.pygame.org/info.shtml Laura Creighton

1 0

Re: [Edu-sig] quantum instance
by Arthur Sept. 16, 2005

Sept. 16, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > > OTOH, his general explanation for the use case of properties in respect > to > > API design seemed to me to be a perfect defense of the extensive use of > a > > pattern of: > > > > @property > > def getx(self): > > return self._x > > > > @porperty > > def sety(self,x) > > self._x =x > > > > because while now x is a normal attribute you never know what tomorrow > may > > bring. > > And I say such defensive programming is unnecessary in Python. You can > turn > 'x' into a property later Yes. John explains this as well. I told you I was confused. But I remain confused to the extent that this - from where I sit - rather obscure and remote situation comes up prominently as a reason properties are so welcome as a builtin function. As I don't think I sit anywhere *that* far off the mainstream of things. As an emergency fix - __getattr_ and __setattr__ would serve as well. "As well" as in also. As well as in "as well as" I guess is open to debate, but I keep thinking we are in obscure corner of things in any case - and having to get there as a use case for properties implies a stretch, and for me, is therefore a source of suspicion. Art

1 0

Draft math/CS stuff (satacad 6938)
by Kirby Urner Sept. 15, 2005

Sept. 15, 2005

I'd be happy if anyone wants to comment on and/or mess with the code below. It's what I'm working on for my upcoming Saturday Academy class, which uses a combination of Python and POV-Ray to teach geometry. http://www.saturdayacademy.org/classes/ClassDetail.aspx?id=6938 Some of my background info is on file here (another list) i.e. I talk about what's unfinished: http://mail.geneseo.edu/pipermail/math-thinking-l/2005-September/000840.html plus I'm still looking at properties, and continuing some recent threads re pedagogy here on our edu-sig list. Also, math-think-l unindented/trashed the source, perhaps because I submitted in rich text through gmail, whereas a plain text submission might've gotten through unscathed (??). Kirby ===== class Vector(object): color = 'Red' def __init__(self, xyz): self.xyz = xyz def write(self): basic = "cylinder <0,0,0>, <%s,%s,%s>, 0.1" % self.xyz return "%s %s" % (basic, "pigment { color %s }" % self.color) def __repr__(self): return "Vector <%s, %s, %s>" % self.xyz def __mul__(self, scalar): xyz = tuple([scalar * i for i in self.xyz]) return Vector(xyz) def __add__(self, other): xyz = tuple([ i+j for i,j in zip(self.xyz, other.xyz)]) return Vector(xyz) def _get_xyz(self): return '<%s, %s, %s>' % self.xyz def _get_length(self): return pow(sum([i**2 for i in xyz]), 0.5) coords = property(_get_xyz) length = property(_get_length) class Edge(object): color = 'Red' def __init__(self, v0, v1): self.v0 = v0 self.v1 = v1 def __repr__(self): return "Edge %s, %s" % (self.v0.coords, self.v1.coords) def write(self): basic = "cylinder %s, %s, 0.1" % (self.v0.coords, self.v1.coords) return "%s %s" % (basic, "pigment { color %s }" % self.color) class Polyhedron(object): color = 'Red' def __init__(self, vertsdict, faces): self.verts = vertsdict self.faces = faces self.edges = self._get_edges() def __repr__(self): return "Polyhedron: %s edges, %s faces" \ % (len(self.edges), len(self.faces)) def _get_edges(self): # stub procedure: take a list of face-tuples and distill # all the unique edges, e.g. ((1,2,3)) => ((1,2),(2,3),(3,1)) # e.g. icosahedron has 20 faces and 30 unique edges # ( = cubocta 24 + tetra's 6 edges to squares per jitterbug) pass def write(self): # stub procedure -- needs to be completed return 'write out edges' def __mul__(self, scalar): newvectors = {} for v in self.verts: newvectors[v] = self.verts[v] * scalar return Polyhedron(newvectors, self.faces) class Header (object): # defaults bgcolor = "color Gray50" lightloc = "<300, 300, -1000>" lightcolor = "White" @staticmethod def write(): return """ #include "colors.inc" background { %(bgcolor)s } light_source{ %(lightloc)s %(lightcolor)s } """ % Header.__dict__ class Camera (object): # defaults look_at = 0 location = '<0, .1, -25>' @staticmethod def write(): return """ camera { location %(location)s look_at %(look_at)s angle 30 } """ % Camera.__dict__ def buildicosa(): phi = (1 + pow(5,0.5))/2.0 verts = {# 2*phi x 2 rectangle in XZ 1:Vector((-phi, 0, -1)), 2:Vector((-phi, 0, 1)), 3:Vector(( phi, 0, 1)), 4:Vector(( phi, 0, -1)), # 2*phi x 2 rectange in XY 5:Vector(( -1, phi, 0)), 6:Vector(( 1, phi, 0)), 7:Vector(( 1, -phi, 0)), 8:Vector(( -1, -phi, 0)), # 2*phi x 2 rectange in YZ 9:Vector(( 0, 1, phi)), 10:Vector(( 0, -1, phi)), 11:Vector(( 0, -1, -phi)), 12:Vector(( 0, 1, -phi))} faces = ((5,6,9),(5,6,2),(5,12,1),(5,6,1),(5,1,2), (11,1,12),(11,12,4),(11,1,8),(11,4,7),(11,7,8), (4,12,6),(4,6,3),(4,3,7), (3,9,6),(3,6,4), (10,7,8)) #unfinished return verts, faces def main(): icosa = Polyhedron(*buildicosa()) f = file('icosa.pov','w') Camera.location = '<0, 2, -20>' print >> f, Header.write() print >> f, Camera.write() print >> f, icosa.write() f.close() if __name__ == '__main__': main()

1 1

Re: [Edu-sig] quantum instance
by Arthur Sept. 15, 2005

Sept. 15, 2005

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > > If you want to see me as a confused student - you're welcome. > > > > Art > > I don't see you as confused. Can't we agree about anything? I'm confused I tell you ;) Scott David's Triangle did *not* use a property for area. I think that was quite purposeful. OTOH, his general explanation for the use case of properties in respect to API design seemed to me to be a perfect defense of the extensive use of a pattern of: @property def getx(self): return self._x @porperty def sety(self,x) self._x =x because while now x is a normal attribute you never know what tomorrow may bring. OTOH, as you point out Alex did use exactly your case of the area of a Triangle to illustrate properties in Nutshell. Was he simply illustrating mechanics or, in so doing, advocating a use case as well? Would we have flatted the area method before properties, through the __getattr__ mechanism. Were properties put into the language to make it more convenient for us to do this kind of thing - *as a way of encouraging this kind of pattern*. I think you - implicated or explicitly - think yes. I think I explicitly think no. John and Dethe point out that when a color attribute in vpython is changed the proverbial e-mail to Mary needs to be sent - rerender. Before properties it was done under the covers, now we have the convenience of properties as an alternative. The unambiguous use case, IMO. John feels the appearance of properties in the language to be an unambiguous win. I would probably agree if I didn't believe it had the side effect of having some of us second-guessing the way they did business pre-properties. I guess I am pleading for constraint in the presentation of properties to novices, with clear *and narrow* use cases. Its part of my campaign for this year's Willison award. I'm think my chances are 50/50, best case ;) Art

3 4

Re: [Edu-sig] quantum instance
by ajsiegel＠optonline.net Sept. 15, 2005

Sept. 15, 2005

>You could read up on __getattr__, __getattribute__, and > >friends in the Language References section 3.3.2: > Customizing attribute access "and friends" include descriptors, so that the discussion about properties here had actually led me into some better understanding of this realm of Python. It ties together a bit, in that in reviewing my own code and my own use of properties I see I did use it mostly in comformity with the example outlined in Guido's article on new style classes, and to solve a problem not unrelated to the one I am trying to solve by a "blended class". Specifically, vpython will try to draw anything you send to it, but if you send it a vector outside of some range relative to the current zoom level, the display fritzes. So in retrieving a vector (which I consider an attribute) for purposes of rendering, I was setting a constraint that would be sufficient to avoid the fritz, while keeping the actual values of the vector pure, for the purposes of further calculation. IOW I am managing the retrievel of data from an attribute. Another friend of __getattr__ is __slots__. I was confused by slots as well early on, as I think were many others. I satsified myself - if no one else - that my confusion was in part generated by a general confusion, including some confusion in the What's New in Python2.X (when __slots__ first appeared). It is not too surprising that there can be some degree of misinprepation of Guido's intention in adding a feature to the language. The problem is exasperated when an example of the mechanical use of something like properties is presented - and confused (by folks at my level ,at least) as an actual use case of the feature. I do think this happened with getters and setters and properties, and think there may be some pedagogical lesson in this somewhere. Extending the point - one reason that I think Java cannot work well (or as well) as an introductory language is that it forces one to mechanically understand attribute access modification (and such like) well before one can be expected to understand in any authentic manner the use cases. The result is seditious and wide ranging, because we then settle on an approach where expectations as to authenticity are generally lowered. Much preferable to understand the feature, its mechanics, and its use case as one process. I get there my not concerning myself about features I don't need, until I think I need them. And then determine whether it actually solves my problem. If I manage the mechanics, and it solves my problem - I have my use case. But of course I have a context - my interests. I think teaching programming outside a context - as an abstract discipline - is unavoidably problematic in this regard. Web and network programming, scientific programming, algorithomics, business programming, graphics and entertainment programming ... all provide a context and a context implies use cases. I am not convinced "programming" as a stand-alone subject cannot be optimum as an approach. But I guess that postion runs counter to enough established realities as to be essentially meaningless. My specialty. I do think Python lends itself well to a pedagogoical approach that gives context - whatever it might be - due weight. Which is what brings me here , at least indirectly. And why I am committed to annoy everyone until everyone sees everything my way. ;) Art

6 19

Gutless classes
by Kirby Urner Sept. 13, 2005

Sept. 13, 2005

I'm thinking about how, in Ruby, class definitions are never closed, meaning you can add methods to a script in various locations. You don't supersede the old class def when you reopen it for more stuff. There's also this idea of defining a module full of methods and then binding those to a class -- I haven't really learned this fully yet. In Python, we have the ability to define methods externally to classes, as ordinary functions, except we need the implicit 'self' variable as a first argument. For example: >>> def __init__(self, a,b): self.a = a self.b = b >>> def __repr__(self): return 'Duh object (%s, %s)' % (self.a, self.b) >>> class Duh(object): pass >>> Duh.__init__ = __init__ >>> Duh.__repr__ = __repr__ >>> o = Duh(1,2) >>> o Duh object (1, 2) Or we could do it this way: >>> class Duh2(object): __init__ = __init__ __repr__ = __repr__ >>> o = Duh2(3,4) >>> o Duh object (3, 4) Why do it this way? I suppose you might have several classes that all use some method. Define the method once, then shove it into more than one gutless class. In the above case, I guess there's no reason to use underunder syntax in the external function name, given the rebinding to a local attribute at runtime. I.e. we might as well go: >>> def representer(self): return 'Duh object (%s, %s)' % (self.a, self.b) >>> class Duh(object): pass >>> Duh.__init__ = constructor >>> Duh.__repr__ = representer >>> o = Duh(9,10) Duh object (9, 10) Kirby

5 9

Re: [Edu-sig] quantum instance?
by Arthur Sept. 11, 2005

Sept. 11, 2005

Kirby Urner wrote: >Lines aren't >perfectly straight either -- zoom in and they become zig-zaggy/wavilinear. >Zoom out, and all you get are curves and great circles. > > Yes. From a bitmap perspective, anyway. And certainly circles, even from a vector computer graphics point of view are actually polygons, not circles. Which is really my problem.. And is directly related to dynamic zooming. I am in fact attempting to make my algorithm for converting a representation from a circle (i.e. polygon) to a line and back again sensitive to the actual zoom level. At some definition of local, the circle becomes a line. Summer must be over . I have time for this kind of fun again. Art

1 0

Re: [Edu-sig] quantum instance?
by Arthur Sept. 11, 2005

Sept. 11, 2005

Kirby Urner wrote: >In Fuller's synergetic geometry, circles don't become infinite lines, but >just bigger and bigger circles. Lines that appear locally straight are just >that: local. Clearly we're starting with different assumptions than those >of Euclidean greek metaphysics. More from Democritus. Lines aren't >perfectly straight either -- zoom in and they become zig-zaggy/wavilinear. >Zoom out, and all you get are curves and great circles. > FWIW, I am working with (as in studying and implementing some tools in PyGeo to enliven that study of) the geometry of complex numbers. And doing so in such a way that all fundamental elements are defined by its 2X2 hermitian matrix. So I am getting fairly abstract - a "line" has hermitian[0][0] == 0, else I am looking at a "point" or a "circle". Drawing the damn things is a lot less abstract - and as hermitian[0][0] approaches 0, a line makes a better represetantion - is all. And since things are dynamic, I need my iinstances to think on their feet as to what makes a better representation. If/else is really all I need - but I was playing in my head with trying something more "dramatic". Fredrk Lundh - the fbot and author of PIL - posted a blog entry a few months ago about working with complex numbers to do basic image manipulation. With Numeric in play, I can imagine a lot of efficiency gains by working with it and the Python built_in complex numbers- via Hermitian matrixes and 2X2 mobius transformation matrixes - to accomplish a lot of the kind of image transformation effects that I imagine are normally done otherwise. I expect that experimentation along these lines is going to eventually get me more into playing with bitmap graphics, whereas until now I have been a vector graphics kind of guy. Art

1 0