RE: [Edu-sig] Re: Best approach to teaching OOP and graphics

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Beni Cherniavsky
> 
> I think teaching students to actively detest code that with huge redudant
> repetitive piles of redudancy repeated all over is more important than
> teaching them any single guideline.  



> Rule of thumb: use tuples where you typically change all members together.
> Use mutable objects (lists/dicts/objects with attrs) where you frequently
> change individual members.

The tuple/list distinction is a recurring question on python-list - people
trying to understand in what way the 2 structures are not redundant. This
comes up repeatedly ;) 

I find your formulation more satisfying than anything I've come a cross
before.

Art



___
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

[Dethe Elza]

On 31-Mar-05, at 3:53 PM, Beni Cherniavsky wrote:
There are still times when you don't want to expose attributes 
directly, but getters and setters don't help you there either.  For 
example, if both myObj.x and myObj.y must be changed in synch to stay 
valid, then they should be set via myObj.setXandY(x,y) not myObj.x = 
newX, myObj.y = newY.  But this is a design problem not a language 
problem.
myObj.xy = (x, y)
Rule of thumb: use tuples where you typically change all members 
together. Use mutable objects (lists/dicts/objects with attrs) where 
you frequently change individual members.
Good point.  Python solves another design problem.  Is there anything 
it can't do?

--Dethe
I can't watch television without praying for nuclear holocaust.  --Bill 
Hicks


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Beni Cherniavsky]

Dethe Elza wrote:
On 27-Mar-05, at 2:04 PM, John Zelle wrote:
There is a good reason for these traditional guidelines, that is to 
make the abstraction you are defining independent of its 
implementation. Down the road, I might want to change the internal 
representation of color, or remove or rename the color instance 
variable. If existing code exploits this internal feature of a class, 
then changing the implementation may break code that uses it. So this 
is bad design --- in most languages.

And yet, this is common in Python. Why? Because of Python's dynamic 
nature I can still change the implementation should I choose to and I 
can preserve the old abstraction (interface) using getAttr and setAttr 
magic. I can't do that in most other languages, which is why they tend 
to use getter and setter methods.

>
> Or more recently (and cleanly) by using properties (new style classes
> only).
>
> The *only* reason that other languages promote the use of method calls
> over direct property access is because they don't have properties.
> Without properties it is very
> difficult to go in and modify the implementation without changing the
> interface if you start by using attributes, but in Python that problem
> just doesn't exist.
>
I will dare a stronger formulation:  Littering trivial getters/setters is 
unpythonic because it is vebose and ugly.  This is reason enough not to write 
them, whether we have properties or not.  Given this axiom, Python provides 
properties to solve a need *resulting* from not calling getters/setters 
exlicitly - it is secondary.

I think teaching students to actively detest code that with huge redudant 
repetitive piles of redudancy repeated all over is more important than 
teaching them any single guideline.  The guidelines are tools invented for 
writing better code, nothing more.

There are still times when you don't want to expose attributes directly, 
but getters and setters don't help you there either.  For example, if 
both myObj.x and myObj.y must be changed in synch to stay valid, then 
they should be set via myObj.setXandY(x,y) not myObj.x = newX, myObj.y = 
newY.  But this is a design problem not a language problem.

myObj.xy = (x, y)
Rule of thumb: use tuples where you typically change all members together. 
Use mutable objects (lists/dicts/objects with attrs) where you frequently 
change individual members.

--
Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
___
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

[Dethe Elza]

On 27-Mar-05, at 2:04 PM, John Zelle wrote:
I am not really talking about access modifiers. I am simply saying 
that most OOD guidelines would suggest that an object should be 
modified by calling its methods, not by setting fields. In VPython one 
does mySphere.color = color.red as opposed to something like: 
mySphere.setColor(color.red)

There is a good reason for these traditional guidelines, that is to 
make the abstraction you are defining independent of its 
implementation. Down the road, I might want to change the internal 
representation of color, or remove or rename the color instance 
variable. If existing code exploits this internal feature of a class, 
then changing the implementation may break code that uses it. So this 
is bad design --- in most languages.

And yet, this is common in Python. Why? Because of Python's dynamic 
nature I can still change the implementation should I choose to and I 
can preserve the old abstraction (interface) using getAttr and setAttr 
magic. I can't do that in most other languages, which is why they tend 
to use getter and setter methods.
Or more recently (and cleanly) by using properties (new style classes 
only).

The *only* reason that other languages promote the use of method calls 
over direct property access is because they don't have properties.  
Without properties it is very
difficult to go in and modify the implementation without changing the 
interface if you start by using attributes, but in Python that problem 
just doesn't exist.

There are still times when you don't want to expose attributes 
directly, but getters and setters don't help you there either.  For 
example, if both myObj.x and myObj.y must be changed in synch to stay 
valid, then they should be set via myObj.setXandY(x,y) not myObj.x = 
newX, myObj.y = newY.  But this is a design problem not a language 
problem.

What I am saying, is that if you are teaching programming for the 
purpose of having students learn general principles of programming, 
implementation independence is an important concept. But you probably 
don't want to get into setAttr and getAttr right away. That means you 
probably want examples of OOD that use methods to change objects. 
Otherwise you _seem_ to be providing them examples that contradict 
good practice that you tell them about.
No, don't get into setAttr and getAttr right away!  Avoid them if you 
can.  Go with new style classes (those that inherit from object), and 
teach them to use attributes to begin with (simple), and properties 
when needed.

If you are just teaching programming as a road to learning some other 
subject in depth, then I don't see much problem here. But I wouldn't 
want my students to apply the Python style in, say, Java.
Nor Java style in Python.  Phillip Eby has a longer (and quite good) 
piece on this: http://dirtsimple.org/2004/12/python-is-not-java.html.

--Dethe
"No lesson seems to be so deeply inculcated by experience of life as 
that you should never trust experts.  If you believe doctors, nothing 
is wholesome; if you believe theologians, nothing is innocent; if you 
believe soldiers, nothing is safe."

--Lord Salisbury, 19th century British prime minister


smime.p7s
Description: S/MIME cryptographic signature
___
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

[John Zelle]

Arthur wrote:

-Original Message-
From: John Zelle [mailto:[EMAIL PROTECTED]
Arthur wrote:
I agree that graphics programming is a great, concrete way, to teach
about objects. That is the point of my 2D graphics library. VPython is
also a great tool. The one caveat I would make here is that many OO
designers would say that the approach taken by VPython allowing direct
attribute access is not good style. Objects should generally be
manipulated through methods, not by twiddling fields. I know this is
fairly common in Python, but maybe Vpython is not the best first example
of object-oriented design.

I don't fully grasp what you are saying. Probably mostly because my primary
understanding of OOP comes directly from Python, and how and to what extent
Python differs from other approaches is not an area of much clarity for me.
There are also OOP designers who, I know, would argue that the absence of
access modifiers in Python is violation of good OOP.  I have heard that
argument used as a reason why Java is a more appropriate introductory
language than Python - establishing good OOP habits early.
I am not really talking about access modifiers. I am simply saying that 
most OOD guidelines would suggest that an object should be modified by 
calling its methods, not by setting fields. In VPython one does 
mySphere.color = color.red as opposed to something like: 
mySphere.setColor(color.red)

There is a good reason for these traditional guidelines, that is to make 
the abstraction you are defining independent of its implementation. Down 
the road, I might want to change the internal representation of color, 
or remove or rename the color instance variable. If existing code 
exploits this internal feature of a class, then changing the 
implementation may break code that uses it. So this is bad design --- in 
most languages.

And yet, this is common in Python. Why? Because of Python's dynamic 
nature I can still change the implementation should I choose to and I 
can preserve the old abstraction (interface) using getAttr and setAttr 
magic. I can't do that in most other languages, which is why they tend 
to use getter and setter methods.

What I am saying, is that if you are teaching programming for the 
purpose of having students learn general principles of programming, 
implementation independence is an important concept. But you probably 
don't want to get into setAttr and getAttr right away. That means you 
probably want examples of OOD that use methods to change objects. 
Otherwise you _seem_ to be providing them examples that contradict good 
practice that you tell them about.

If you are just teaching programming as a road to learning some other 
subject in depth, then I don't see much problem here. But I wouldn't 
want my students to apply the Python style in, say, Java.

I would stay out of the argument as to whether access modifiers are
essential to enterprise level development efforts. 

But would note that I do have Java in a Nutshell, Second Edition,
publication date 1996 in my library - because that is where I first started
in trying to learn programming.   And would say that access modifiers were a
key impediment to my taking off with Java. I sensed, I think completely
correctly, that I was approaching a language whose structure was complicated
by concerns that were no way immediate to my own concerns. If enterprise
development were to become an interest it would be many moons from my
starting point, and I would be able to deal with the issues involved at that
time - a natural ordering in time that a language like Java I don't think
allows very well.
Agreed here. Access modifiers are another matter. I think intro 
programming are much more natural in languages where I don't have to 
worry about Public, Private, and Protected and the like.

And I don't think we need to be afraid of teaching Python, exactly as it is,
as a developed OOP approach. It has grown enough in stature, I think, to
have proven itself to be another fully legitimate approach - trading
productivity for what others might consider to be necessary stricture.
I don't disagree with this. And I think there is no reason to avoid 
VPython per se. I'm just suggesting there is an issue to consider in 
that it appears (on its surface) to violate an important OOD principle.

Which brings us back around to TDD, in some sense.  
Not sure I see the connection here. But I agree with others in this 
thread that TDD is a great way to teach and develop.

--
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] Re: Best approach to teaching OOP and graphics

[David Handy]

On Sat, Mar 26, 2005 at 04:51:26PM -0500, David Handy wrote:
> So I created a module called demotest that does the same thing as doctest,
> except that it prints each command and response, and it waits for me to
> press Enter before going on to the next line. I just put:
> 
> if __name__ == '__main__':
> import demotest
> demotest.test()
> 
> at the bottom of my example module and it steps me through my demonstration.

Correction:

if __name__ == '__main__':
import demotest
demotest.demo()

(The function name is demo(), not test(). You'd think I could get my own API
right...)

David H.

> 
> If this sounds interesting, here is the link to the notes from my
> presentation:
> 
> http://trizpug.org/Members/dhandy/newclass/
> 
> and here is a direct link to my demotest module:
> 
> http://trizpug.org/Members/dhandy/demotest.py
> 
> Maybe someone else will find it as useful as I did. It requires Python 2.4
> because it uses the "advanced" doctest API: it uses DocTestFinder and
> extends DocTestRunner.
> 
> David H.
___
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

[Arthur]

> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 26, 2005 3:14 PM
> To: 'Arthur'; edu-sig@python.org
> Subject: RE: RE: [Edu-sig] Re: Best approach to teaching OOP and graphics
> 
> 
> > And what is the VPython framework you'd use to introduce OO?
> 
> Uhm... PyGeo ;)
> 
> Art
> 
> Exactly, which is why I was encouraging you to flesh this out.  If you
> don't
> write it, I doubt it'll happen.

Well I'm reluctant to promote PyGeo until I have a distribution available
with which I am more happy. 

The version on my machine is already quite restructured from what is in cvs
on sourceforge. What is downloadable on my site is downright obsolete, from
my perspective.

Interesting how refractoring works.  The more I work at it, the less code
there is.  

Difficult to get it polished off and out there for the same reasons I found
it impossible to make it to PyCon.

Once there is something out there with which I am happy, you will hear more
about PyGeo then you can stand ;)

Art
> 
> Agreed that the shapes metaphor is standard in a lot of intro books.
> 
> Kirby
> 
> 



___
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

[David Handy]

On Sat, Mar 26, 2005 at 11:18:47AM -0500, Jeffrey Elkner wrote:
> On Sat, 2005-03-26 at 12:08 +0200, Linda Grandell wrote:
> > I dived right into your lessons... Looks *very* good.

I have to echo that sentiment. Jeff, your approach is excellent.  Test
Driven Development really works, I've proved that myself.

But what I'm also impressed with is that you gave the students series of
tests to pass, each one adding more functionality. You are teaching your
students *incremental* development, which is extremely important IMO.

> I wanted to find a way to use this approach throughout the course, but the
> existing testing frameworks always got in the way.
> 
> DocTest has changed all that.

That has been my experience exactly.

Speaking of making good use of doctest, I did a presentation recently at the
Triangle Zope/Python user's group (TriZPUG) on Python's new-style classes. I
wanted to demonstrate the features using an interactive Python session, but
I didn't trust myself not to be too nervous to type the commands right.

So I created a module called demotest that does the same thing as doctest,
except that it prints each command and response, and it waits for me to
press Enter before going on to the next line. I just put:

if __name__ == '__main__':
import demotest
demotest.test()

at the bottom of my example module and it steps me through my demonstration.

If this sounds interesting, here is the link to the notes from my
presentation:

http://trizpug.org/Members/dhandy/newclass/

and here is a direct link to my demotest module:

http://trizpug.org/Members/dhandy/demotest.py

Maybe someone else will find it as useful as I did. It requires Python 2.4
because it uses the "advanced" doctest API: it uses DocTestFinder and
extends DocTestRunner.

David H.

- End forwarded message -
___
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

[Kirby Urner]

> And what is the VPython framework you'd use to introduce OO?

Uhm... PyGeo ;)

Art

Exactly, which is why I was encouraging you to flesh this out.  If you don't
write it, I doubt it'll happen.

Agreed that the shapes metaphor is standard in a lot of intro books.

Kirby



___
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

[Jeffrey Elkner]

On Sat, 2005-03-26 at 12:08 +0200, Linda Grandell wrote:
> I dived right into your lessons... Looks *very* good. I am always 
> looking for "new" approaches to teaching programming, since this is the 
> very topic of my future PhD-thesis. Giving the students a "standard" 
> which there programs are to meet should indeed be very motivating and 
> pose a positive challenge to all students. My class starts in three 
> weeks, so I have some time (not much :) to try out doctest on my own and 
> see if it would be suitable for my students. 

Please note, Laura, that I used doctest in more complicated way than
needed.  *All* you need to do to use doctest is add this to the bottom
of your file:

if __name__ == "__main__":
import doctest
doctest.testmod()

Then you simply run the module from the command line, and your testing!

> Did your students find it difficult to learn and start implementing TDD?

Absolutely not.  They found it as natural as can be.  I've been hanging
around an eXtreme Programming user's group for several years now, and I
wanted to find a way to use TDD in the classroom.  I had a wonderful
experience with it two years back (see
http://www.elkner.net/jeff/testFirst/index.html), and I wanted to find a
way to use this approach throughout the course, but the existing testing
frameworks always got in the way.

DocTest has changed all that.  It is not hard to understand why this is
so if you look at Tim's description of why he created DocTest:

http://c2.com/cgi/wiki?DocTest

Tim has done a brilliant job of creating a testing mechanism that is
completely natural to python.  Students have no difficulty using it,
since it mirrors the way they were informally testing previously.

> Have you considered using this approach in the exam? One thought that 
> came to mind would be to make the grades depend on which test cases the 
> programs pass. The test cases could be divided into groups, and in order 
> to pass the tests in the "higher grade"-groups, the programs would have 
> to be more flexible, advanced and so on than programs passing the basic 
> test cases. In this way  the same task could be challenging for all 
> students. Finding suitable exam questions can, in my opinion, sometimes 
> be really tricky, especially when there is great variation in the 
> students' programming skills.

Great idea.  I want to work on a python testing program (probably using
Zope3) that works this way.  If you are interested in the same type of
thing, perhaps we could work together?

jeff elkner


___
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

[Arthur]

> -Original Message-
> From: John Zelle [mailto:[EMAIL PROTECTED]
> Arthur wrote:
> I agree that graphics programming is a great, concrete way, to teach
> about objects. That is the point of my 2D graphics library. VPython is
> also a great tool. The one caveat I would make here is that many OO
> designers would say that the approach taken by VPython allowing direct
> attribute access is not good style. Objects should generally be
> manipulated through methods, not by twiddling fields. I know this is
> fairly common in Python, but maybe Vpython is not the best first example
> of object-oriented design.

I don't fully grasp what you are saying. Probably mostly because my primary
understanding of OOP comes directly from Python, and how and to what extent
Python differs from other approaches is not an area of much clarity for me.

There are also OOP designers who, I know, would argue that the absence of
access modifiers in Python is violation of good OOP.  I have heard that
argument used as a reason why Java is a more appropriate introductory
language than Python - establishing good OOP habits early.

I would stay out of the argument as to whether access modifiers are
essential to enterprise level development efforts. 

But would note that I do have Java in a Nutshell, Second Edition,
publication date 1996 in my library - because that is where I first started
in trying to learn programming.   And would say that access modifiers were a
key impediment to my taking off with Java. I sensed, I think completely
correctly, that I was approaching a language whose structure was complicated
by concerns that were no way immediate to my own concerns. If enterprise
development were to become an interest it would be many moons from my
starting point, and I would be able to deal with the issues involved at that
time - a natural ordering in time that a language like Java I don't think
allows very well.

And I don't think we need to be afraid of teaching Python, exactly as it is,
as a developed OOP approach. It has grown enough in stature, I think, to
have proven itself to be another fully legitimate approach - trading
productivity for what others might consider to be necessary stricture.

Which brings us back around to TDD, in some sense.  

Art



___
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

[Winston Wolff]

This is a great idea, test driven lessons.

-ww

On Mar 25, 2005, at 1:58 PM, Jeffrey Elkner wrote:

One more note on this topic.  I'm quickly coming to the conclusion that
the best way to teach any programming, OOP or otherwise, is using Test
Driven Development (TDD).  DocTest is an absolutely wonderful tool in
this regard (thanks to Tim Peters!).  I write the assignment as a
collection of tests, which the students are asked to pass one at a time.
They find it fun and empowering, since it helps them break down complex
tasks into simple steps.  More students are able to solve the problem,
and to better understand difficulties they have along the way.

I only discovered DocTest a few weeks ago, but if anyone is interested
in seeing my first attempt at writing lessons with it you can see them
here:

http://linus.yhspatriot.net/cs/cs

(note: this site changes rapidly, so the lessons might not be here
later, but I plan to refine them a bit and put them on the Python
Biblioteca:

http://www.ibiblio.org/obp/pyBiblio/


On Fri, 2005-03-25 at 19:36 +0100, Laura Creighton wrote:
If you want to teach OOP but don't want to teach GUI programming,
it is often convenient to develop some text processing tools, using objects
like 'words' 'paragraphs' 'names' and what have you.

Laura

-- 
Jeffrey Elkner <[EMAIL PROTECTED]>
Open Book Project 

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

_
winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating
___
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

[John Zelle]

Arthur wrote:

-Original Message-
From: [EMAIL PROTECTED] [mailto:edu-sig-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
But there is no real point being made beyond that. If one chooses to
follow
the convention - something like VPython provides a quite convenient way
for
one to get one's DrawableCircle to actually draw, and without the need to
prepare anything in the way of a drawing context - which might otherwise
become the most complex, obscure and least relevant portion of the code.

Actually on a little more thought, it is just the point that Scott already
made.  VPython provides an environment of instantaneous visual feedback.
Visual business can be conducted from the command line.  Change the color
attribute of the object, and the color of the circle instantaneously changes
- not even "no compile cycle", no rerun of code of any kind.  The object
seems in fact like an object - conveys some sense of  tangibility, as an
object should.
I agree that graphics programming is a great, concrete way, to teach 
about objects. That is the point of my 2D graphics library. VPython is 
also a great tool. The one caveat I would make here is that many OO 
designers would say that the approach taken by VPython allowing direct 
attribute access is not good style. Objects should generally be 
manipulated through methods, not by twiddling fields. I know this is 
fairly common in Python, but maybe Vpython is not the best first example 
of object-oriented design.

And thereby seems to exist in an environment naturally adaptable to  the
teaching task at hand.
Art
___
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] Re: Best approach to teaching OOP and graphics

[Linda Grandell]

I dived right into your lessons... Looks *very* good. I am always 
looking for "new" approaches to teaching programming, since this is the 
very topic of my future PhD-thesis. Giving the students a "standard" 
which there programs are to meet should indeed be very motivating and 
pose a positive challenge to all students. My class starts in three 
weeks, so I have some time (not much :) to try out doctest on my own and 
see if it would be suitable for my students. Did your students find it 
difficult to learn and start implementing TDD?

Have you considered using this approach in the exam? One thought that 
came to mind would be to make the grades depend on which test cases the 
programs pass. The test cases could be divided into groups, and in order 
to pass the tests in the "higher grade"-groups, the programs would have 
to be more flexible, advanced and so on than programs passing the basic 
test cases. In this way  the same task could be challenging for all 
students. Finding suitable exam questions can, in my opinion, sometimes 
be really tricky, especially when there is great variation in the 
students' programming skills.

/Linda
Jeffrey Elkner wrote:
One more note on this topic.  I'm quickly coming to the conclusion that
the best way to teach any programming, OOP or otherwise, is using Test
Driven Development (TDD).  DocTest is an absolutely wonderful tool in
this regard (thanks to Tim Peters!).  I write the assignment as a
collection of tests, which the students are asked to pass one at a time.
They find it fun and empowering, since it helps them break down complex
tasks into simple steps.  More students are able to solve the problem,
and to better understand difficulties they have along the way.
I only discovered DocTest a few weeks ago, but if anyone is interested
in seeing my first attempt at writing lessons with it you can see them
here:
http://linus.yhspatriot.net/cs/cs
(note: this site changes rapidly, so the lessons might not be here
later, but I plan to refine them a bit and put them on the Python
Biblioteca:
http://www.ibiblio.org/obp/pyBiblio/
 

___
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

[Arthur]

> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:edu-sig-
> > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> But there is no real point being made beyond that. If one chooses to
> follow
> the convention - something like VPython provides a quite convenient way
> for
> one to get one's DrawableCircle to actually draw, and without the need to
> prepare anything in the way of a drawing context - which might otherwise
> become the most complex, obscure and least relevant portion of the code.
> 

Actually on a little more thought, it is just the point that Scott already
made.  VPython provides an environment of instantaneous visual feedback.
Visual business can be conducted from the command line.  Change the color
attribute of the object, and the color of the circle instantaneously changes
- not even "no compile cycle", no rerun of code of any kind.  The object
seems in fact like an object - conveys some sense of  tangibility, as an
object should.

And thereby seems to exist in an environment naturally adaptable to  the
teaching task at hand.

Art


___
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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:edu-sig-
> [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]

 
> I'd have to see you proposal fleshed out in more detail.  What is the
> triangle a subclass or superclass of?  What are its methods and
> properties?

Its less of a proposal than an observation.  OOP is in fact often introduced
by way of classes of geometric objects, and subclasses thereof.

Java in a Nutshell Second Edition Chapter 3 
"Classes and Object in Java" walks the reader  through the creation of a
Circle class, explains that "Objects are Instances of Classes" and goes from
there in defining constructors, methods, etc. and then eventually
subclassing the Circle class with a DrawableCircle class.

The point is not that this particular book adopts this approach, but that in
so doing it is conforming to something of a convention - or so it seems to
me. Like the 3d teapot, or the "Hello World" program.

But there is no real point being made beyond that. If one chooses to follow
the convention - something like VPython provides a quite convenient way for
one to get one's DrawableCircle to actually draw, and without the need to
prepare anything in the way of a drawing context - which might otherwise
become the most complex, obscure and least relevant portion of the code.

> And what is the VPython framework you'd use to introduce OO?

Uhm... PyGeo ;)

Art


___
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

[[EMAIL PROTECTED]]

>That's where I am being confused.
>
>Graphical programming has nothing necessarily to do with a GUI, so
>I am confused why we are discussing them in any way together.

The key word is "necessarily" and I completely agree.  I was mentioning
several kinds of programming.  GUI programming *is* graphical, in the
sense that "G" stands for "graphical".

It so happens the GUI stuff is almost always OO (I talked about that
in terms of the Nokia 60 cell phone).  I have very limited experience
with OpenGL (or PyOpenGL), but yes, the VPython stuff is obviously OO.
POV-Ray isn't so obviously, if at all -- but if we write a Python layer
on top of POV-Ray (what I like to do), then it makes sense to use OO.

> I don't see GUI programming as a necessarily appropriate 
> environment to introudce OOP.

It's certainly the way a lot of people come into contact with it.  But
you may be right.  I think it's possibly useful as an introductory 
environment, but it could lead to that problem of not understanding
OO concepts generically enough, and getting confused about the difference
between GUI programming and OO.  That seemed to be a confusion we were
worried about in this thread.

> But using the metaphor of geometric objects already *is* the
> canonical way of introducing OOP.  

Yes, could be.  Another canonical metaphor is animals.  The mammal class
is subclassed into dogs, cats, humans and so on.  I've also seen telephones
subclassed as fax-phones, cell phones etc. (all types of phone).

> What VPython, for example, allows is pursuit of the canonical 
> methodology, but cutting directly to an actual implementation,
> rather than working on "as-if" basis.  We wee the triangle, derived
> from our more general geometric object, rather than (or in addition to) 
> only seeing a prompt message saying "I am now a triangle".
>
> Hard for me to see anything but upside in this approach.

I'd have to see you proposal fleshed out in more detail.  What is the
triangle a subclass or superclass of?  What are its methods and properties?
And what is the VPython framework you'd use to introduce OO?

Kirby



mail2web - Check your email from the web at
http://mail2web.com/ .


___
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

[Jeffrey Elkner]

One more note on this topic.  I'm quickly coming to the conclusion that
the best way to teach any programming, OOP or otherwise, is using Test
Driven Development (TDD).  DocTest is an absolutely wonderful tool in
this regard (thanks to Tim Peters!).  I write the assignment as a
collection of tests, which the students are asked to pass one at a time.
They find it fun and empowering, since it helps them break down complex
tasks into simple steps.  More students are able to solve the problem,
and to better understand difficulties they have along the way.

I only discovered DocTest a few weeks ago, but if anyone is interested
in seeing my first attempt at writing lessons with it you can see them
here:

http://linus.yhspatriot.net/cs/cs

(note: this site changes rapidly, so the lessons might not be here
later, but I plan to refine them a bit and put them on the Python
Biblioteca:

http://www.ibiblio.org/obp/pyBiblio/


On Fri, 2005-03-25 at 19:36 +0100, Laura Creighton wrote:
> If you want to teach OOP but don't want to teach GUI programming,
> it is often convenient to develop some text processing tools, using objects
> like 'words' 'paragraphs' 'names' and what have you.
> 
> Laura

-- 
Jeffrey Elkner <[EMAIL PROTECTED]>
Open Book Project 

___
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

[ajsiegel]

- Original Message -
From: Dan Crosta <[EMAIL PROTECTED]>

> As my prof said: "if you ever figure out how students actually 
> learn to
> program, be sure to let me know..." :)

With a copy to edu-sig@python.org, if they would be so kind ;).

Art

___
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

[Laura Creighton]

If you want to teach OOP but don't want to teach GUI programming,
it is often convenient to develop some text processing tools, using objects
like 'words' 'paragraphs' 'names' and what have you.

Laura
___
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

[Dan Crosta]

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

RE: [Edu-sig] Re: Best approach to teaching OOP and graphics

[Dan Crosta]

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

[ajsiegel]

- Original Message -
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>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 
> graphicalprogramming?   You can write highly object oriented code 
> that has no GUI

That's where I am being confused.

Graphical programming has nothing necessarily to do with a GUI, so
I am confused why we are discussing them in any way together.

VPython and Povray being 2 examples that immediately 
come to mind.

I don't see GUI programming as a necessarily appropriate 
environment to introudce OOP.

But using the metaphor of geometric objects already *is* the
canonical way of introducing OOP.  

What VPython, for example, allows is pursuit of the canonical 
methodology, but cutting directly to an actual implementation,
rather than working on "as-if" basis.  We wee the triangle, derived
from our more general geometric object, rather than (or in addition to) 
only seeing a prompt message saying "I am now a triangle".

Hard for me to see anything but upside in this approach.

Art


___
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

[[EMAIL PROTECTED]]

Original Message:
-
From: Dan Crosta [EMAIL PROTECTED]
Date: Fri, 25 Mar 2005 11:52:37 -0500 (EST)
To: edu-sig@python.org
Subject: [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. 

Although we sound like a disagreeable bunch perhaps, I think we're all in
general agreement.

Graphics programming is very OOPish in most implementations and it makes a 
whole lot of sense to do graphical programming (GUIs, games, whatever) 
using objects.

The typical think is to export an API in the form of objects with methods
and properties.  This is how every Pythonic graphics library I'm aware of
works.  You import a module and you get access to a lot of GUI widgets in 
the form of objects with methods.  You can subclass these widgets or compose
them, the way OOPers always do.  Typically, we instantiate a window or
frame object (some canvas deal) and populate it with buttons, pull-downs
and whatever it is.  Typically, clicking or mousing over results in events,
which our code traps, often by means of callbacks, but maybe by means of
the observable/observer design pattern (like Java's).  Typically the events
themselves are objects (e.g. mouse over events).

I just saw a demo of using Python on the Nokia 60-series (a cell phone
model).  Same thing:  a little phone-specific API is imported and appears
to the programmer as objects.

>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.

Absolutely.  I bet we all agree.

>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

I'm a little confused why you'd bring up Java/AWT/Swing as your example 
of doing some procedural stuff with graphics, as this language is highly
object oriented in the way you described previously.

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.

Kirby

Other fun things at Pycon 2005:

Python used to write a prototype Air Traffic Control system (prototype only
in the sense that it's not commercial yet -- not in the sense that the
"real" version would be written in something else (it'd stay Python)).

Python used in a language teaching engine with Unreal Tournament 2003 as
the simulator (showing fictional Iraqi town) and a speech recognizer. 
Soldiers train on this before going to Iraq.  The mission is basically one
of "take me to your leader" except it's more "Hi, I'm Joe, this is my team,
where's your main guy and could you please give me directions" (all in
Arabic, with the detailed directions likewise in Arabic).

I did a presentation on Hypertoons that generated some interest.



mail2web - Check your email from the web at
http://mail2web.com/ .


___
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

[Dan Crosta]

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

[Edu-sig] Re: Best approach to teaching OOP and graphics

[Scott David Daniels]

Linda Grandell wrote:
How about making a small graphics library that has Shape objects. You 
create a shape object and manipulate it's attributes such as position, 
color, size, numOfVertices (triangle, square, pentagram), etc. Then 
you can teach subclassing a shape object, and finally making your own 
from scratch. PyGame of course is a great environment to build such a 
thing.
This sounds like a good idea. I was thinking about using the pygsear
package first, mainly because I then would have ready-made material and
examples to start from. The course starts in three weeks, so I am not
really spoiled with time here. However, your suggestion should not take
that long to implement. I will put it on my list of possible alternatives.
Take a look at VPython.  It is the simplest to grasp how to put a
few things on the screen; it has a nice small set of 3-D primitives,
and a quick intro to get a small display going.  Really easier than
most 2-D packages I've seen to start with, and you get to roll it
around.  If you are at PyCon, talk to Kirby about his experiences
using it in his classes.
/Linda

--
-- Scott David Daniels
[EMAIL PROTECTED]
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig