Re: [Edu-sig] a common misconception
Kirby, This is an interesting and subtle point. I understand the distinction that you are making, but syntactically and pragmatically, the call to a class constructor IS a function call in Python (unlike languages such as Java where one needs "new" to call a constructor). As support for this point of view, I would point to the Python documentation: https://docs.python.org/3/library/functions.html Both the section heading and the table in which "range" and "list" occur have the heading "Built-in Functions." Yes, it says there are both built-in functions and types, but they are lumped together under this broader category. If I tell my students that "list is not a built-in function," I guarantee some smart aleck is going to pull up that table of built-in functions to "prove" me wrong. This is an issue I thought about when writing the Python 3 version of my textbook. In the end, it seemed more awkward/muddying to pedantically separate the call to a constructor (invoked by the type name) vs. a call to a "normal" function. They look, feel, and act the same to the user. Just as I would consider any method invocation a "function call", I consider the constructor invocation to be a function call. I concede your technical point, but I stand by my (and other authors') decision on how to treat this. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College From: Edu-sig [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner [kirby.ur...@gmail.com] Sent: Saturday, January 23, 2016 11:03 AM To: edu-sig@python.org Subject: [Edu-sig] a common misconception A common misconception in communicating Python is that range() and even list() are "function calls". That's correct for range() in 2.x: >>> type(range) but has never been correct terminology regarding list(). Example: """ >From Chapter 9 of Inventing in Python: The range() and list() Functions When called with one argument, range() will return a range object of integers from 0 up to (but not including) the argument. This range object can be converted to the more familiar list data type with the list() function. Try entering list(range(10)) into the interactive shell: """ The author knows a range object is returned, however that's our clue that range() is calling a type (a class) and returning an instance of that class, ditto list( ). I'd like to see the Python 3.x teaching literature not muddying the waters by referring to range() and list() -- and zip() and enumerate() -- as "function calls". Kirby ___ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Parallel computing
We've had good luck in the past using pypar (http://code.google.com/p/pypar/) in a college scientific computing class for students who have had a single programming course in Python. At that time (2 years ago), it seemed to be the simplest entry point for Python-based MPI type programs. John Zelle, PhD Professor of Computer Science Wartburg College From: Edu-sig [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of roberto [robert...@gmail.com] Sent: Monday, March 31, 2014 8:11 AM To: edu-sig@python.org Subject: [Edu-sig] Parallel computing Hi, I recently finished setting up a Beowulf Cluster using some Linux machines at schools. Some students eagerly helped out. We'd like to start studying some parallel computing on this system. I already studied it on C but never on Python. My students regularly study Python, so I'd like to ask you if you taught some Python Parallel Computing to High School students and where to start from. Thank you very much -- Roberto ___ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] a short essay about programming
Hi Again, Of course, David is right here. My previous statement only applies to code where all state change is effected by the code itself. All bets are off in a multi-thread or multi-process situation. That is what makes concurrent programs devilishly hard to reason about. But I wouldn't use that as an excuse to make single-threaded code hard to reason about as well. --John John Zelle, PhD Professor of Computer Science Wartburg College From: da...@handysoftware.com [da...@handysoftware.com] Sent: Sunday, April 22, 2012 5:06 PM To: John Zelle Cc: kirby urner; edu-sig@python.org Subject: Re: [Edu-sig] a short essay about programming Yes, interesting thread. I've been thinking about this statement: If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. What if condition C includes an expression like (datetime.datetime.now().hour) == x)? What if condition C is (not q.empty()), where q is a queue.Queue object fed by other threads? I think there has to be some constraints on C for that statement to be correct. Something like and C does not refer to volatile attributes nor variables and doesn't contain method calls whose results vary over time or something like that. I guess that's why I think using while True: with break is Ok in many cases. David H -Original Message- From: John Zelle john.ze...@wartburg.edu Sent: Saturday, April 21, 2012 11:13pm To: kirby urner kirby.ur...@gmail.com, edu-sig@python.org edu-sig@python.org Subject: Re: [Edu-sig] a short essay about programming Hi All, Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions. One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following. Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV, that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to. --John John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner [kirby.ur...@gmail.com] Sent: Saturday, April 21, 2012 9:12 PM To: edu-sig@python.org Subject: Re: [Edu-sig] a short essay about programming ... another useful contribution to this thread. -- Forwarded message -- From: Richard Pattis pat...@ics.uci.edu Date: Sat, Apr 21, 2012 at 6:53 PM Subject: I'm not allowed to post To: kirby urner kirby.ur...@gmail.com Feel free to post this for me, which got returned. Probably because I use a mail alias and never tried to post before. Rich I replied to Kirby privately, and he suggested I post to the listserv, so I have. Because UCI is starting to teach Python next year, I might be on the listserv (more than you want) over the summer as I learn Python and how to program in it and teach it: a tall order for a few months. As Charles McCabe (SF Examiner) said, Any clod can have the facts; having opinions is an art. - rep Kirby, I'm a long time Java teacher (heck, I started teaching Fortran in 1976) who will soon be teaching Python. We (here at UC Irvine) are switching to a 3 quarter introduction to programming sequence all in Python (and then on to Java and C++ for upper division courses, although Python could leak upwards). I've been subscribing to edu-sig Python for a while and appreciate your efforts (and have learned from them). I'm a big fan in Java of teaching beginners only for(;;) -I call it for-ever- and if/break termination (although some colleagues accuse me of teaching machine language in Java). I like forever if/break for a few reasons, among them are I teach ifs right before looping, so students get a chance to immediately use ifs; I think it is easier to state the condition in which to break instead of the condition in which to continue (although we discuss how to compute one from the other by DeMorgan's laws later); there is only one looping form, so students aren't faced with the up-front decision of what kind of loop to use; and finally, they can fully write the loop and its body and then worry about termination later (unlike a while loop
Re: [Edu-sig] a short essay about programming
Kirby, There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false. That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop: guess = int(input(Guess? )) while(guess != secret): // as long as the user didn't get it, get another guess print(Nope, try again) guess = int(input(Guess? )) // Here we know the condition is false print(You guessed it) There's no reason for the re-test of the loop condition to either break or continue. This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit: allowed = 5 guess = int(input(Guess? )) tries = 1 while guess != secret and tries allowed: //user gets to try again print(Nope, try again) guess = int(input(Guess? )) tries += 1 if tries = allowed: print(You guessed it) else: print(You've maxed out.) I like having the loop condition telling us exactly what the loop accomplishes. Using something like an exit or done variable obscures that because it does not announce what is required in order for the loop to be done. Of course the cost of this style is the repeated input statement, but a priming read is a standard part of a sentinel loop, and both examples are shorter than the versions that retest or assign a conditional inside the loop. John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner [kirby.ur...@gmail.com] Sent: Saturday, April 21, 2012 2:45 AM To: edu-sig@python.org Subject: [Edu-sig] a short essay about programming A common error (not too serious) that I see in beginning Python (and no doubt other languages, but Python is the one I'm teaching), is having a while condition that appears to put a lid on things, but then the flow all leaks away through break statements, such that the front door condition is never revisited. while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) break else: print(Nope, try again...) What's messed up about the above code is you never really go back to the top in the case where you'd get to leave. Rather, you exit by the back door, through break. So in that case, wouldn't have been simpler and more elegant, even more correct (dare I say it) to have gone: while True: # no ifs ands or buts guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) break else: print(Nope, try again...) I see lots of heads nodding, and that could be the end of the matter, but then a next question arises: wouldn't this also be a more correct solution?: while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) continue # instead of break else: print(Nope, try again...) We're back to having a variable while condition, not a boolean constant, but this time we actually exit by means of it, thanks to continue or... while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) else: print(Nope, try again...) ... thanks to no continue. This last one is getting a thumbs up, but then I'd pause here and say continue can be easier on the eyes. It's unambiguous where it takes you, in contrast to having to scan on down the gauntlet, looking for possibly other open doors. What happens next should not require scanning ahead too far. Help us not to get lost. Be a civic-minded coder. I'm thinking of a programming style that advises two things: (a) if you use a while condition that's variable, that's expected to change, then your goal should be to always exit because of that, i.e. that should be your only exit point. Even if some other criterion suggests exiting, you have the option to flip that lid at the top, to crack that front door, and bounce the ball out. (b) which is why 'continue' is your friend. You are showing the user where your 'break' statements are, except you don't use break statements, as you've given a non-constant condition, and your aim is to make that your ONLY exit point. In short: never use break to exit a while loop unless your condition is while True. Instead, always flip the condition and exit through the font door. However, as soon as I make that rule I can think of good reasons to break it. The other programmers in the room are shaking their heads. Won't we lose information, needed elsewhere in the program, if we artificially force a True
Re: [Edu-sig] a short essay about programming
Oops, I think I have an off by one error in my last example. I would change the conditional at the bottom to: if guess == secret: print(You guessed it!) else: print(You maxed out.) That's clearer anyway. John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of John Zelle [john.ze...@wartburg.edu] Sent: Saturday, April 21, 2012 8:11 AM To: kirby urner; edu-sig@python.org Subject: Re: [Edu-sig] a short essay about programming Kirby, There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false. That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop: guess = int(input(Guess? )) while(guess != secret): // as long as the user didn't get it, get another guess print(Nope, try again) guess = int(input(Guess? )) // Here we know the condition is false print(You guessed it) There's no reason for the re-test of the loop condition to either break or continue. This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit: allowed = 5 guess = int(input(Guess? )) tries = 1 while guess != secret and tries allowed: //user gets to try again print(Nope, try again) guess = int(input(Guess? )) tries += 1 if tries = allowed: print(You guessed it) else: print(You've maxed out.) I like having the loop condition telling us exactly what the loop accomplishes. Using something like an exit or done variable obscures that because it does not announce what is required in order for the loop to be done. Of course the cost of this style is the repeated input statement, but a priming read is a standard part of a sentinel loop, and both examples are shorter than the versions that retest or assign a conditional inside the loop. John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner [kirby.ur...@gmail.com] Sent: Saturday, April 21, 2012 2:45 AM To: edu-sig@python.org Subject: [Edu-sig] a short essay about programming A common error (not too serious) that I see in beginning Python (and no doubt other languages, but Python is the one I'm teaching), is having a while condition that appears to put a lid on things, but then the flow all leaks away through break statements, such that the front door condition is never revisited. while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) break else: print(Nope, try again...) What's messed up about the above code is you never really go back to the top in the case where you'd get to leave. Rather, you exit by the back door, through break. So in that case, wouldn't have been simpler and more elegant, even more correct (dare I say it) to have gone: while True: # no ifs ands or buts guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) break else: print(Nope, try again...) I see lots of heads nodding, and that could be the end of the matter, but then a next question arises: wouldn't this also be a more correct solution?: while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) continue # instead of break else: print(Nope, try again...) We're back to having a variable while condition, not a boolean constant, but this time we actually exit by means of it, thanks to continue or... while guess != secret: guess = int(input(Guess?: ) if guess == secret: print(You guessed it!) else: print(Nope, try again...) ... thanks to no continue. This last one is getting a thumbs up, but then I'd pause here and say continue can be easier on the eyes. It's unambiguous where it takes you, in contrast to having to scan on down the gauntlet, looking for possibly other open doors. What happens next should not require scanning ahead too far. Help us not to get lost. Be a civic-minded coder. I'm thinking of a programming style that advises two things: (a) if you use a while condition that's variable, that's expected to change, then your goal should be to always exit because of that, i.e. that should be your only exit point. Even if some other criterion suggests exiting, you have the option to flip that lid at the top, to crack that front door, and bounce the ball out. (b
Re: [Edu-sig] a short essay about programming
Hi All, Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions. One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following. Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV, that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to. --John John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner [kirby.ur...@gmail.com] Sent: Saturday, April 21, 2012 9:12 PM To: edu-sig@python.org Subject: Re: [Edu-sig] a short essay about programming ... another useful contribution to this thread. -- Forwarded message -- From: Richard Pattis pat...@ics.uci.edu Date: Sat, Apr 21, 2012 at 6:53 PM Subject: I'm not allowed to post To: kirby urner kirby.ur...@gmail.com Feel free to post this for me, which got returned. Probably because I use a mail alias and never tried to post before. Rich I replied to Kirby privately, and he suggested I post to the listserv, so I have. Because UCI is starting to teach Python next year, I might be on the listserv (more than you want) over the summer as I learn Python and how to program in it and teach it: a tall order for a few months. As Charles McCabe (SF Examiner) said, Any clod can have the facts; having opinions is an art. - rep Kirby, I'm a long time Java teacher (heck, I started teaching Fortran in 1976) who will soon be teaching Python. We (here at UC Irvine) are switching to a 3 quarter introduction to programming sequence all in Python (and then on to Java and C++ for upper division courses, although Python could leak upwards). I've been subscribing to edu-sig Python for a while and appreciate your efforts (and have learned from them). I'm a big fan in Java of teaching beginners only for(;;) -I call it for-ever- and if/break termination (although some colleagues accuse me of teaching machine language in Java). I like forever if/break for a few reasons, among them are I teach ifs right before looping, so students get a chance to immediately use ifs; I think it is easier to state the condition in which to break instead of the condition in which to continue (although we discuss how to compute one from the other by DeMorgan's laws later); there is only one looping form, so students aren't faced with the up-front decision of what kind of loop to use; and finally, they can fully write the loop and its body and then worry about termination later (unlike a while loop, where syntactically the first thing you must write is the continuation test -although some computer scientists would consider this a feature, not a bug). So my students don't have to think of which Java loop to use: while or do/while. They code everything (early in class) using forever if/break, although later I illustrate the semantics of Java's other looping forms, using forever if/break (which they are familiar with), tell them if the pattern fits, do the transformation to simplify their code, and if you do this enough, later in the course you will write the right pattern first, without thinking about the transformation. I'm not a big fan of continue here. I conceptualize this as an N=1/2 loop (sentinel loops are also of this form) and am happy with forever if/break; The question I'd have for a while loop, is where does guess come from the first time the test is evaluated; if the answer is some initialization that is not equal to secret, I'd say yuck: guess should store the user's guesses only, not some crazy value to make things work the first time the loop is entered. Another reason I don't like continue is that it isn't local; you have to go around the loop again to exit.; and will you exit the next time around, it doesn't jump out at me (same, but a little less so, for your exit = True code in the later example; more soon). With break, you recognize termination and perform the action immediately (like return). Also, you have to have the condition stated twice in your final code, in two opposite forms (guess != secret) and also (guess == secret); confusing and double yuck. Now in Java you
Re: [Edu-sig] mac python graphics
Andrew, We have numerous students and faculty here who are successfully using graphics.py with OSX Lion. The main problem for them was getting the ActiveState Tcl/Tk fix, but it sounds like you have already done that. If IDLE is running, there is no reason that the graphics package should give you difficulties. I have two quick suggestions. First make sure you have the latest version of the graphics library available from my python page: http://mcsp.wartburg.edu/zelle/python. You probably do have it, as it has not been updated in quite a while. The important thing is that you need the unthreaded iteration of the library. Second, make sure that every graphics program shuts down properly by executing window.close(). If your processes are hanging up on program termination, this could be the issue. It is not sufficient to simply have the Python program quit. If neither of these addresses your issue, then I would appreciate it if you would send me a slightly more detailed report letting me know exactly what version of python and Tcl/Tk you are running and providing a simple example program that causes freeze up along with a description of exactly how it locks up. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of Andrew Harrington [ahar...@luc.edu] Sent: Wednesday, December 07, 2011 11:45 AM To: edu-sig@python.org Subject: [Edu-sig] mac python graphics I just got my first Mac. I know issues with Mac graphics have been discussed before, but I'm not sure what is relevant with OSX Lion. With the active state Tcl and the standard python.orghttp://python.org python and idle appears fine. Still if I try running a Zelle graphic program inside or outside idle I get a freeze. The massive installation through MacPorts, that uses X11 for graphics makes my Zelle graphics library Tk based programs work fine, but the X11 version of Idle has many of the common keyboard shortcuts not working, and is (intensionally) not the standard Apple menu setup. What am I missing? Thanks, -- Dr. Andrew N. Harrington Computer Science Department Loyola University Chicago Lakeshore office in the Math Department: 205 Loyola Hall http://www.cs.luc.edu/~anh Phone: 773-915-7999 Fax:312-915-7998 ahar...@luc.edumailto:ahar...@luc.edu ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] mac python graphics
Andrew, The only real disadvantage of the non-threaded (current) version is that it does not play as well with the IDLE shell when demonstrating graphics interactively. But there are numerous advantages of the non-threaded version including that it works on OSX :-). I also like that I can have my students use Tkinter dialogs for opening files or getting simple inputs in graphics programs. As far as documenting the complete GraphWin API, I've always been a bit lazy about moving things into the official API, just because I want to keep the API really small so that it doesn't overwhelm first-time users of graphics. There have always been a few undocumented goodies lurking in the module. When I decide that I _have_ to have them for certain class projects, then they make their way into the official API. I'm very conservative, because I don't want to remove things (for backward compatibility), and I consider the API now to be at the limit of what I can expect my CS1 students to reasonably master. John Zelle, PhD Professor of Computer Science Wartburg College From: anharring...@gmail.com [anharring...@gmail.com] on behalf of Andrew Harrington [ahar...@luc.edu] Sent: Wednesday, December 07, 2011 2:27 PM To: John Zelle Cc: edu-sig@python.org Subject: Re: [Edu-sig] mac python graphics Thanks, Juhn. I had somehow missed the latest version. What complications does the single threading bring? On Wed, Dec 7, 2011 at 12:19 PM, John Zelle john.ze...@wartburg.edumailto:john.ze...@wartburg.edu wrote: Andrew, We have numerous students and faculty here who are successfully using graphics.py with OSX Lion. The main problem for them was getting the ActiveState Tcl/Tk fix, but it sounds like you have already done that. If IDLE is running, there is no reason that the graphics package should give you difficulties. I have two quick suggestions. First make sure you have the latest version of the graphics library available from my python page: http://mcsp.wartburg.edu/zelle/python. You probably do have it, as it has not been updated in quite a while. The important thing is that you need the unthreaded iteration of the library. Second, make sure that every graphics program shuts down properly by executing window.close(). If your processes are hanging up on program termination, this could be the issue. It is not sufficient to simply have the Python program quit. If neither of these addresses your issue, then I would appreciate it if you would send me a slightly more detailed report letting me know exactly what version of python and Tcl/Tk you are running and providing a simple example program that causes freeze up along with a description of exactly how it locks up. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College From: edu-sig-bounces+john.zelle=wartburg@python.orgmailto:wartburg@python.org [edu-sig-bounces+john.zelle=wartburg@python.orgmailto:wartburg@python.org] on behalf of Andrew Harrington [ahar...@luc.edumailto:ahar...@luc.edu] Sent: Wednesday, December 07, 2011 11:45 AM To: edu-sig@python.orgmailto:edu-sig@python.org Subject: [Edu-sig] mac python graphics I just got my first Mac. I know issues with Mac graphics have been discussed before, but I'm not sure what is relevant with OSX Lion. With the active state Tcl and the standard python.orghttp://python.org python and idle appears fine. Still if I try running a Zelle graphic program inside or outside idle I get a freeze. The massive installation through MacPorts, that uses X11 for graphics makes my Zelle graphics library Tk based programs work fine, but the X11 version of Idle has many of the common keyboard shortcuts not working, and is (intensionally) not the standard Apple menu setup. What am I missing? Thanks, -- Dr. Andrew N. Harrington Computer Science Department Loyola University Chicago Lakeshore office in the Math Department: 205 Loyola Hall http://www.cs.luc.edu/~anh Phone: 773-915-7999tel:773-915-7999 Fax:312-915-7998tel:312-915-7998 ahar...@luc.edumailto:ahar...@luc.edu -- Dr. Andrew N. Harrington Computer Science Department Loyola University Chicago Lakeshore office in the Math Department: 205 Loyola Hall http://www.cs.luc.edu/~anh Phone: 773-915-7999 Fax:312-915-7998 ahar...@luc.edumailto:ahar...@luc.edu ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Interesting gotcha
Hi,
I agree that the behavior of booleans in Python can sometimes lead to subtle
errors, but I think it's important to stress to students that writing things
like:
if xy == True:
is _really_ bad style. After pointing that out, I start taking points away for
doing this. Code like this shows that the writer really does not understand
Boolean types and their use. Expressions like this can cause subtle errors in
just about any language, even those that are statically typed to prevent this
sort of confusion. In Java, (xy==true) is not a valid expression, so it won't
compile. But consider this loop that seems to use done as a boolean flag::
boolean done = false;
while(done = false){
// do some stuff here
}
The loop body will never execute. This sort of error in a strongly typed
language is often very hard to spot, since we assume the compiler should catch
it. If the condition is simply written as:
while(!done){
then you can't go wrong.
My point is that while I agree this is a gotcha in Python, there are similar
gotchas in just about all languages. The real culprit in the original example
is poor coding style, not the language semantics per se.
--John
From: edu-sig-bounces+john.zelle=wartburg@python.org
[edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of Christian
Mascher [christian.masc...@gmx.de]
Sent: Tuesday, March 29, 2011 10:12 AM
To: edu-sig@python.org
Subject: Re: [Edu-sig] Interesting gotcha
Hi,
I really like it that python allows me to write
if 10 x = b:
...
impossible in many other languages.
But all things come at a cost:
if x y == True:
I think this is a real gotcha, because it might get you, because you
_know too much_:
if 4:
print True
True
So all things different from 0, '', ... are considered True by python.
But.
spoiler ahead ;-)
4==True
False
Cheers
Christian
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] looking for explanations... globals dynamic dict
Hello,
Isn't the issue here simply that globals does not return a copy of the globals
dictionary, it returns THE actual globals dictionary. It's not some sort of
callable, it is the globals dictionary, period. There is no such thing as a
static dictionary, they are mutable, and this one changes every time you define
a new variable. For example, try:
g = globals()
g['k'] = 3
k
3
So when you assign to new variables, this globals dictionary is changing, and
that leads to the iteration error. As long as you iterate using existing
variables, there is no problem.
g = globals()
k = None
v = None
for k,v in g.items():
... print k,v
...
g {'g': {...}, '__builtins__': module '__builtin__' (built-in), 'k': 'g',
'__package__': None, 'v': {...}, '__name__': '__main__', '__doc__': None}
__builtins__ module '__builtin__' (built-in)
k None
__package__ None
v None
__name__ __main__
__doc__ None
--John
From: edu-sig-bounces+john.zelle=wartburg@python.org
[edu-sig-bounces+john.zelle=wartburg@python.org] on behalf of kirby urner
[kirby.ur...@gmail.com]
Sent: Monday, March 28, 2011 1:19 PM
To: edu-sig@python.org
Subject: [Edu-sig] looking for explanations... globals dynamic dict
One of my Python students alerted me to this state of affairs.
I understand that what globals( ) returns will fluctuate as new names come and
go.
What I less understand is why g isn't just a *snap shot* of what was global at
the time globals( ) ran.
Now it's just a dictionary like any other (and yes, it contains itself, as
another global).
So when I go to print its items, why should it care that the names k and v have
been added.
Why isn't g just a static dictionary?
I guess because it's tied to a callable that gets re-executed whenever g is
used. g.items( ) is like globals( ).items( ) -- another call.
g = globals()
g
{'__builtins__': module 'builtins' (built-in), '__name__': '__main__',
'__doc__': None, 'g': {...}, '__package__': None}
len(g)
5
for k, v in g.items(): print(k, v)
__builtins__ module 'builtins' (built-in)
Traceback (most recent call last):
File pyshell#156, line 1, in module
for k, v in g.items(): print(k, v)
RuntimeError: dictionary changed size during iteration
g
{'g': {...}, '__builtins__': module 'builtins' (built-in), 'k':
'__builtins__', '__package__': None, 'v': module 'builtins' (built-in),
'__name__': '__main__', '__doc__': None}
len(g)
7
Oh no, not again
for t,v in g.items(): print(t,v)
g {'g': {...}, '__builtins__': module 'builtins' (built-in), 'k':
'__builtins__', '__package__': None, 't': 'g', 'v': {...}, '__name__':
'__main__', '__doc__': None}
Traceback (most recent call last):
File pyshell#160, line 1, in module
for t,v in g.items(): print(t,v)
RuntimeError: dictionary changed size during iteration
This seems to solve the problem:
RESTART
g = dict(globals())
g
{'__builtins__': module 'builtins' (built-in), '__name__': '__main__',
'__doc__': None, '__package__': None}
for t,v in g.items(): print(t,v)
__builtins__ module 'builtins' (built-in)
__name__ __main__
__doc__ None
__package__ None
This behavior still seems a little peculiar.
help(globals)
Help on built-in function globals in module builtins:
globals(...)
globals() - dictionary
Return the dictionary containing the current scope's global variables.
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] What version of Python to teach ....
Hi, On Sunday 19 April 2009 18:44:30 michel paul wrote: On Sun, Apr 19, 2009 at 2:48 PM, Gregor Lingl gregor.li...@aon.at wrote: How do you explain the nature of range to beginners? How about using list(range())? Something like: # Here's how you can create a list of integers: list(range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] list(range(1, 10)) [1, 2, 3, 4, 5, 6, 7, 8, 9] list(range(1, 10, 2)) [1, 3, 5, 7, 9] list(range(-10, 10, 2)) [-10, -8, -6, -4, -2, 0, 2, 4, 6, 8] # 'list' creates a list, and 'range' specifies its starting point, ending point, and interval between points. I would say that the range specifies the sequence of objects that the list is created from. I agree that using list is a good way to approach this. # a range object produces these values when called upon to do so. # for example, in a loop: for x in range(10): (x, x**2) (0, 0) (1, 1) (2, 4) (3, 9) (4, 16) (5, 25) (6, 36) (7, 49) (8, 64) (9, 81) Now, interesting, here I've stumbled on a question that I need some clarification on: a = range(10) type(a) class 'range' next(a) Traceback (most recent call last): File pyshell#49, line 1, in module next(a) TypeError: range object is not an iterator help(range) Help on class range in module builtins: class range(object) | range([start,] stop[, step]) - range object | | Returns an iterator that generates the numbers in the range on demand. So is range an iterator? No, a range object is not itself an iterator. It is an object that returns an iterator when you ask it for one. You can create any number of independent iterators from a single range object: x = range(1,10) it1 = iter(x) next(it1) 1 next(it1) 2 it2 = iter(x) next(it2) 1 next(it2) 2 A for loop always asks the sequence object for its iterator. If you want to loop over a collection object, it should implement the __iter__ hook that produces and iterator object. It is the iterator object that implements the __next__ hook. Of course, the usual approach is to use a generator method (uses yield) which itself hands back an iterator when it is called. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA john.ze...@wartburg.edu (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Scratch pad nuttiness... (re generators)
Hi Kirby, I happen to be working through some Python3.0 issues right now. A couple comments: On Monday 16 March 2009 10:42:24 kirby urner wrote: So then it occurs to me, would there by a way to do a kind of special names overloading such that __next__ (that which triggers the next cycling to yield) might be replaced with the word kick in some namespace, as in kick(o) instead of next(o) -- using Python 3.x syntax here i.e. not o.next(). What would a student try, if this were the challenge? Simple solution: def kick(o): return next(o) Of couse, the simplest solution is just to bind kick to next: o = iter(range(10)) kick = next kick(o) 0 kick(o) 1 That does the trick. def f(): # could use a generator expression for i in range(10): yield i type(f) # just a function so far class 'function' o = f() next(o) 0 kick(o) 1 kick(o) 2 type(o) # a generator once instanced class 'generator' Another student might think different and try something like this: o.__next__ method-wrapper '__next__' of generator object at 0x8367edc o.kick = o.__next__ Traceback (most recent call last): File pyshell#51, line 1, in module o.kick = o.__next__ AttributeError: 'generator' object has no attribute 'kick' Dang, you can't give your generator object a random attribute i doesn't already have, write-protected in some way Of course, even if this worked, it wouldn't give you the kick(o) behavior that you specified above. I could see where one might try this to get the 2.xish o.kick() behavior. Of course, you could easily get an alias to o's __next__ via simple assignment again: o = iter(range(10)) kicko = o.__next__ kicko() 0 kicko() 1 Note that the generator type is inappropriate as a base class for your own kind of user class. class newgen (type(o)): kick = type(o).__next__ Traceback (most recent call last): File pyshell#10, line 1, in module class newgen (type(o)): TypeError: type 'generator' is not an acceptable base type I don't follow the reasoning in this attempt at all. --John ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] looking for references
Barry Schwartz's book, The Cost of Living: How Market Freedom Erodes the Best Things in Life, has a chapter titled The Debasing of Education: Turning Play into Work that summarizes various evidence and makes a similar argument along these lines. On Sat, 2008-07-26 at 10:11 -0500, Daniel Ajoy wrote: I am looking for a study I used to know which demonstrated that the introduction of a grading scheme had a damaging effect on the ability of educators to actually teach students. Anybody got some references lying around? Laura Punished by rewards Daniel ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Pass by Reference
Hi David, I gave a detailed description of my definitions in a post a while back. In that, I referred to the traditional view of a variable as a named location. As per your request: In call-by-value the formal parameter is a local variable whose content is initialized with a copy of the value of the actual parameter. Assignment to the formal parameter has no effect on the actual argument. In pass by reference, the formal parameter is a name bound (by reference) to the variable used as the argument of the call. In this case, assignment to the formal parameter actually changes what is stored in the caller variable. On Wed, 2008-05-21 at 08:41 -0700, David MacQuigg wrote: Hi John, I think what we all agree on is the details of what is happening in Python. As long as we use unambiguous words to describe that process, there is no problem. The problem is in the definition of call-by-value. I have offered a simple definition, what I called the traditional definition, but perhaps that is claiming too much priority for one tradition. I'll call it the common definition, what most programmers will tell you, and what you find at http://en.wikipedia.org/wiki/Call_by_value I'm using the exact same definition of call-by-value as you find in this wikipedia entry. The difference between your view and mine does not turn on the definition of call by value, but rather on what constitutes the value of the expression. I'm saying it's clean, simple, and correct to say the result of an expression in Python is a reference to some object. And that reference is what is stored into a variable (which is then still just a named location). You're saying the value of the expression _is_ the object. In your view then, variables contain objects. I often speak along those lines with Python, but in terms of defining the semantics of languages, I think it's cleaner to say that Python variables contain references. That way the term variable means the same thing for virtually every language (Prolog notwithstanding). And all of the historical terms still work just fine. In addition, if you look at the Python interpreter, I'm sure there are references (addresses) to these heap-allocated objects running around all over the place, for example in the runtime stack-frames. What do you call the locations that contain those references, if not variables. That's certainly what they've been called in the traditional programming languages literature for decades now. As for the wikipedia entry on call-by-reference, I find it too ambiguous to say much about, but I can certainly make the case that it agrees with me. What is an implicit reference to the argument? In the canonical call by reference languages such as FORTRAN and Pascal, the argument to the call has to be a variable (C++ lifts this restriction). The formal parameter then becomes an alias for the same memory location as the argument variable. In essence the formal parameter is a variable that still lives in the caller's stack frame. This is achieved by passing the variable's address behind the scenes, and the language then specially and automatically dereferences the address to manipulate the non-local variable. That, to me, is call by reference. The reference is being sent _implicitly_ and the language does something special to make it all work. In other words, I reserve the term pass-by-reference as a name for this specific language mechanism, not as a generic term for passing references around in programs. You can pass references around in (virtually) any language, regardless of what parameter passing mechanism the designers provide. As I've pointed out before, I can pass references (pointers) around in Pascal without ever using the pass-by-reference mechanism that's built into the language. And I will have the visible side-effects that result from aliasing. But that is not pass-by-reference semantics. In the case of Python, the references are _explicit_. The interpreter doesn't do anything special or different behind the scenes at function call time to grab the address of the argument. All Python variables contain references, and expressions evaluate to references. The parameter passing mechanism just copies the value of the reference from the caller's variable into the formal parameter. The formal parameter is still a local variable in every sense. You know this to be true, because reassigning it has no effect in the caller. I notice that the Wikipedia article tries to have it both ways by saying Java is a call-by-value language but frequently displays call by reference semantics. But there are not two different mechanisms in Java. The _mechanism_ is call-by-value. The call always happens in exactly the same way regardless of the argument type. It just so happens that when the argument is a reference to something mutable, then changes to that mutable thing are visible to the caller, just as in Python, Pascal (non VAR params), C, and any other call-by-value language
Re: [Edu-sig] Pass by Reference
Hi John,
I can't agree with this.
On Tue, 2008-05-20 at 10:50 -0400, John Posner wrote:
... and stop trying to invent new names for a parameter passing mechanism
that is identical in function to traditional call by value.
Yeah, but ... it will be difficult to stick to a call-by-value
characterization when confronted with this example, which is straight from
Call by Reference 101:
def AddArtist(mylist):
mylist.append('TheOtherTerry')
troupe
['Graham', 'John', 'Eric', 'Michael', 'Terry']
AddArtist(troupe)
troupe
['Graham', 'John', 'Eric', 'Michael', 'Terry', 'TheOtherTerry']
Great example, but the result here has NOTHING WHATSOEVER to do with
parameter passing by reference. If I do this:
mylist = troupe
myList.append(TheOtherTerry)
I get exactly the same result. That's because the value of a variable in
Python IS A REFERENCE. Aliasing is aliasing, and it has nothing to do in
this case with how parameters are passed.
As I keep explaining, when the term pass-by-reference is applied to
parameter passing, it means that the formal parameter becomes a
reference to the actual variable used in the argument (more technically,
the formal parameter name is bound to the storage location of the
argument variable). That means changes to the value of the formal
parameter actually change the contents of the calling variable. Python
does not do this! You can change the state of the object that's referred
to, but you _cannot change the contents of the variable_ (what it refers
to).
The example you give illustrates what happens with call-by-value in _any
language_ that allows the value of a variable to be a reference
(pointer). Java has no reference parameters or call by reference
mechanism, but it exhibits exactly the same behavior (when the argument
is a reference). Similarly in C, if I pass a pointer and change the
state of the object that it points to, then the change will be visible
to the caller even though the pointer itself is passed-by-value. The C
trick of sending an address of the variable (foo) is a way of
simulating or effecting call by reference. Technically, the parameter
is still passed by value. The programmer must send the reference and
also do the appropriate dereferencing in the function (using
*formal_param).
Perhaps the confusion comes because these other languages allow some
variables to be references and others not. In Python all variable values
are references. Furthermore Python has no C-like trick to effect
pass-by-reference, because even if you can get the value of a variable's
contents (say by doing id(a)) you cannot set up a way for a different
variable to change that value (even if b = a, setting b = c cannot
change the contents of a).
This mechanism (pass-by-value) is distinct from pass-by-reference as
found in languages like FORTRAN, Pascal, or (arguably) C++.
Most students (especially newbies) won't care about what happens under the
hood -- not at first. If it looks like a duck, walks like a duck, and quacks
like a duck ...
First up, there is no reason to discuss these distinctions in detail
with newbies. Tell them how it works. That's all you need to do. Newbies
won't give a hoot about call-by-reference or call-by-value, as they have
not yet learned those terms. But don't teach them the wrong term!
Second, it doesn't quack like a reference parameter because Python
doesn't allow changing the value of the callers variable!!! It walks and
quacks exactly like a variable whose value is a reference being
passed-by-value. So if you insist on giving the newbie a label, give
them the right label. The _parameter_ passing_ mechanism is plain old
pass-by-value.
When dealing with more experienced folks, explain that all Python
variables are references. That's what's different from (most)
traditional languages. That explains many things about the Python. Then
when you tell them parameters are passed by value, they will understand
the implications of that. Another reference to the same object allows
changes in the object state through one to be visible to the other. But
please don't pretend that the parameter passing mechanism is some
strange and bizarre hybrid and not like other languages, because that's
just not true.
--John
ps. OK, now I'm letting go of the issue.
-John
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer ScienceWaverly, IA
[EMAIL PROTECTED] (319) 352-8360
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Pass by Reference
Hi David, It's enough for me at this point that we all agree on what we're talking about. The rest is a matter of taste, I think. The one real sticking point I still have with your approach is simply that what you expect pass-by-value to do in Python (namely make a copy of the object that a variable refers to) is not to my knowledge implemented in any language. Lots of languages have been built around pass-by-value, and none is doing what you consider your acid-test for pass-by value. On the flip side, any language that claims pass-by-reference as part of the language allows me to do what I consider the acid test for pass-by-reference (namely I can change the referent of the calling argument), which I cannot do in Python. So I prefer to use the terms the way they have been used historically and remain consistent with language design traditions. As I've tried to emphasize, this is not really an issue of how Python passes parameters, but rather how it treats variables. I base my terminology on the traditional view of what a variable is, and that still works quite well as a consistent model for Python. Doing so allows me to use traditional terminology for parameter passing without any imprecision or change of meaning. Your model of a variable is not the traditional model (as you point out). That doesn't make your model better or worse, just different. It does mean that your model will not work for describing languages like Pascal, Fortran, C++, or Java. But your model is exactly the way I encourage my students to think about Python. I guess you are arguing for a clean break with old traditions and I am suggesting that they can co-exist (perhaps not to everyone's satisfaction). I think both of those positions have merit. --John On Tue, 2008-05-20 at 10:29 -0700, David MacQuigg wrote: Hi John, I did some more searching on this question, and I see it has been discussed many times before. I read a few of the threads, and they seem to go on forever with no resolution, just a lack of communication. It comes down to the definition of value. One camp says a value is only the actual data in an object, the other says the value can be the reference. I've been using it to mean only the data. variable:(name, pointer) -- object:(type, value, address) Looks like this controversy is not just in the Python community. I found a good discussion in Bruce Eckel's Thinking in Java, 2nd ed, Appendix A: Passing and Returning Objects. On p. 1018, he has a discussion of pass-by-value with a nice summary of the views of two distinct camps. He concludes with I will attempt to sidestep the issue. In the end, it isn't that important. What is important is that you understand that passing a reference allows the caller's object to be changed unexpectedly. I think that is what we need to focus on. What will students remember in later years? Which explanation will be most beneficial in helping them avoid problems? I hope that you will recognize the validity of other views, and not just say they are wrong. I think that is the only way this discussion can move forward. I wrote a detailed response to your last post, but decided to delete most of it. I'll just leave a few parts where I need to correct a serious misunderstanding of what I am saying. At 06:36 PM 5/19/2008 -0500, John Zelle wrote: You insist on writing/thinking/reasoning as if Python variables contain the objects they refer to, but that simply is not the case for the traditional use of the term variable. That is not at all what I meant. In my model the variable has only a name and a pointer. The variable refers to an object, but it does not contain the object, in the sense that a variable in C is like a box containing a value. variable:(name, pointer) -- object:(type, value, address) Literally, your model, with the traditional definition would require that every assignment statement in Python create a new variable. Consider this sequence: a = 3 # creates the variable a a = 4 # a is now bound to another location a = 5 # a is now bound to yet another location Since the address of the value changes with each assignment, the pair (name, location) is changing each time, and hence we have here three different variables with the same name. That's certainly not the way I think about what's happening in Python! In my model, the pointer associated with the variable named a is moved from one object to the next, leaving the old object for the garbage collector. So, my question is why don't we just stick with the traditional notion of a variable being a (name, location) pair. I've been calling it a (name, pointer) meaning the same thing. Realize that Python dereferences the values for us when we use variables in expressions and stop trying to invent new names for a parameter passing mechanism that is identical in function to traditional call by value. We
Re: [Edu-sig] Pass by Reference
Hi Warren, Some interesting thoughts. You have given me something of a new insight. (So call this a post on a related topic :-) On Tue, 2008-05-20 at 18:35 -0700, Warren Sande wrote: I would argue that from a functional point of view (black box, the way it behaves), Python does behave like call-by-reference, for mutable types. In another language, if I use call-by-reference, and the function modifies the variable, the caller's variable changes. That's the same behavior I get in Python with mutable types (just as in John Posner's example). OK. Again, this is not about parameter passing. To demonstrate, let's take a language that has both call-by-reference and call-by-value, Pascal springs to mind. If you send a linked list (most probably a pointer to a header node) by value in Pascal and you change the structure of the linked list, guess what, the change appears back in the caller. The same thing happens if you use Pascal's pass by reference mechanism. This example is not a test of what kind of parameter passing you do. It is a test of whether the variable you pass holds a reference or actually stores the object. Of course all Python variables hold references and are therefore analogous (in this respect) to Pascal pointers. I understand that it is not truly call-by-reference. But from the outside, that's what it looks like, for mutable types. For immutable types it looks like call-by-value, since changing it in the function does not change the caller's copy I simply don't understand this comment. You can't change an immutable object in the caller or the callee. That's what makes the object immutable. What you can do is change what object a variable refers to (by assignment) and that change has no effect in the callee regardless of whether the type of the object (originally) being referred to is mutable or not. I definitely agree that Python is the best choice for a first language. But there is this one inconsistency (or maybe call it a duality) of mutable vs immutable types, that I think can be a bit confusing. Putting aside the pass-by-X question, a beginner asks: If I doA = (something) then B = Athen I change A, does B also change? The answer to this question is yes always and everywhere in Python. If A refers to a mutable object, then any changes through A will be visible to B. If A's object is not mutable, then you can't change it, period. So if you can make a change to A's object, it is mutable and B's object changes as well (since they are the same object). If you mean does reassigning A have any effect on B, then the answer is no always and everywhere in Python. Setting A = C will change A's reference and have no effect whatsoever on B, it makes no difference whether A's original object was mutable or not. And the answer, again, is It depends. For mutable types, yes, for immutable types, no. And that's a sticky thing to get into for a beginner who is just learning what variables (names) are about. No, it does not depend on whether the object is mutable. It depends on whether you are changing the object or reassigning the variable. The question is not whether A refers to a mutable object, but rather, what does the student mean by change A. Does he/she mean assign A to be a different object or apply an operation that changes the state of A's object. When posed that way, both answers seem fairly obvious. I think you are on to something here, namely that some confusion actually stems from the overloaded meaning of Change A. That can mean either change what A refers to or change the state of the object that A refers to. Perhaps as teachers we need to be more careful about using phrases like reassign A and change A's object vs. change A. No doubt, this is what leads to your (apparent) mutable/immutable dichotomy, since reassignment is the one and only way to change A if A is a reference to an immutable object. a = 5 b = a a 5 b 5 a = 7 a 7 b 5 a = [8] b = a a [8] b [8] a.append(9) a [8, 9] b [8, 9] I know that in the first case, you are not really changing a, you are attaching the name 'a' to a new object (7, instead of 5). But that's not what it looks like from the outside. It looks like you are changing a, and b is not changing. In the second case, you are changing a, and b is changing. I really like your example, because it makes my point that this discussion is not about parameter passing at all, but rather about memory models. But I don't understand what you mean that is not what it looks like from the outside. In one case you reassign a and in the other case you don't. They _look_ like _very_different_ things (a = 8, vs. a.append(9)). Therefore one should probably expect they have very different effects, which they do. If you just draw the picture of what assignment does (using arrows for references), these examples are crystal clear. I don't think it should be confusing for newbies. It's
Re: [Edu-sig] Pass by Reference
of the traditional definitions. If we look just at the machinery, its
a call-by-reference. Then we run into problems if we expect to modify the
original object. Unlike C, there is no way to simply stuff a value into a
location specified by a pointer. The result is much like call-by-value, at
least for immutable objects.
If look just at this result, and say call-by-value, we run into problems
with mutable objects, and have to resort to explanations that students find
vague and counter-intuitive, like - the object itself is passed or, the
value IS the pointer.
My preference at this point (perhaps my engineer's bias) is to say Python is
like call-by-reference. That keeps the explanation a lot closer to the
underlying machinery (which engineering students will remember). It is safer
to err on the side of call-by-reference (no nasty surprises with mutable
objects). The apparent deviations from the simple model can be explained
with concepts that students need to learn anyway (mutability and re-binding).
I said earlier that we shouldn't raise this topic in a class for beginners,
but now I think it is quite appropriate for college freshmen. I'm an
electrical engineer, not a computer scientist, but I do remember learning
about call-by-value/reference decades ago. I think there is value in keeping
the definitions simple, even if modern languages don't conform. Let's not
muddy the waters with call by object or other ill-defined concepts. There
really are only two ways to pass an argument to a function - copy the value
or copy a reference.
-- Dave
At 01:48 PM 5/16/2008 -0700, David MacQuigg wrote:
If there are no objections to my models and terminology, the next step is to
describe exactly what happens when we pass an argument in C and in Python.
C is very helpful, since there is nothing hidden in this primitive language,
and we can see exactly what is happening. Also, there is no confusion about
the definitions of call-by-value and call-by-reference. See Kernighan
Ritchie, 2nd ed. p.27. Let's call these the traditional definitions. In
C there are only two ways to pass an argument - copy its value or copy a
reference (pointer) to that value.
Again, the model and terminology for C in this discussion is:
variable:(name, type, pointer) -- object:(value, address)
The variable name, type, and pointer are kept by the compiler. The compiled
module has just the actual data bits representing the value stored at a
particular address.
Here is a simple program that calls a function with two parameters, one
called by value, the other by reference.
f(int a, int *b) {
a += 1; // modifies a local variable
*b += 10; // modifies the caller's variable
}
main() {
int x = 0;
f(x, x); // pass the value and the pointer
printf(x = %d\n, x);
}
// output is x = 10
In the call to function f, the value of the caller's variable x is copied to
the function's parameter a. The function then operates on its own copy of
this value, and the original data value is safe from any modification by the
function. This is call-by-value in C.
In that same call, the address of the caller's variable x is copied to the
function's parameter b. Operations on b then change the value of x, but not
its type or address. This is call-by-reference in C.
In Python, there is only one way to pass an argument. There may be pointers
flying around, but we never see them. We will have to infer what is going
on by doing some tests. Again, the model and terminology for our discussion
is:
variable:(name, pointer) -- object:(type, value, address)
Here is a simple program that calls a function with one parameter.
def f(b): b[:] = range(9)
x = ['abc', 'xyz']
f(x)
x
[0, 1, 2, 3, 4, 5, 6, 7, 8]
In the call to function f, we must infer that a reference to the caller's
variable x is copied to the function's variable b. Operations on b then
change the value of x, but not its type or address.
I know there are later complications ( What if x is immutable? What if b
gets re-assigned within the function? ), but right now I would like to focus
on exactly what happens in the call to function f.
I'll pause once more to see if I've made any mistakes, before the third and
final step - deciding what to call this thing that Python does in passing an
argument.
-- Dave
At 12:41 PM 5/15/2008 -0700, David MacQuigg wrote:
At 04:30 PM 5/14/2008 -0500, John Zelle wrote:
At some point, I have to just let this go, as I think we all on this
list have a pretty good understanding of the differences between C and
Python in terms of assignment and parameter passing. But let's _not_ use
the term pass by reference when talking about Python. You CANNOT
CHANGE THE CONTENTS OF THE VARIABLE THAT IS SUPPLIED AS AN ACTUAL
PARAMETER. It will still refer to the same object (contain the same
Re: [Edu-sig] Sticky-note Analogy
At some point, I have to just let this go, as I think we all on this list have a pretty good understanding of the differences between C and Python in terms of assignment and parameter passing. But let's _not_ use the term pass by reference when talking about Python. You CANNOT CHANGE THE CONTENTS OF THE VARIABLE THAT IS SUPPLIED AS AN ACTUAL PARAMETER. It will still refer to the same object (contain the same reference) regardless of what is done to the formal parameter. Hence, the variable IS NOT passed by reference. The value of the variable (which happens to be a reference) is copied. Pass by value is the accepted label for this mechanism. Pass by reference means something else (as I've pointed out in previous posts). Christopher's point on teaching the differences directly is, I think, a good one. But we don't need to worry about that for beginners. --John On Tue, 2008-05-13 at 22:10 +0100, Christopher Thoday wrote: Would it not be better to describe the differences between C and Python variables directly rather than using an analogy? In C, a variable is the address of a storage location that contains its value. If that value is itself an address then the variable is described as a pointer. In Python, a variable is a reference to an object that has a type as well as a value. The statement: a= b = c; results in three separate values in C but only one in Python. The effect is the same in both languages provided that c refers to a constant. However, if c is a mutable object, such as a list, then changing the value of one variable changes them all. Anyone coming to Python from C may be confused by this as it is not clearly described in any of the books on Python that I have read. When passing an argument to a function, C uses pass-by-value whereas Python uses what is in effect pass-by-reference. In order to obtain pass-by-reference in C the value must be a pointer. Inside the function the pointer must be dereferenced by prefixing it with an asterisk to obtain the value. Eur Ing Christopher Thoday Software Engineer ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] How does Python do Pointers?
David, Actually, I don't think there is that much confusion among the folks who understand/design/study programming languages. Python uses call by value, period, as that term is technically used. But your note below shows the continued confusion (among programmers) about what parameter passing terminology. In classifying calling mechanisms, the question is what happens with a variable being passed and the value it (contains in the traditional usage of those words); it has nothing to do with objects. When modeling Python semantics, a variable actually holds a reference (pointer, address) of an object. When the variable is passed as a parameter, its value (the reference/pointer) is copied into the formal parameter variable. That's it. It's call by value. The confusion and fuzzy thinking comes because the automatic dereferencing of Python variables when they are used in expressions leads people to think about objects being stored in variables. Then they talk about whether objects being copied or not copied in function call parameters. But an object is _never_ stored into a Python variable. To see the difference between passing a mutable object in Python vs. a reference parameter in other languages, you just have to ask if you can change the value of the calling code's variable by assigning a value to the corresponding formal parameter in a function. In C++ or Pascal, setting the value of a reference parameter actually changes the contents of the variable in the calling program. def func(formal_param): # change the value of formal_param to be a reference to foo_object formal_param = foo_object x = bar_object func(x) # for pass by reference, x would now contain a foo_object # In Python (pass by value) x is still bar_object. In Python, you cannot change the actual parameter variable (x above). No matter what you do in the function, the actual parameter still contains the same thing, a reference to the same object it was always pointing to at the time of call. That's because the function operates on it own copy of that reference, not the _actual_variable_ of the caller. Summary: Python's parameter passing is just call by value. But Python variable values are always references and Python semantics dictates that those values are dereferenced when variables are used in expressions. That leads some programmers to (imprecisely) talk about parameter passing in terms of variables having objects as values. I often do this loosely myself, because it's easy to think of a Python name as a variable that stores and object. --John On Tue, 2008-05-06 at 07:45 -0700, David MacQuigg wrote: I agree, there is no reason to dig into call-by-??? terminology with new untainted programmers. The sticky-note analogy is all we need for these students. The figures in Michael's book are excellent. However, having been tainted by C, I am finding the discussion interesting. I just don't understand why there is so much confusion with these call-by terms. Does the function get a copy of the object or a reference to the original object? It's got to be one or the other. At 10:11 PM 5/5/2008 -0500, Michael H.Goldwasser wrote: Python's model is quite clean, it just doesn't match up perfectly with the standard call-by-??? terminology. In call-by-reference evaluation, a function receives an implicit reference to the argument, rather than a copy of its value. -- http://en.wikipedia.org/wiki/Call_by_value By this definition, Python's model is call-by-reference, even though the reference (pointer) is not seen by the user. C's model is call-by-value, even though that value can be an explicitly-evaluated address (pointer). -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Scratch interface for Python, and network programming games.
This is a very interesting assignment, but I would just point out that this is hardly an intro CS course. They are doing these particular projects in an intermediate/advanced data structures/algorithms class. That would be a 3rd semester college-level course for those who entered without a programming background. At least that is where the link goes, and that seems appropriate for the assignment. Just building this as a Python API, rather than a separate interpreter might make for an interesting (and somewhat simpler project). The critters could then easily be programmed right in Python, which is something that even beginning programmers could do. --John On Monday 27 August 2007 9:08 am, Clare Richardson wrote: There's an intro CS course at UT Austin that has an assignment where students create critters that can eat each other, etc, and the students in the class have a big tournament to see whose critter is the last man standing. This is often the favorite assignment of the semester, and many students from past years even come back for the tournament! The assignment comes in two parts: 1) Write an interpreter for the Critter language 2) Define your own Critter in the Critter language The class assignment is in Java, but could easily be turned into Python. The project description and code are on this page: http://www.cs.utexas.edu/users/jdiamond/cs315h/index.html#Proj3 Clare Richardson Technology and Program Coordinator Girlstart www.girlstart.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Winston Wolff Sent: Wednesday, August 22, 2007 4:35 PM To: Dethe Elza Cc: edu-sig@python.org Subject: [Edu-sig] Scratch interface for Python,and network programming games. Hi Dethe- I have been thinking of exactly the same thing--a Scratch type environment for Python. And I've also purchased a Nintendo DS development kit, hoping to make a Python to Nintendo DS development system. Haven't had time to work on it though with my summer classes. I should have more time in the fall, perhaps we can collaborate? My biggest interest on the Scratch/Python angle right now is to develop some team programming games. I.e. you write a program using Python raw or Python via a Scratch interface for beginners, and then you throw your program into the ring via the network and have it compete against other students. Winston Wolff [EMAIL PROTECTED] (646) 827-2242 -- Stratolab - video game courses for kids in new york - http:// stratolab.com ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Fwd: Re: Using IDLE with students
I think Richard intended this for the group. Unfortunately, due to socket issues on Windows, said patch has not yet been implemented. -- Forwarded Message -- Subject: Re: [Edu-sig] Using IDLE with students Date: Friday 17 August 2007 8:24 am From: Richard Guenther [EMAIL PROTECTED] To: John Zelle [EMAIL PROTECTED] I remember installing a patch when I couldn't get IDLE to restart on my Windows computer. Here's a discussion of said patch: http://mail.python.org/pipermail/patches/2006-July/020360.html - Original Message From: John Zelle [EMAIL PROTECTED] To: Richard Guenther [EMAIL PROTECTED] Cc: edu-sig@python.org; [EMAIL PROTECTED] Sent: Thursday, August 16, 2007 9:25:12 PM Subject: Re: [Edu-sig] Using IDLE with students snip Yeah, now you run into the problem that you can only have 1 IDLE process running at a time. I don't understand why IDLE uses a fixed port. --John snip _ ___ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC --- -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Using IDLE with students
On Thursday 16 August 2007 8:01 am, Andy Judkis wrote: When teaching Python to beginners and using IDLE, it seems that one of the dangers would be to have them assigning variables in the interactive mode and then maybe using them in a script they're writing. Then, when they run the script, the variable is still in memory so the program works--for now. I run into this a lot, and I find that it's very very difficult to explain what's going on to kids who are just getting their feet wet. This is why I prefer the new IDLE running in the standard (not -n mode). It really is much better to keep the running script isolated in a subprocess. snip The problem that I run into is that the livewires graphics package doesn't behave properly unless the -n is used. Here's a link with some background: http://mail.python.org/pipermail/edu-sig/2005-November/005583.html I think I've run into other packages that also have problems but livewires is the one I'm sure about. This has been a real problem for me. This is also certainly true. Getting my simple graphics package (graphics.py) to play nicely with IDLE was a pain, and it has really taken on hit on efficiency as a result. I am thinking of reverting to a non-threaded version, but that would require IDLE to be run with the -n switch. Of course, the problem I'm running into now is that many folks are running IDLE with -n, and my graphics package does not run well in that mode (although an older version that I still make available runs quite well). Another alternative is to use IDLE for as a development environment but do use a regular python session from a command prompt for doing interactive noodling around with packages that also run under Tk. There's just no good way around the deuling event loops problem in Tk (at least not on Windows, Linux is less of a problem). --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] spinning 'self'
On Monday 13 August 2007 11:30 pm, kirby urner wrote:
On 8/13/07, John Zelle [EMAIL PROTECTED] wrote:
I would quibble about self not doing any work (you need it to access its
attributes), but I understand the point you are making. Again, though
this makes things seem a bit more mysterious than they really are. The
self parameter is a placeholder in the exact same sense that all formal
parameters are place holders for objects that are provided at call time.
The self parameter has no 'specialness' in this regard.
Yes, I agree. What's special about 'self' is simply what you mentioned
above: it gets passed silently and you need take special care to have
a variable (usually 'self') ready for it as the first parameter of your
method definition -- but then don't mention it when you call in (' self '
is implied -- what makes it special).
But this is exactly my point. Self is _not_ passed silently. The actual
parameter is right there in the call: obj.someMethod(actual1, actual2). obj
_is_ the parameter. The only difference is that it's not inside the parens
when the call is made (unless you use someClass.someMethod(obj, actual1,
actual2, which makes my point even more directly). Self in the method
definition is not at all special. Rather it's the calling syntax that's
different. And the simplest explanation for the different form of call
syntax the fact that it's dispatching a method based on the type of obj
(although I wouldn't use that terminology for beginning students).
But the purpose of 'self' comes into its own when you have a million
'selves' (or just ten) all instantiated from the very same class
definition.
Then we start to appreciate how each of those million has its own
state, its own anchor in memory, thanks to 'self' (or whatever) and in
turn self.__dict__.
OK, so objects have state. That's an important part of OO, but again, I don't
see any particular tie to the magic of self. Perhaps I'm reading too much
into what you are saying, but it seems like you are somehow trying to tie OO
into some deep truth or grand insight into the notion of self, perhaps in
the sense of self-reference and self-knowledge. At least that's what your
musing on the different points of view presented by renaming self seem to
suggest to me. I would emphasize quite the opposite: The _mechanisms_ of OO
are quite straightforward, mundane actually, and not at all amazing or
mysterious.
Again, I might just be reading too much into what you are saying, as I
personally have always been fascinated with the human sense of self (The
mind's I as Hofstadter and Dennet put it). Having just read Hofstader's I
am a Strange Loop, I find myself thinking about these issues perhaps a bit
too much.
There's nothing much else to distinguish two objects of the same type.
' self ' objectifies objects, and as such isn't really called upon to play
its role until an object is instantiated (i.e. gains a self).
I forgot to suggest 'I' (capital 'eye') as an interim possibility (in
addition to candidates ' this ', ' ghost ', ' me ') though of course that's
hard to decipher in ASCII (looks just like Number One).
Hofstadter and others point out that there is some strange entanglement or
loop going on when we use the terms like I or me. That's the kind of
conundrum I'd like not to have my students thinking is part of OO. Again, the
mechanisms of OO are quite pedestrian, even though we _can_ use them to build
amazing abstraction. I say leave contemplation of self to philosophy and AI
classes. For me, Python's self is just the conventional name of the first
formal parameter of a method. Using the same name all the time allows anyone
reading even the smallest snippet of my code to know that I am accessing an
attribute of the object that caused the method lookup. There is nothing deep,
mysterious, magical, or even difficult, about it. Let's not give the
impression that there is.
--John
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer ScienceWaverly, IA
[EMAIL PROTECTED] (319) 352-8360
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] spinning 'self'
On Monday 13 August 2007 3:43 pm, kirby urner wrote: Python is remarkably liberal in its design, in that 'self' is not a keyword. You're free to use other names for this important place in memory. Yet there's still self-imposed discipline (another way of saying 'self discipline'), such that we tend to all use 'self' anyway, by convention (but Python-the-interpreter doesn't complain if we don't -- not likely to change). However, as Python teachers have widely remarked, this concept of 'self' is not easily communicated at first, given the OO paradigm is itself still coming into focus for some students. The nice thing about explicit 'self' from a teaching perspective is that it really is not different from other parameters. Once students understand parameters (not necesarily an easy thing for them), self does not really involve any OO mystery at all. It's just a matter of showing how the parameters match up in a method call: obj.someMethod(actual1, actual2)someMethod(self, formal1, formal2) (you'll have to draw the arrows yourself, my font is proportional -- rats!, there should be a nice arrow from obj to self, actual1 to formal1 and actual2 to formal2) Then of course you explain the reason for the special syntax is that obj is what determines where we go looking for the definition of someMethod. The actual result is still just a plain old function call. In the class definition, the 'self' is really a 'place holder' (akin to zero) i.e. it doesn't do any work, but keeps a place open, like a driver's seat waiting for a driver. When an *object* of said class is created, the self becomes specified, as a kind of *anchor*. And plumbing the depths of 'self' is easy: all you need is __dict__ (i.e. a self is basically another namespace, a concept already familiar from earlier discussions). I would quibble about self not doing any work (you need it to access its attributes), but I understand the point you are making. Again, though this makes things seem a bit more mysterious than they really are. The self parameter is a placeholder in the exact same sense that all formal parameters are place holders for objects that are provided at call time. The self parameter has no 'specialness' in this regard. Python-by-comic-book (including on the net) is an emerging genre, influenced by Head First, Dive Into, and For Dummies series. I'm storyboarding for comics (could be TV shows) in which ' this ', ' me ' and ' ghost ' each get a crack at occupying the ' self ' position. Each of these English options has its own logic and connotations. I especially like ' ghost ' because of its ' ghost in the shell ' connotations (a link to manga, the genre we're in).[1] As Python goes towards Unicode, other non-Romanji substitutes for ' self ' may suggest themselves. However (back to self-discipline) I think it's wise to stick to the guidelines and go with non-idiosyncratic forms. Yes, otherwise you incur the wrath of the Python Gods. Deviation from self appears to be the one form of heresy that is never tolerated under any circumstance. To thine self be true! David Goodger was good on this in his 'Idiomatic Python' at OSCON 2007 [2]: If your object is an iterable (i.e. has a duck face (which is like being a duck type but sounds more like interface)) then address as such, as in in 'for myvar in self.__dict__', and not using has_key() or some such more specialcase form. Huh? I'm affraid I don't follow this. If my object (meaning self?) is iterable, I doubt that I intend to iterate through its namespace. If the point is simply not to use keys() as the iterable sequence for a dictionary, whether it's self.__dict__ or any other dictionary, that I get. In this same spirit (aha! another one), we just go with 'self' at the end of the day. And all is right with the world. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] a non-rhetorical question
Hi All, I am very interested in responses to Andy's question because it was just this sort of frustration with students' inability to write simple programs that led me to using Python (as opposed to C++ or Java) in CS1. After my switch to Python and back to basics CS1 back in 1999, my results dramatically improved. However, I've noticed lately that an increasing share of my (college-level) students are beginning to struggle. It's not like the C++ days, but enough to be concerned. So I ask myself again What has changed about the course? If anything, what has changed is that I am adding more bells and whistles to try to make the course enticing. Doing projects like HTML screen scrapers, image processing, and animations. However, even though the students like these projects, I'm feeling that they may actually detract from learning fundamental concepts like how to design sentinel loops and simple decisions. Let's face it, every API you introduce is extra detail for the students to master, no matter how fun it is. Plain old text processing programs can be fun too if: 1) The instructor provides the proper setup/explanation/motivation. 2) Students have opportunity to master them. Students enjoy what they feel they understand and can do. On Thursday 05 July 2007 11:24 pm, Michael Tobis wrote: Sorry, but I don't think you've successfully motivated your students if that is all they can do in a month. Let me hazard a suggestion. Rather than being too mabitious you are not being ambitious enough. Scripting languages have batteries included. Doing the stuff you would have done with BASIC in 1980 is not necessary and not sufficient. I imagine few tenth graders can connect printing sentences backwards and such with anything they care about. see http://hacketyhack.net I've looked at hacetyhack.net. As others have pointed out, it looks like lots of fun for certain well-motivated students. Those with a strong inner-geek can go to a site like this and actually learn something. But there is a ton of mystery lurking behind this API, and it's not clear to me that this is the quickest way for the average student to really learn the universals of programming. I'd rather kids learned Python than Ruby or PHP or ActionScript, but I'd *much* rather they learned one of those than nothing at all. I'd much rather that they learned the power and limitations of computing in general. Learning the details of any particular specialized API does not seem all that valuable (or important or useful) to me. Of course, your mileage may vary. I'm dealing with older and presumeably more mature students. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] a non-rhetorical question
I agree with Kirby that madlibs are a fun example. On Friday 06 July 2007 2:12 pm, kirby urner wrote: As I mention in my slides for EuroPython (looking forward to meeting Laura again tomorrow), Madlibs proved appealing to most students, little stories where they have to prompt themselves (since raw_input seems to be a theme here, though interacting with the shell and having no main loop at all is just as possible, I'd say better at first...) Possible to use %s substitution but string module has these nifty Template as in: sillystory = string.Template( There once was a certain $persons_name from $city who had a pet $animal. One day, the $animal ate all the food in the house and $persons_name was very angry. One note (I meant to post this in the discussion of string.Template before): You can do this same thing just as simply w/o using the string library. Plain old string formatting works with dictionaries as well. You can just do this: sillystory = There once was a certain %(persons_name)s from %(city)s who had a pet %(animal)s. One day, the %(animal)s ate all the food in the house and %(persons_name)s was very angry. fillins = dict(persons_name=Jack, city=Timbuktu, animal=lemur) print sillystory % fillins I also like the string library for certain pedagogical reasons, but I don't think the Templates are compelling when you can do essentially the same thing with string formatting. Is the $ notation that much of a win? --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Strange transitive import problem
Hi Peter, You have identified the crux of the matter. Basically what happens is that the import apparently locks the interpreter so that the graphics thread does not get a chance to run (import is atomic?). So any call into the graphics library (like creating a GraphWin) deadlocks, since the call cannot return until the thread runs, and the thread won't run until the import is complete. I could fix this by having my graphics package delay the thread launch until the first graphics call is made. But that means _every_ graphics operation will have to check to see if the thread has been launched yet. Even if that's not a big efficiency issue (I'm not sure), it feels too ad hoc to me, so I've resisted doing it. I may resort to that in the next release. By the way, I personally would pair the initGraphics() with a closeGraphics() operation that closes the window clean up at the end. --John On Monday 12 February 2007 10:59 am, Peter Drake wrote: I tried just tacking all of my procedural wrappers on to the end of your file so there would be no transitive import. Surprisingly, that didn't work. The trick you mention below DOES work, and I'll use that as a workaround. A clue, then: it's not the transitive importing that causes the problem, it's the importing of a file that calls GraphWin(). Peter Drake Assistant Professor of Computer Science Lewis Clark College http://www.lclark.edu/~drake/ On Feb 9, 2007, at 1:09 PM, John Zelle wrote: Peter, I should have caught this when you posted your file. There is a bizarre import interaction that I am aware of, but can't say that I fully understand regarding my graphics library. It seems that Python imports are in some-way, somewhat atomic, and with the way my graphics library is set up this can produce this deadlock. I have a workaround for you. Move the graphics setup code in your module into a function: def initGraphics(): global root root = z.GraphWin() print If you can't see the graphics window, print it's probably at the upper left print of your screen, behind this one. Then call this function once at the start of your graphics programs. This is what will now pop up the window. So your junk program becomes: from graphics2 import * print imported graphics2 initGraphics() background(red) If someone has a better understanding of Python module imports and why that causes a problem with my graphics package, I'd love to know how to fix this problem rather than working around it. --John On Friday 09 February 2007 1:36 pm, Peter Drake wrote: The graphics2.py file I supplied earlier (http://www.lclark.edu/ ~drake/courses/cs0/graphics2.py) is a procedural front-end for Zelle's graphics.py. If I run the graphics2.py module, everything works fine, and I can issue commands interactively. A problem happens if I write ANOTHER program, say junk.py: from graphics2 import * print imported graphics2 background(red) When I run this (within IDLE), it hangs trying to import graphics2. There is no error message or processor load, it just hangs. Can anyone explain (or reproduce) this behavior? Peter Drake Assistant Professor of Computer Science Lewis Clark College http://www.lclark.edu/~drake/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Strange transitive import problem
Peter, I should have caught this when you posted your file. There is a bizarre import interaction that I am aware of, but can't say that I fully understand regarding my graphics library. It seems that Python imports are in some-way, somewhat atomic, and with the way my graphics library is set up this can produce this deadlock. I have a workaround for you. Move the graphics setup code in your module into a function: def initGraphics(): global root root = z.GraphWin() print If you can't see the graphics window, print it's probably at the upper left print of your screen, behind this one. Then call this function once at the start of your graphics programs. This is what will now pop up the window. So your junk program becomes: from graphics2 import * print imported graphics2 initGraphics() background(red) If someone has a better understanding of Python module imports and why that causes a problem with my graphics package, I'd love to know how to fix this problem rather than working around it. --John On Friday 09 February 2007 1:36 pm, Peter Drake wrote: The graphics2.py file I supplied earlier (http://www.lclark.edu/ ~drake/courses/cs0/graphics2.py) is a procedural front-end for Zelle's graphics.py. If I run the graphics2.py module, everything works fine, and I can issue commands interactively. A problem happens if I write ANOTHER program, say junk.py: from graphics2 import * print imported graphics2 background(red) When I run this (within IDLE), it hangs trying to import graphics2. There is no error message or processor load, it just hangs. Can anyone explain (or reproduce) this behavior? Peter Drake Assistant Professor of Computer Science Lewis Clark College http://www.lclark.edu/~drake/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py
On Wednesday 07 February 2007 10:54 am, Peter Drake wrote: Your philosophy may differ, but I'd like to see control structures explained sooner. You currently don't introduce if for 200 pages. I find that it's hard to come up with interesting assignments without if. (My idea of interesting assignments usually leans toward simple games, as in my book Data Structures and Algorithms in Java.) Actually, I don't think our philosophies differ all that much. Just to set the record straight, the first control structure in my book is explained on page 15, and the idea of control structures in general is explained in detail on page 39. You're right in that decision structures aren't introduced until around page 200. Everyone has their own pet ordering of the basic topics, and I do have ifs later than lots of folks like to teach them, but the chapters are designed so they can be mixed and matched. Should an instructor want to do ifs earlier (and lots do), that chapter can be used right after Chapt. 2. Although it's hard for me to imagine what interesting problems you can solve without understanding the basic data types of numbers and strings. My own approach is to very rapidly get to the graphics in Chapter 5 (I skip quite a bit of chapter 4 on first pass), because students really groove on that. It seems to work, as we put about 100 students per year through this class (it can be used to meet a gen ed math requirement) with a success rate of over 90%. I'd rather give the students a few simple pieces that they can (with enough practice) fully understand than give them a large library of special-purpose commands. My goal early on is to teach algorithmic thinking. That is breaking down a problem into a sequence of discrete steps. You need some vocabulary of steps in order to do that. Different vocabularies allow you to solve problems in different domains, but the algormithmic thinking process is every bit as generic as it is later with decisions added. But by all means, do decisions early if the problems you want to tackle require them. The types of problems I use tend to require I/O and loops. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Interactive Tkinter graphics under IDLE
Hi Peter, Just a quick question for you. I am wondering if you have checked out the simple graphics package that I built on top of Tkinter for doing these sorts of simple manipulations. It's also name graphics.py. If you haven't seen it, you can check it out at: http://mcsp.wartburg.edu/zelle/python. It's probably that case that it doesn't meet your needs, but if it does it would keep you from aving to reinvent the wheel. --John On Tuesday 06 February 2007 1:03 pm, Peter Drake wrote: Okay, so I've got a simple system worked up that allows students (these are CS0 non-CS-majors) to manipulate objects with commands in the IDLE command window. The file is attached. The next thing I'd like to do is define a function mouse() that starts the main loop, waits for a mouse click, stops the main loop, and returns the coordinates of the mouse click. Any suggestions? -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] experiences teaching Python with turtle graphics?
On Friday 17 November 2006 8:07 am, Ernesto Costa wrote: Hi, Returning to the question of a good module about graphics. I'm using Zohn Zelle's book for my course. It has a interesting and simple to use graphics module. It would be nice if that module could be merged with xturtle i.e to incorporate a turtle class that use the graphics canvas :-)! One project that we often use in my classes is writing a simple turtle module on top of graphics.py. It's a great exercise for introducing students to writing their own classes. Still, I have to say that xturtle looks very interesting, and this might be a great combination. I haven't looked at xturtle's implementation in any detail, so I don't have any sense on how hard such a merger would be. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
On Monday 30 October 2006 10:49 am, Arthur wrote: [EMAIL PROTECTED] wrote: I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes: x = a and b # if both a and b are true, x is assigned b, otherwise x is assigned a x = 2 and 3 # x is assigned 3 x = 0 and 2 # x is assigned 0 x = a or b # if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False You need to determine what should make vertex_map[tp] be true... thanks, but having some trouble: import Numeric as N a=N.array([0,0,0]) b=N.array([0,0,1]) a and b array([0, 0, 0]) This tells me that a zero array is being treated as False (the logical extension to arrays of 0 being false. b and a array([0, 0, 0]) Right. In both cases, the answer is False, which Python gives to you by handing you the first False expression. In either case the false part of the and is the 0 array, while the other is True (a non-zero array). You can check this out: not(a) True not(b) False Can this be? Either both a and b are true, or they are not, so can it be returning the a in both cases? Something screwy, other than my comprehension here? Because a is False ;-). They're not both true. Same problem with a or b array([0, 0, 1]) b or a array([0, 0, 1]) This works the same way, but returns the first True expression as the value of True. any(a) False all(a) False any(b) True all(b) False Though anyone growing up with the Python boolean operator might wonder why it is as it is - i.e. when 0 was the way to spell False this behavior is fairly well expected. Now that False is spelled False, having 0 any less true than 1, when thinks one is dealing with numbers as numbers, is likely to catch the less geeky unaware, IMO. This is why in teaching I prefer to use explicit tests: if x != 0: do something Rather than if x: do something --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The Fate of VPyton BLENDER ??
Jason, I've looked into Blender a number of times, and while I would like to learn it, I have never had time for the learning curve. VPython is something my students and I can use immediately to solve problems at hand. If my goal were to become a 3D artist, then something like Blender would be the way to go. You suggest some sort of streamlined tool built on Blender is possible. But my recollection of Blender is that it embeds a Python intepreter, but is not itself a Python extension. If that is true, then I cannot use such a tool (even if streamlined) to augment _my_ Python environment. When I need a quick 3D visualization for something I'm working on, I would have to somehow import all my work, libraries, etc. into this Blender-based environment. I just don't see Blender and VPython in the same niche. If I am wrong about this, please let me know. Perhaps I have not looked hard enough, or perhaps Blender has changed since I last visited it. --John On Friday 13 October 2006 4:04 am, Jason Cunliffe wrote: Art Thanks for your clear reply.. Yes. Having a reasonable sense of your sensibilities from edu-sig dialogues, I hesitated 3 times before even suggesting it. personal memo I range wide in my sensibilities and preferences. btw, I think I was perhaps the original poster to edu-sig about VPython. Was greatly influenced by a magnificent shell+3D window on Amiga c.1987 called PageRender3D. Am fairly sure you would approve highly of that one. And then live GEOMETER implemented on SGI c.1993 [minimal and mind-blowing] Or REBOL for example for its less-is-more philosophy. In general prefer one-to-one encounters than groups anytime. Signal to noise is usually so much better. /personal memo However we are entering the great RW [read-write] cooperative, collaborative epoch. Ideas and process having many roots in the world of [Open]software, networks of networks, virtuality [modeling/simulation/contemplation... in every order] These dynamics are now bubbling up out into social financial and political spheres [ah see - Pure Geometry purifies] meme-nets are thriving as never before My subversive proposal to you is along those lines. Optimistically, I imagined that maybe a VPython version of Blender is quite possible AND a good idea. The key paradigm is for a pure geometric minimal shell with live 3d viewer and modular architecture. small fast cheap beautiful user-controls I think using the Blender Python API it is possible to configure Blender to run as shell based Geometry [Game] Engine. You can ignore all the dancing girls and singing seals if you want. What you gain however may be like a laboratory for geometry [with physics::: particles, light, gravity, etc] Geometry meme - Kepler elipses - lead to orbiting planets. or geometry behind this http://en.wikipedia.org/wiki/Image:Milky_Way_2005.jpg And heres a video clip of experimental interface where minimal 2D geometry symbolizes physical mechanics [draw = think = link] [ancient Greeks making marks in the sand with sticks seashells and string] * MIT live drawing* http://www.youtube.com/watch?v=NZNTgglPbUA Won't be surprised if you tell me that you love it OR hate it :-) I understand why you don't want all the bells and whistles of Blender as it installs now. But if it turned out that all that stuff was in proactive very easy to turn-off ,and instead present a VPython face. Something installs well quickly cross-platform, how would you feel? Jason ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of vpython
On Monday 09 October 2006 3:59 pm, Dethe Elza wrote: On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote: My other hope for VPython would be to build it on a more capable 3D system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of such systems: http://www.vrplumber.com/py3d.py). In this scenario, VPython would be an easier entry point into one of these more capable (and correspondingly more complex) systems, an Ogre-lite so to speak. Here I finally get to strongly disagree. Vpython IMO should remain stand-alone, light-weight. Please, please. VPython is only lightweight conceptually. Boost and C++ are not lightweight, in my book. Again, I could only see it going this way if there was a library that was easy to install (so that VPython became easier to install than it is now), and that doesn't exist right now (not for the three main platforms). Just curious, is PyOpenGL easy to install for both Mac and Windows? I know it's dead simple on most Linux distributions. I think it's pretty easy for Windows, but have no experience at all on the Mac. All this is just hot air, since I really have nothing to do with how VPython goes. I also see it as a possible entry point to things like Ogre and Panda3d, but that is on a cognitive level, not a technical level. One interesting way would be to have a pure-python (on top of PyOpenGL?) VPython, and a higher performance VPython (maybe on Ogre), similarly to how there are now ElementTree (pure-python XML), cElementTree (higher performance), and lxml (same API as ElementTree, but really a portal to all the XML processing power of libxml and libxslt, i.e., much more powerful *and* higher performance). As a component to something either high-level and more heavyweight, or more low-level, I don't see a purpose to it. I doubt it does anything that Panda3d can't already do, and certainly nothing OpenGL can't already do. No comparison with OpenGL, since VPython (and all the 3D libraries I know of) already build on OpenGL. They add scenegraphs and higher- level APIs, but it's all OpenGL underneath. My dream would be to have a VPython that is as easy to learn as it is now, easier to install than it is now, and capable of growing with you for awhile. This is the reason for my above question. If PyOpenGL is easy to install then something pure Python on top of that should also be easy. Supposedly that solution will be too slow. That may be, but I'm not absolutely convinced. If Johnathon tried to implement VPython in Python using the existing VPython approach, the result would certainly be too slow. When I was working on VPython, I was struck by how much work it does that could nowdays be turned over to the graphics card itself. VPython is (at least was) not very OpenGLish, even though the final engine is OGL. In some of the VR work we're doing, we have models with over 200,000 polygons that render allowing for smooth real-time rotate and zoom all done in Python. A few hundred spheres should be a piece of cake. Maybe we can't dupicate the most intensive VPython applications, but it sure seems like we should be able to tackle the types of demos that come with VPython. Of course, this is all just hot air too. I would _love_ to work on this project, but I don't see when I'm going to have any time. So it's only a dream here as well. --John But right now that's just a dream. --Dethe Lao-Tse thought XML was verbose but that did not matter because computers will someday learn from poets. --unknown, via Jason Cunliffe -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of vpython
On Monday 09 October 2006 6:56 pm, Arthur Siegel wrote: On Mon, 2006-10-09 at 18:41 -0500, John Zelle wrote: Just curious, is PyOpenGL easy to install for both Mac and Windows? I know it's dead simple on most Linux distributions. I think it's pretty easy for Windows, but have no experience at all on the Mac. Assuming that PyOpenGL *is* easy to install, we come back to the same question - an OpenGL windowing context, be it pygame, be it wxWindows, be it togl, be it gtkgl, be it whatever one does on Mac. PyOpenGL provides the functionality, given a windowing context, not the windowing context. Right. But VPython really requires very little in the way of windowing context. I was thinking that GLUT (available by default in every OpenGL platform I've ever run across) would be sufficient. If PyOpenGL runs, GLUT is probably available. I have no idea off the top of my head whether a PyOpenGL + GLUT implementation of VPython is possible. To me, the main worry is how threading works across platforms. And since much of the cross-platform complexity of vpython is on the windowing context issue, I see that solving that issue for vpython is a more direct approach to solving the problem. But again, to me vpython begins to lose its charm if we have to assume wxPython installed, or pygame installed, or Panda3d installed. Togl across platforms??? Is Togl another dead end? Is anyone supporting it? Personally, I'm not all that excited with TK as a cross-platform solution anymore. It's been difficult to keep even my little graphics library stable on TK across Windows, Linux, and Mac. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Saturday 16 September 2006 9:35 am, Arthur wrote: John Zelle wrote: no, No, NO. I never said this. At least I didn't intend to. Please see the top of the message where I ask (virtually beg) for clarification on what you are saying. I thought you were saying that it's OK to teach programming in a math class, because it's being used there to motivate and illustrate mathematical concepts. no, No, No. ;) I am trying to say that some integration of algorithmics into required math education is eminently sensible. Among other things is a statement that computer programming - in some sense of the word - *is* for everyone. Despite all my silliness and freewheeling intelligence there being so much noise around these issues - I try to make sure any position I might try to advocate passes some basic test against common sense. I am satisfied this position does. And because I am satisfied it does, I don't feel the need for banners of any kind, for armies or - I would have thought - for confrontations. So I have always been confused why such an idea would meet with *any* resistance on a list such as this. It has from day one. Which has always been a clue to me that I had in some sense entered Chinatown, in arriving here. No - it ain't the Media Lab. It is modest. It is unconnected with Revelation, New Ages, and Second Comings. It brings us to no new dimensions. It actually brings no new great amount of stature to the geeks of the world, or to the software industry. It must be on the right track. And I can't see how any reasonable person could be against that, which I why I thought you were saying something else ;-). By all means, let's agree that teaching some programming as part of math is a sensible enterprise. But that's not happening at the moment, at least not around here. I don't see this as a reason to denigrate the computer scientists who are trying to teach intro to programming courses as another entry point into this important mathematical domain. If the students have not yet learned programming but have already learned basic algebra, then an introduction to programming seems the next logical step. There is no conspiracy of CS academia to keep programming out of the secondary schools. College CS programs are just dealing with the situation on the ground as we find it. Let me add just one more thought before signing off on this thread permanently. This undercurrent of introduction to programming as somehow being a poor way to teach programming is still bothering me. It _is_ true that mathematics is all about algorithms and CS has undeniable mathematical roots. But the vast history of mathematics is mostly about developing and using notations that are for use by humans (with some obvious attempts at mechanization along the way). The arrival on the scene of the modern general purpose computer is quite new. It seems to me there is still room for teaching math as math and treating the translation of mathematical techniques and algorithms into a fully formal system (a programming language) as a somewhat more specialized kind of mathematics, a subfield in its own right. I'm not arguing that it's the right or wrong thing from a practical perspective, I'm just saying it's not patently ridiculous. I am always suspicious of gurus who argue that there is one true curriculum. It always seems to me that they are quick to dismiss any course that doesn't contain their pet topic(s) as a waste of time. I can't even count now the number of times that I've been told my education was useless because it didn't include X, where X is some fashionable topic. Yet, my useless education has been incredibly valuable and worthwhile to me. In my mind, there are so many meaningful and valuable things to learn, that we can't possibly begin to pack them all into a single universal curriculum. Once you accept that premise, you realize the important thing is that students are learning _something_. If students are learning mathematical and scientific reasoning, they'll be able to apply those skills to pick up whatever specialized knowledge they need later. So if current math teachers are uncomfortable with teaching programming, I've go no problems with them teaching some math that they do know well and can communicate their passion for. And before I get boxed into another corner where I am not standing, I am not saying that reasoning skills are all that matter and that's what we should teach. I don't think those skills can be taught, per se. They are acquired through the process of learning about something. You can't reason deeply without some deep knowledge. My point is that there are lots of great things to learn about that will help develop those skills. I happen to believe a good CS program rooted in programming is one example of a fantastic curriclum for doing this. But of course, I'm self-serving in thinking that. I continue to be part
Re: [Edu-sig] The fate of raw_input() in Python 3000
A new twist on this thread: discussing the very nature of intro courses. Should we read more code and program less, should our programs build to something and not be a bunch of random scripts? I think it's obvious to everyone that a course that tackles real world problems will be more interesting than one that doesn't. But that doesn't mean simple scripts can't address real world issues. While it's true that the first programs are not polished applications, they certainly can solve real problems. It's also obvious that by the end of the course, students should have progressed beyond the simple script phase and be able to write programs that are truly intresting in their own right. A good class is one that can have multiple projects building toward some larger result. Of course, the downside here is that a project that really interests one student may be drop-dead boring to another. Notice that each of you is talking about how you learned by tackling a particular project that was of interest to you personally. It's hard to manage a class of, say, 10 different cumulative projects, although I frequently allow students to choose among several that I lay out for them. BTW, this focus on solving real problems is what keeps me from using an approach like Alice. As for spending more time reading programs and less time writing them, if anyone thinks this will interest and motivate _more_ students, I suspect that person has never actually tried to teach a class. It is success in writing programs that keeps students interested and motivated. There's nothing better than that Yahoo! when the program works. It's a battle to get students to read any code at all. I specifically chose not to box off code in my book to get students used to actually reading the code as part of the text, not as extra material. Typically students will just skim over larger program examples. Finally, all of us can learn a lot by reading others' code, but there is no substitute for actual programming to learn the full problem solving mindset and skills. Once again, most intro CS courses are not just about learning a language. That's a means to a deeper end, which is learning algorithmic thinking and problem solving. Imagine an introductory German class where the students were not asked to actually speak or write German. They might still be learning a lot, but it would not be nearly as useful. So yes, we want our students to be reading cade, especially good code, but I also want my students to be writing programs, lots and lots of programs. It's hard to appreciate what makes code good until you've written some bad stuff yourself. --John On Wednesday 13 September 2006 7:18 am, Arthur wrote: Peter Bowyer wrote: At 11:47 13/09/2006, Arthur wrote: I can imagine an introductory course that was in fact more a *reading* course than a writing course - that spent a good deal of its time analyzing the code of relatively straightforward, but interesting, working applications. The satellite view, before we attempt to descend to a finer resolution. That's a lot like how I learned to program. I bought a book (Professional PHP - nothing like an intro book!) and once I'd read some basics I went in and wrote a proper application - an ecard script, following the outline of Perl code that I'd read previously (without being able to write). That way I learned from someone else (apprenticeship) and wrote something that was *useful* when finished (encouraging me to learn). Myself as well. My first major Python project was simply a port of some Java code to Python - a 3d math library. Read/write - read the Java, write the Python. But in the end I had something actually useful, to an extent I could not possibly have accomplished at that point on a write/write basis. All this of course makes Open Source of central importance. It happens that the 3d Java library I wanted to port was not open - nice API docs, no source. Luckily someone in Japan had taken upon themselves to do a functionally equivalent Open Source version of the library, .i.e. creating functional source working backward from the API. As it happens, on a *read* basis, about the first thing one can expect to encounter and need to explain (maybe after the doc string) is the import statement. To me this feels exactly right. OTOH, a recent post on the Python3000 list - discussing the fate of raw_input() - re-iterates the position that an understanding of the import statement is something that belongs way, way down the road - in a way that was much to sure of itself, for my taste. That one point - where the import statement belongs, pedagogically - seems to in some way represent the quake line of different points of view. Bucky might recognize this fact as a symptom of a pre-synergistic stage of things. But one side or the other always needs to lose some surety in order to make a first move in the
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Wednesday 13 September 2006 10:22 am, Arthur wrote: John Zelle wrote: I think it's obvious to everyone that a course that tackles real world problems will be more interesting than one that doesn't. But that doesn't mean simple scripts can't address real world issues. But there is a basic, probably irreversible - anti-synergistic - evolution that seems to have occurred that has exasperated the problem. The peeling off of programming introduction to CS, and the peeling off of CS from everything else. I'm not sure I understand what you are saying in that paragraph. First, can you tell me what you perceive as the problem in this context? I also don't know what you mean by these various peelings off. Are you saying that the introduction to CS shouldn't be about programming or that CS isn't real world, or something else entirely. I'm just trying to get my head around what your basic premise is here. Seems to me that in order to tackle real world problems we should be working within a specific problem domain - as a starting point. Within a particular domain, it is more realistic to build in stages, to the point of getting to something useful - within that domain. I think everyone would probably agree that that's a great way to be introduced to programming. Just as using math to solve problems that are personally interesting is a great way to be introduced to mathematics. But computer science and programming share with mathematics this wonderful property (and curse) that they are very general and powerful tools. And in both fields there is an extensive body of knowledge developed that could be of use in virtually limitless domains. If every domain teaches its own programming, then we have tremendous duplication of effort, because the foundational principles are the same. It seems to me this is the exact same tension that exists between having your calculus taught by the mathemticians vs. having it taught by the engineering school and the business school and the music department, etc. There are arguments on both sides. My personal preference would be to have students exposed to calculus by the mathematicians who are not just users, but I hope, have and can convey a deeper understanding of the foundations of calculus. The mathematicians are the professional owners of that content. For many of us, introduction to programming is too broad a context in which to be introduced to programming. OK, so what counts as a domain for you. I could just as easily say for many of us introduction to algebra is too broad a context in which to be introduced to algebra. Similarly introduction to writing is too broad a context to be introduced to writing. I'm guessing that you think it's OK to count math as a domain and so to teach math classes and assume that students are learning math in their math classes, even though they can apply this knowledge in limitless other areas. Furthermore, one can easily make the case that these math students might be more motivated to learn math if they learned it in the context of those other areas of direct interest where they could build up a truly useful system of mathematics for their personal use. In the math/programming synergy at an earlier stage (not too early, please) strategy, the introduction course in the CS department evolves into something more than what it apparently needs to be now. We know a little, and presumably know we have an interest in knowing more than that. I _think_ I'm all for this, but again I'm not sure I know exactly what you are saying. If you are saying that students might get interested in programming through exposure in math (or some other domain) and then want to turn to CS classes to learn more, that sounds like a good thing. But it's still curious to me that the implied tone here is one of denigrating teaching introductory programming in CS classes because it is divorced from any domain and then at the same time suggesting the thing to do is teach programming in the context of math. Teaching a math class is teaching another tool divorced from any domain. Why is it good to teach algebra in math classes, but somehow wrong to teach programming in CS classes? On the contrary, if you consider math to be a proper domain, they why isn't my field (CS) a proper domain? I take a middle ground that says a good teacher can motivate programming both for its intrinsic beauty and for the utility it brings students to solve whatever problems are appropriate for their current interests and level of understanding. While my students may come from many different disciplines, there are problems common to their lives that we can talk about computer solutions to. Motivation to learn programming need not solely arise from domain specific interests. Kirby, it seems to me, is right about all this. It's just less brilliant to be right about this than Kirby sometimes seems to make it sound. It really
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Friday 08 September 2006 4:27 pm, kirby urner wrote: On 9/8/06, kirby urner [EMAIL PROTECTED] wrote: You're not making a monkey out of your mom, by making her loop through some little menu, oblivious of the language underneath, its logic and design. You're protecting you mother (aka paradigm end user) from knowing *anything* about Python. That's your goal, that's the whole point (i.e. end user = not a programmer). Just to clarify: I think it *is* condescending to newbies to force them through a lot of raw_input scripts, since this is: (a) not state of the art from and end user's point of view nor is it (not GUI) This is like saying that Physics students have to start with General Relativity and Quantum Mechanics, because those are state of the art. No one is denying that it's good to teach GUI programming at some point. Is that the simplest way to introduce programming? My learning philosophy is to always search out the simplest thing that illustrates the principles I want my students to learn at the moment. Anything more complex is just adding noise and complicating the learning process. (b) not state of the art coding for self idiom (which'd be more shell interactive) While I accept the power of twiddling in the shell particularly as an educational tool (again, I come from a Lisp/Prolog tradition), this statement is just silly. How can you define state of the art for any self but your own. When I write a script to automate some routine task, I virtually always use interactive text input. Why? Because the whole point is to make something routine and automatic. Why would I write a program that forces me to: Start Python Import a module Recall what I'm suppose to invoke and what information it needs. Instead I can write an incredibly simply script that I just click on, and when it needs information it prompts me for it. That's _my_ state of the art in programming for myself. And it's something I can teach students to do for themselves in very short order. Whether I'm writing for myself or whether I want my students to be able to write the simplest possible useful programs for themselves and others, that involves textual input. I'll say it one more time: IO is fundamental to programming; the simplest universal form of IO deserves to be in the core language so that it is easily accessible and available everywhere the language runs. Pascal got that right and Python (pre 3000) has it right. As teachers, we shouldn't be propagating the hidden assumptions that go with raw_input, i.e. that there's this class if people out there too dumb to know anything about namespaces or functions. Translate this to any other discipline. Running with my physics example: As teachers, we shouldn't be propogating the hidden assumptions that go with Newtonian mechanics, i.e. that there's this class of people out there 'too dumb' to know anything about quantum physics or general relativity. Does that really make sense? The fact that there is more advanced stuff that they will surely learn in due course is in no way a justification for not teaching simpler, useful concepts first. I'm saying this'll all be common knowledge soon. Define soon. I see the same demographic as Brad Miller. My students are freshman in college who have never programmed. And frankly, I'm OK with that. We'll know about 'strings' just as surely as we know about 'numbers'. Why? Because computer literacy is not just for some tiny inner circle. It's just basic fluency. Like my friend Gene Fowler puts it (paraphrasing): any poet worth his or her salt should know about XML already. http://controlroom.blogspot.com/2006/08/more-cast.html None of the poets I know care a twiddle about XML. I guess we just move in different circles. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Saturday 09 September 2006 12:35 pm, you wrote: snip But mostly I'm advocating going to the other extreme: drop GUI as a topic and just code up a namespace, reach into the grab bag for functions, like f(x) or cos(x). We pretend kids don't have the background, but if they did *any* work with a TI calculator or an algebra course, they know about functions, at least tacitly. My prerequisite for my Saturday Academy class is algebra only, and typing above 30 a minute really helps (a lot of 'em are getting that from chat rooms these days, buy a typing drill for home). As I said below, I'm all for this kind of interaction, and when input and raw_input go away, I'll probably do more of it. While I accept the power of twiddling in the shell particularly as an educational tool (again, I come from a Lisp/Prolog tradition), this statement is just silly. How can you define state of the art for any self but your own. When I write a script to automate some routine task, I virtually always I can define it for my gnu math teachers, the people I work with in South Africa for example. This, of course, misses my whole point that you can't define state of the art in programming for self for others (me, for example). use interactive text input. Why? Because the whole point is to make something routine and automatic. Why would I write a program that forces me to: Start Python Import a module Recall what I'm suppose to invoke and what information it needs. Sounds like your program is one of these top-to-bottom glued-together script thingys. We don't teach that way. Modules are grab bags, perhaps containing rich data structures (lat/long dictionary say). Modules define namespaces, like boxes of chocolates (Forest Gump understands). First up, I was not talking about the way I teach, but the way I program to automate my environment. To use your terms: defining state of the art in programming for myself. Your model is less convenient for these tasks than the one I describe. Further, I highly doubt that the script I'm writing for those purposes are any less modular than they should be to get the job done. Namespaces are a wonderful tool (which I use liberally), but don't confuse being modular with being good. There's plenty of bad modularity too. This need to glue it all together with some main() -- why? We compete with that idea of programming. We're not a part of *that* particular conspiracy. Umm, the point of my program is to automate something. That's why I glue it together. If I don't do that, I haven't solved the problem I set out to solve. I'm only 'conspiring' to solve the problems I have at hand. Last week, we were working on phi and the fibonaccis. Let's get back to that now. Pull out a file drawer (import) and behold: all our favorite specimens (even the bugs are back). Great. Fantastic. It has nothing to do with what I was describing. I have plenty of these experimental evnrionments as well. Instead I can write an incredibly simply script that I just click on, and when it needs information it prompts me for it. That's _my_ state of the art in programming for myself. And it's something I can teach students to do for themselves in very short order. Yeah, we don't like that style. OK for you, works for your students, I think you're probably a dynamite teacher. But... we still don't like that style. Again, I'm talking about writing a useful tool to automate some mundane task. What's not to like about that style? Should I make automating that task harder so as to fit your pedagogical style? My arguments had nothing to do with how you or I go about teaching math. Later on maybe, if/when they're committed to CS. But this is just basic numeracy here, and they already know about functions from calculators. import math math.cos( 90 * math.degrees) -- that's what a first class might include. If what stops 'em isn't the Python syntax, but the trig, then we go over the trig. Basic numeracy. All as a bundle. Not your grandfathers math class (but some hoped it'd be for their kids -- remember when the future was, well, futuristic?). Again, this sounds great. I like it, and I'm glad you're doing it. And you don't need raw_input (or input). But having input available in no way impedes this, and for the tasks I'm describing, lack of the same is a hindrance. Whether I'm writing for myself or whether I want my students to be able to write the simplest possible useful programs for themselves and others, that involves textual input. I'll say it one more time: IO is fundamental to programming; the simplest universal form of IO deserves to be in the core language so that it is easily accessible and available everywhere the language runs. Pascal got that right and Python (pre 3000) has it right. And I'm saying using the shell to trigger namespace events is (a) closer to what a GUI is doing and (b) is fully
Re: [Edu-sig] The fate of raw_input() in Python 3000
First up, I support the petition/ suggestion whatever you want to call it. I'm somewhat disappointed that our discussion here seems to have gotten derailed by Arthur's comments that it's all about ease of teaching. I think I put forward a number or solid arguments about IO being core to programming and the expressiveness of input/raw_input that no one has bothered to address. Whether you want to teach import day 1 is only one small point in the discussion as far as I'm concerned, and that seems to be the only point that is picked up in certain circles. Anyway, I also strongly support keeping the input statement, and I have to respectfully disagree with the comments below. On Thursday 07 September 2006 8:49 pm, Andre Roberge wrote: On 9/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [Does this capture the essense of the discussion? I know some said that they don't use them, and this would not stop them from not using them :) -Doug] Since I raised the issue in the first place, I'll just mention again one additional point I raised which may have been overlooked. It is generally recognized that input() == eval(raw_input()) is not safe and therefore not a good example to give to beginners. Furthermore, in the context of teaching, input() is, I believe, primarily used to extract a number from a string. Thus, I would suggest that input should be replaced by something like def get_number(prompt): s = raw_input(prompt) try: n = int(s) except: try: n = float(s) except: print s + is not a valid number. return None return n There is _nothing_ untoward about allowing a beginner to use input as is. Input is most easily conceptualized as allowing a user to type an expression at runtime or as I like to call it a delayed expression (see earlier post). It's very easy to grasp that in a program I can write x = 3 or x = foo or x = [1,2,3]; if I want to replace the righthand side of that statement with input at runtime, I just do that: x = input(Enter a value for x: ). In other words, I am letting the user write the code. That's a simple concept; saying it's dangerous is just making the statement that programming is dangerous. Of course it is! But that's exactly what we're giving our students the power to do: be dangerous by programming. This proposal strips input of much of its power. I use input to get all kinds of data, not just numbers. It's a very expressive feature of Python, and it happens also to be padagogically useful. Proposals that turn input into some typed scanning statement ala Java (or C or C++ or Pascal) rob it of it's dynamic nature and make it unpythonic in my book. Python is a dynamic language, let's keep dynamic input. I am more comfortable with Ian's proposal to only allow Python literals (not expressions), but now you've made input more complicated by putting restrictions on it. Why can't I enter exactly what I would put in the assignment statement if I were writing the code? I often fire up Python, type a little loop and use it to evaluate expressions as a calculator. Perhaps I am tainted by my association with languages such as Lisp and Prolog that are beautiful for experimentation because they allow the freedom to intermingle programs and data. I would really miss input as a day-to-day user of Python, not just as an educator. I will have to carry my custom IO module with me and load it on every Python 3000 bearing computer I come across. What a pathetic waste of my time that will be. --Johnny Inputseed ps. That's my last entry on this thread; I've got more pressing things to worry about right now. See Arthur, I do understand it's not a life or death issue :-). Otherwise, while I am not using Python in a classroom, I certainly agree with the summary below and support it. André Core Python maintainers, Over on the Python edu-sig, we have been discussing a small aspect of PEP 3100 and its effects on teaching and classroom use. What is at issue is input() and raw_input(), which have been targeted for removal, and marked [done]: http://www.python.org/dev/peps/pep-3100/ Guido suggested in his 2002 Python Regrets talk that eval(sys.stdin.readline()) and sys.stdin.readline() can be used for these, respectively. That's not quite true of course, because they also have a prompt. But even that aside, we believe that we would like to keep them as-is. I think that we have consensus among (the teachers of edu-sig) that many of us rely on the ease-of-use of the input() and raw_input() functions for one simple reason: input() and raw_input() can be used on day-1 of class, before discussing imports, streams, strings, eval, or functions. Complete replacement solutions require discussions of all of those topics. We believe that their removal goes against the spirit of Python in the classroom, and Python will be
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Wednesday 06 September 2006 8:00 am, Arthur Siegel wrote: Being dispassionate on the issue itself - I have *never* used raw_input() and, as it happens, I am generally literate enough at this point so that the intentions of sys.stdin.readline is *clearer* to me than is raw_input() - I am disturbed by the tone of the discussion. Guess I prefer the all-in-the-family temper tantrum, then the calm and dispassionate threat - explicit or implicit. I have no idea what you mean here. Speaking only for myself, I am simply stating that a language that requires me to use an extended library to do simple input is less useful as a teaching tool than one that does not. I also gave arguments for why, as a programmer, I find it less useful. You have not addressed those arguments. I guess I view it also as an example of the result of Python promoting itself to the educational community in the wrong way, and on the wrong footing, from day one - as the easy alternative, rather then as the literate and productive alternative, the *best* alternative for getting a certain class of problems solved in the least circuitous way. So you are saying it's less circuitious when writing a simple script that needs a bit of user interaction that I have to include an import statement and split a single logical operation (asking a user for input) into two steps: first printing a prompt and then calling on my imported library to do the input? I can't say as I follow that logic. To me, one of the beauties of Python is how it mirrors the way I think about algorithms and how I teach my students to think about algorithms. Get a number from the user is a primitive operation in my thinking, having a built-in that allows this makes for a straightforward translation from thought to code. That's efficent both in terms of programmer productivity and student learning. In particular, the kinds of real world problems a student might want to solve or explore. Again, I would like to see the distribution breakdown of this feature in extant code. I think it is widely and heavily used because others view it as I do. That's the real world of problem solving. My _point_ is that input and raw_input meet exactly this criteria, it helps students to directly solve or explore the types of real-world problems that new programmers often want to solve. Since sys.stdin.readline seems to me *more* literate, I'm OK with it. First up, you ignored my note pointing out that this is not equivalent to raw_input, as I have to type another line of code for the prompt. You also ignore the fact that you must import sys in order to use this. If by more literate, you mean less convenient to use, then I agree with you. My deeper philosophical point is that operations essential to computing (input and output) should be part of the core language, not things that are imported from the library. That's just as true for plain old programmers as it is for teaching. And will maintain my apparently cloistered, unreal world view of how a motivated student might want most to be approached, and her fragility. Just because a motivated student can (and should be able to) learn something is not an argument to go out of our way to put up hurdles, no matter how small, to their learning. Both input and raw_input are part of the language now (and always have been). Many of us in education see them as being useful to new programmers and real world programmers and are outlining our reasons for such. If you want to convince us otherwise, then you should have a reasoned argument about how this incompatible change significantly _improves_ the language for solving your real world problems. I don't really think this particular case fits your model of promoting Python for the wrong reasons (a case I generally agree with). Of course, I'm just a unreal ivory-tower academic, feel free to dismiss my opinions regardless of the reasoning behind them, pedagogical or otherwise. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Monday 04 September 2006 11:03 pm, Toby Donaldson wrote: I don't care about input. Its there now and hasn't ever been useful to me (eval(raw_input(...)) is a fine alternative), and, more importantly, has apparently not caused confusion among students. Again, for similar reasons to those being mentioned, I would like to keep input as well as raw_input. From a pedagogical perspective, it's best to meet students where they're at. Most of my students have studied algorithms and computation before, but in the context of mathematics. The most straightforward way to start them out is to take their math background and turn it into programs. This has the additional motivation of taking some of the drudgery out of the math. Given that starting point, it's very natural to write programs that get a number from the user. That's what input allows us to do, it interprets any literal (more generally, expression) provided. Forcing them to use eval(raw_input()) requires introducing strings as a data type, if they are to understand it. While strings are simple and easy to introduce early, they are not as intuitive to my students as numbers. They have never manipulated strings before. They've been crunching numbers since second grade. Numbers, then strings is the natural progression. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of raw_input() in Python 3000
On Monday 04 September 2006 8:56 pm, Dethe Elza wrote:
On 4-Sep-06, at 5:45 PM, Andre Roberge wrote:
The following is something I have been pondering for quite a while now
and am wondering what other people on this list think.
According to PEP 3100
(http://www.python.org/dev/peps/pep-3100/ )
raw_input() [as well as input()] is recommended for removal from the
built-in namespace, to be replaced by sys.stdin.readline().
But it is trivial to add this back in:
raw_input = sys.stdin.readline
This is simply not equivalent. readline does not take a prompt as an argument.
You'll have to write the function.
While I don't think anyone can argue that this removal makes a major
difference for Python as a programming language, I believe it makes a
significant difference for using Python as a learning language, adding
a non-trivial barrier to learning.
Removing this from built-ins isn't going to be any more confusing or
off-putting than trying to understand the difference between input
and raw_input in the first place. I remember being tripped up by
*that* when I was first learning Python.
My hunch is that your confusion came because of your experience with other
languages. Having an input statement that evaluates just like what you type
into the code is a _wonderful_ teaching tool. An input is just a delayed
expression. value = input(Enter an expression: ) where the input is 3+4*5
is just like the line of code value = 3+4*5. Students find that very easy to
understand.
Consider the following fake sessions at the interpreter prompt, where
I use extra parentheses to turn print as a function (as is also
proposed in Python 3000) - these parentheses can of course be used
with today's Python.
The standard prompt is great, but not the best learning environment.
I would recommend that students use IPython instead, and since
IPython already adds lots of convenience methods to the global
namespace, there's nothing to stop it from pre-populating globals
with input and raw_input.
Sure, there are better learning environments. But the standard prompt is _the
sole arbiter_ of what _Python_ actually does. Whenever you want students to
figure out a feature of the language, the interactive prompt is the way to
go. Let's see how Python interprets that. Using some other environment with
built-in defs is not giving you Python.
That is:
1. It isn't necessary for global functions at the command-line prompt
to be in builtins
But it's useful. See my message that passed yours in cyberspace.
2. It possible (and desirable) to have different command-line prompts
for different purposes
sure.
3. It isn't necessary to clutter the builtins with every convenience
function, even if we're used to it
Built-ins should not be cluttered with _every convenience_, but requiring an
import to do _any_ input is silly. Input is not a convenience, it's virtually
part of the definition of a useful program.
Now, all that given, I do hope Python doesn't start going down the
road that Java has taken and replace
open('myfilename.txt')
with
open(BufferedStream(InputStream(FileStream('myfilename.txt')
This looks like a step in that direction to me. I would like to see a Zipf
diagram that shows an analysis of the prevelance of various built-ins in
extant Python code. I'm betting input has been used over the years as a core
feature. It's part of what makes Python Python. While we're at it, isn't
opening a file something that really happens at a system or OS level? Perhaps
it should be something like:
files.PythonFile(os.open(BufferedStream(InputStream(FileStream('myfilename.txt')
Why should file opening be any more of a convenience than asking the user
for input, after all?
but I don't think the loss of raw_input is quite on that scale.
It may not be on that scale, but it would certainly cause me to survey the
language landscape again to see if there are better languages for teaching.
I/O is a core concept in programming, period. Don't make me introduce
extended libraries (via import) in order to teach a core concept.
--John
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer ScienceWaverly, IA
[EMAIL PROTECTED] (319) 352-8360
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] What was that syntax again?
Is this what you're looking for:
d = dict(key1=52, key2=12)
d
{'key2': 12, 'key1': 52}
Of course this only works for keys that are strings.
--John
On Tuesday 15 August 2006 1:28 am, kirby urner wrote:
Someone (Dethe? Ian?) showed me syntax I'd never seen before around
Python dictionary defining, involving an equal sign I thought. Tried
searching my gmail, other things. Maybe faster to just ask: what was
that syntax again?
Kirby
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer ScienceWaverly, IA
[EMAIL PROTECTED] (319) 352-8360
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Smalltalk syntax benefits
On Thursday 10 August 2006 10:24 am, Paul D. Fernhout wrote: What about constructors like Line origin: 10 @ 10 angle: 35 degrees distance: 10 mm (which is easy to have in Smalltalk syntax) and so on? And I bet you can read what it means not even knowing Smalltalk. Would you rather read: Line(10, 10, 35, 10)? Or at best: Line(Point(10, 10), 35, 10)? Which is clearer? I think this goes beyond my bias as being experienced using Smalltalk system keyword syntax. Not to be too hard on you or Kirby, but I think it is easy to not see the value of the unfamiliar, and there is a lot functional foo() syntax makes difficult and awkward looking (Lisp, a Python ancestor in a sense, has a bit of this problem too). Again, just because Smalltalk has this and Python does not does not mean I'm saying use Smalltalk. I'm just saying, how can Python get this feature? Maybe it can't. Then my next thing is, can the two syntaxes live side by side -- a possible area for exploration. Just so we're all clear on this, you _can_ use keyword arguments in Python. So your constructor could just as well be: Line(origin=Point(10,10), angle_in_degrees=35, distance_in_mm=10) Of course, Python only allows this, it does not force you to use such a style. To me this is at least as descriptive as the SmallTalk version. Perhaps it says something that Python allows this form, but it does not seem to be used often in practice, except when there are large numbers of mostly default-valued parameters. Perhaps the reason is that the keyword form _requires_ more typing (lowering productivity) and the labeling of the arguments (revealing formal parameter names) is pretty much provided by any IDE that is worth its salt. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] digits of pi
Here's a generator I coded up based on a paper by Gibbons: http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/spigot.pdf It's simple to code, but I think you have to read the paper to figure out what it's doing. (I just translated some code, so I really can't tell you :-) In the paper, this was done in a lazy functional language. I was mostly interested to see how it would translate to a Python generator. # pi.py -- imlementation of Gibbons' spigot algorithm for pi # John Zelle 4-5-06 def pi_digits(): generator for digits of pi q,r,t,k,n,l = 1,0,1,1,3,3 while True: if 4*q+r-t n*t: yield n q,r,t,k,n,l = (10*q,10*(r-n*t),t,k,(10*(3*q+r))/t-10*n,l) else: q,r,t,k,n,l = (q*k,(2*q+r)*l,t*l,k+1,(q*(7*k+2)+r*l)/(t*l),l+2) Here it is in action: import pi digits = pi.pidigits() for i in range(30): print digits.next(), ... 3 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4 3 3 8 3 2 7 Since this uses long ints, it slows down considerably after a few thousand digits. You might want to use psyco when generating really deep digits. --John The On Thursday 27 July 2006 8:27 pm, Tim Peters wrote: [Michel Paul] When a student first sees Long integer capabilities a question often is How many digits of pi can it show? There's a slight disappointment when they find out that though there's a Long integer, there is no Long decimal. The newish `decimal` module has user-settable precision, although it's more educational to use integers. See the pi() function at: http://docs.python.org/dev/lib/decimal-recipes.html I would like to be able to show them a good way to compute a list of an arbitrary number of digits in the decimal expansion of of pi. I think they might find that interesting. See the very old Demo/scripts/pi.py in a Python distribution -- it's one of the first things Guido coded in Python. Although I'm considered a numerical expert, I still have no idea how it works :-) An enormous number of ways you /could/ proceed: http://mathworld.wolfram.com/PiFormulas.html ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Setting a variable's value
On Thursday 11 May 2006 16:19, you wrote: snip We're straying a bit from the original thread here, but I couldn't resist this comment. Ergo my point: I don't look to mathematicians to tell me how to write math, but to computer scientists such as Kenneth Iverson. Although sure, I'll take suggestions from math PhD peanut gallery. I believe Iverson used = to mean equals (as God intended it) and used - (an arrow) to mean assignment. He knew enough not to mess with a perfectly good existing notation :-). --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] PySqueak: more on the cultural divide among paradigms
On Saturday 06 May 2006 11:40, Winston Wolff wrote: On May 6, 2006, at 11:25 AM, John Zelle wrote: To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal. snip But I'd like some clarification on what this goal is. It seems like a lot of people are talking about lots of cool technology, but I've not read what we are trying to do with it. And of course we wouldn't want to build a technical solution in search of a problem. Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project? If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system. Kirby has already weighed in with his grand vision. My goals are much more modest (though not necesarily in opposition). Winston is right that there are lots of great tools available now, an embarrasment of riches so to speak. We can and should plunge ahead with educational materials. Still I have an itch that is currently not scratchable, and I think requires reinventing the wheel. I am looking at Python as a learning environment for computer science, as a platform for building compelling educational material (e.g., bringing VR to the classroom), and as a sandbox for all kinds of experimentation. Here's what I don't have now: 1) An easy to use 3D environment (ala VPython) that is extendable in Python. When I need realistic materials or textures, I want to be able to add that without having to wait for the C++ gurus to put it into their library for me or having to wade into that muck myself. 2) A solid, easy to program cross-platform GUI toolkit that integrates with #1. I cannot now reliably develop, say, on Linux and expect that my students with various flavors of Windows and Macs will get the same experience. Educational apps/IDEs/enviroments need to be rock solid, snappy, and consistent across platforms. We really don't have that now. There are always extra layers and external dependencies that get in the way. Maybe PyQT4 will solve this one? 3) A simple to use GUI builder (ala Visual BASIC, but more basic ;-) for #2 to take the tedium out of widget placement. 4) For CS education (and all those interested in knowing how computers really work), it would be great if the Python graphics stack went all the way down to the machine (actually OpenGL) level. Like Squeak, but using hardware acceleration. Then everyone has a ticket to play just by learning Python and showing some curiousity. Can we program a modern 3D game, for example, in Python? Or is knowledge of C++ the price of admission. I don't know, and I'd like to find out. I think #4 is where I part company with Kirby. I'm not looking for some machine-level 3D libraries that are scripted via Python (or another high-level language, ala Alice). I want the snake all the way down, and I want the underlying graphics engine to be installed everywhere Python lives with OpenGL, so that I can count on it. I know I'm asking a lot, but I also think it's all doable. This to me would be the foundation for a better than Squeak Python environment. The saving the state issue seems secondary to this basic foundation. How can we even talk about saving the state of widgets that we don't own. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Don't kids program anymore?
This has been an interesting thread. I haven't had time to contribute, but I saw something here that I felt I had to address. On Sunday 30 April 2006 14:47, kirby urner wrote: On 4/30/06, Michael Tobis [EMAIL PROTECTED] wrote: Most kids, most humans in general, will voluntarily spend many hours in such environments. The game industry proves this. That the graphics are amusing is secondary to the design of interesting vs dull games. What keeps games interesting is that they stay near the optimum flow point between triviality and frustration. This impulse can and should be channelled toward useful skills. mt I'm glad you mention REWARD. Many of us share this vision: find a way to disburse credits via distance education circuits such that those putting in the hard work of actually learning this stuff actually get rewarded, and not just in heaven, but on this very Earth as well. You'd think it wouldn't be so hard, given ample precedents, including clippable coupons or ID specific promotionals (e.g. use this code for a free subscription to...). We need to be very careful about rewards in this context. A lot of psychological research suggests that once a person is paid for doing something that is fun to them, it ceases to be fun and they tend not to do it anymore unless they are paid. One of the real problems in our educational system is that we unwittingly train our students that everything should be done for external rewards (a good grade now, a better job later). Learning becomes something to be done for external reasons, rather than doing it for the joy of learning itself. That leads to all sorts of negative outcomes (rampant cheating is one). In a video game, the compelling reward is simply being good at the game. In learning to program, the reward should be the sense of accomplishment and empowerment that comes with mastering a bit of that craft. I fear that any other type of reward is counterproductive in the long run. As soon as you start making a return (maybe not in terms of cash, but in terms of barter, which eCommerce makes easier), the school space gives way to the work place i.e. they're paying you instead of you're paying them -- or at least it's more of a 2-way street. Relevant: http://worldgame.blogspot.com/2006/04/computer-lab-as-playground.html Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] How to Think Like A Computer Scientist
On Tuesday 28 March 2006 09:42, kirby urner wrote: So we have different levels of mutability. A complex type which doesn't allow resassignment of real and imaginary parts might look like: Immutable: c = Complex(1,2) c = c.real(3) # assigning a new value c = c.imag(4) # yet another new value Actually is a mutable version. Allowing the change to the components after creation makes it mutable. It does not matter if the change is through mutating methods or by direct attribute access. The point is that the object itself changes. If two variables reference the same object (or two threads manipulate it) they will both see the changes. An immutable complex would simply disallow changes. To change either component would require creation of a new object. Mutable: c = Complex(1,2) c.real = 3 c.imag = 4 Even more mutable: c + c # changes c to 2c c**2 # 2nd power of c (changes c in place) All are codable in Python of course. Of these three possibilities, my own bias is in favor of the least mutable (top example). Arthur is proposing first level mutability (2nd example). I doubt any of us like the 3rd level. Am I right? Note that Python's built-in complex number doesn't even allow the top example. Instead, one might go: Even more immutable: c = Complex(1,2) c = Complex(3, c.imag) # assigning a new value c = Complex(c.real, 4) # yet another new value So obviously there's a spectrum here. Python supports them all, with coding. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Since my name was invoked recently on this thread (albeit with a question mark), let me try to summarize: We all agree that mutability introduces interesting issues, particularly in the face of true concurrency. Language designers are very interested in languages with semantics that avoid or minimize these problems. As a Prologer at heart, I'm a big fan of unification semantics myself. I think we all also agree that Python is an OO language, and as such it institutionalizes side-effects. OO is not functional, it is not single assignment, it is not dataflow. It is a different computational model, and one that makes use of mutable objects as an inherent feature of design. We use objects to enacpsulate changeable state. When designing a system using OO, I as the designer make choices about what types (mutable vs. immutable) make the most sense for my design. That evaluation involves issues such as efficiency, maintainablility, and elegance. I understand Arthur to be saying: In my design, a container for a complex that masquerades as a complex is a good and useful type. Without taking a detailed look at his code and the design ramifications of that choice, I personally have no basis for saying it's a bad decision (or a good one, for that matter). He is aware of the risks of mutability and has decided his design criteria still calls for it. Even though I'm a CS type (sometimes that's a pejorative here, I know), Arthur has my blessing to use the tools of his chosen paradigm (OOP) to solve his problem in an elegant way. If that's all he's looking for, then we can close the thread :-). BTW, I have also found this discussion very interesting, if not particularly helpful for Arthur. --John On Thursday 23 March 2006 10:00, Laura Creighton wrote: In a message of Thu, 23 Mar 2006 16:24:39 +0100, Grégoire Dooms writes: Arthur wrote: -Original Message- From: Laura Creighton [mailto:[EMAIL PROTECTED] And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-) Sorry - I suspect everyone else is quite done with this, but I'm still bothered by mixed signals. I would like to be able to present PyGeo as good, sensible code. Not M useum Quality, to be sure. But good and responsible. There is an implication in what you are saying that I am still off the mark. Perhaps I am. But its not fair, in my mind, to throw that at me knowin g that it still has not gotten through to me (and Zelle ?) in what way I am off the mark. For the life of me I don't see the problem. My class has 2 __slots__ - .real and .imag. It does with them the kind of things that classes do. How is this class different and less thread safe than an infinite numbe r of other classes that do with attributes the kinds of things that classes do with attributes? This is a complex matter and I'll try to give a very short (hence a little categoric) answer. First of all, IMO Laura was referring to several thousands of lightweight thread such as those found in the Oz/Mozart language (http://www.mozart-oz.org). And that is because we have had a PyPy/Oz sprint two weeks ago where we made plans and prototypes for the integration of some ideas of Mozart into PyPy (mostly logic variables, search, and constraint programming, micro-threads were already on the g o). In that language stateful datatypes such as mutable objects are an exception. By default the variable store is a single assignment store. That means when you create a variable (e.g. with this statement X=_ ) it is uninitialized (called unbound). Then when you assign it you cannot rebind it to an other value: X=4 works but if you do X=5 later you get a sort of exception (failure). In a sense = does not do assignment but true mathematical equality (called unification). So you can do 4=X as well as 1+X = 5. The language supports very lightweight threads (having a million of those is no problem), when they try to use the value of a variable , they block if the variable is unbound. So you can launch inter-dependant threads accessing values computed by each others without wondering about the synchronization. That is called dataflow concurrency. In a sense, your mutable complex object is opposite to that approach where (almost) all variables never ever change their value. I have unintentionally stimulated a CS nerve, apparently. But would s till love to get to the bottom of issue. HTH :-) Or get an official CS - proper use case aside - bill of health. I would refer you to the CTM book: http://www2.info.ucl.ac.be/people/PVR/book.html You will find there lots of interresting ideas about computer language semantics. Best,
Re: [Edu-sig] Properties use case
On Saturday 18 March 2006 16:39, Michael Tobis wrote: So, is there a problem with wrapping them thus: ### class mcx(object): def __init__(self,val): self.val = complex(val) def __add__(self,other): and similarly for most other special methods return self.val.__add__(other) ### This reminds me of a question I have with new-style classes. With classic Python classes, we can do something like this even more simply with getattr magic: class Mutable: def __init__(self, value): self.value = value def __getattr__(self,name): return getattr(self.value, name) This saves me the trouble of having to specifically reimplement all of the methods just so that I can trivially pass the work off to self.value. Everything works just fine: from mutable import Mutable x = Mutable(3+5j) x (3+5j) x + (4+7j) (7+12j) print x (3+5j) x.value = 3 x + 4 7 I've used this technique to good advantage when mixing objects from different toolkits. My question is, is there an easy way to do this with new-style classes? While I'm on the thread, let me just add my 2 cents on Arthur's creepy mutable complex type. I understand all of the arguments about the potential pitfalls of mutable types (I'm one of those CS types, don't you know :-). But OOP is all about mutable objects. As a _design_ decision, if a mutable complex will streamline my system, or make it more intuitive, then I wouldn't hesitate to do it. I think the creepiness here is just in the name. We don't expect complex numbers to be mutable. Let's call the new type a complex container with auto-unboxing. Does anyone object to a mutable container? I hope not, we used to just call them variables. Since the contents are isomorphic to complex, it could be handy to have the container object also duck-type to a complex (or whatever else it contained). I don't see any creepiness in that. Of course, this kind of thinking could get out of hand. The next thing you know people might use these to simulate wacko things like reference parameters (oh, the horror! :-) Just my 2 cents. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] IDLE wish (was Edu-sig Digest, Vol 31, Issue 16)
I also like the simplicity of lightning, but it would need some enhancements before I could imagine using it in class. For example, it doesn't seem to auto-indent and requires typing the filename on a save. I'm sure it would not be hard to tidy up those things. I'd also like to handle multiple open files. I noticed on my system (Linux, Kubuntu 5.10), lightning plays well with my graphics.py library, but it seg faults if I try to use VPython. I don't think I would switch to an environment that doesn't play well with VPython, and I'm afraid that VPython is pretty closely tied to IDLE. Anybody know why packages like lightning and SPE (both wxPython) don't seem to work with VPython? Eric (QT-based) seems to work fine. On Wednesday 08 March 2006 14:54, Brad Miller wrote: I just downloaded lightning and took it for a spin. Its really very nice. The simplicity of IDLE is one of the keys to the success of Python in our introductory CS courses. But students do have a bunch of trouble with IDLE on windows. I like the fact that the traceback pane pops up right under the editor pane when you run a script and hit a problem. Regarding the 'batteries'. What if we, as a community of educators using python, did something like the Enthought or MacEnthon people and created our own 'batteries included' distribution of Python. Students and other interested parties would have one stop shopping to get all the Python they needed to use python for learning computer science. What packages would we include? This is an interesting question. I think this idea of an educational distribution has been kicked around before. For those of us in the Linux world, installation of the major non-standard tools is pretty simple. I can just apt-get install the vast majority. For students with Windows or OSX, it's not as simple. I wonder of the cheeseshop and ez-install tools will eventually make it all pretty easy regardless of platform. --John Andre Roberge wrote: On 3/6/06, Vern Ceder [EMAIL PROTECTED] wrote: It might be useful for teachers in a classroom situation. It is available from rur-ple's sourceforge page: https://sourceforge.net/project/showfiles.php?group_id=125834 On the down side, it does require wxPython which is not an included battery! André Vern -- This time for sure! -Bullwinkle J. Moose - Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 [EMAIL PROTECTED]; 260-436-0746; FAX: 260-436-5137 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Low Enrollments - programming as anti-intellectualism
Kirby Urner wrote: I think there's a shortage of computer pros with strong presentation skills. Like, at Europython we got a 5 minute upbraiding by one of the few female geeks, complaining that we collectively mumbled too much, failed to project our enthusiasm for our topics. We must do more to delight, less to impress. Actually, there is a shortage of _people_ with strong presentation skills, period. Computer types are no worse than the rest of the population in my experience. snip here, Toby's call for service courses in software engineering Probably the only way to push CS departments into offering such courseware is to compete with them. Small technical academies, like those mom and pop martial arts schools that dot Greater Portland, could specialize in various skillsets. Mom, I've off to a Plone class at Free Geek, then a C# class at the mall, then a movie! OK dear, don't forget to take your cell. Academia has this clever way of setting up a lot of prerequisites, getting you involved in this twisted maze, with degrees the cheese. With the new certifications though, you can get a black belt in something, without getting bogged down in somebody else's bright idea of what competent means. That's what a of geeks want: freedom to customize and configure. Of course the Internet itself is the best place to start. Hopefully academia is not now and never will be about certification. They fill very different needs. Academia is about exploring the potential of mind in all directions. It's the place to go for truly broadening (in the sense of character and worldview) and deepening (in the sense of critical thought) experiences. That's why academics value scholarship so highly, even though outsiders may see it all as silly games. It's the one place in the world where students can be immersed in the exercise of reason and free inquiry with a minimum of distractions. Academic education is about fostering a mastery orientation where new challenges are met with determination and excitement. Certification, while valuable, is about demonstrating proficiency in some particular, narrow skill set. If you want to develop potential in-depth, you need experience building a body of knowledge with some depth and sophistication. The seemingly arcane pre-req structure allows that to happen. If there's anything I've learned from studies in both human and machine learning, it is that you can only learn new things that are relatively close to the scaffolding of knowledge that you already have. Part of a good education is figuring out how that scaffolding can be built step-by-step to lay a foundation for deeper knowledge. Of course, one could just let the market sort out who has the necessary background or aptitude to gain from a particular course. But that assumes that individuals who are not yet trained have as good an eye for how to build the scaffolding as those who have already ascended it. I don't see how that can ever be as efficient. Kirby, do you not see any irony between your two comments in this thread? One of the goals of liberal education is to produce well-rounded, deeply human individuals. One of the bright ideas of competence academics have is that students should be able to express themselves elequently, persuasively, and publicly. In my view, we (as a society) need more of this sort of whole education, with it's attendant mazes of pre-reqs and extraneous requirements. All the technical certification programs in the world will never produce a good presenter, let alone a truly educated citizen. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Low Enrollments - programming as anit-intellectualism.
Arthur wrote: A business trip had me passing through New Haven. As a lover of books, and therefore bookstores, I took the opportunity to stop to look for a bookstore near the Yale campus - figuring I would find a bookstore with significantly more depth than those to which I normally have access. I'm a big bookstore fan too. It's the best place to go when you want to learn about some hot new technology ;-). It's not necesarily the place I go for a liberal education. I was right. I will make this short. Without a question (IMO) - the least interesting section of the bookstore was the Computer area. Hundreds of how-tos on the commercial technologies currently hot. The end. They stock these books because that's what sells. Professionals buy books to learn new technologies. There are many such professionals in the New Haven area. Nothing worth talking about that precedes the current hot technologies - one would conclude from the book selection. Yes, one might conclude that from the book selections. But that would be a silly conclusion. Why would anyone spend $40,000 a year to study how-tos of technologies that will be obsolete by the time they are 30 - if not before. One would be a fool to do this. Fortunately, that is not a description of very many academic programs, certainly not those in the liberal arts tradition (the ones you pay $40,000 for). On the other hand, if you actually ask students what they look for in a CS program, this is exactly the answer you'll often get. They _think_ they want to learn about all the latest hot technologies. It's more likely they don't go into CS because they perceive (correctly, in our opinion) it's not primarily about that. I am no more an intellectual than I am a comedian. But give me a good stand-up, or a facile, learned mind to try to follow and digest. I don't understand how this is precluded, just because certain kinds of technical books have a big market. If I look at the psychology section of a bookstore, I see tons of titles on self-improvement, birth order, quantum conciousness, and other assorted new-age poppycock. What does any of that have to do with the academic study of psychology? I certainly don't conclude from this that the study of psychology would be a waste of money. Bookstores are measures of markets, not of academic practice or worth. Programming as an academic subject area is *way*, *way* off track - to the extent my little browse of yesterday was indicative of anything - which I do believe it was. What you saw has very little to do with programming as an academic subject. Actually, most CS types would say that programming itself is not an academic subject; rather it is a skill of some importance to the study of real academic subjects such as Computer Science. I personally think programming teaches wonderful habits of mind including problem-solving, modeling/abstraction, mastering complexity, and attention to detail. But please don't confuse technology books with a CS curriculum. And again, I'm sorry to say that from where I sit, even fewer students would express an interest in CS if it were really presented to them in its academic glory. Technology is often a useful hook that can help to get them jazzed on more fundamental enduring principles and deep ideas. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python as a first language for computer sciencist
Carlos, I doubt that you'll get much disagreement on this list about Python being an excellent first language choice. Hence, there is unlikely to be much of a discussion. I wrote a paper titled Python as a First Language back in 1998, you can find it at: http://mcsp.wartburg.edu/zelle/python Carlos Eduardo Sotelo Pinto wrote: Hi people i was making a researching about python for computer science students as a first language, and it coul be good in Peruvian Universities and Colleges, may you have some experiences, or articles or ideas about it. Coul you send me to my personal email address. Also I propose to you to began a discussion about this topic. I think in my personal opinion, python could be better for students, for one so imoprtant reazon: Python is clearly and powerfull; and because of it, students just think in solve problems and learning programming, and the language could be an excellent easy learning progamming tool. Also teachers can use the power of python for making good problems for the students. Based on my actual experience, I can say that Python _is_ a much better first language choice than C, C++, Java, or Visual Basic. It has most of the advantages of Scheme, but with a smoother transition to more traditional languages. More and more CS programs are discovering the joy of teaching Python first. So far, I've not heard of any program that tried Python and then went back to something like C++ or Java. Incidentally, I think Python is a marvelous tool throughout the CS curriculum. It's a language that gets out of your way so that you can concentrate on fundamental concepts. I even use Python in my Op Systems class, something I'm frequently told Python isn't good for. Not true. Python is (arguably) the simplest vehicle that allows my students to program directly with underlying Posix system calls. It's simpler than doing systems programming in C or C++. To say nothing of trying to access the OS in Java... While I would not try to write an OS in Python, it sure is a lot easier for teaching _about_ them. That is, I am using the programming as a learning tool, not trying to teach them how to program an OS. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Microsoft's KPL
As usual, I don't have time to comment on all the intriguing things that have come out of this thread. But gender balance is something that I've spent a lot of time thinking about and working on as regards our own program. So I felt compelled to say something. Laura Creighton wrote: Why females shy away from math and science is no big mystery. It is deemed 'not useful' by them. See many posts by Anna Ravenscoft on the subject here in edu.sig archives. These days she is 'Anna Ravenscroft Martelli' having married Alex Martelli. (Hi Anna. cc'd to you so as to not talk behind your back, and in case you want to comment.) I hear researchers say this at conferences, and I read it in the literature about gender balance in computer science, but I still don't understand it. Can you explain why when selecting majors women consider CS as not useful and therefore to be avoided when they seem to have no such qualms about, say, history or English literature? Here in the states, women are also severely underrepresented in natural sciences and engineering, also areas of obvious utility. Speaking specifically to CS, both boys and girls are heavy users of computers now (although girls tend to start a bit later). So why don't girls perceive computing as a useful field of study? I don't think it's because it involves mathematics, because frankly, most entering CS majors (male or female) have no idea that CS involves much mathematics. I can understand this usefulness argument to some extent for mathematics majors, but at our institution (liberal arts school in rural, midwest US), we have little trouble attracting female math majors. On the other hand, it is extremely rare to find a female interested in CS, period. Virtually all of our female majors are recruited when they take our CS1 class as either a Gen Ed. class or a requirement for another major. To my mind, the useful argument is a nonstarter. There must be something else going on. Any ideas on what that is? snipped part about Laura being a mutant But most women are not like this. They want concrete usefulness. Here at Chalmers in Sweden the women students outnumber the men in all the Chemistry departments. Chemistry is presented as concretely useful. As I mentioned above, this is not the case in the US. Chemistry is still one of the fields where women are underrepresented. When I offered a night-course of three weeks at the Chalmers computer society (all chalmers students are automatically members) on compiler design, pypy, and how to hack ... only got 4 takers, and all male. A different 4 week course -- 'how to build a bot to take care of seeing if your favourite websites are announcing the things you want to know about -- NO PREVIOUS PROGRAMMING SKILLS NECESSARY' got me 57 takers, 35 of which were women. This is interesting. But is the real difference here practicality, or is it something else like the web (i.e. communication) or the NO PREVIOUS SKILLS NECESSARY? Women are not programming because they do not see it as Art, Joy, and a worthwhile selfish pleasure. But also because they do not see it as useful. I have no idea why this is a mystery to the educators. They must not speak to many women. I speak to women all the time, and when I ask them why they're not in CS, they tell me it's because they don't like computers. I've never ever had one tell me they didn't find computers or computer progams useful. As to why they don't see the Art and Joy, it's probably because they've never been exposed to it. It seems as if boys like using computers, and many of them, for whatever reason, are motivated to take a peek underneath and end up hooked on programming. Girls are using computers just as much, but don't seem to go that next step and try to see what makes them tick. Why? I don't know. Someone please tell me so that I can get my daughter interested in programming some day. (Not too soon though; I don't think there's a need for any kid to spend much time with a computer before at least Jr. High. But that's another thread entirely...) In Sweden we have laws preventing the sort of advertising that I think MSFT is doing in the USA -- targetting children is illegal. Then how do your kids know what their parents need to buy for them ;-) But given that you are stuck with it, I would be very interested in seeing if it has an effect in student sex ratios. Perhaps that's one good thing that could come out of KPL-type efforts--- getting some girls to see the Art and Joy. Though I'm not holding my breath. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Brute force solutions
On Wed, Sep 21, 2005 at 09:31:41AM -0700, Kirby Urner wrote: Of course all of this requires temporarily ignoring the fact that algebraic methods give us a way to compute phi as simply (1 + math.sqrt(5))/2.0. I've been considering this a bit. The closed form here begs the question, what is math.sqrt(5)? Sure, we have a built-in function that computes this, but someone had to write the algorithm that computes sqrt. That calculation makes use of numerical techniques similar to what we are discussing w.r.t. phi (much more efficient ones, of course). In a sense, you could view your discussion as a look under the hood at possible implementations. In fact, I would think a good problem to tackle in a math class is to develop some algorithms for approximating square roots. Various guess and check techniques can be successful. Newton's method is vary good, and can easily be derived/motivated without actually looking at any of the calculus. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Brute force solutions
David Handy wrote: On Wed, Sep 21, 2005 at 09:31:41AM -0700, Kirby Urner wrote: Mine original draft makes sense to set the stage, cuz the reasoning is so dang primitive. Yours adds a layer of sophistication more reflective of how real world programmers learn to squeeze the most out of their cycles. Your original draft was a great baseline. That's one good reason not to prematurely optimize: it makes you look like a hero when you optimize later. :) Of course all of this requires temporarily ignoring the fact that algebraic methods give us a way to compute phi as simply (1 + math.sqrt(5))/2.0. The technique is generally useful to solve any equation of one variable, given: 1. You have an interval in which the solution lies 2. You have an error function that is monotonically increasing over the interval the further you get from the solution (and goes to zero at the solution) If you have the sign of the error, you can also make use of simple bisection (aka binary search). Here's a version: def findphi3(tolerance=0.01): low = 0.0 high = 1.0 while True: a = (low + high)/2.0 b = 1.0-a e = b/a - 1/b if abs(e) tolerance: break if e 0: low = a else: high = a return b/a Which turns out to be a bit more efficient than the adaptive stepsize version in this case: Slow method -- result: 1.61803406588 time: 0.756837797165 seconds Faster method -- result: 1.6180333003 time: 0.000106906890869 seconds Bisection -- result: 1.61803328419 time: 3.86953353882e-05 seconds I think exposing students to numerical equation solving using Python can give them an understanding that will help them later when they are trying to, i.e. figure out how to solve a problem with their fancy caculator, spreadsheet functions, etc. Kirby -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: My only objection to it being there - in fact - is the lack of consensus as to the compelling reason it is necessary. There seems to be agreement, in fact, on only this one aspect of the reason for its presence as a built_in function. The fact that the reason is compelling. I thought we already agreed that properties are a _convenience_. We could already do everything that properties give us using __getattr__ and friends. The _convenience_ was added because many people find it useful. You seem to be saying that having multiple good reasons for a feature is an argument against its inclusion! Most of us consider multiple justifications evidence of a compelling feature. To extend the argument in your direction: I _can_ do everything I _need_ to do in C++, Java, or even assembler. I choose to use Python exactly because it makes the things I need to do _more convenient_ to accomplish. Mind you, I have managed quite well in Python without properties. Now that I have them, I will use them. Furthermore, because it allows me to do something I feel is useful in a simpler way, I will probably use them more often than I used __getattr__ magic before. That is, the benefit I derive (attribute access syntax with implementation independence) is now offset by an even smaller overhead cost (code complexity). Plus my code is more transparent, a double win. And it in no way affects how you have to write your code, so that argument that you don't want to do things the Java way (or any other way) is a complete strawman. I still have not read an argument that the property feature itself is in _any_ way a bad thing. Only your claim that some people may like them for reasons that differ from Guido's (and even that is open to interpretation--I happen to view Guido's use-case and the implementation-independence use-case as one and the same). Hence I stand by my previous conclusion that properties are an unambiguously Good Thing (tm). Whatever the hell it is. It is convenience. Convenience is the compelling argument. I guess I'll have to accept your offering the we simply disagree here. My only misgiving is that I still don't know exactly what we're disagreeing about. But we've probably already spent more time and effort than this particular disagreement was worth. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur, It often seems to me that I agree with you, but you think that you don't agree with me. This may be one of those cases. Arthur wrote: -Original Message- 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. First up, I don't particularly like the decorator syntax here. However main concern is (in your words) the use cases for properties. No one is arguing that you should use use properties anywhere where normal attribute access suffices. The point is that you can just use the simple attribute access mechanism if that is what you need now. Later on, if your design changes, you can use properties so that the API remains unchanged even though you are now using a method call. Not having to change the API is good in two ways. First, it means that existing clients don't break, and second at preserves the simpler user model of assigning and reading attributes. This second advantage is one that a desginer might choose to use up-front. That is, even when an initial design uses a method call, it might be convenient for users to have an attribute-based API (ala VPython). 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. 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. 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. H. Are you saying adding something to the language that provides a more elegant way of doing what you were doing before (__getattr__) is a bad thing? Or are you talking about using properties everywhere you used to just do attribute reference? The former I don't understand. The latter I already addressed; don't use a property unless that is what you need. I guess I am pleading for constraint in the presentation of properties to novices, with clear *and narrow* use cases. I can't disagree with this. Beginners don't need properties. Start with attribute reference. It's important to realize that this would be anathema in many OO languages (Smalltalk, Java, C++), but it's OK in Python because it still maintains implementation independence. I used to be able to guarantee this through __getattr__ and friends. Now it's much simpler with properties. Its part of my campaign for this year's Willison award. I'm think my chances are 50/50, best case ;) Best of luck to you. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Updated graphics library
Hello all, For those of you who use my graphics.py library for teaching, I wanted to let you know that I've just released an update to version 3.2. This version has two important improvements over the last release (3.0): 1. Significantly improved performance of communication with the Tk thread. 2. A new Pixmap object that can be used for simple image manipulation programs. Pixmap is a wrapper around the TK photoimage class and allows creation and manipulation of gif, ppm, and bitmap graphics files through setPixel and getPixel methods. As usual, the package and updated documentation are available at: http://mcsp.wartburg.edu/zelle/python The threading updates have been fairly well tested at this point, as we've used them already in a CS1 class. The Pixmap object is not as extensively tested, but it's so simple that I feel it is ready for release. Id' be happy to hear any feedback (good or bad). --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python for CS101
Toby Donaldson wrote: For instance, to write an efficient queue data structure (where adding and removing form the queue are always constant-time operations) in LISP/Scheme requires using arrays. Hi Toby, I don't think this is a valid criticism. If the point of using a queue is to teach how to write an efficient data structure, is the target audience really going to be beginners? Do beginners care about efficiency, to the exclusion of all else? If beginners don't care about the efficiency of queues, then they need to learn otherwise. Performance is certainly not the only thing, but it was one of the most important things, especially for an object that is going to be re-used again and again. What you said is also technically wrong: there are efficent ways to implement queues with pure list structures. See: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/210459 which is basically a translation of a Lisp-friendly queue class. Indeed, this is a neat trick for implementing queues with stacks. However, it's not the best implementation for simple fixed capacity queues where each add/remove operation is required to finish in constant time (as opposed to amortized constant time). I don't know any way to achieve that in LISP using only lists. For the record, it's very easy in LISP to implement a Queue using a cons-pair with car pointing to the front of a linked list and cdr pointing to the back. Using such a structure, constant time enqueue and dequeue is trivial without arrays or amortized analysis. LISP allows one to easily build any linked structure you'd like. There is no restriction to a linear list with only a head (car) pointer. Of course implementing something like a queue which has state (side-effects) is not pure functional programming, but real LISP programmers don't worry too much about that. The discussion in the link above also shows that it's perfectly easy --- and all too often likely --- for beginners to do silly things using Python's lists too. On Python-tutor, we often do get beginners who will do things like list.pop(0), and not understand why it goes so slowly, compared to doing list.pop(). Interestingly, I recently needed a queue in Python and timed some alternatives. For run-of-the-mill work, the naive use of a list using append and pop(0) actually faired quite well for modest Q sizes. In any case, it is important at some point for Python suers to learn and understand the implications of Pythons continguous allocation. It's probably not crucial that the first queue they write be the most efficient one. Remember, premature optimization is the root of much evil. Abstractions always leak. But I wouldn't say that Python is flawed because it makes it easy to do list.pop(0), nor would I say Lisp is flawed because it makes it easy to use linked lists. True. I would agree with this statement. The flaw in LISP is the fact that it requires *both* the use of lists and arrays to implement certain elementary algorithms in the best way, and that the lists and arrays have different interfaces. Sometimes a linked structure us the right one, sometimes a contiguous structure is better. Having both in LISP hardly seems like a design flaw. Python does not provide a built-in linked structure, but you can easily implement one yourself. Some would argue the lack of a built-in linked list is the flaw. If your argument is that both kinds of structures should have exactly the same interface, that adds to the beginner's confusiuon over efficiency that you argued above. By only providing the operations that are efficient for the particular structure, LISP helps the novice programmer use the more appropriate structure for a given task. I don't think this is a particularly compelling argument for Python over LISP. Perhaps imperfection is a nicer term than flaw. :-) Toby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] FW: RFS: python-visual - VPython 3D scientific visualization library
Arthur wrote: Floris Bruynooghe has created a VPython Debian distribution and is in process of attempting to have it accepted as official Debian package. Not being familiar with the process I am having trouble following the dialogue - sponsorship vs. adoption, etc. Obviously I would like to see Floris successful. This would, for example, make is possible to see VPython available in the ubuntu universe of packages. A very good thing, IMO. I agree. As a dedicated Debian and VPython user, I'd also like to see this happen. Can anyone here help sort this out? To get a package into Debian, one must either be a Debian developer, or find a developer willing to sponsor the package. In the case of a sponsor, the sponsor is the one who verifys, signs, and uploads the package to the Debian distribution, however, the original packager (Floris in this case) is tagged as the maintainer of the package. There is something more to sponsorship than uploading packages, however. Having one's package sponsored is also a way of showing that one is capable of contributing to Debian, and thus might later be considered as a developer. In order to become an actual developer, you need to have an advocate who is a current developer. The sponsorship practice can be part of mentoring and eventually advocacy as a pathway to becoming a full-fledged Debian developer. If I read the following message correctly, Jonas is volunteering to take over maintenance of the VPython package, rather than sponsoring it. That means he would upload it and also be listed as the maintainer, and hence be responsible for future revision and maintainence of the package. I don't know what his reasoning is exactly, but he appears not to want any part of the sponsorship thing. Does that answer your question? --John Art -Original Message- From: Jonas Smedegaard [mailto:[EMAIL PROTECTED] Sent: Sunday, April 03, 2005 5:33 AM To: Floris Bruynooghe Cc: debian-edu@lists.debian.org; [EMAIL PROTECTED] Subject: Re: RFS: python-visual - VPython 3D scientific visualization library -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-04-2005 18:14, Floris Bruynooghe wrote: I have been packaging VPython for some time now and would like to get it into the main Debian archive. There has been an ITP for this way back in September 2001 (#112118) which was retitled to RFP in December 2002 due to nothing happening with it. Hopefully I tempted someone to sponsor this package. Are you requesting sponsorship or adoption of the package? I have had a look at the package, and find your packaging very well done. I'd like to adopt it if that's ok with you. I do not, however, want to sponsor your package as part of you becoming a Debian Developer (I _do_ want more Debian developers, I just don't believe in the current package sponsoring logic). If you later become a Debian Developer and want to take over official maintainance of it for Debian, I'd be happy to hand it back to you. So please tell me if it's fine with you that I adopt the package for official Debian maintainance. Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCT7hNn7DbMsAkQLgRAtnhAKCWOmjMPJf9P67HQX39hi/z6MnfuACfcE6X 7SWYbckx0rSu6zR5BEtsom0= =ojYH -END PGP SIGNATURE- ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] 9. Best approach to teaching OOP and graphics
Lloyd Hugh Allen wrote: On Wed, 23 Mar 2005 14:02:15 +0200, Linda Grandell [EMAIL PROTECTED] wrote: I wonder if letting the students pair up for themselves could work? That would more or less be a variant of the second alternative above. Or does this introduce the risk of weaker students pairing up with strong students doing less work? Even learning less? Generally, I would say that letting students on the K-12 level pair themselves in a totally, totally free fashion leads to less learning. This strategy often leads to a classroom management nightmare. With all heterogenous groups (perhaps all groups), it's a good idea to have assigned tasks (for instance, if the program has already been flowcharted, then this person is responsible for this area and this other person is responsible for this area) or differentiated assessment (in my bf/gf example, to have the weaker student lead you through the code in order to ensure that even if they didn't come up with the code, at least they are able to read it) I don't have experience with pre-college students, so take this advice with a grain of salt. I use pair (even group) programming frequently in my classes. Educational studies have shown that groups of 2 or 3 help students learn better than just having them work alone. One of the real advantages of pair programming is that students can pick up techniques and useful habits from each other. In order to gain the greatest advantage of this, it's important that teams rotate around. That way students end up working with many others during the course of the term, not just their favorite. I wouldn't worry too much about the weaker students coasting. They will learn a lot from assisting stronger students, and if the teams change frequently, they will at some point be the stronger student where they can pass on what they've seen others do. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Hypertoons!
Kirby, Thanks for the update. I had tried to run this earlier and noticed the missing dependency, but had not yet tracked down what was up. I've got it running now (with a couple tweaks for Python 2.3). This is a nifty application for demonstrating stereo visualization. Just set scene2.stereo = 'redblue' and scene2.stereodepth = 1.5, slip on the red-blue glasses, and enjoy the show. Awesome. It's even better with active or passive stereo, but I know must of you don't have that option. Thanks loads for the posting. --John ps. For stereo, it generally works a bit better to set the background to medium gray (.5, .5, .5) rather than black or white. Kirby Urner wrote: hypertoons.py rbf.py ... coords.py... See: http://www.4dsolutions.net/ocn/python/hypertoons/ There was another dependency I spaced mentioning: colors.py -- just a mapping between color words and associated RGB strings, used in various programs I've got. I've added that to my site. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] 3d goggles -- any recommendations
Hans, There are lots of sources for the cheap (= $0.40 US) anaglyph (red-blue) glasses on the net. I have recently ordered from RainbowSymphony and had decent results (not wild about the packaging but otherwise fine). As for the shutterglasses, it depends on what you are trying to achieve. There are some cheap ones (VR-Joy has a pair for under $100) that can be used with any video card, but they require either: 1) special software drivers that convert regular OpenGL code to frame-swapping stereo. This software usually is designed for games under windows. (i.e. NOT vpython or VTK apps and generally not under Linux.) 2) use of interlace mode. This requires your images to have left and right eye interlaced. Effectively halving your vertical resolution. At the moment, neither VPython or VTK supports this, although I had intended to add this to the VPython mode, and just never got around to it. Otherwise, you are talking about investing in a quad-buffered stereo card. I doubt if you can find this in the price range you are talking about. If so, it would be a very low-end product. I can't say that I've looked into this very recently. If you told us a little bit more about what you are hoping to accomplish, I might have some ideas for you. We've done quite a bit of playing with stereo display here (I am one of the principle authors of the VPython stereo mode). If you've got a couple protable LCD or DLP projectors available, you can put together a nice portable, full-color, multiple viewer stereo display system for the price that you're considering. You might check out some of the things we've done on this page: http://mcsp.wartburg.edu/SVEN Unfortunately, I don't think any of the VTK stereo modes work with our setup, but some other packages do (e.g. VPython and the molecular modeler PyMol). --John Hans Fangohr wrote: Hi Kirby, On the low end, price-wise, I was able to snag a stack of red/blue stereo glasses from a local 3D museum. They're basically cardboard with cellophane color filters, and I got mine for free. I expect they'd typically go for well under a euro in bulk. This is excellent (and if anyone can tell me where I can order such glasses, please do! (Need them delivered to the United Kingdom)). I'd love to use this, too -- seems ideal for presentations and lectures. And I obtained these glasses specifically for a demonstration involving VPython. I wanted my OSCON 2004 audience to experience a rhombic triacontahedron floating out in front of the big screen on which I was projecting. The illusion was very effective, with people going oo, ahh. I remember reading your email about it ;-) However, I am still interested in the more high-tech product I did ask for: it's appealing in another sense. Thanks, Hans Kirby -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Fangohr Sent: Wednesday, February 09, 2005 8:49 AM To: edu-sig@python.org Subject: [Edu-sig] 3d goggles -- any recommendations Dear all, I am looking for a product that provides three-dimensionality to OpenGL (aiming for visual Python but also VTK graphics) scenes (for teaching purposes). Something like graphics adapter with 3d goggles which work in sync and provide two pictures one for the left and the other for the right eye. Price range not to exceed 250US$; better less. Does a product fitting this criteria exists? Does anyone have any experience with such systems? Thanks, Hans P.S. It would help if this piece of hardware worked on Linux. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig - Dr Hans Fangohr Computational Engineering Design Research Group School of Engineering Sciences University of Southampton Southampton, SO17 1BJ United Kingdom Location: Building 25, Room 1027 phone : +44 (0) 23 8059 8345 fax : +44 (0) 23 8059 7082 email : [EMAIL PROTECTED] - ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] IDLE and Matplotlib
Hans, I know you are already in communication/waiting for a bugfix on this, but I have a quick inquiry. This sounds related to issues I've had with my graphics library (now solved, knock on wood). I would think that running IDLE -n would solve this problem for you. Please see my question below: Hans Fangohr wrote: Dear all, I am about to teach Python to a number of students who already know how to use Matlab (on a basic level). For that reason, the matplotlib library for plotting curves is ideally suited (it seems quite good anyway). The teaching computers are Win XP machines. I have settled for the Enthough Python Edition and the latest matplotlib (both executables can be found in www.soton.ac.uk/~fangohr/download/python). I have prepared the exercises on linux and am now trying to run them in windows. This is where I realised that matplotlib doesn't work well with IDLE. More particularly, it is known that the default backend TkAgg doesn't work with IDLE (see here http://matplotlib.sourceforge.net/backends.html#TkAgg) but it appears to work with IDLE -n (this is what it says on that web page). The problem I experience is this: -start idle -execute these commands: import pylab pylab.plot(range(10)) pylab.show() This produces a figure window which seems to work fine. At this point when closing the figure window, I can't get the IDLE prompt active again. (It seems that IDLE thinks the program and the figure process are still running, and is waiting for control to return.) This, in itself, is maybe not suprising. However, the idle -n switch doesn't seem to solve the problem for me (see below). The same problem is observed when I execute a program in the IDLE editor (by pressing F5). What do people think how I should continue? I could - try to make IDLE work with matplotlib (I think this is my preferred option) In that case, how do I tell IDLE on Windows to start with -n? (Not a Windows freak). In the start menu, I can change the properties for the link to idle from ''' C:\Python23\pythonw.exe C:\Python23\Lib\idlelib\idle.pyw C:\Python23\pythonw.exe C:\Python23\Lib\idlelib\idle.pyw -n but this doesn't seem to solve the problem: I get exactly the same behaviour as described above. When you say you get exactly the same result, does this mean that IDLE's behavior is unchanged? If so, you are not getting the -n flag set. IDLE should fire up with a message that simply says no subprocess instead of the warning about personal firewalls. If you just mean that Matplotlib acts the same, that's a different story. What happens if you change the menu item to this: C:\Python23\pythonw.exe C:\Python23\Lib\idlelib\idle.pyw -n Unfortunately, I don't have access to Windows to try this out at the moment. Another way to fire up IDLE in the -n mode is to right-click on a Python file and then select edit with IDLE. I actually find it annoying that opening IDLE this way puts it in -n mode, but it might be a way to test out exactly what's happening. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
