General Programming Education

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

General Programming Education

Corey Richardson

I was discussing programing with some peers at an MIT summer program, and
many of them came from the "JAVA AND OOP!" type of places to the point that,
when the opportunity came up for them to learn the basics in a seminar, a
few said "Pfff, but python sucks. It's too simple". Is it just me, or should
simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
     -- Abraham Lincoln

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

Carl Cerecke-4
To the 'Pfff, but python sucks. It's too simple' crowd, you can pretty much ignore them - that or get some code off code.activestate.com that does something gnarly to show off. I've even got a recipe on there, but it's probably not the best one for Java programmers (or python programmers, come to think of it :-)

As for teaching programming, I recommend staying away from classes at the start, but introducing objects early. Students can easily understand the idea of objects and methods before learning about classes, because lists, strings, dicts, etc are objects with methods. Once they are familiar with built in classes/types, then you can introduce custom types (classes) to them.

I've just had the first week of a semester teaching python to stage 1 Computer Science students, and that's how we're doing it (and have done it in the past) with reasonably good success.

Cheers,
Carl.

On 15 July 2011 15:20, Corey Richardson <[hidden email]> wrote:

I was discussing programing with some peers at an MIT summer program, and
many of them came from the "JAVA AND OOP!" type of places to the point that,
when the opportunity came up for them to learn the basics in a seminar, a
few said "Pfff, but python sucks. It's too simple". Is it just me, or should
simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
 "Those who deny freedom to others, deserve it not for themselves"
    -- Abraham Lincoln

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

Charles Cossé
In reply to this post by Corey Richardson
Hi, Python's simplicity allows programmers to focus on the job that they originally set out to do (as opposed to getting side-tracked and bogged-down by language overhead considerations).   Very often a procedure is challenging enough to work through without any unnecessary overhead.  Heck, I think it's safe to say that nobody needs overhead added unnecessarily in any circumstance.  BTW, there is the jython language, which is exactly python with access to the jdk via python syntax ... thereby making Java (appear as) a subset of Python (whereas it's really an implementation of Python written in Java!). 

As far as the teaching in general, I think introducing via procedural and motivating oop by example would be a good approach. 

Best Regards,
Charles Cossé

(sorry for 2x emails Corey -- 1st one didn't cc edu-sig)

On Thu, Jul 14, 2011 at 9:20 PM, Corey Richardson <[hidden email]> wrote:

I was discussing programing with some peers at an MIT summer program, and
many of them came from the "JAVA AND OOP!" type of places to the point that,
when the opportunity came up for them to learn the basics in a seminar, a
few said "Pfff, but python sucks. It's too simple". Is it just me, or should
simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
 "Those who deny freedom to others, deserve it not for themselves"
    -- Abraham Lincoln

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig




--
AsymptopiaSoftware|Software@theLimit
          http://www.asymptopia.org

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

Laura Creighton-2
In reply to this post by Corey Richardson
In a message of Thu, 14 Jul 2011 23:20:06 EDT, Corey Richardson writes:

>a few said "Pfff, but python sucks. It's too simple". Is it just me, or
>should simplicity be a Good Thing? </rant>

It is not just you.  I think these people may be members of the
'misery loves company' crowd.  ``It was hard for me to learn it, so it
had better be hard for you, too.''  Or the ``suffering builds
character'' crowd.  Or the ``programming is an elite business -- we
wouldn't want just anybody doing it´´.  Possibly they just hate
fun, and get annoyed at the idea that it might be fun to program in
Python.  I've met all of the above.  Pity their students.  Of course,
some just have too optimitic a view of the human condition.  They
reason that there must be something good about all the complexity of
java -- even if it is not obvious to them - or else we would have
stopped using it already.  They just need a lesson in the inertia
of human institutions.

<snip>

>Any other insights?

Python already has a lot of very nice data types.  The dictionary is a
wonderful thing.  People should _use_ them.  Many people who have been
taught the OOP religion automatically refactor every dictionary they
find into a class with attributes, because they think that this is in
some way 'better'.  This is dead wrong.  If you refuse to use the very
high level abstractions out of your VHLL, and only stick to the Low
Level abstractions, then you might as well be programming in a LLL
such as Java.  That some of your colleagues apparantly did not
recognise that the reason that Python is simpler is because it is a
VHLL -- because simplicity in expressing ideas in the hallmark of a
VHLL -- does not speak very well for them.

Laura

>Corey Richardson

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

kirby urner-4
In reply to this post by Corey Richardson
On Thu, Jul 14, 2011 at 8:20 PM, Corey Richardson <[hidden email]> wrote:

<< SNIP >>
 
But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
 "Those who deny freedom to others, deserve it not for themselves"
    -- Abraham Lincoln


I like the Lincoln quote.

Many approaches have validity of course, especially in the hands
of someone experienced who keeps it interesting.

When I first splashed into programming, OOP had yet to hit, but
it wasn't like there wasn't already a veritable menagerie of amazing
languages -- even sans OOP. 

Like, we had SNOBOL and APL and PL/1 (just a few I got to mess
around in).

I transitioned to OOP along the xBase track, as many did:
dBase II, dbase III, dBase IV, Clipper, FoxPro, FoxPro for
Windows, and Visual FoxPro (VFP).

Some of my peers along that track are just beginning to appreciate
Python, now that Microsoft has signaled it's pulling the plug on
VFP.

http://fox.wikis.com/wc.dll?Wiki~VFPRoadMapDiscussion

The J community (J being a successor to APL (or a mutant
child of?)) uses a grammar-teaching approach to teaching
programming, referring to verbs, nouns, adverbs, other parts
of speech as parts of its language.

http://www.cs.trinity.edu/~jhowland/math-talk/functional1/

Following that model, I sometimes teach OOP by writing
things like:

noun.verb(args)
thing.adjective
thing.verb()
noun.property

and so on, deliberately confusing "parts of speech" talk with the
OOPy stuff.  Then I teach looking at the world that way, not using
a computer language.  What are the properties and behaviors
of a flower?  A panda?  Analyze an airport in terms of its objects
and processes.  Come back to computers when you're ready,
take your time.

But then when I can get away with it, my topic is not "programming"
or "CS" but a more exotically named "digital math" or (last year)
"martian math".  In the more formal presentations, the latter is
a topic area within the former:

http://wikieducator.org/Digital_Math

In this approach, you want to develop an awareness of types
(types of things -- like types of biotum) and their respective
namespaces.  This dovetails with Carl's focus on objects
before classes. 

A "list" is a convergence of many concepts, a "dict" is another,
an "int" yet another and so on.  A "type" is not just a simple
thing.  Knowing about types helps us learn about math,
with its concentric N, Z, Q, R and C types.

In treating computer languages as math notations, we're
treading somewhat in the footsteps of Russell and Frege (etc.),
except we're using Stallman type tools for building our
machinery, more than the tools of the so-called analytic
philosophers (Quine etc.)

Kirby

@ Pacific Lutheran University (PLU)
(visiting)


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

mokurai-2
In reply to this post by Corey Richardson
On Thu, July 14, 2011 11:20 pm, Corey Richardson wrote:
>
> I was discussing programing with some peers at an MIT summer program,
and
> many of them came from the "JAVA AND OOP!" type of places to the point
that,
> when the opportunity came up for them to learn the basics in a seminar, a
> few said "Pfff, but python sucks. It's too simple". Is it just me, or
should
> simplicity be a Good Thing? </rant>

http://www.pbm.com/~lindahl/real.programmers.html
Real Programmers Don't Use Pascal

> But, my real question to you educators is, which paradigm do you use
when first teaching programming, and why?

I'm working with a different age group than you, but I start by mixing
object programming and procedural programming. I use Turtle Art in the
Sugar education suite for One Laptop Per Child XOs, now ported to several
kinds of Linux. We begin with one object, and we send it a stream of
messages to tell it what to do. One of the advantages is that the program
elements are snap-together tiles/blocks rather than text, so that it is
impossible to mistype a keyword or make a syntax error. Another advantage
is that the children learn to work directly with the parse trees of
programs before learning to write them in linear text.

Then we have a choice of transitioning to Python, supported directly
within Turtle Art using program blocks; Logo, which we can create as an
export option from Turtle Art; or the Etoys environment for Smalltalk,
which can also do turtle graphics using tile-based programming. There are
also stack primitives in TA, so that we can introduce RPN and FORTH
concepts. I am working on a set of lessons on all of this. Tony Forster is
also contributing topics handled in Turtle Art.

http://wiki.sugarlabs.org/go/Turtle_Art/Tutorials

Marvin Minsky (born 1927)

    You don't understand anything until you learn it more than one way.

    In Rebecca Herold, Managing an Information Security and Privacy
Awareness and Training Program (2005), 101.

    We like to think that a child's play is unconstrained—but when
children appear to feel joyous and free, this may merely hide from
their minds their purposefulness; you can see this more clearly when
you attempt to drag them away from their chosen tasks. For they are
exploring their worlds to see what's there, making explanations of
what those things are, and imagining what else could be; exploring,
explaining and learning are among a child's most purposeful urges and
goals. The playfulness of childhood is the most demanding teacher we
have. Never again in those children's lives will anything drive them
to work so hard.

    The Emotion Machine

We have many studies of successful introduction of programming in third
grade, using a variety of languages, but we do not know how much earlier
we can begin. Preschoolers can be introduced to Turtle Art with the game
You be the Turtle. I have proposed a version of Turtle Art with icons
instead of words on the blocks, so that we can test how much of it the
preliterate can manage. There are several visual forms of digits that
children can read directly by counting elements, usually dots or lines. I
use colors for variable and procedure names, and skip over text input and
output until later.

My most advanced CS example, not suitable for very small children, is a
Turing Machine implemented in Turtle Art.

--
Edward Mokurai
(&#40664;&#38647;/&#2343;&#2352;&#2381;&#2350;&#2350;&#2375;&#2328;&#2358;&#2348;&#2381;&#2342;&#2327;&#2352;&#2381;&#2332;/&#1583;&#1726;&#1585;&#1605;&#1605;&#1740;&#1711;&#1726;&#1588;&#1576;&#1583;&#1711;&#1585;
&#1580;) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

Richard Enbody
In reply to this post by Carl Cerecke-4
We do it that way. Use lots of methods for strings, lists and dictionaries effectively "use objects first".  Later we teach how to build classes.  We switched our CS1 to Python back in 2007 and that approach has worked well to prepare our students for CS2 in C++.

-rich
[hidden email]
"The Practice of Computing using Python" by Punch & Enbody

On 7/15/11 12:00 AM, Carl Cerecke wrote:
To the 'Pfff, but python sucks. It's too simple' crowd, you can pretty much ignore them - that or get some code off code.activestate.com that does something gnarly to show off. I've even got a recipe on there, but it's probably not the best one for Java programmers (or python programmers, come to think of it :-)

As for teaching programming, I recommend staying away from classes at the start, but introducing objects early. Students can easily understand the idea of objects and methods before learning about classes, because lists, strings, dicts, etc are objects with methods. Once they are familiar with built in classes/types, then you can introduce custom types (classes) to them.

I've just had the first week of a semester teaching python to stage 1 Computer Science students, and that's how we're doing it (and have done it in the past) with reasonably good success.

Cheers,
Carl.

On 15 July 2011 15:20, Corey Richardson <[hidden email]> wrote:

I was discussing programing with some peers at an MIT summer program, and
many of them came from the "JAVA AND OOP!" type of places to the point that,
when the opportunity came up for them to learn the basics in a seminar, a
few said "Pfff, but python sucks. It's too simple". Is it just me, or should
simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
 "Those who deny freedom to others, deserve it not for themselves"
    -- Abraham Lincoln

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig




_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

A. Jorge Garcia
Richard Enbody <[hidden email]> wrote:
We do it that way. Use lots of methods for strings, lists and dictionaries effectively "use objects first".  Later we teach how to build classes.  We switched our CS1 to Python back in 2007 and that approach has worked well to prepare our students for CS2 in C++.

-rich
[hidden email]
"The Practice of Computing using Python" by Punch & Enbody

On 7/15/11 12:00 AM, Carl Cerecke wrote:
To the 'Pfff, but python sucks. It's too simple' crowd, you can pretty much ignore them - that or get some code off code.activestate.com that does something gnarly to show off. I've even got a recipe on there, but it's probably not the best one for Java programmers (or python programmers, come to think of it :-)

As for teaching programming, I recommend staying away from classes at the start, but introducing objects early. Students can easily understand the idea of objects and methods before learning about classes, because lists, strings, dicts, etc are objects with methods. Once they are familiar with built in classes/types, then you can introduce custom types (classes) to them.

I've just had the first week of a semester teaching python to stage 1 Computer Science students, and that's how we're doing it (and have done it in the past) with reasonably good success.

Cheers,
Carl.

On 15 July 2011 15:20, Corey Richardson <[hidden email]> wrote:

I was discussing programing with some peers at an MIT summer program, and
many of them came from the "JAVA AND OOP!" type of places to the point that,
when the opportunity came up for them to learn the basics in a seminar, a
few said "Pfff, but python sucks. It's too simple". Is it just me, or should
simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when
first teaching programming, and why? My peers cite OOP because, frankly,
it's the only thing they've learned and have heard that e.g. procedural
programming is bad. Personally, I like to use procedural (this is in
Python, of course) for as long as possible. I don't even mention objects
for a while, they aren't necessary or even desirable in many instances.
I love using games as a project, and that's when I swoop in and bring up
objects. My segue are usually the monsters of a text based game. I don't
have them design an object for everything because it introduces complexity
without benefit. Of course, it's not as flexible/correct a program as it
could be, but it's a nice slow ease into OOP. But it certainly isn't the
ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights?
--
Corey Richardson
 "Those who deny freedom to others, deserve it not for themselves"
    -- Abraham Lincoln

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig




_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig

We have a year of Python and Discrete Math using SAGE as an intro to programming. We follow this with AP Computer Science and Java. In Computer Math we don't address objects. In Computer Science we do "objects first!"
Thanx,
A. Jorge Garcia
Applied Math and CompSci
http://shadowfaxrant.blogspot.com
http://www.youtube.com/calcpage2009
Sent via DROID on Verizon Wireless
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

Kirby Urner-6
In reply to this post by mokurai-2

Then we have a choice of transitioning to Python, supported directly
within Turtle Art using program blocks; Logo, which we can create as an
export option from Turtle Art; or the Etoys environment for Smalltalk,
which can also do turtle graphics using tile-based programming. There are
also stack primitives in TA, so that we can introduce RPN and FORTH
concepts. I am working on a set of lessons on all of this. Tony Forster is
also contributing topics handled in Turtle Art.

http://wiki.sugarlabs.org/go/Turtle_Art/Tutorials


I only found an empty page here.  Coming soon?

There's a lot of good turtle stuff out there in Python.

Gregor is a resident master.

        *      *     *

My sense is there's no shortage of anything except a willingness to try new things.

Innovation is hard to accomplish at the end of the day, simply because it's easier to keep doing what you were doing  -- until it's not.

Freeing up schools to try new things means not locking them in to pre-specified curricula complete with state mandated texts and tests.

Not everyone has such freedoms.

Kirby

Note:


I've got very primitive "tractor" objects in a field of ascii, just to show off 2d data structures, draw Mandelbrots, play Life (OST servers).

One of the freakiest tractors is a generator that implements the "send" feature in a weird way:

http://www.4dsolutions.net/ocn/python/OST/thefarm.py
(you can refuel it, change direction, change the mark it makes when it plows)

... depends on the Farm class (a 2d field) here:
http://www.4dsolutions.net/ocn/python/OST/farmworld.py

Here's a silly drawing of how I think of it:
http://www.4dsolutions.net/ocn/python/OST/farmer_gen.jpg



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: General Programming Education

mokurai-2

On Fri, July 15, 2011 2:14 pm, Kirby Urner wrote:

>> Then we have a choice of transitioning to Python, supported directly
>> within Turtle Art using program blocks; Logo, which we can create as an
>> export option from Turtle Art; or the Etoys environment for Smalltalk,
>> which can also do turtle graphics using tile-based programming. There
>> are
>> also stack primitives in TA, so that we can introduce RPN and FORTH
>> concepts. I am working on a set of lessons on all of this. Tony Forster
>> is also contributing topics handled in Turtle Art.
>>
>> http://wiki.sugarlabs.org/go/Turtle_Art/Tutorials

Ah, yes. http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Tutorials

My apologies.

> I only found an empty page here.  Coming soon?
>
> There's a lot of good turtle stuff out there in Python.
>
> Gregor is a resident master.
>
>         *      *     *
>
> My sense is there's no shortage of anything except a willingness to try
> new things.
>
> Innovation is hard to accomplish at the end of the day, simply because
> it's easier to keep doing what you were doing  -- until it's not.
>
> Freeing up schools to try new things means not locking them in to
> pre-specified curricula complete with state mandated texts and tests.
>
> Not everyone has such freedoms.
>
> Kirby
>
> Note:
>
>
> I've got very primitive "tractor" objects in a field of ascii, just to
> show
> off 2d data structures, draw Mandelbrots, play Life (OST servers).
>
> One of the freakiest tractors is a generator that implements the "send"
> feature in a weird way:
>
> http://www.4dsolutions.net/ocn/python/OST/thefarm.py
> (you can refuel it, change direction, change the mark it makes when it
> plows)
>
> ... depends on the Farm class (a 2d field) here:
> http://www.4dsolutions.net/ocn/python/OST/farmworld.py
>
> Here's a silly drawing of how I think of it:
> http://www.4dsolutions.net/ocn/python/OST/farmer_gen.jpg
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
>


--
Edward Mokurai
(&#40664;&#38647;/&#2343;&#2352;&#2381;&#2350;&#2350;&#2375;&#2328;&#2358;&#2348;&#2381;&#2342;&#2327;&#2352;&#2381;&#2332;/&#1583;&#1726;&#1585;&#1605;&#1605;&#1740;&#1711;&#1726;&#1588;&#1576;&#1583;&#1711;&#1585;
&#1580;) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig