Re: [Edu-sig] Truth values and comparisons
Arthur wrote: if sum(x) !=0: use this array else: use other array. be careful: a = [1, 0, -1] if a: print true true if sum(a) != 0: print true that's why it's probably safer and more readable to use any() and all(), which i believe were both introduced to __builtin__ in py2.5. - d ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The fate of vpython
I don't know much about VPython or NumPy, but I've been involved in both contributing to and forking open source projects, from both sides, and I would caution against forking a project unless you're planning to take it in a new direction, or if there's some other compelling reason not to continue contributing from the main branch. If the author of VPython is not planning to work on it for several months and you aren't planning to do anything other than make it compatible with a soon-to-be released version of one of its dependencies (is that the relationship b/w VPython and NumPy?), then why not carry on work from 4.0b5? Surely the dev will welcome any contributions which reduce work he'd later have to do anyway. He may even be willing to give you write access to the repository if you can demonstrate to him your willingness to work hard and ability to rally the troops of that class at Cornell. This way you avoid duplication of work, since the VPython devs will neither have to duplicate your compatibility patches nor port your patches from 3.x to 4.0. The community is almost always better served by contribution than by forking, IMO. - d On Oct 6, 2006, at 8:32 AM, Arthur wrote: This from the August 10 announcement of VPython 4.0beta5 In the Recent developments section of vpython.org you can read a summary of the new features, which is also included in the documentation contained in the release. This includes a description of remaining known bugs, some of which are serious, which means that you may enjoy playing with the exciting new features, but be aware that there are problems. I am not going to be able to do any more work on VPython for about three months, as the publisher of the physics textbook Ruth Chabay and I have written needs a second edition completed by November. Jonathan Brandmeyer has graduated from NCSU and is moving on to other things. So unless someone else steps forward, it is possible that this version 4 beta is frozen for several months. Bruce Sherwood Essentially it reads to me that the 4.xxx branch of vpython is in some netherworld and, probably, deep trouble, with serious bugs, and no developer. Don't know what Bruce's plan might be after completing his textbook work, but I think he would acknowledge that he's not the guy to do the hands-on development work to put things back on track. Problem is, neither am I. But I will try to begin to take this bull by the horns, as time allows. My plan at the moment is to try to fork from the latest stable 3.xxx branch, with the initial goal of making it Numpy compatible. As Numpy approaches final 1.0 release as the standard for array processing in Python, it seems to me that a package such as vpython *needs* to work to support it if it is to survive. If it doesn't survive there is a serious hole in the Python educational world, IMO. Serious educational projects are already suffering from this lack of compatibility. See The World is Your Python http://www.physics.cornell.edu/~myers/teaching/ComputationalMethods/ python/WorldPy.html related to a Cornell U graduate physics course Computational Methods for Nonlinear Systems This course is a graduate computer laboratory, emphasizing hands-on programming with a variety of data structures and algorithms. We focus on the next generation of tools for computation, simulation, and research in a broad range of fields where vpython is among the required packages, but where they face: The current version of VPython, however, is built on top of the older Numeric package, and seems a bit fussy when used in conjunction with the newer NumPy. Fussy I think being a bit of an understatement I have gotten as far as to set up my ubuntu environment with necessary dev libraries for building against Python2.5 - boost, gtk2, gtkglarea,etc. and atc. and began to explore the .cpp moudles related to Numeric compatibility. It would be great to see something concrete come out of all this edu-sig chaos, brainstorming, bickering and worse. So I would prefer to see this fork of vpython from 3.xxx live as a community project, with *real* C developers involved, rather than myself learning as I go and perhaps quickly finding myself over my head and throwing up my hands. Any interest out there?? Art ___ 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] creating an interface vs. using one (Michel Paul)
kirby urner wrote: Excellent suggestion. Maybe come back if you have a good idea for a change. I've got a better idea -- why don't you both start a new list, maybe '[EMAIL PROTECTED]', where you guys can have your little show-off competition, and leave edu-sig for conversation about eudcation with Python? I've been on list for a few months, and so far there's about 3% signal to your 97% noise. For pete's sake, take your little tiff off-list! - d ___ 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
kirby urner wrote: I would like a deeper discussion of why we still need to prompt ourselves for input. I think the model today is a person writing code for him or herself i.e. self as client -- at least in an early context. We're not guiding the unknowing through a menu tree. We're computer literate, fluent. Why would we ask ourselves for raw_input, when it's much easier to just pass arguments to functions? When I think back to when I was learning to program in 9th grade (I'm not a professional software devel) I know that it was really exciting to be able to twiddle with the computer for a bit, then call my mom over and have her work with my program -- simple guessing games, then eventually moving on to more sophisitcated things like memory, card games, etc. At the time I was learning QBasic, so console-oriented input was what you had. Granted QBasic had no notion of an interactive console -- or rather it did, but that was not a predominant way of interacting with it. But even though it did, it would not have been as exciting to sit my mom down with it and let her play around, and I wouldn't want to have to explain to her (even now with a nearly infinitely more sophisticated understanding of computers and programming than I did in my first months) what a function is, how to interact with it, what arguments are, etc. It may not be how you like to teach computer programming or interacting with computers, but I think there's a very important case to be made for other as client at the very beginning, as a way of keeping it interesting, when someone else is going to see it. If you're *really* coding for a complete newbie, then learn GUI programming, meet them where they want to be met. Otherwise, just import and use a namespace, like a real grownup. All this ask myself for degrees centigrade stuff is just too 1970s, too BASIC (yech!). I don't think programming with, eg, raw_input() is programming for a newbie, but it is programming *at the level of a newbie* for someone else who may or may not be -- in my mom's case, sure, if I had made a GUI that might have been easier for her. but the goal was not to make a program for her, the goal was to make a program, and having someone else who could use it was a really powerful motivator that got me to explore ways to extend it beyond the beginning code that was assigned by my teacher. - d ___ 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
kirby urner wrote: On 9/8/06, Dan Crosta [EMAIL PROTECTED] wrote: It may not be how you like to teach computer programming or interacting with computers, but I think there's a very important case to be made for other as client at the very beginning, as a way of keeping it interesting, when someone else is going to see it. This is a good example, of showing off new skills to one's mother. But maybe CP4E is about having one's mother learn to program, in which case maybe the first thing you say is mom, when you import, you bring in a namespace, which is like stuff you might interact with, like go from zoo import Monkey and then go mymonkey = Monkey(Curious George) To me, this sounds like you're really educating your mother, not making it be about you and your new skills, but about cluing her in, letting her be a part of your world of Python namespaces, where knowing about import is absolutely key. 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). I'm saying CP4E is here to change all that. Your mom knows how to program, learned how to when she was your age. She's been writing little programs for her kids for decades, plus others for the microwave, light dimmers, heater, plant waterer, and car. Not because she's friggin genius or anything, but because this is 2006, and moms have skills, aren't like in the 1950s (nothing wrong with the 1950s, but nothing improving in 56 years would be laughably stupid). [...] You should just write for yourself at first, and find that satisfying. You shouldn't need this hypothetical guinea pig other. OK, maybe a few times (and mom is proud). Well in that case I agree with you -- it would be great if my mom knew how to program. But let's be realistic: my mom has only recently learned to understand email, she's not about to go out and program her own spam filter. It's just not in her skillset, and more importantly, her interest set. I think you're projecting a bit onto the entire world to think that people are going to program their dimmer switches. Let me draw a related example: it has recently become more or less impossible to own any content sold by the MPAA and television industry, and, less so, by the RIAA. HDMI makes it impossible to do anything other than watch what your cable box records on an expensive HDTV. If you were right, there'd be a million light switch-programming mom march on Washington and Hollywood protesting this insult to their rights. Now wake up: there isn't. People want their technology to do what it needs to do at a basic level, but aren't really out there extending it; whether we like it or not, we're the exception, not the rule, us people more comfortable at a keyboard than a mouse, more comfortable knowing how it works than just knowing that it *does* work. As I said before, I think it's great that you're training the next generation to love the interactive interpreter rather than the monkey menus, if you will. I think it's great you're training people to be self-reliant and program for themselves first, then for others as a job but always still for themselves. Very Snow Crash. But not realistic, and not now. Maybe in 2036 when my generation (I'm 22) grows up and has kids of our own, maybe when I'm Dad, not Dan, people really will be able to program their light switch and microwave -- but I'm not sure what that'll really have gained us, my light switch and microwave work fine. Do yours? Start thinking like a professional really early. Code for the back office if it's back office (don't need no bells and whistles). Don't waste your life polishing API skills no job market will ever need (i.e. some raw_input based dialog, menu tree, looks like a 1960s mainframe). Or rather, don't *start* with that. It's hard to claim that anything you learn in CS1 (or equivalent) is either polished or a skill. Instead, I think the point is to become familiar and comfortable with computers as more than a user, and if that happens to take the form of baby steps, menu monkies, GUI programming, or whatever, as long as it happens it's good. It's evident to all of us that menu monkeying works, because that's how we all got trained programming and look where we are today. It seems fair to say that teaching through the interactive shell using functions and classes will accomplish the same goal. Even most moms these days know that unless junior learns GUI programming, there's nothing much here, as far as code for end user skills. She's secretly unimpressed, but doesn't show it. Well, first of all, you evidently don't know my mom at all. Actually, that's a good thing, I don't think she'd like you
Re: [Edu-sig] The fate of raw_input() in Python 3000
Radenski, Atanas wrote: Me too :-) I would like to see both input and raw_input preserved. Replacing these with more complicated (from pedagogical perspective) methods would probably give an additional reason for educators to look at alternative languages, such as Ruby. I realize this is the education SIG list, but it's important to remember that Python is not just for educators and students (though I believe it makes a great language for those demographics). I used Python extensively for scripting system administration tasks and interactive scripts that our users would use. While hiding the input functions inside the sys module wouldn't make life substantively harder for the sysadmins, it might prove just enough hurdle to look at other options. I will, for the sake of sanity and on-topic-ness, refrain from recanting some of the great Python/Perl battles that the SCCS [1] has suffered over the years. - d [1] Swarthmore College Computer Society, the group at which I was an admin for 3 years. http://www.sccs.swarthmore.edu/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python Pedagogy
Andre Roberge wrote: Well, while we're at it: class Human: def __init__(my, name): my.name = name I = my def __repr__(my): return 'My name is %s' % my.name def is_hungry(I): print I am hungry. I.eat() def eat(I): print I eat! Kirby = Human(Kirby) print Kirby Kirby.is_hungry() I don't really know how decorators work, but wouldn't it be possible to write a decorator that would let you define functions like this: class Human: def __init__(my, name): my.stomach_state = 'empty' my.name = name @wackydecorator def is_hungry(I, my): print %s stomach is %s % (my.name, my.stomach_state) if my.stomach_state != 'full': I.eat() def eat(my): my.stomach_state = 'full' kirby = Human(Kirby) kirby.is_hungry() kirby.is_hungry() so basically the decorator would duplicate the first argument twice so that you could transparently get two (or more) names for it... I don't know how to write decorators (and can't really spend time learning here at work), but something like this: def wackydecorator(func, *args): return func(args[0], *args) I think that would do the trick. - d ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
whoops, sent this reply off-list by accident (apologies to Scott) Here's a thought that just jumped into my mind, I don't know if it has any value, but bear me out: I think it probably makes most sense to introduce programming to totally new people in a procedural/structured/whatever you want to call it way. My feeling is that most people who haven't done any programming think of a computer program as a big list of instructions for what to do, and this model should be pretty easy to introduce to them. Now you start to try to do more compliated things, and you have to start accumulating global state so that your many functions can do meaningful things without having to pass loads of arguments around. Pretty soon, depending on the topic, you probably want a way to group global variables together -- the first approach might be to name them similarly, like foo_bar and foo_baz for bar and baz relating to foo. But what if you have two different things of type foo? Now introduce objects as essentially structs. You have a class definition, like: class Foo: bar = someDefault baz = someDefault and just work with that for a while. Now, you are passing around Foo's as arguments to your functions, and you realize that certain functions can only work on Foo's, while others can only work on OtherThing's. Isn't it logical to group your functions in the same way as your variables? Oh, look, thats object-orientation (or the core of it), and you got there all on your own. My experience as a student has been that the best teachers are the ones who give you all but the conclusion, and let you make the final leap yourself. That, I think, makes the knowledge both more likely to stick, and the excercise (which is probably at least somewhat artificial, as most exercies tend to be) more exciting, as you feel like you're making a new contribution to how it all works. Anyway, that's roughly how I had been introduced to OO programming over the years: first BASIC, learning the, well, basics, of program organization with sub's; next, larger scale programs, maybe in C, organizing static members and functions into files; soon structs; then full-on OO with Java (which I loathe), and later Python and C++. Just my $0.02 dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python for CS101
As a follow up note to my earlier comments, it might be worth considering why the current language (at Swat, currently C, but transitioning to Java) is used in the intro course? Certainly C at least is a language worth knowing as a computer scientist, but need it be introduced to students who've never used anything other than Windows or Mac OS? Probably not. Are there any good reasons why such a low-level language ought to be taught in the intro-intro course, other than that the faculty probably know it pretty well? I see it fitting in nicely as a mid-level class, or even as a task students take on when in a class that requires knowing C (my experience has been that picking up a new programming language is time consuming but not that difficult). Swat at least wants to keep a one-track intro to the department, but I'm not as certain that's the right choice, since it seems important to recognize the two primary experience levels incoming students have: none and some. Students in the none category are likely to be scared off by C -- a friend of mine this year who I encouraged to take our intro class was scared off exactly for this reason after 2 classes. Students in the second category have probably already programmed in C (or now, what with the AP, Java) and would either not take the class, or gain little from it. One of our intro class used to be taught in Scheme, which leveled the playing field among the two groups of students, and taught good recusive practice to all rising CS students. Java seems unlikely to help in either of those ways, and, at least as far as I know, is not even one of the primary research languages. OK, now I'm just complaining about Java, so I'll stop. dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Best approach to teaching OOP and graphics
Linda Grandell wrote: In my book, OOP and graphical programming *are* two different things. I totally agree on this. What I, however, do see as a potential risk here is that the division might lead to students thinking thoughts such as First of all, I disagree here. Well -- they are. But they really shouldn't be. In my opinion (speaking as a Computer Graphics undergrad), computer graphics are a fundamentally object-oriented task. You're manipulating meshes, polygons, lines or points inside one or more graphical contexts, and each of which share certain attributes (location, color) and methods (translate, draw). This suggests a strong class heirarchy to me, and in fact, when I went about writing my own graphics library last semester, my partner and I took a heavily object-oriented approach (though in C++, not Python). Once we got into the real meat of the assignments, we had a much easier time when we only had to reimplement a few functions, thanks to inheritance, rather than rewriting whole functions from the ground up. Additionally, I think graphics provides a helpful visual metaphor for heirarchical systems, which is, in my opinion, an important part of understanding object orientation. If you have a model heirarchy like: - Model m - SubModel a - SubModel b And you call m.translate(10, 0, 0), the students will see that a and b translate by 10 in x as well. This is metaphorically analagous to changing the impelentation of a method or value of a field in a base class, and having that change reflected in the children. In fact, non-OO graphics systems (I'm thinking OpenGL) basically are object oriented, just without the benefit of living in an OO language. You find, when programming OpenGL, that you do a lot of PushMatrix() and PopMatrix(), which implicitly defines 'objects' in the sense of bits of graphical stuff that move around together. Other begin and end calls work similarly. To finish, I'd say that you should consider what you want the students to get out of the course: if you just want them to have a good time, then programming some procedural stuff with graphics (say, a tron-like game, which I did in Java/AWT/Swing when I was in high school) might be a good idea. If you want them to really learn about object orientation, I think working in an object-oriented modeling system, even if you just end up doing simple 2D stuff, makes a whole lot more sense to me. dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
RE: [Edu-sig] Re: Best approach to teaching OOP and graphics
On Fri, 25 Mar 2005, [EMAIL PROTECTED] wrote: But here's the thing, the question I think we're asking in this thread: how do we make it clear to students that OOP is NOT *just* about graphical programming? You can write highly object oriented code that has no GUI whatsoever, is invoked only from the command line with switches, maybe runs in the background as a daemon process (like a database) and communicates with the outer world only through some ports over TCP/IP. Is there anything less OOP about such code, which has no graphical shell? No. OOP, as a concept, is conceptually distinguishable from doing GUI or game or graphical programming, even though, as a paradigm, it has become probably the most popular way of doing all of those things. Oh -- I think I misunderstood. I took graphics to mean computer graphics, in the sense of 2D or 3D drawings, modeling, rendering, etc, not GUI design. I've never worked with a non-OO gui toolkit (though I think GTK is, if I'm not mistaken). My point about Java/AWT/Swing was not meant to be about the language -- we just made a big Graphics object, and used its drawline/drawrect/etc functions inside a big ol' while loop. It was a pain, we had to maintain a lot of state that would have been better served by using an OO approach to state maintenance (the two players, their histories, etc) rather than lots of arrays, variables, etc. dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: RE: [Edu-sig] Re: Best approach to teaching OOP and graphics
On Fri, 25 Mar 2005 [EMAIL PROTECTED] wrote: But using the metaphor of geometric objects already *is* the canonical way of introducing OOP. Slightly tangent: here, in our Object Oriented Programming/Algorithms class (the curriculum of which I'm not a great fan, I should say) uses the Person - Student, Person - Professor paradigm for introducing object orientation. I don't think it's a great example, but I struggle to think of any better. I sort of think that graphics might not be a good introduction, since it requires a lot of associated stuff to understand (graphics contexts, how images work or how to draw on-screen)... and you could say just use this boilerplate for now, you'll get to understand it later but I feel like that's just as likely to confuse as to provide a good example. As my prof said: if you ever figure out how students actually learn to program, be sure to let me know... :) dsc ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
