Mailman 3 February 2006 - Edu-sig

First things first (Re: Python in the Classroom)
by Christian Mascher 26 Feb '06

26 Feb '06

Hi, I'm currently introducing 9th graders (15-16 year-old) with no prior coding experience (apart from a little bit of HTML/CSS) to basic programming with Python. We have only just started in this group. Some background: We meet twice a week, on mondays for 90 minutes (two lesson hours, one of them not in the computer lab, so only demonstration possible)), on thursday for 45 minutes. @ Kirby: 8th-graders are 14 year-olds, right? (That is: do you count classes from primary school grade 1 (like we do here)? How many lesson hours do you have? When starting with total newbies, you have to decide very carefully, what to explain in what order. Python being so "easy" (for someone who already knows what programming is about), it is also easy to go too fast. And you will always want to introduce quite a lot of ideas pretty soon, in order do to something interesting. On the other hand: Learners will probably appreciate a common solution (say: loops) better, if they have noticed the tediousness of programming without such a means _first_. I have looked at two books which address these items in a similar way: Gregor Lingls German Book "Python für Kids" and the new book from Stephane Ducasse: Squeak - Learn programming with Robots (doing it the smalltalk way). Both take a Logo-like approach with turtle graphics as a first start. Something which always seems to work with children of all ages in my experience (besides producing nice graphics as a visual feedback and reward). Differences (in the mentioned books) of course concern the syntax and the environment. For Python you have to explain the difference between interacting with Python via the Idle Shell-Window and using a File-Window (for saving the work properly) soon. These are "first things" you can't leave out. Then Ducasse produces turtles as Objects and calls methods on these to draw simple pictures. No problem. Rather than using turtle.py directly, I have always put an extra file named turtlegraphics in a reachable directory on the network (in my pythonpath). I have now modified it to include no module-level functions but only a Turtle class - of course just an interface to turtle.py. I also like it, when the method names are German - you see at a glance the difference between Python keywords and simple methods of an Object. So the standard interaction is (translated back to English): >>> from turtlegraphics import Turtle >>> joe=Turtle() # I don't really explain this much >>> joe.forward(80) >>> joe.color('red') So right from the start, we have dot-notation calling methods on instances we first have to create by calling a "factory" Turtle. Another good thing is also that >>> dir(joe) will only deliver the known methods, wheras the module turtle.py (where all the real programming was done for me) contains all sorts of things, and no class Turtle, but a Pen. This is quite the way Ducasse does it in Smalltalk/Squeak. I only can't exchange turtle joe's shape with my own drawing (like in squeak)- but I have found Python Tkinter runs a lot faster on my old machines than the fullblown squeak environment. And why not stay simple, when teaching simple, beginner things? How do we start? I try to introduce only _one_ *big idea* at once. On top of this there is still a lot of small bits (syntax, file saving, using the IDLE-Shell, correcting errors etc.) they have to learn along the way. Some first *big* ideas in my sequence are: 1. Code as a linear flow of statements as "commands" 2. Functions without parameters as abbreviation for longer parts of reuseable code 3. Loops on a list We actually did some "Using Python as a Calculator" in the Idle-Shell in the first lesson (Big Idea #1: Shell commands). Long Integers are a motivating factor (which pocket calculator could really tell you the result of 2**100?). I also introduced math.sqrt() because luckily they have just learned sqrt in maths, and it gives a first impression of "functions". More than one of them stumbled over some "wrong" results (float representation): To explain this properly, I would have needed another lesson, but I guess at this stage it is not that they are _that_ interested in the question (just wanted a _short_ answer). In a second lesson we defined some own mathematical functions in an informal way: Just like a function in maths with an x between the brackets and "return" something to deliver the result. No further treatment of this at this stage - I want turtlegraphics now. In the first lesson with turtlegraphics, pupils drew simple pictures (and had to use pythagoras a**2+b**2=c**2 to compute the length of a diagonal) using turtles they gave a funny name first. Then we defined a function triangle() (deliberately without parameters first time) to draw *many* triangles, reusing code by calling "subprograms". I let them figure out how to draw a "color wheel" with six triangles, using our triangle() function. This, they should do in a file, so they know about saving modules: -----start file----- from turtlegrphics import Turtle t=Turtle() def triangle(): <snip: its a regular (60-degrees) Wossname-triangle> # main program: t.color('red') t.fill(1) triangle() t.fill(0) t.left(60) t.color('orange') t.fill(1) triangle() t.fill(0) <and so on 4 more triangles, purple last> --------------- I hope this tedious repetition with only the color changing is motivation enough to call for a loop on a list: for colorname in ['red','orange','yellow','green','blue','purple']: t.color(colorname) t.fill(1) ... you get the impression From there on I will develop the loop for drawing a square: >>> for sidenumber in [1,2,3,4]: ... actually we don't need sidenumber here >>> for sidenumber in [0,1,2,3]: ... because computer scientists start counting with a zero >>> for sidenumber in range(4): ... made it to range() at last. Now we can do quite neat things looping with one or more turtles, exercising for-loops (and without much talk, lists on the way) >>> for i in range(18): for i in range(4): joe.forward(50) jack.forward(50) joe.left(90) jack(right(90) joe.left(10) jack.right(10) Sorry for the rather long post, but you didn't have to read it, did you ;-) Cheers, Christian

2 1

edupy bof at pycon2006
by Jeffrey Elkner 25 Feb '06

25 Feb '06

Hi All! We had a "Python in Education" BOF at PyCon2006 last night that was both productive and exciting. The wiki page describing goals we discussed as well as providing contact information for the attendees can be found here: http://edupy.pbwiki.com Andrew Harrington offered to look into providing us with web space (and perhaps a place to move our wiki) when he gets back to Loyola University. Michael Tobis kindly offered to help me make the next edition of "How to Think Like a Computer Scientist: Learning with Python" into a "live" textbook. I've already approached Cannonical about getting help with hosting for bzr repositories for software and educational materials. Question: Is everyone who attended the BOF and/or who is interested in the project on the edu-sig mailing list? We agreed that the edu-sig list is the natural place to for emails concerning our efforts. I'll be back soon with more information... jeff elkner open book project http://ibiblio.org/obp

1 0

Python as a CS1 Language: Updated List of Responses
by Atanas Radenski 23 Feb '06

23 Feb '06

Hello all, Back in December 2005, I asked for a list of schools that use Python as a CS1/CS2 language. A list is now posted in a Moodle installation that I maintain, http://studypack.com. The list is here: http://studypack.com/comp/mod/glossary/view.php?id=2835 This list is not limited to school names only, but offers a few details, in case details are available. The list is not limitted to CS1/CS2 courses. I will be glad to receive suggestions, corrections, and additional information. Actually, anyone can create an account, login and insert new records, or insert comments on existing records. One can also edit own records. Contributions will be appreciated. Atanas Atanas Radenski mailto:radenski@chapman.edu http://www.chapman.edu/~radenski/ I find television very educating. Every time somebody turns on the set, I go into the other room and read a book - Groucho Marx

1 0

More Python in the Classroom
by ajsiegel＠optonline.net 23 Feb '06

23 Feb '06

Kirby writes - >I was thinking of Arthur's suggesting to reinforce the distinction between 'print' and 'return'. The only thing I recall is an exchange with John Brawley that I reported here. If I remember correctly, he was creating a VPython sphere in a fucntion, assigning a variable to the function call, and couldn't unerstand why he was getting an attribute error when trying to change the sphere's color. It was simply a matter of explaining to him that since he was not explicity asking the function to return anything, it was returning Nothing - which is Something. So that the Something which he was trying to color was actually exactly the Nothing Something. Not the Sphere Something. ;) Art

2 1

More Python in the Classroom
by kirby urner 23 Feb '06

23 Feb '06

So I taught Python to 8th graders again this morning, as I've been doing for the last 10-11 weeks. I used the "dog theme", introducing a simple Dog class, per recent thread with Andre, in IDLE: class Dog: def __init__(self, name): self.name = name and using it to create instances dog1, dog2 (Fido and Rover). Then I went back and added a bark method. The point was to introduce the class/instance distinction. I use this wrap about a house blueprint, and an architect using it to build an instance in Beaverton and Mt. Tabor (local neighborhoods): one blueprint, two actual houses (or house objects). Then I go back to my dogs. All this is a prelude to reinforcing "dot notation" i.e. now that we have dog.name and dog.bark(1), it makes more sense to discuss a first collection type: lists. We gradually build up the following function, in several iterations, with kids entering at their workstations, watching my projected version up front: def askme(howmany=3): dogs = [] for i in range(howmany): thedog = raw_input("Dog's name? ") dogs.append(thedog) dogs.sort() return dogs I was thinking of Arthur's suggesting to reinforce the distinction between 'print' and 'return'. A first draft of the above function simply prints, doesn't sort. Then I talk about returning a value versus echoing it to screen (essentially what 'print' does -- not to a printer (one girl asked me about that)). Also, we start without any argument, looping 3 times. Adding howmany is a separate step, making it default to 3 yet another iteration. I like the way IDLE lets me "copy down" i.e. continually re-edit a given function, gradually adding to it. I'm projecting in 20 pt type or so, using Comic Sans (looks friendly). This is all very basic stuff, not breaking much new ground. I'm experimenting with how to introduce "dot notation" which I regard as very important. Really, it should be incorporated into standard math notations in a more integral way. object.verb(args) and object.property just makes a lot of sense as a standard way to notate. """ In my view, the mathematicians have been too slow to acknowledge dot notation as a legitimate contribution to mathematics proper. The math books don't allow that A.b(z) is a good way to organize thinking, A being an object of some type, perhaps inheriting from parent types, and b being a method, accepting argument(s) z. v1.add(v2) is as smart a way to signify vector addition as v1 + v2, plus makes it clear where the methods belong: in the class definitions. When math students are asked to actually number crunch with these mathematical objects (quaternions say), dot notation is what they encounter, more often than not. And yet there's this artificial line that gets drawn: "that's just the computer's way of expressing things, not really a math notation" is the party line (I'm not in that party). """ Source: http://mail.geneseo.edu/pipermail/math-thinking-l/2006-February/000982.html Another recent mention of Python in education (today, by me): http://mathforum.org/kb/thread.jspa?threadID=1337652&tstart=0 Kirby

1 0

leave
by adam 17 Feb '06

17 Feb '06

1 0

This showed up in my mailbox
by Laura Creighton 16 Feb '06

16 Feb '06

Possibly of interest. ------- Forwarded Message Return-Path: python-logic-bounces(a)www.logilab.org Delivery-Date: Thu Feb 16 09:59:44 2006 Date: Wed, 15 Feb 2006 16:34:58 -0600 From: Ralph Miller <miller_ralph(a)sbcglobal.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en PyIE, Python Inference Engine, is now available at "DFWPython.org", under "Our Source Repository", thanks to Jeff Rush. The current revision is 0.9.10. What's PyIE ? - ------------- PyIE is an hypothesis based, agenda driven, object oriented inference engine written in Python. Inferencing modes include back chaining, opportunistic forward chaining and explicit forward chaining. The object base supports classes, first-class objects and multiple, dynamic inheritance. PyIE uses a TMS (truth maintenance system) for non-monotonic reasoning. All objects are first class objects and all values are slot values, i.e. data members attached to some object. The GUI uses TKinter and consists of a main control panel and seven editors for the agenda, classes, objects, slots, rules, methods and commands. The knowledge base file types are currently XML and an older Python-like text format. A version is associated with all .py files and when the KBs are saved, this current version number is saved within the knowledge base source files. Only the XML format supports methods and is the default file type. Knowledge is usually, but not always, expressed in rules and the sequencing of the inferencing is controlled by a structure called an agenda. The current truth-values of each clause and each rule are kept in an hypothesis. Rules typically contain the main expression of knowledge and experience. Every rule must be associated with a hypo. Every rule has one or more antecedent clauses, usually termed the 'left hand side' (lhs). Rules may also have one or more consequent clauses; usually termed the 'right hand side' (rhs). In order to prove the associated hypo true, a rule must prove all antecedent clauses true. A hypothesis is simply a truth-value, in PyIE one of four possible values: True, False, Not Known or Unknown. 'Unknown' indicates that the hypo has not been tested, while 'Not Known' specifies that the hypo has been tested but proven neither 'True' nor 'False'. The engine proves hypotheses taken from an agenda. The agenda is hypothesis driven, that is, only hypotheses are contained in the agenda, not rules. The engine selects the relevant hypothesis to be proved and follows a specific set of steps to prove the hypo. Firing rules is only one method for proving a hypothesis. Download - -------- The current PyIE may be exported from the subversion repository: https://python.taupro.com/repo/Projects/PyIE/trunk Compressed gzip and zip files will be available from time to time from: https://python.taupro.com/repo/Projects/PyIE/downloads External Dependencies - --------------------- PyIE relies on Python 2.3 and later and also TKinter. No other modules need be installed. License - ------- The license is MIT. Caveats - ------- This is a research project. The documenetation is woefully incomplete. 'Eval' and 'compile' are used in the "KBsXML.py" module to process rules and methods. The underlying assumption is that there will be no malicious use. Author - ------ Ralph S. Miller miller_ralph(a)sbcglobal.net Regards, Ralph _______________________________________________ Python-logic mailing list Python-logic(a)lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-logic ------- End of Forwarded Message

1 0

Re: [Edu-sig] nice()
by Smith 13 Feb '06

13 Feb '06

| From: Josiah Carlson <jcarlson(a)uci.edu> | "Alan Gauld" <alan.gauld(a)freenet.co.uk> wrote: || However I do dislike the name nice() - there is already a nice() in || the || os module with a fairly well understood function. perhaps trim(), nearly(), about(), defer_the_pain_of() :-) I've waited to think of names until after writing this. The reason for the last name option may become apparent after reading the rest of this post. || But I'm sure some || time with a thesaurus can overcome that single mild objection. :-) | | Presumably it would be located somewhere like the math module. I would like to see it as accessible as round, int, float, and repr. I really think a round-from-the-left is a nice tool to have. It's obviously very easy to build your own if you know what tools to use. Not everyone is going to be reading the python-dev or similar lists, however, and so having it handy would be nice. | From: Greg Ewing <greg.ewing(a)canterbury.ac.nz> | Smith wrote: | || When teaching some programming to total newbies, a common || frustration is how to explain why a==b is False when a and b are || floats computed by different routes which ``should'' give the || same results (if arithmetic had infinite precision). | | This is just a special case of the problems inherent | in the use of floating point. As with all of these, | papering over this particular one isn't going to help | in the long run -- another one will pop up in due | course. | | Seems to me it's better to educate said newbies not | to use algorithms that require comparing floats for | equality at all. I think that having a helper function like nice() is a middle ground solution to the problem, falling short of using only decimal or rational values for numbers and doing better than requiring a test of error between floating values that should be equal but aren't because of alternate methods of computation. Just like the argument for having true division being the default behavior for the computational environment, it seems a little unfriendly to expect the more casual user to have to worry that 3*0.1 is not the same as 3/10.0. I know--they really are different, and one should (eventually) understand why, but does anyone really want the warts of floating point representation to be popping up in their work if they could be avoided, or at least easily circumvented? I know you know why the following numbers show up as not equal, but this would be an example of the pain in working with a reasonably simple exercise of, say, computing the bin boundaries for a histogram where bins are a width of 0.1: ### >>> for i in range(20): ... if (i*.1==i/10.)<>(nice(i*.1)==nice(i/10.)): ... print i,repr(i*.1),repr(i/10.),i*.1,i/10. ... 3 0.30000000000000004 0.29999999999999999 0.3 0.3 6 0.60000000000000009 0.59999999999999998 0.6 0.6 7 0.70000000000000007 0.69999999999999996 0.7 0.7 12 1.2000000000000002 1.2 1.2 1.2 14 1.4000000000000001 1.3999999999999999 1.4 1.4 17 1.7000000000000002 1.7 1.7 1.7 19 1.9000000000000001 1.8999999999999999 1.9 1.9 ### For, say, garden variety numbers that aren't full of garbage digits resulting from fp computation, the boundaries computed as 0.1*i are not going to agree with such simple numbers as 1.4 and 0.7. Would anyone (and I truly don't know the answer) really mind if all floating point values were filtered through whatever lies behind the str() manipulation of floats before the computation was made? I'm not saying that strings would be compared, but that float(str(x)) would be compared to float(str(y)) if x were being compared to y as in x<=y. If this could be done, wouldn't a lot of grief just go away and not require the use of decimal or rational types for many users? I understand that the above really is just a patch over the problem, but I'm wondering if it moves the problem far enough away that most users wouldn't have to worry about it. Here, for example, are the first values where the running sum doesn't equal the straight multiple of some step size: ### >>> def go(x,n=1000): ... s=0;i=0 ... while s<n: ... i+=1;s+=x ... if nice(s)<>nice(i*x): ... return i,s,i*x,`s`,`i*x` ... >>> for i in range(1,100): ... print i, go(i/1000.) ... print ... 1 (60372 60.3719999999 60.372 60.371999999949999 60.372) 2 (49645 99.2899999999 99.29 99.289999999949998 99.290000000000006) ### The soonest the breakdown occurs is at the 22496th multiple of 0.041 for the range given above. By the time someone starts getting into needs of iterating so many times, they will be ready to use the more sophisticated option of nice()--the one which makes it more versatile and less of a patch--the option to round the answers to a given number of leading digits rather than a given decimal precision like round. nice() gives a simple way to think about making a comparison of floats. You just have to ask yourself at what "part per X" do you no longer care whether the numbers are different or not. e.g., for approximately 1 part in 100, use nice(x,2) and nice(y,2) to make the comparison between x and y. Replacing nice(*) with nice(*,6) in the go() defined above produces no discrepancy in values computed the two different ways. Since the cost of str() and '%.*e' is nearly the same, perhaps a default value of leadingDigits=9 would be a good default value, and the float(str()) option could be eliminated from nice. Isn't nice() sort of a poor-man's decimal-type without all the extra baggage? | In my opinion, if you ever find | yourself trying to do this, you're not thinking about | the problem correctly, and your algorithm is simply | wrong, even if you had infinitely precise floats. | As for real world examples of when this would be nice I will have to rely on others to justify this more heavily. Some quick examples that come to mind are: * Creating histograms of physical measurements with limited significant digits (i.e., not lots of digits from computation) * Collecting sets of points within a certain range of a given value (all points within 10% of a given value) * Stopping iterations when computed errors have fallen below a certain threshold. (For this, getting the stopping condition "right" is not so critical because doing one more iteration usually isn't a problem if an error happens to be a tiny bit larger than the required tolerance. However, the leadingDigits option on nice() allows one to even get this stopping condition right to a limited precision, something like ### tol = 1e-5 while 1: #do something and compute err if nice(err,3)<=nice(tol,3): break ### By specifying the leadingDigits value of 3, the user is saying that it's fine to quit when the err >= 0.9995. Since there is no additional cost in specifying more digits, a value of 9 could be used as well. | Ismael at tutor wrote: | How about overloading Float comparison? I'm not so adept at such things--how easy is this to do for all comparisions in a script? in an interactive session? For the latter, if it were easy, perhaps it could be part of a "newbie" mode that could be loaded. I think that some (one above has said so) would rather not have an issue pushed away, they would want to leave things as they are and just learn to work around it, not be given a hand-holding device that is eventually going to let them down anyway. I'm wondering if just having to use the function to make a comparison will be like putting your helmet on before you cycle--a reminder that there may be hazards ahead, proceed with caution. If so, then overloading the Float comparision would be better not done, requiring the "buckling" of the floats within nice(). | | If I have understood correctly, float to float comparison must be done | comparing relative errors, so that when dealing with small but rightly | represented numbers it won't tell "True" just because they're | "close". I | think your/their solution only covers the case when dealing with "big" | numbers. Think of two small numbers that you think might fail the nice test and then use the leadingDigits option (set at something like 6) and see if the problem doesn't disappear. If I understand you correctly, is this such a case: x and y defined below are truly close and nice()'s default comparison would say they are different, but nice(*,6) would say they are the same--the same to the first 6 digits of the exponential representation: ### >>> x=1.234567e-7 >>> y=1.234568e-7 >>> nice(x)==nice(y) False >>> nice(x,6)==nice(y,6) True ### | Chuck Allison wrote on edu-sig: | There is a reliable way to compute the exact number of floating-point | "intervals" (one less than the number of FP numbers) between any two | FP numbers. It is a long-ago solved problem. I have attached a C++ | version. You can't define closeness by a "distance" in a FP system - | you should use this measure instead (called "ulps" - units in the | last place). The distance between large FP numbers may always be | greater than the tolerance you prescribe. The spacing between | adjacent FP numbers at the top of the scale for IEEE double precision | numbers is 2^(972) (approx. 10^(293))! I doubt you're going to make | your tolerance this big. I don't believe newbies can grasp this, but | they can be taught to get a "feel" for floating-point number systems. | You can't write reliable FP code without this understanding. See | http://uvsc.freshsources.com/decimals.pdf. A very readable 13 page introduction to some floating point issues. Thanks for the reference. The author concludes with, "Computer science students don't need to be numerical analysts, but they may be called upon to write mathematical software. Indeed, scientists and engineers use tools like Matlab and Mathematica, but who implements these systems? It takes the expertise that only CS graduates have to write such sophisticated software. Without knowledge of the intricacies of floating-point computation, they will make a mess of things. In this paper I have surveyed the basics that every CS graduate should have mastered before they can be trusted in a workplace that does any kind of computing with real numbers." So perhaps this brings us back to the original comment that "fp issues are a learning opportunity." They are. The question I have is "how soon do they need to run into them?" Is decreasing the likelihood that they will see the problem (but not eliminate it) a good thing for the python community or not? /c

1 0

nice()
by Smith 12 Feb '06

12 Feb '06

I've been thinking about a function that was recently proposed at python-dev named 'areclose'. It is a function that is meant to tell whether two (or possible more) numbers are close to each other. It is a function similar to one that exists in Numeric. One such implementation is def areclose(x,y,abs_tol=1e-8,rel_tol=1e-5): diff = abs(x-y) return diff <= ans_tol or diff <= rel_tol*max(abs(x),abs(y)) (This is the form given by Scott Daniels on python-dev.) Anyway, one of the rationales for including such a function was: When teaching some programming to total newbies, a common frustration is how to explain why a==b is False when a and b are floats computed by different routes which ``should'' give the same results (if arithmetic had infinite precision). Decimals can help, but another approach I've found useful is embodied in Numeric.allclose(a,b) -- which returns True if all items of the arrays are ``close'' (equal to within certain absolute and relative tolerances) The problem with the above function, however, is that it *itself* has a comparison between floats and it will give undesired result for something like the following test: ### >>> print areclose(2, 2.1, .1, 0) #see if 2 and 2.1 are within 0.1 of each other False >>> ### Here is an alternative that might be a nice companion to the repr() and round() functions: nice(). It is a combination of Tim Peter's delightful 'case closed' presentation in the thread, "Rounding to n significant digits?" [1] and the hidden magic of "prints" simplification of floating point numbers when being asked to show them. It's default behavior is to return a number in the form that the number would have when being printed. An optional argument, however, allows the user to specify the number of digits to round the number to as counted from the most significant digit. (An alternative name, then, could be 'lround' but I think there is less baggage for the new user to think about if the name is something like nice()--a function that makes the floating point numbers "play nice." And I also think the name...sounds nice.) Here it is in action: ### >>> 3*1.1==3.3 False >>> nice(3*1.1)==nice(3.3) True >>> x=3.21/0.65; print x 4.93846153846 >>> print nice(x,2) 4.9 >>> x=x*1e5; print nice(x,2) 490000.0 ### Here's the function: ### def nice(x,leadingDigits=0): """Return x either as 'print' would show it (the default) or rounded to the specified digit as counted from the leftmost non-zero digit of the number, e.g. nice(0.00326,2) --> 0.0033""" assert leadingDigits>=0 if leadingDigits==0: return float(str(x)) #just give it back like 'print' would give it leadingDigits=int(leadingDigits) return float('%.*e' % (leadingDigits,x)) #give it back as rounded by the %e format ### Might something like this be useful? For new users, no arguments are needed other than x and floating points suddenly seem to behave in tests made using nice() values. It's also useful for those computing who want to show a physically meaningful value that has been rounded to the appropriate digit as counted from the most significant digit rather than from the decimal point. Some time back I had worked on the significant digit problem and had several math calls to figure out what the exponent was. The beauty of Tim's solution is that you just use built in string formatting to do the work. Nice. /c [1] http://mail.python.org/pipermail/tutor/2004-July/030324.html

2 1

whitespace and newlines and seperators ... oh my
by Arthur 03 Feb '06

03 Feb '06

More (semi-IMO) irrelevancy .... Trying to get to a presentable, announceable alpha release of PyGeo... and ending up confronting new complexities of the kind I want to just wish away. Alan Kay hasn't gotten there yet, so I am stuck with the prospect of understanding things and thinking things through. OK - watch my directory separators in HTML. HTML that works on my local Windows box breaks on the server. Think Unix separators. Got it.. Then there is of course the cross platform newline issue - CRLF, CR, LF which gets me doing search and replace in ascii hex (geeky) and screwing up working code. What's the standard way to deal with this issue in a cross platform distribution?. Still don't know. But then it gets hairy, and Python specific: Trying to use the pre-alpha pudge document generator for the portion of PyGeo I consider to be the underlying "framework". http://pudge.lesscode.org/ Choosing pudge because it supports embedded reStructured text, and it supports "code as text" - which I see as part of PyGeo at a basic level - by automating the linking of documentation to colorized, html versions of the actual code. Very cool. There seems to be a group of heavyweights behind it. And the code base is small, I can follow it - so when it breaks when confronting a Boost-wrapped cvisual function I can find the work around.. First bigger problem is that pudge chokes on what I think is valid reStructured text - finding tables that pass reStructured scrutiny in stand-alone files to be malformed when embedded in triple quoted doc comments. I am assuming this is some kind of whitespace parsing issue, but haven't dug into the code far enough to verify. I am hoping it is something I can solve and feed back into the pudge project. Remains to be seen. More surprising was the html colorizing problem. The colorizing code relies on tokenize.py from the standard library - which keeps choking on code that compiles and runs fine by Python. So I go to tabnanny.py, which is seems to be there exactly to diagnose these kinds of issues. But one of the symptoms of the problem is that tabnanny (i.e tokenize) is parsing the file in such a way that it is reporting back line numbers that don't correspond to the code when viewed in a text editor. So its hard to pinpoint the problem. Turns out (I think) - this took be a while - that tokenize seems to be trying to parse things between triple quoted strings, and since there is a lot of code intended to output to Povray SDL and formatted for that purpose - it is choking on whitespace issues (that IMO shouldn't be issues) in that code. Is it fair to think that all rules should be off between """ ...and... """ - and that if I am right that this is where the choke is, that I should file a bug report. OTOH, seems unlikely that this has not been confronted before. Any clues to what I may be missing is appreciated. Art

1 2