Mailman 3 August 2005 - Edu-sig

Writing books/manuals containing code
by Peter Bowyer 06 Sep '05

06 Sep '05

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

7 9

Design Patterns
by Arthur 28 Aug '05

28 Aug '05

>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

2 3

Re: [Edu-sig] Design Patterns
by Arthur 27 Aug '05

27 Aug '05

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

1 0

Re: [Edu-sig] Design Patterns
by Arthur 27 Aug '05

27 Aug '05

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

2 1

FW: [Visualpython-users] Visualpython 3.2.1 for Mac OSX 10.4 now in Fink
by Arthur 27 Aug '05

27 Aug '05

-----Original Message----- From: visualpython-users-admin(a)lists.sourceforge.net [mailto:visualpython-users-admin@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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/visualpython-users

1 0

Re: [Edu-sig] Design Patterns
by Laura Creighton 27 Aug '05

27 Aug '05

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

2 2

Re: [Edu-sig] Design Patterns
by Arthur 27 Aug '05

27 Aug '05

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

3 4

Python is not Java
by Arthur 26 Aug '05

26 Aug '05

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

1 0

"Model syntax changed" (was Design Patterns)
by Arthur 26 Aug '05

26 Aug '05

>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

1 0

Re: [Edu-sig] Design Patterns
by Arthur 26 Aug '05

26 Aug '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > I *enjoy* your exotic other-worldliness. Other than what, I'm wondering ;) Art

1 0