Re: [Edu-sig] Design Patterns
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
-Original Message- From: Laura Creighton [mailto:[EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
-Original Message- From: Laura Creighton [mailto:[EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] FW: [Visualpython-users] Visualpython 3.2.1 for Mac OSX 10.4 now in Fink
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/visualpython-users ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
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
Re: [Edu-sig] Design Patterns
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Design Patterns
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
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 [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
