-----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
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
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é
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__ <Triangle <3-4-5>> ok.b = 3 ok <Triangle <3-3-5>>
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 <Triangle 9-9-15>
Kirby
participants (3)
-
André Roberge -
Arthur -
Kirby Urner