From kirby.urner at gmail.com  Mon Apr  2 18:52:01 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Apr 2012 09:52:01 -0700
Subject: [Edu-sig] edu-sig in Pythonia
Message-ID: <CAPJgG3QXZvQ1-HVsKedP1Yp3EVh024O3VQwLf=seGan4niokJA@mail.gmail.com>

A few of us at Pycon were nodding heads (+1ing)
over the idea that our subculture / ethnicity could
evolve these "canned talks" that different people
deliver in their personalized style.  More than that,
they demonstrate new "teaching techniques" such
that the audience might appreciate how advances
in pedagogy -- and in andragogy -- still occur.

Consider the O'Reilly 'Head First Into...' series.
Like 'for Dummies', it explains up front that there's
psychology at work, smart cookies have baked a
new mix of graphic art, sound bites, who knows
what's coming, and you, the reader / student are
in for a treat.  But then books, like videos, are a
somewhat passive medium.  Once you jump on
that gym equipment, that treadmill, that weight
pump, you know there's more to the educational
experience than having your butt in a chair.

Among the canned topics would be ArgsKwargs.
Everyone learning Python needs to keep spiraling
through the ArgsKwargs literature, wherein we do
what in other languages might be called gathering
and scattering.  The star and double star, which
C-language readers are used to seeing anyway
in function headers etc., have become scavengers,
accepting / liberal "all may pass" type guards at the
gate (function entrance), and yet still there are rules
(positionals before keyword).  Used when passing
arguments, the star and double-star are "exploders"
(scatterers), setting free their tuples and dicts to
mingle as individuals.

>>> def baby(skin="soft", noise_might_be = "crying", **blahblah):
    print ("Hey baby, I notice the {} skin, and the {} noise you're
making".format(skin, noise_might_be))
    print(blahblah)


>>> random_keys = {"safe":"12-15-44", "skin":"purple", "tomorrow":"wash
car"}
>>> baby(**random_keys)
Hey baby, I notice the purple skin, and the crying noise you're making
{'safe': '12-15-44', 'tomorrow': 'wash car'}

Another canned talk -- could be lightning format --
is IterStuff, beginning with the difference between
an iterator and an iterable, climbing through
generators (with plenty of send use) to iterator
defining classes, to itertools more generally, and
a discussion of "just in time" versus pre-stocking
memory with impossibly huge inventories.

Here I'd suggest a lore-based approach wherein
we go over how Python itself has become ever more
fascinated with iterators.  How is it that a range class
object is a sequence (indexable) whereas the
dict_items object is not (not indexable)?

>>> dict(a=1,b=2).items()[0]
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    dict(a=1,b=2).items()[0]
TypeError: 'dict_items' object does not support indexing
>>> range(2)[0]
0

Then there'd be the protocol talks i.e. lets talk about
interfaces in the abstract.  The iterator is our first example,
in being about having __iter__ and __next__.  Then
comes the descriptor and its interface / protocol.

The point being:  we should always have these talks.

There will always be people new to Python (in this
model), or people wanting a refresher and (here's
the kicker) people needing practice in their teaching
techniques in front of an audience that's already very
much in the ballpark (already at a Pycon, not just
casually dropping by to see what this might be about).

Also:  the people most interested in teaching Python,
such as here on edu-sig, should be most involved in
organizing this track.

The track of standard topics, things we all need to
know -- but how best to share?  That track and that
question are one of our angles / self-chosen
responsibilities, along with the poster session.

I would extend this philosophy to say edu-sig types
should also take some 3rd party modules under their
collective wing, by which I mean to include such worthies
as:  Visual Python, I-Python, matplotlib, numpy, Blender
and web frameworks (including Google App Engine).

OK, now that's starting to sound like a complete Pycon,
not just a track.  Fair enough.

The edu-sig "base" is around a track of core topics.
Then each topic is conceived to "branch off" into
various "worlds" or "namespaces".  E.g the IterStuff
branches off into Twisted and asynchronous techniques
such as David Beazely has specialized in inventing and
teaching.  We'd need more diagrams, roadmaps, to
show the "lay of the land" (Pythonia).  Seeing it one
way doesn't preclude also seeing it in other ways too.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120402/b4a9a6d8/attachment.html>

From goodmansond at gmail.com  Mon Apr  2 19:07:51 2012
From: goodmansond at gmail.com (DeanG)
Date: Mon, 2 Apr 2012 12:07:51 -0500
Subject: [Edu-sig] edu-sig in Pythonia
In-Reply-To: <CAPJgG3QXZvQ1-HVsKedP1Yp3EVh024O3VQwLf=seGan4niokJA@mail.gmail.com>
References: <CAPJgG3QXZvQ1-HVsKedP1Yp3EVh024O3VQwLf=seGan4niokJA@mail.gmail.com>
Message-ID: <CAM9XDdxXd=rJzOVwgHc0fMyAf8NDjKR9MbYMePDbRj3_Lgcv7Q@mail.gmail.com>

+1

Regarding the  Args Kwargs, Matt Harrisons "Guide to: Learning Python
Decorators" was a great read for this topic.
http://www.amazon.com/Guide-Learning-Python-Decorators-ebook/dp/B006ZHJSIM


On Mon, Apr 2, 2012 at 11:52 AM, kirby urner <kirby.urner at gmail.com> wrote:
>
> A few of us at Pycon were nodding heads (+1ing)
> over the idea that our subculture / ethnicity could
> evolve these "canned talks" that different people
> deliver in their personalized style.? More than that,
> they demonstrate new "teaching techniques" such
> that the audience might appreciate how advances
> in pedagogy -- and in andragogy -- still occur.
>
> Consider the O'Reilly 'Head First Into...' series.
> Like 'for Dummies', it explains up front that there's
> psychology at work, smart cookies have baked a
> new mix of graphic art, sound bites, who knows
> what's coming, and you, the reader / student are
> in for a treat.? But then books, like videos, are a
> somewhat passive medium.? Once you jump on
> that gym equipment, that treadmill, that weight
> pump, you know there's more to the educational
> experience than having your butt in a chair.
>
> Among the canned topics would be ArgsKwargs.
> Everyone learning Python needs to keep spiraling
> through the ArgsKwargs literature, wherein we do
> what in other languages might be called gathering
> and scattering.? The star and double star, which
> C-language readers are used to seeing anyway
> in function headers etc., have become scavengers,
> accepting / liberal "all may pass" type guards at the
> gate (function entrance), and yet still there are rules
> (positionals before keyword).? Used when passing
> arguments, the star and double-star are "exploders"
> (scatterers), setting free their tuples and dicts to
> mingle as individuals.
>
>>>> def baby(skin="soft", noise_might_be = "crying", **blahblah):
> ??? print ("Hey baby, I notice the {} skin, and the {} noise you're
> making".format(skin, noise_might_be))
> ??? print(blahblah)
>
>
>>>> random_keys = {"safe":"12-15-44", "skin":"purple", "tomorrow":"wash
>>>> car"}
>>>> baby(**random_keys)
> Hey baby, I notice the purple skin, and the crying noise you're making
> {'safe': '12-15-44', 'tomorrow': 'wash car'}
>
> Another canned talk -- could be lightning format --
> is IterStuff, beginning with the difference between
> an iterator and an iterable, climbing through
> generators (with plenty of send use) to iterator
> defining classes, to itertools more generally, and
> a discussion of "just in time" versus pre-stocking
> memory with impossibly huge inventories.
>
> Here I'd suggest a lore-based approach wherein
> we go over how Python itself has become ever more
> fascinated with iterators.? How is it that a range class
> object is a sequence (indexable) whereas the
> dict_items object is not (not indexable)?
>
>>>> dict(a=1,b=2).items()[0]
> Traceback (most recent call last):
> ? File "<pyshell#0>", line 1, in <module>
> ??? dict(a=1,b=2).items()[0]
> TypeError: 'dict_items' object does not support indexing
>>>> range(2)[0]
> 0
>
> Then there'd be the protocol talks i.e. lets talk about
> interfaces in the abstract.? The iterator is our first example,
> in being about having __iter__ and __next__.? Then
> comes the descriptor and its interface / protocol.
>
> The point being:? we should always have these talks.
>
> There will always be people new to Python (in this
> model), or people wanting a refresher and (here's
> the kicker) people needing practice in their teaching
> techniques in front of an audience that's already very
> much in the ballpark (already at a Pycon, not just
> casually dropping by to see what this might be about).
>
> Also:? the people most interested in teaching Python,
> such as here on edu-sig, should be most involved in
> organizing this track.
>
> The track of standard topics, things we all need to
> know -- but how best to share?? That track and that
> question are one of our angles / self-chosen
> responsibilities, along with the poster session.
>
> I would extend this philosophy to say edu-sig types
> should also take some 3rd party modules under their
> collective wing, by which I mean to include such worthies
> as:? Visual Python, I-Python, matplotlib, numpy, Blender
> and web frameworks (including Google App Engine).
>
> OK, now that's starting to sound like a complete Pycon,
> not just a track.? Fair enough.
>
> The edu-sig "base" is around a track of core topics.
> Then each topic is conceived to "branch off" into
> various "worlds" or "namespaces".? E.g the IterStuff
> branches off into Twisted and asynchronous techniques
> such as David Beazely has specialized in inventing and
> teaching.? We'd need more diagrams, roadmaps, to
> show the "lay of the land" (Pythonia).? Seeing it one
> way doesn't preclude also seeing it in other ways too.
>
> Kirby
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>

From kirby.urner at gmail.com  Mon Apr  2 19:41:24 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Apr 2012 10:41:24 -0700
Subject: [Edu-sig] edu-sig in Pythonia
In-Reply-To: <CAM9XDdxXd=rJzOVwgHc0fMyAf8NDjKR9MbYMePDbRj3_Lgcv7Q@mail.gmail.com>
References: <CAPJgG3QXZvQ1-HVsKedP1Yp3EVh024O3VQwLf=seGan4niokJA@mail.gmail.com>
	<CAM9XDdxXd=rJzOVwgHc0fMyAf8NDjKR9MbYMePDbRj3_Lgcv7Q@mail.gmail.com>
Message-ID: <CAPJgG3SGQTTzFia2BSbZ95209M7ouv_=pvff78cK+TZG-=UJ0Q@mail.gmail.com>

On Mon, Apr 2, 2012 at 10:07 AM, DeanG <goodmansond at gmail.com> wrote:

> +1
>
> Regarding the  Args Kwargs, Matt Harrisons "Guide to: Learning Python
> Decorators" was a great read for this topic.
> http://www.amazon.com/Guide-Learning-Python-Decorators-ebook/dp/B006ZHJSIM
>
>

I'm quite tempted to buy a Kindle.  I had no idea there was a whole Kindle
book on decorators.

Yes, decorators would have to be another one of those Standard Gotta Have
It track talks we edu-siggers are focused on.

ArgsKwags, IterStuff, Decorators, Metaclasses, Introspection... Dialectical
Differences

Library:  talks always welcome, standard usergroup fare (Portland's groups
always has Module of the Month)

3rd party:  IDEs (e.g. I-Python), VIsualization (e.g. Blender, VPython,
Pygame, matplotlib). Web (Django, web2py, Google App Engine)

Python plays well with others, so a lot of Design Patterns stuff relating
to OO in general would could push off to those OSCON type events where we
have Java, Python, Ruby, Perl, C++ all under one big tent.

There should be like OO track topics that don't count against the Python
quota, if ya know what I mean.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120402/b521bdaf/attachment-0001.html>

From matthewharrison at gmail.com  Mon Apr  2 19:59:53 2012
From: matthewharrison at gmail.com (Matt Harrison)
Date: Mon, 2 Apr 2012 11:59:53 -0600
Subject: [Edu-sig] edu-sig in Pythonia
In-Reply-To: <CAPJgG3SGQTTzFia2BSbZ95209M7ouv_=pvff78cK+TZG-=UJ0Q@mail.gmail.com>
References: <CAPJgG3QXZvQ1-HVsKedP1Yp3EVh024O3VQwLf=seGan4niokJA@mail.gmail.com>
	<CAM9XDdxXd=rJzOVwgHc0fMyAf8NDjKR9MbYMePDbRj3_Lgcv7Q@mail.gmail.com>
	<CAPJgG3SGQTTzFia2BSbZ95209M7ouv_=pvff78cK+TZG-=UJ0Q@mail.gmail.com>
Message-ID: <CAGp0cSLqpjAcYxNRiCBnhtJvQ8HsckU8+6RkHWqvgHWa70xvZQ@mail.gmail.com>

Dean-

Thanks for including me on this topic. (Just subscribed to the list).

Rest-

As the author of said book, tutorial presenter at PyCON and co-wrangler of
the local Python group, I think it is important to remember the newbies. My
Intermediate Python tutorial has consistently been one of the top PyCon
tutorials. It doesn't have really anything new, but condenses a lot of
information that I wish someone had provided to me. It is nothing sexy, but
is a stepping stone for more advanced stuff. My short books are an attempt
to provide these stepping stones in a condensed format. The assumption that
all attendees are experts at PyCON, local user groups, etc is not true.
There are quite a few people interested in the stone stepping.

-matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120402/7e45992c/attachment.html>

From kirby.urner at gmail.com  Tue Apr  3 19:09:27 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 3 Apr 2012 10:09:27 -0700
Subject: [Edu-sig] transforming CS at Harvey Mudd
Message-ID: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>

Picked off the math-teach list (where I'm active).

Mentions Python (as part of what made CS less intimidating).

Kirby


===

April 2, 2012
Giving Women the Access Code
By KATIE HAFNER

CLAREMONT, Calif. ? When Maria Klawe became president of Harvey Mudd
College in 2006, she was dismayed ? but not surprised ? at how few
women were majoring in computer science.

A mathematician and computer scientist herself, she arrived at Harvey
Mudd (the smallest of the five so-called Claremont Colleges) in the
midst of a nationwide downturn for women in computer science. As
recently as 1985, 37 percent of graduates in the field were women; by
2005 it was down to 22 percent, and sinking.

And the situation at Mudd was even grimmer. Of the college?s 750
students, about a third were women (the figure is now closer to half),
but for years the percentage of computer science graduates had been
hovering around the single digits.

How Dr. Klawe (pronounced KLAH-vay) and her faculty turned things
around ? this year, nearly 40 percent of Harvey Mudd?s computer
science degrees will go to women ? sheds light on a gender gap that
elsewhere remains stubbornly resistant to changing times.

Thanks in part to companies like Facebook, Yelp and Zynga and in part
to cultural sensations like the movie ?The Social Network,? coders are
hip and computer science is hot. Departments across the nation are
brimming with students.

But those students are overwhelmingly male. In 2010, just 18.2 percent
of undergraduates in the field were women, according to the National
Center for Education Statistics ? in spite of gains in chemistry,
biomechanical engineering and other so-called STEM fields (the acronym
stands for science, technology, engineering and mathematics).

?It must be the unique area of science and technology where women have
made negative progress,? said Nicholas Pippenger, a mathematics
professor at Harvey Mudd, who is married to Dr. Klawe.

Dr. Klawe and others say the underrepresentation of women in the field
is detrimental in a larger sense. Computer science, they say, is as
vital to propelling society forward in the digital era as mechanical
engineering was in the industrial age.

?If we?re not getting more women to be part of that, it?s just nuts,?
Dr. Klawe said. At Mudd, she continued, ?we?re graduating 20 female
computer science majors a year, and every one of them is a gem.? In
2005, the year before Dr. Klawe arrived, a group of faculty members
embarked on a full makeover of the introductory computer science
course, a requirement at Mudd.

Known as CS 5, the course focused on hard-core programming, appealing
to a particular kind of student ? young men, already seasoned
programmers, who dominated the class. This only reinforced the women?s
sense that computer science was for geeky know-it-alls.

?Most of the female students were unwilling to go on in computer
science because of the stereotypes they had grown up with,? said
Zachary Dodds, a computer scientist at Mudd. ?We realized we were
helping perpetuate that by teaching such a standard course.?

To reduce the intimidation factor, the course was divided into two
sections ? ?gold,? for those with no prior experience, and ?black? for
everyone else. Java, a notoriously opaque programming language, was
replaced by a more accessible language called Python. And the focus of
the course changed to computational approaches to solving problems
across science.

?We realized that we needed to show students computer science is not
all about programming,? said Ran Libeskind-Hadas, chairman of the
department. ?It has intellectual depth and connections to other
disciplines.?

Dr. Klawe supported the cause wholeheartedly, and provided money from
the college for every female freshman to travel to the annual Grace
Hopper conference, named after a pioneering programmer. The
conference, where freshmen are surrounded by female role models, has
inspired many a first-year ?Mudder? to explore computer science more
seriously.

Firsthand Experience

The topic of women in computing was a preoccupation for Dr. Klawe well
before she took over at Harvey Mudd, in part because when she chose
her profession, women in male-dominated fields were especially rare.

?She was consistently told by teachers in adolescence, then later by
colleagues, that the things she was interested in were things women
didn?t do, and that there were no good female mathematicians,? Dr.
Pippenger said.

Dr. Klawe persevered. A native Canadian, she received her Ph.D. in
mathematics in 1977 from the University of Alberta. She started a
second Ph.D., in computer science, at the University of Toronto, but
was offered a faculty position there before completing the degree.

In 1980, she married Dr. Pippenger, a highly regarded theoretical
computer scientist, and for the first decade of their marriage Dr.
Klawe was the professional afterthought. In the 1980s, they both
worked at the I.B.M. Almaden Research Center in San Jose, Calif. ?They
only hired me so they wouldn?t lose Nick,? Dr. Klawe said.

They moved to the University of British Columbia in Vancouver in 1988,
and Dr. Klawe?s talents as an administrator began to blossom. In 2002,
she was recruited to Princeton University as dean of engineering and
applied sciences.

?By the time we went to Princeton,? Dr. Pippenger said, ?it was clear
they were hiring me because they really wanted to get Maria.? Dr.
Klawe, a slight and sprightly woman, had not been at Princeton long
before she began receiving recruiting inquiries. ?If you?re a female
administrator at a place like Princeton, you?ll get a request to be
president or provost twice a week,? she said. ?A lot of times it?s not
that they care about you, but they need a credible female candidate.?

She seldom read beyond the first few lines. ?I had this automatic
message saying I was honored to be nominated, but had no intention of
leaving Princeton in the near future,? she said.

Then one day in 2005, an announcement about the search for a president
at Harvey Mudd floated into her in-box. She knew about the college and
couldn?t resist opening the attachment.

?I read it and thought, ?Oh, my God, the person they?re talking about
for this job is exactly me,? ? she said.

Soon after arriving at Mudd, she gathered the school?s extended
community to help formulate a long-term strategic vision. ?She shut
down the school for four days,? said Robert Cave, vice president for
academic affairs. ?She said, ?I want the entire community to be
involved in charting the course of Harvey Mudd for the next 10 years.?
?

In her third year on the job, Dr. Klawe landed the largest single
contribution in the college?s 57-year history ? $25 million from R.
Michael Shanahan, a financier and the former chairman of Mudd?s board,
who has since given an additional $6 million.

Now 60, Dr. Klawe is most often seen on campus in jeans ? even,
sometimes, on a skateboard, a skill she taught herself in just the
last few years. (?We would all really worry if she didn?t wear her
protective gear,? Dr. Cave said.)

Her leadership style is equally informal, and it has taken some of the
faculty by surprise. Professor Libeskind-Hadas recalled that at one of
the first full faculty meetings, she spoke while sitting on a table in
front of the room.

In a nod to Mudd?s very personal character, Dr. Klawe said, every
summer she uses a flash card program to memorize the names of the
nearly 200 incoming freshmen. On campus, she greets each student she
passes by name. When the occasional prankster tries to stump her by
presenting her with a non-Mudder, ?usually I can figure it out,? she
said, ?but not always.?

She is an inveterate booster and recruiter for Harvey Mudd. On planes
and ski lifts, at conferences and in far-flung restaurants, she often
wears a T-shirt reading, ?The Most Amazing School You?ve Never Heard
Of.? (The answer is on the back. Harvey Mudd, by the way, was a mining
magnate in the first half of the 20th century.)

Finding Success

Efforts like these are bearing fruit. More high school seniors than
ever are applying to Harvey Mudd. The college now accepts just 17
percent of applicants, and routinely snatches high school seniors who
might otherwise choose better-known institutions like the
Massachusetts Institute of Technology and Carnegie Mellon.

Dr. Klawe sometimes does the recruiting herself, sending personal
messages to fence-sitters. ?You tell her about a kid you really want
and within four seconds, she?s sent an e-mail,? said Thyra Briggs,
Mudd?s vice president for admission and financial aid.

Dr. Klawe and others speak of ?converting? female students to computer
science. The idea, they say, is to make the introductory course
enjoyable and interesting enough that women who were thinking of other
majors choose computer science instead.

Bridgette Eichelberger, a sophomore, is one such convert. She entered
Mudd interested in engineering, only to switch computer science after
taking CS 5.

?I?m in my required engineering course now, and it?s fun,? she said.
?But it?s nothing like the happiness I?ve been getting from C.S.
courses.? She has a job lined up for the summer, working for
Microsoft.

?If she had missed computer science, it would have been a missed
opportunity for both sides,? Professor Dodds said.

Whether Mudd?s success can be replicated on a broad scale is unclear.
Only a handful of colleges make computer science a requirement, which
creates built-in exposure to the subject. And with fewer than 100
female freshmen, Mudd can afford to send all of them to the Hopper
conference.

Still, signs of progress dot the higher education landscape.

At Carnegie Mellon, the percentage of incoming women enrolled in the
computer science program has been rising since 2008, and is at 32
percent. M.I.T.?s figure is 30 percent. ?Close to 50 percent of our
undergraduates are women,? said Barbara Liskov, a computer scientist
there. ?So having 30 percent is nice, and better than it used to be,
but not as good as you might hope for.?

The University of California, Berkeley, and a few other universities
have also redesigned their computer science courses to be less
intimidating. The Berkeley course aimed at nonmajors is called ?The
Beauty and Joy of Computing.? Brian Harvey, a computer scientist
there, said half the students who finish the course go on to take the
course for majors. ?We are 150 students per semester and climbing,? he
said, adding that half the students are women and women do as well as
the men.

Bucknell University, in Lewisburg, Pa., recently adopted the ?gold?
version of Mudd?s CS 5 course in its entirety.

Stanford is also working to make computer science more attractive to
women. ?What Harvey Mudd has done is super,? said Stephen Cooper, a
computer scientist there. ?What other schools need to do is take a
serious look at what works for their own environment.?

Despite the success at her own campus, Dr. Klawe continues her crusade
to lift the numbers. She visits other universities and corporations to
give advice on recruiting women to STEM careers ? and retaining them.
Often she reminds her audience that for much of her career she felt
like an impostor.

Jennifer Tour Chayes, a friend of Dr. Klawe?s who is managing director
of Microsoft Research New England, in Cambridge, Mass., says that is
an important lesson.

?Women are often questioned, and then they take the impostor syndrome
as their inner voice, as proof they shouldn?t go on,? she said. ?What
they need to know is that women like Maria also had that inner voice,
and luckily they went on, and look how they?re doing.?

In spite of unequivocal evidence to the contrary, Dr. Klawe still has
moments when she is convinced she is an impostor.

?If you?re constantly pushing yourself, and putting yourself in new
environments, you?ll feel it over and over again,? she said. ?So the
only really important thing is not to let it stop you.?

From macquigg at ece.arizona.edu  Wed Apr  4 02:40:00 2012
From: macquigg at ece.arizona.edu (David MacQuigg)
Date: Tue, 3 Apr 2012 17:40:00 -0700 (PDT)
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
Message-ID: <1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>

Excellent article. ?It is good to see the revolution moving forward in at least a few schools. ?Khan Academy is also adding CS. ?This is very encouraging.

When I read the headline "Giving Women the Access Code", I was worried that it sounded like a watered-down course for women. ?It's not that at all. ?It's the guys that need to change their attitude.

When I see our introductory class with 220 freshmen in a course on C, 2/3 of whom will be "washed out" by next year, I wonder how many of them will go on to be leaders in law, politics, even technology. ?What will be the impact of their lack of understanding or appreciation of what us techies do. ?It's no wonder engineers are not even in the room when important decisions are made.



>________________________________
> From: kirby urner <kirby.urner at gmail.com>
>To: edu-sig at python.org 
>Sent: Tuesday, April 3, 2012 10:09 AM
>Subject: [Edu-sig] transforming CS at Harvey Mudd
> 
>Picked off the math-teach list (where I'm active).
>
>Mentions Python (as part of what made CS less intimidating).
>
>Kirby
>
>
>===
>
>April 2, 2012
>Giving Women the Access Code
>By KATIE HAFNER
>
>CLAREMONT, Calif. ? When Maria Klawe became president of Harvey Mudd
>College in 2006, she was dismayed ? but not surprised ? at how few
>women were majoring in computer science.
>
>A mathematician and computer scientist herself, she arrived at Harvey
>Mudd (the smallest of the five so-called Claremont Colleges) in the
>midst of a nationwide downturn for women in computer science. As
>recently as 1985, 37 percent of graduates in the field were women; by
>2005 it was down to 22 percent, and sinking.
>
>And the situation at Mudd was even grimmer. Of the college?s 750
>students, about a third were women (the figure is now closer to half),
>but for years the percentage of computer science graduates had been
>hovering around the single digits.
>
>How Dr. Klawe (pronounced KLAH-vay) and her faculty turned things
>around ? this year, nearly 40 percent of Harvey Mudd?s computer
>science degrees will go to women ? sheds light on a gender gap that
>elsewhere remains stubbornly resistant to changing times.
>
>Thanks in part to companies like Facebook, Yelp and Zynga and in part
>to cultural sensations like the movie ?The Social Network,? coders are
>hip and computer science is hot. Departments across the nation are
>brimming with students.
>
>But those students are overwhelmingly male. In 2010, just 18.2 percent
>of undergraduates in the field were women, according to the National
>Center for Education Statistics ? in spite of gains in chemistry,
>biomechanical engineering and other so-called STEM fields (the acronym
>stands for science, technology, engineering and mathematics).
>
>?It must be the unique area of science and technology where women have
>made negative progress,? said Nicholas Pippenger, a mathematics
>professor at Harvey Mudd, who is married to Dr. Klawe.
>
>Dr. Klawe and others say the underrepresentation of women in the field
>is detrimental in a larger sense. Computer science, they say, is as
>vital to propelling society forward in the digital era as mechanical
>engineering was in the industrial age.
>
>?If we?re not getting more women to be part of that, it?s just nuts,?
>Dr. Klawe said. At Mudd, she continued, ?we?re graduating 20 female
>computer science majors a year, and every one of them is a gem.? In
>2005, the year before Dr. Klawe arrived, a group of faculty members
>embarked on a full makeover of the introductory computer science
>course, a requirement at Mudd.
>
>Known as CS 5, the course focused on hard-core programming, appealing
>to a particular kind of student ? young men, already seasoned
>programmers, who dominated the class. This only reinforced the women?s
>sense that computer science was for geeky know-it-alls.
>
>?Most of the female students were unwilling to go on in computer
>science because of the stereotypes they had grown up with,? said
>Zachary Dodds, a computer scientist at Mudd. ?We realized we were
>helping perpetuate that by teaching such a standard course.?
>
>To reduce the intimidation factor, the course was divided into two
>sections ? ?gold,? for those with no prior experience, and ?black? for
>everyone else. Java, a notoriously opaque programming language, was
>replaced by a more accessible language called Python. And the focus of
>the course changed to computational approaches to solving problems
>across science.
>
>?We realized that we needed to show students computer science is not
>all about programming,? said Ran Libeskind-Hadas, chairman of the
>department. ?It has intellectual depth and connections to other
>disciplines.?
>
>Dr. Klawe supported the cause wholeheartedly, and provided money from
>the college for every female freshman to travel to the annual Grace
>Hopper conference, named after a pioneering programmer. The
>conference, where freshmen are surrounded by female role models, has
>inspired many a first-year ?Mudder? to explore computer science more
>seriously.
>
>Firsthand Experience
>
>The topic of women in computing was a preoccupation for Dr. Klawe well
>before she took over at Harvey Mudd, in part because when she chose
>her profession, women in male-dominated fields were especially rare.
>
>?She was consistently told by teachers in adolescence, then later by
>colleagues, that the things she was interested in were things women
>didn?t do, and that there were no good female mathematicians,? Dr.
>Pippenger said.
>
>Dr. Klawe persevered. A native Canadian, she received her Ph.D. in
>mathematics in 1977 from the University of Alberta. She started a
>second Ph.D., in computer science, at the University of Toronto, but
>was offered a faculty position there before completing the degree.
>
>In 1980, she married Dr. Pippenger, a highly regarded theoretical
>computer scientist, and for the first decade of their marriage Dr.
>Klawe was the professional afterthought. In the 1980s, they both
>worked at the I.B.M. Almaden Research Center in San Jose, Calif. ?They
>only hired me so they wouldn?t lose Nick,? Dr. Klawe said.
>
>They moved to the University of British Columbia in Vancouver in 1988,
>and Dr. Klawe?s talents as an administrator began to blossom. In 2002,
>she was recruited to Princeton University as dean of engineering and
>applied sciences.
>
>?By the time we went to Princeton,? Dr. Pippenger said, ?it was clear
>they were hiring me because they really wanted to get Maria.? Dr.
>Klawe, a slight and sprightly woman, had not been at Princeton long
>before she began receiving recruiting inquiries. ?If you?re a female
>administrator at a place like Princeton, you?ll get a request to be
>president or provost twice a week,? she said. ?A lot of times it?s not
>that they care about you, but they need a credible female candidate.?
>
>She seldom read beyond the first few lines. ?I had this automatic
>message saying I was honored to be nominated, but had no intention of
>leaving Princeton in the near future,? she said.
>
>Then one day in 2005, an announcement about the search for a president
>at Harvey Mudd floated into her in-box. She knew about the college and
>couldn?t resist opening the attachment.
>
>?I read it and thought, ?Oh, my God, the person they?re talking about
>for this job is exactly me,? ? she said.
>
>Soon after arriving at Mudd, she gathered the school?s extended
>community to help formulate a long-term strategic vision. ?She shut
>down the school for four days,? said Robert Cave, vice president for
>academic affairs. ?She said, ?I want the entire community to be
>involved in charting the course of Harvey Mudd for the next 10 years.?
>?
>
>In her third year on the job, Dr. Klawe landed the largest single
>contribution in the college?s 57-year history ? $25 million from R.
>Michael Shanahan, a financier and the former chairman of Mudd?s board,
>who has since given an additional $6 million.
>
>Now 60, Dr. Klawe is most often seen on campus in jeans ? even,
>sometimes, on a skateboard, a skill she taught herself in just the
>last few years. (?We would all really worry if she didn?t wear her
>protective gear,? Dr. Cave said.)
>
>Her leadership style is equally informal, and it has taken some of the
>faculty by surprise. Professor Libeskind-Hadas recalled that at one of
>the first full faculty meetings, she spoke while sitting on a table in
>front of the room.
>
>In a nod to Mudd?s very personal character, Dr. Klawe said, every
>summer she uses a flash card program to memorize the names of the
>nearly 200 incoming freshmen. On campus, she greets each student she
>passes by name. When the occasional prankster tries to stump her by
>presenting her with a non-Mudder, ?usually I can figure it out,? she
>said, ?but not always.?
>
>She is an inveterate booster and recruiter for Harvey Mudd. On planes
>and ski lifts, at conferences and in far-flung restaurants, she often
>wears a T-shirt reading, ?The Most Amazing School You?ve Never Heard
>Of.? (The answer is on the back. Harvey Mudd, by the way, was a mining
>magnate in the first half of the 20th century.)
>
>Finding Success
>
>Efforts like these are bearing fruit. More high school seniors than
>ever are applying to Harvey Mudd. The college now accepts just 17
>percent of applicants, and routinely snatches high school seniors who
>might otherwise choose better-known institutions like the
>Massachusetts Institute of Technology and Carnegie Mellon.
>
>Dr. Klawe sometimes does the recruiting herself, sending personal
>messages to fence-sitters. ?You tell her about a kid you really want
>and within four seconds, she?s sent an e-mail,? said Thyra Briggs,
>Mudd?s vice president for admission and financial aid.
>
>Dr. Klawe and others speak of ?converting? female students to computer
>science. The idea, they say, is to make the introductory course
>enjoyable and interesting enough that women who were thinking of other
>majors choose computer science instead.
>
>Bridgette Eichelberger, a sophomore, is one such convert. She entered
>Mudd interested in engineering, only to switch computer science after
>taking CS 5.
>
>?I?m in my required engineering course now, and it?s fun,? she said.
>?But it?s nothing like the happiness I?ve been getting from C.S.
>courses.? She has a job lined up for the summer, working for
>Microsoft.
>
>?If she had missed computer science, it would have been a missed
>opportunity for both sides,? Professor Dodds said.
>
>Whether Mudd?s success can be replicated on a broad scale is unclear.
>Only a handful of colleges make computer science a requirement, which
>creates built-in exposure to the subject. And with fewer than 100
>female freshmen, Mudd can afford to send all of them to the Hopper
>conference.
>
>Still, signs of progress dot the higher education landscape.
>
>At Carnegie Mellon, the percentage of incoming women enrolled in the
>computer science program has been rising since 2008, and is at 32
>percent. M.I.T.?s figure is 30 percent. ?Close to 50 percent of our
>undergraduates are women,? said Barbara Liskov, a computer scientist
>there. ?So having 30 percent is nice, and better than it used to be,
>but not as good as you might hope for.?
>
>The University of California, Berkeley, and a few other universities
>have also redesigned their computer science courses to be less
>intimidating. The Berkeley course aimed at nonmajors is called ?The
>Beauty and Joy of Computing.? Brian Harvey, a computer scientist
>there, said half the students who finish the course go on to take the
>course for majors. ?We are 150 students per semester and climbing,? he
>said, adding that half the students are women and women do as well as
>the men.
>
>Bucknell University, in Lewisburg, Pa., recently adopted the ?gold?
>version of Mudd?s CS 5 course in its entirety.
>
>Stanford is also working to make computer science more attractive to
>women. ?What Harvey Mudd has done is super,? said Stephen Cooper, a
>computer scientist there. ?What other schools need to do is take a
>serious look at what works for their own environment.?
>
>Despite the success at her own campus, Dr. Klawe continues her crusade
>to lift the numbers. She visits other universities and corporations to
>give advice on recruiting women to STEM careers ? and retaining them.
>Often she reminds her audience that for much of her career she felt
>like an impostor.
>
>Jennifer Tour Chayes, a friend of Dr. Klawe?s who is managing director
>of Microsoft Research New England, in Cambridge, Mass., says that is
>an important lesson.
>
>?Women are often questioned, and then they take the impostor syndrome
>as their inner voice, as proof they shouldn?t go on,? she said. ?What
>they need to know is that women like Maria also had that inner voice,
>and luckily they went on, and look how they?re doing.?
>
>In spite of unequivocal evidence to the contrary, Dr. Klawe still has
>moments when she is convinced she is an impostor.
>
>?If you?re constantly pushing yourself, and putting yourself in new
>environments, you?ll feel it over and over again,? she said. ?So the
>only really important thing is not to let it stop you.?
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120403/3234ea78/attachment-0001.html>

From lac at openend.se  Wed Apr  4 10:17:43 2012
From: lac at openend.se (Laura Creighton)
Date: Wed, 04 Apr 2012 10:17:43 +0200
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: Message from David MacQuigg <macquigg@ece.arizona.edu> of "Tue,
	03 Apr 2012 17:40:00 PDT."
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com><1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
Message-ID: <201204040817.q348HhEY026353@theraft.openend.se>

In a message of Tue, 03 Apr 2012 17:40:00 PDT, David MacQuigg writes:
>When I read the headline "Giving Women the Access 
>Code", I was worried that it sounded like a watered-down course for women.
>It's not that at all. It's the guys that need to change their
>attitude.

The guys may need to change their attitude, but the gals do too.

Laura

From mark.engelberg at gmail.com  Thu Apr  5 07:28:25 2012
From: mark.engelberg at gmail.com (Mark Engelberg)
Date: Wed, 4 Apr 2012 22:28:25 -0700
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
Message-ID: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>

On Tue, Apr 3, 2012 at 5:40 PM, David MacQuigg <macquigg at ece.arizona.edu>wrote:

> When I read the headline "Giving Women the Access Code", I was worried
> that it sounded like a watered-down course for women.  It's not that at
> all.  It's the guys that need to change their attitude.
>

I'm not sure that's what comes across in the article.  According to the
article:

"To *reduce the intimidation factor*, the course was divided into two
sections ? ?gold,? for those with no prior experience, and ?black? for
everyone else. Java, a notoriously opaque programming language, was
*replaced by a more accessible language* called Python. And the *focus of
the course changed* to computational approaches to solving problems
across science."

I think it's pretty easy to interpret this article as saying that the women
couldn't hack it until it was replaced with something light and fluffy with
fewer sharp edges.  Nowhere does it indicate that students are learning
just as much, or that this change in approach benefits all students, not
just the women.  Are we elevating the quality of our computer science
graduates, or just lowering the definition of what that means?  Without
addressing these questions, I fear this article does more harm than good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120404/a1f278d1/attachment.html>

From jwilson at paduaacademy.org  Thu Apr  5 13:31:44 2012
From: jwilson at paduaacademy.org (Jacqueline Wilson)
Date: Thu, 5 Apr 2012 07:31:44 -0400
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
	<CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
Message-ID: <CAG9LWaxK_HMt4DH2X=Tz3yPLP81N42V83iA5XPLfndX7GnWQDQ@mail.gmail.com>

I agree with Mark, but it's probably an unfortunate choice of wording. This
story has been floating around for a while. Bloomberg's (somewhat better)
version from September reads...

"Instead of Java, the class uses the Python language, which has simpler
rules and is easier to deploy in Web applications. One of the overarching
goals is to ?demystify the inner workings of a computer,? according to the
course website <https://www.cs.hmc.edu/twiki/bin/view/ModularCS1/>."

I manage the information technology curriculum at an all-female high
school. While we also offer operating system, security and networking
courses, the Intro to Programming course is important a bellwether for our
students' potential in college comp sci. I spent much time trying to decide
among various languages for the introductory course: C, Java, Python and
Scheme/Racket. Even though I wasn't experienced with it at the time, Python
appeared to be the clear choice.

Back in the day, my Introduction to Computer Science class was in C and our
very full lecture hall looked to be 50% women. By the time I earned my
degree, I was the only female in much smaller classes. So we were losing
many people, not just the girls. I don't think it's intimidation. I think
it's frustration and drudgery (at least at the start) with very little
creative outlet. Python takes much of that away. I can focus on concepts
more than syntax. My students picked it up so quickly I decided to add SQL.
My girls are now solving real-world problems of their choosing with Python
after six months of study. I wouldn't be there with Java or C, and there'd
be many tears over variable type rules and semi colons.

In my class I have girls who wanted to be vets, go into the music industry,
be lawyers, ocean biologists... Only one had IT aspirations. I've convinced
the majority now to explore computing. My future music major has decided to
minor in comp sci, but that's ok, even though she appears to be a coding
prodigy. I hope and am cautiously confident that the enthusiasm and
momentum they've gained will get them through their future Java endeavors.
They stay in touch with me so I'll find out.


On Apr 5, 2012, at 1:28 AM, Mark Engelberg <mark.engelberg at gmail.com> wrote:

On Tue, Apr 3, 2012 at 5:40 PM, David MacQuigg <macquigg at ece.arizona.edu>
 wrote:

> When I read the headline "Giving Women the Access Code", I was worried
> that it sounded like a watered-down course for women.  It's not that at
> all.  It's the guys that need to change their attitude.
>

I'm not sure that's what comes across in the article.  According to the
article:

"To *reduce the intimidation factor*, the course was divided into two
sections ? ?gold,? for those with no prior experience, and ?black? for
everyone else. Java, a notoriously opaque programming language, was
*replaced by a more accessible language* called Python. And the *focus of
the course changed* to computational approaches to solving problems
across science."

I think it's pretty easy to interpret this article as saying that the women
couldn't hack it until it was replaced with something light and fluffy with
fewer sharp edges.  Nowhere does it indicate that students are learning
just as much, or that this change in approach benefits all students, not
just the women.  Are we elevating the quality of our computer science
graduates, or just lowering the definition of what that means?  Without
addressing these questions, I fear this article does more harm than good.

_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/436132a5/attachment.html>

From andre.roberge at gmail.com  Thu Apr  5 13:44:43 2012
From: andre.roberge at gmail.com (Andre Roberge)
Date: Thu, 5 Apr 2012 08:44:43 -0300
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
	<CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
Message-ID: <CAGMu_=oPGOqAvZGsy5wELh1ytKSxiNgo5LDVpLESjx0YUAotoQ@mail.gmail.com>

On Thu, Apr 5, 2012 at 2:28 AM, Mark Engelberg <mark.engelberg at gmail.com>wrote:

> On Tue, Apr 3, 2012 at 5:40 PM, David MacQuigg <macquigg at ece.arizona.edu>wrote:
>
>> When I read the headline "Giving Women the Access Code", I was worried
>> that it sounded like a watered-down course for women.  It's not that at
>> all.  It's the guys that need to change their attitude.
>>
>
> I'm not sure that's what comes across in the article.  According to the
> article:
>
> "To *reduce the intimidation factor*, the course was divided into two
> sections ? ?gold,? for those with no prior experience, and ?black? for
> everyone else. Java, a notoriously opaque programming language, was
> *replaced by a more accessible language* called Python. And the *focus of
> the course changed* to computational approaches to solving problems
> across science."
>
> I think it's pretty easy to interpret this article as saying that the
> women couldn't hack it until it was replaced with something light and
> fluffy with fewer sharp edges.
>

What an incredibly sexist and uninformed statement.   There were women "who
could hack it" before the course was changed.  They probably did not see it
as very interesting before, and the new format likely changed that.

I have seen it with my own daughter who, at a very young age, zipped
through entirely on her own half of the lessons in rur-ple in less than a
day, only to decide that she did not like programming (much to my dismay).
 10 years later, she is now starting her university studies and will have
to take a traditional programming course using Java as the only CS course
required in her program.  I am sure she will be able to "hack it" but it
will probably only reinforce her opinion of programming - whereas a course
like that offered at Harvey Mudd might have change things.



> Nowhere does it indicate that students are learning just as much, or that
> this change in approach benefits all students, not just the women.  Are we
> elevating the quality of our computer science graduates, or just lowering
> the definition of what that means?  Without addressing these questions, I
> fear this article does more harm than good.
>

An article like this does not teach anything about CS; it does promote it
though.  Are you saying that promoting CS does more harm than good?   ...
If so, I strongly disagree.

Andr?

>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/c3024fdd/attachment.html>

From calcpage at aol.com  Thu Apr  5 17:07:57 2012
From: calcpage at aol.com (A. Jorge Garcia)
Date: Thu, 5 Apr 2012 11:07:57 -0400 (EDT)
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
References: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
Message-ID: <8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>

I'm hoping this is a real college as the article is inspiring.

I mean, Harvey Mudd, really? That's a character from Star Trek!

Tell me this isn't an April Fool's prank.

Regards,
A. Jorge Garcia
Applied Math and CompSci
http://shadowfaxrant.blogspot.com
http://www.youtube.com/calcpage2009




From vceder at gmail.com  Thu Apr  5 17:21:54 2012
From: vceder at gmail.com (Vern Ceder)
Date: Thu, 5 Apr 2012 10:21:54 -0500
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
References: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
	<8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
Message-ID: <CAAdq-kg28X22b8mbS1jWOPD1S6161wNvD+gMxsDZFGijVYgfcA@mail.gmail.com>

I believe the Star Trek character is *Harry* Mudd... and the college
certainly predates Star Trek... ;)

It's real and as someone else mentioned, word about their program has been
slowly getting out for a while now.

Cheers,
Vern

On Thu, Apr 5, 2012 at 10:07 AM, A. Jorge Garcia <calcpage at aol.com> wrote:

> I'm hoping this is a real college as the article is inspiring.
>
> I mean, Harvey Mudd, really? That's a character from Star Trek!
>
> Tell me this isn't an April Fool's prank.
>
> Regards,
> A. Jorge Garcia
> Applied Math and CompSci
> http://shadowfaxrant.blogspot.com
> http://www.youtube.com/calcpage2009
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



-- 
Vern Ceder
vceder at gmail.com, vceder at dogsinmotion.com
The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/e880df4e/attachment.html>

From holbert.13 at osu.edu  Thu Apr  5 17:22:35 2012
From: holbert.13 at osu.edu (Richard Holbert)
Date: Thu, 05 Apr 2012 11:22:35 -0400
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
References: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
	<8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
Message-ID: <4F7DB8BB.8020700@osu.edu>

On 04/05/2012 11:07 AM, A. Jorge Garcia wrote:
> I'm hoping this is a real college as the article is inspiring.
>
> I mean, Harvey Mudd, really? That's a character from Star Trek!
>
> Tell me this isn't an April Fool's prank.
>
> Regards,
> A. Jorge Garcia
> Applied Math and CompSci
> http://shadowfaxrant.blogspot.com
> http://www.youtube.com/calcpage2009
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
Jorge,

You are thinking of Harcourt Fenton "Harry" Mudd.

http://en.memory-alpha.org/wiki/Harcourt_Mudd

Harvey Mudd College is a real institution of higher learning:

http://www.hmc.edu

Live long and prosper :-)

Rick

From kirby.urner at gmail.com  Thu Apr  5 18:02:02 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 5 Apr 2012 09:02:02 -0700
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
	<CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
Message-ID: <CAPJgG3SuyieiBQRxZ+k=KwuD35SHwTVZ_0pzo0yEtU7nV=MR5Q@mail.gmail.com>

On Wed, Apr 4, 2012 at 10:28 PM, Mark Engelberg
<mark.engelberg at gmail.com> wrote:

< ... >

> I think it's pretty easy to interpret this article as saying that the women
> couldn't hack it until it was replaced with something light and fluffy with
> fewer sharp edges.? Nowhere does it indicate that students are learning just
> as much, or that this change in approach benefits all students, not just the
> women.? Are we elevating the quality of our computer science graduates, or
> just lowering the definition of what that means?? Without addressing these
> questions, I fear this article does more harm than good.
>

Yes, that's exactly the context in which the article was being cited
in the thread I got it from:  more evidence of dumbing down.

The implicit assumption is then that Python is watered down pabulum
while Java is for real non-quiche eating men or something.

I got into sparring with the guy pushing that interpretation.

http://mathforum.org/kb/message.jspa?messageID=7760263

(there's a tree view of our discussion commenting on the article -- ongoing)

Kirby

From kirby.urner at gmail.com  Thu Apr  5 19:16:25 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 5 Apr 2012 10:16:25 -0700
Subject: [Edu-sig] CS + theater
Message-ID: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>

As I was telling my younger daughter during the ride to school today
(she's a senior in high school, though already 20% professor and 22%
your boss), a huge missed opportunity (so far) is the hybrid of
theater and computer science.

My older step daughter majored - minored in something like that, but
the college wasn't really doing the work to marry the two, she was.

Like with television, the computer comes with a "back stage" where we
craft a user experience (e.g. web site) -- like museum exhibit design
(interactive), like department store design (people behind counters,
customer service, help desk).**

The code is about animating agents and actors (how the systems people
talk).  In popular culture, this way of thinking was vastly aided and
abetted by 'The Matrix', wherein the idea was we live inside a
computer program built for us by computer viruses of extraterrestrial
origin.

Anyway, I think as the media continue to cross-fertilize, we'll be
getting back to theater more and more, as a core institution in both
east and west, and as a logical partner for the CS department /
compartment / pod.

Kirby

** museum exhibit design:  http://samgreen.to/blog/

From pg at cs.stanford.edu  Thu Apr  5 19:39:19 2012
From: pg at cs.stanford.edu (Philip Guo)
Date: Thu, 5 Apr 2012 10:39:19 -0700
Subject: [Edu-sig] CS + theater
In-Reply-To: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>
References: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>
Message-ID: <CAMqX+rQ3dshcXa84C6sDWbJmr=SjSHa6n_n0hk7cdHGgyhzTqA@mail.gmail.com>

Agreed that finding more synergies (pardon my business-speak) between
computing and the liberal arts can be wonderful.  Reminds me a bit of
Computing for Poets:

http://cs.wheatoncollege.edu/~mleblanc/131/

On Thu, Apr 5, 2012 at 10:16 AM, kirby urner <kirby.urner at gmail.com> wrote:

> As I was telling my younger daughter during the ride to school today
> (she's a senior in high school, though already 20% professor and 22%
> your boss), a huge missed opportunity (so far) is the hybrid of
> theater and computer science.
>
> My older step daughter majored - minored in something like that, but
> the college wasn't really doing the work to marry the two, she was.
>
> Like with television, the computer comes with a "back stage" where we
> craft a user experience (e.g. web site) -- like museum exhibit design
> (interactive), like department store design (people behind counters,
> customer service, help desk).**
>
> The code is about animating agents and actors (how the systems people
> talk).  In popular culture, this way of thinking was vastly aided and
> abetted by 'The Matrix', wherein the idea was we live inside a
> computer program built for us by computer viruses of extraterrestrial
> origin.
>
> Anyway, I think as the media continue to cross-fertilize, we'll be
> getting back to theater more and more, as a core institution in both
> east and west, and as a logical partner for the CS department /
> compartment / pod.
>
> Kirby
>
> ** museum exhibit design:  http://samgreen.to/blog/
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/09034579/attachment.html>

From skudge at gmail.com  Thu Apr  5 19:52:09 2012
From: skudge at gmail.com (Steve Graham)
Date: Thu, 05 Apr 2012 12:52:09 -0500
Subject: [Edu-sig] CS + theater
In-Reply-To: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>
References: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>
Message-ID: <4F7DDBC9.4030705@dsu.edu>

Computer Game Design seems to encompass this intersection and is a very 
interesting space, since there are connections to theater, but also to 
all sorts of other arts.  Frederick P. Brooks has expressed it about as 
well as anyone:
"The programmer, like the poet, works only slightly removed from pure 
thought-stuff. He builds castles in the air, from air, creating by 
exertion of the imagination. Few media of creation are so flexible, so 
easy to polish and rework, so readily capable of realizing grand 
conceptual structures. Yet the program construct, unlike the poet's 
words, is real in the sense that it moves and works, producing visible 
outputs separate from the construct itself. It prints results, draws 
pictures, produces sounds, moves arms. The magic of myth and legend has 
come true in our time. One types the correct incantation on a keyboard, 
and a display screen comes to life, showing things that never were nor 
could be. ... The computer resembles the magic of legend in this 
respect, too. If one character, one pause, of the incantation is not 
strictly in proper form, the magic doesn't work. Human beings are not 
accustomed to being perfect, an few areas of human activity demand it. 
Adjusting to the requirement for perfection is, I think, the most 
difficult part of learning to program."
-Frederick P. Brooks 
<http://www.softwarequotes.com/showquotes.aspx?id=556&name=Brooks,Frederick>, 
Jr. The Mythical Man-Month: Essays on Software Engineering, Anniversary 
Edition (2nd Edition) by Frederick P. Brooks , ISBN: 0201835959 , Page: 7-8

There is more (very nice imagery) in the original text. The section 
labeled "The Joys of the Craft" is just over a page in length and fantastic.

cheers,
skg


On 4/5/2012 12:16 PM, kirby urner wrote:
> As I was telling my younger daughter during the ride to school today
> (she's a senior in high school, though already 20% professor and 22%
> your boss), a huge missed opportunity (so far) is the hybrid of
> theater and computer science.
>
> My older step daughter majored - minored in something like that, but
> the college wasn't really doing the work to marry the two, she was.
>
> Like with television, the computer comes with a "back stage" where we
> craft a user experience (e.g. web site) -- like museum exhibit design
> (interactive), like department store design (people behind counters,
> customer service, help desk).**
>
> The code is about animating agents and actors (how the systems people
> talk).  In popular culture, this way of thinking was vastly aided and
> abetted by 'The Matrix', wherein the idea was we live inside a
> computer program built for us by computer viruses of extraterrestrial
> origin.
>
> Anyway, I think as the media continue to cross-fertilize, we'll be
> getting back to theater more and more, as a core institution in both
> east and west, and as a logical partner for the CS department /
> compartment / pod.
>
> Kirby
>
> ** museum exhibit design:  http://samgreen.to/blog/
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


-- 
steve graham
associate professor
computer game design
dakota state university
skg at dsu.edu
605-480-6603

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/f9af89ac/attachment-0001.html>

From kirby.urner at gmail.com  Thu Apr  5 19:57:44 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 5 Apr 2012 10:57:44 -0700
Subject: [Edu-sig] CS + theater
In-Reply-To: <CAMqX+rQ3dshcXa84C6sDWbJmr=SjSHa6n_n0hk7cdHGgyhzTqA@mail.gmail.com>
References: <CAPJgG3QLB-iTdkOZMPjQXwgtuuLsMCscYXQyN5HgF8D_LwKijQ@mail.gmail.com>
	<CAMqX+rQ3dshcXa84C6sDWbJmr=SjSHa6n_n0hk7cdHGgyhzTqA@mail.gmail.com>
Message-ID: <CAPJgG3R+6DBM_2i+iaNXKnUWXTO3m=CNrswBqzAEiE5x4ODiYw@mail.gmail.com>

On Thu, Apr 5, 2012 at 10:39 AM, Philip Guo <pg at cs.stanford.edu> wrote:
> Agreed that finding more synergies (pardon my business-speak) between
> computing and the liberal arts can be wonderful. ?Reminds me a bit of
> Computing for Poets:
>
> http://cs.wheatoncollege.edu/~mleblanc/131/
>

Yes.

Theater in particular because they hand you a "Programme" as you go
in, and the actors are following "scripts".  Objects in Python are likewise
actors.  Having a "self" makes OO intrinsically theatrical (agents doing
stuff, acting out).

Problems of parallelism might be "acted out" (Johnny, you block over
here, until you, Sally, are ready to accept from the queue... OK Johnny,
she's ready, walk your message to Jimmy for pre-processing...).

I think the Liberal Arts could swallow CS tomorrow if CS were willing
(CS has its reservations, nostalgia about math, but I say were
swallowing math too so come on in the water's fine -- spoken like
a true Philosophy major).

Related:  I practice a quaint Amish-like (Weird Al like) branch of
Quakerism wherein we call ourselves "unprogrammed", the idea
being if you follow a preacher and stand up and sit down a lot,
you're just a big fat computer (holdover 1600s backlash against
bloated churches).  Here's a picture of our quaint little sign:

http://www.flickr.com/photos/17157315 at N00/7037954577/in/photostream
(note small print)

Yes, Religion and theater go together -- any ethnographer could
tell you that.

Kirby

From jwilson at paduaacademy.org  Thu Apr  5 20:42:02 2012
From: jwilson at paduaacademy.org (Jacqueline Wilson)
Date: Thu, 5 Apr 2012 14:42:02 -0400
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAPJgG3SuyieiBQRxZ+k=KwuD35SHwTVZ_0pzo0yEtU7nV=MR5Q@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
	<CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
	<CAPJgG3SuyieiBQRxZ+k=KwuD35SHwTVZ_0pzo0yEtU7nV=MR5Q@mail.gmail.com>
Message-ID: <CAG9LWaz-Q=JBPQKympp4tFWQ9=GJW9GKO-vPUmwspbWm-x2w1A@mail.gmail.com>

While the wording of that article invited (your opponent's?) criticism,
Kirby, that thread you shared really got my blood pressure up.

I'm surprised he didn't pull out the "those who can do..." BS. I have some
stereotypes to rant about too. I spent 16 years in corporate America before
choosing to leave because I wasn't learning anything new. They pigeon-hole
you into modular assembly line jobs with the ultimate goal of outsourcing
parts. They preach about how we (as educators) can't possibly know anything
about enterprise level this, or security that, all the while clinging to
their Microsoft centric, layer-burdened systems just because they have too
much money and time invested to let them go. They have legacy apps that
nobody in IT can support, but "Sales" or whoever won't let them die.
They'll virtualize, but they won't go cloud because of "security", yet some
over-productive-anti-social-workaholic domain-, network- or email
administrator can destroy their data in one drama-filled weekend because he
didn't like his raise. They promote their best technical people into
management jobs where all they can create are spreadsheets because there is
no career path otherwise. They punish their big-idea creative types because
they didn't adhere to dress codes, or attend some number of diversity
training sessions...

I'm a teacher (isn't that cute) that happens to have Cisco, MCSE, Citrix
(among other) certifications, experienced in several industries as a
technician, project manager and team manager. From what I've seen
creativity and innovation cannot be dictated through corporate structures
of 8:00-5:00 shifts according to bogus pay scale "bands" or incentives. You
need people who enjoy and excel at what they do and you need to give them
the space to do it. That's why the game changing ideas tend to come from
universities and techies "dabbling" at home. I could go into a long list of
"big tech" companies who have fallen prey to too much corporate structure
and loss of vision (Novell, cough). Your buddy has the nerve to accuse
schools of blunting the edge of hardcore subjects to accommodate
underrepresented groups. What are his company's HR policies? Talk about
coddling. It's ridiculous what you have to go through to dismiss a
non-performing employee. In an education setting, the student fails, and
that's that.

If Python makes CS accessible to more big-picture thinkers and future
visionaries, that's what this country needs... not cowboys who spout off
about what a "real job" is, or is not.

On Thu, Apr 5, 2012 at 12:02 PM, kirby urner <kirby.urner at gmail.com> wrote:

> On Wed, Apr 4, 2012 at 10:28 PM, Mark Engelberg
> <mark.engelberg at gmail.com> wrote:
>
> < ... >
>
> > I think it's pretty easy to interpret this article as saying that the
> women
> > couldn't hack it until it was replaced with something light and fluffy
> with
> > fewer sharp edges.  Nowhere does it indicate that students are learning
> just
> > as much, or that this change in approach benefits all students, not just
> the
> > women.  Are we elevating the quality of our computer science graduates,
> or
> > just lowering the definition of what that means?  Without addressing
> these
> > questions, I fear this article does more harm than good.
> >
>
> Yes, that's exactly the context in which the article was being cited
> in the thread I got it from:  more evidence of dumbing down.
>
> The implicit assumption is then that Python is watered down pabulum
> while Java is for real non-quiche eating men or something.
>
> I got into sparring with the guy pushing that interpretation.
>
> http://mathforum.org/kb/message.jspa?messageID=7760263
>
> (there's a tree view of our discussion commenting on the article --
> ongoing)
>
> Kirby
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



-- 
Jacqueline Wilson
Dept Chair, Information Technology
Padua Academy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/4da917f0/attachment.html>

From kurner at oreillyschool.com  Thu Apr  5 21:04:59 2012
From: kurner at oreillyschool.com (Kirby Urner)
Date: Thu, 5 Apr 2012 12:04:59 -0700
Subject: [Edu-sig] transforming CS at Harvey Mudd
In-Reply-To: <CAG9LWaz-Q=JBPQKympp4tFWQ9=GJW9GKO-vPUmwspbWm-x2w1A@mail.gmail.com>
References: <CAPJgG3SuOH9rjfUC8thna4cpk=GSfgMvwCX7-c-Lvr9qAhOa5g@mail.gmail.com>
	<1333500000.58162.YahooMailNeo@web34507.mail.mud.yahoo.com>
	<CAORbMOOnz1++QpCGcukL7uZi5A-H36z8WGhb-6zx82ErMvPYfQ@mail.gmail.com>
	<CAPJgG3SuyieiBQRxZ+k=KwuD35SHwTVZ_0pzo0yEtU7nV=MR5Q@mail.gmail.com>
	<CAG9LWaz-Q=JBPQKympp4tFWQ9=GJW9GKO-vPUmwspbWm-x2w1A@mail.gmail.com>
Message-ID: <CAGe4BMHwSVQxRuNRNLpHcBFT4pcYbAQJcGzUdJeTF5xxr4_Ezw@mail.gmail.com>

On Thu, Apr 5, 2012 at 11:42 AM, Jacqueline Wilson <jwilson at paduaacademy.org
> wrote:

< ... >

Heh, good rant, really liked it.  << applause >>

I've volleyed back at my "buddy" -- hope to see what you'll make of it.

That's a moderated list (iron fist of Drexel) with known-quantity
characters / veterans duking it out in contentious fashion.  Like a comic
strip.

More like me 'n Arthur used to be here on edu-sig afore we lost him.  Kinda
Punch & Judy.

Lotsa listservs like that as I'm sure you well know.  Like Indonesian
shadow puppets.


> If Python makes CS accessible to more big-picture thinkers and future
> visionaries, that's what this country needs... not cowboys who spout off
> about what a "real job" is, or is not.
>
>
Hear hear.  Raises tankard.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120405/4d4d3c29/attachment.html>

From andre.roberge at gmail.com  Fri Apr 13 14:08:33 2012
From: andre.roberge at gmail.com (Andre Roberge)
Date: Fri, 13 Apr 2012 09:08:33 -0300
Subject: [Edu-sig] Slightly off-topic: about Harvey Mudd College
Message-ID: <CAGMu_=ofdHHOqAjDj_fBGho7_W+sq=GedtBLwF8n2r=LJvQuHQ@mail.gmail.com>

A short while ago, someone asked on this list if Harvey Mudd was really a
College - being somewhat skeptical of the name. According to this BusinessWeek
article<http://www.businessweek.com/articles/2012-04-09/college-roi-what-we-found>,
Harvey Mudd College is the one with the best Return On Investment ... I
wonder if it's a sign of the attitude that led to using Python instead of
Java in intro classes.

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120413/b3fb353c/attachment.html>

From PMEDINA at ccisd.net  Fri Apr 13 14:26:56 2012
From: PMEDINA at ccisd.net (Medina, Pat)
Date: Fri, 13 Apr 2012 12:26:56 +0000
Subject: [Edu-sig] Slightly off-topic: about Harvey Mudd College
In-Reply-To: <CAGMu_=ofdHHOqAjDj_fBGho7_W+sq=GedtBLwF8n2r=LJvQuHQ@mail.gmail.com>
References: <CAGMu_=ofdHHOqAjDj_fBGho7_W+sq=GedtBLwF8n2r=LJvQuHQ@mail.gmail.com>
Message-ID: <30BBE65B7E95794F9F4A82F64395F82C4D7B5C55@TLC-MBX02.ad.ccisd.net>

Harvey Mudd has been number one on the list for a few years now. I think one of the reasons is they do have a smaller enrollment than the other colleges, which makes them more selective. Better influx of student makes for better output kind of thing. Not trying to minimize what they do as I am sure the quality of education is top notch.
I remind my students and parents every year that there are alot of quality schools out there people have never heard of. Probably because they don't have an athletics program.

Pat


________________________________
From: edu-sig-bounces+pmedina=ccisd.net at python.org [edu-sig-bounces+pmedina=ccisd.net at python.org] on behalf of Andre Roberge [andre.roberge at gmail.com]
Sent: Friday, April 13, 2012 7:08 AM
To: edu-sig at python.org
Subject: [Edu-sig] Slightly off-topic: about Harvey Mudd College

A short while ago, someone asked on this list if Harvey Mudd was really a College - being somewhat skeptical of the name. According to this BusinessWeek article<http://www.businessweek.com/articles/2012-04-09/college-roi-what-we-found>, Harvey Mudd College is the one with the best Return On Investment ... I wonder if it's a sign of the attitude that led to using Python instead of Java in intro classes.

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120413/5e3bcf14/attachment.html>

From kirby.urner at gmail.com  Sat Apr 21 09:45:24 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 21 Apr 2012 00:45:24 -0700
Subject: [Edu-sig] a short essay about programming
Message-ID: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>

A common "error" (not too serious) that I see in
beginning Python (and no doubt other languages,
but Python is the one I'm teaching), is having a
while condition that appears to put a lid on things,
but then the flow all leaks away through break
statements, such that the "front door" condition
is never revisited.

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

What's messed up about the above code is you
never really go back to the top in the case
where you'd get to leave.  Rather, you exit by
the back door, through break.

So in that case, wouldn't have been simpler and
more elegant, even more "correct" (dare I say it)
to have gone:

while True:  # no ifs ands or buts
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

I see lots of heads nodding, and that could be
the end of the matter, but then a next question
arises:  wouldn't this also be a more correct
solution?:

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        continue  # instead of break
    else:
        print("Nope, try again...")

We're back to having a variable while condition,
not a boolean constant, but this time we actually
exit by means of it, thanks to continue or...

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
    else:
        print("Nope, try again...")

... thanks to no continue.  This last one is getting
a thumbs up, but then I'd pause here and say
"continue" can be easier on the eyes.  It's
unambiguous where it takes you, in contrast
to having to scan on down the gauntlet, looking
for possibly other open doors.  "What happens
next" should not require scanning ahead too
far.  Help us not to get lost.  Be a civic-minded
coder.

I'm thinking of a programming style that advises
two things:

(a) if you use a while condition that's variable,
that's expected to change, then your goal should
be to always exit because of that, i.e. that should
be your only exit point.  Even if some other
criterion suggests exiting, you have the option
to flip that "lid" at the top, to crack that front
door, and bounce the ball out.

(b)  which is why 'continue' is your friend.  You
are showing the user where your 'break' statements
are, except you don't use "break" statements, as
you've given a non-constant condition, and your
aim is to make that your ONLY exit point.

In short:  never use break to exit a while loop
unless your condition is while True.

Instead, always flip the condition and exit
through the font door.

However, as soon as I make that rule I can
think of good reasons to break it.  The other
programmers in the room are shaking their
heads.  Won't we lose information, needed
elsewhere in the program, if we "artificially"
force a True condition to False.  Aren't we, in
effect, lying?  That concern could be addressed.
Keep all the info true, just treat the "lid
condition" (it "keeps a lid on it") as a flag.
Go ahead and remember the user's guess.

allowed = 5
tries = 1
exit = False

while not exit:  # no other way out

    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        exit = True  # instead of break
        continue

    print("Nope, try again...")
    tries += 1
    if tries == allowed:
        print("You've maxed out")
        exit = True
        continue


I think we all understand the main issue:
writing reader-friendly code, and rules for doing
so.  There's something comforting about approaching
a while loop and knowing its not a leaky sieve,
riddled with back doors, maybe even an exit( )
time bomb.  But in the recursion world we want
a minimum of two exits usually:  when another
round is called for versus when we've "hit bottom".
Can we have it both ways?

Conclusions:

Lets not be too hasty with rules of thumb

and:

Lets keep the reader in mind when writing code.

Just because the interpreter knows to compute
the flow unambiguously, doesn't mean all ways
of writing it are equally reader-friendly.

What may seem a gratuitous gesture, an
unnecessary flourish, may actually promote
reader comprehension of your code, and that
should be a goal as much as satisfying the
interpreter.

Kirby

From john.zelle at wartburg.edu  Sat Apr 21 15:11:36 2012
From: john.zelle at wartburg.edu (John Zelle)
Date: Sat, 21 Apr 2012 13:11:36 +0000
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>

Kirby,

There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false. 

That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop:

guess = int(input("Guess? "))
while(guess != secret):  // as long as the user didn't get it, get another guess
    print("Nope, try again")
    guess = int(input("Guess? "))
// Here we know the condition is false
print("You guessed it")

There's no reason for the re-test of the loop condition to either break or continue.

This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit:

allowed = 5

guess = int(input("Guess? "))
tries = 1

while guess != secret and tries < allowed:   //user gets to try again
     print("Nope, try again")
     guess = int(input("Guess? "))
     tries += 1

if tries <= allowed:
    print("You guessed it")
else:
    print("You've maxed out.")

I like having the loop condition telling us exactly what the loop accomplishes. Using something like an "exit" or "done" variable obscures that because it does not announce what is required in order for the loop to be done.

Of course the cost of this style is the repeated input statement, but a priming read is a standard part of a sentinel loop, and both examples are shorter than the versions that retest or assign a conditional inside the loop.

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 2:45 AM
To: edu-sig at python.org
Subject: [Edu-sig] a short essay about programming

A common "error" (not too serious) that I see in
beginning Python (and no doubt other languages,
but Python is the one I'm teaching), is having a
while condition that appears to put a lid on things,
but then the flow all leaks away through break
statements, such that the "front door" condition
is never revisited.

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

What's messed up about the above code is you
never really go back to the top in the case
where you'd get to leave.  Rather, you exit by
the back door, through break.

So in that case, wouldn't have been simpler and
more elegant, even more "correct" (dare I say it)
to have gone:

while True:  # no ifs ands or buts
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

I see lots of heads nodding, and that could be
the end of the matter, but then a next question
arises:  wouldn't this also be a more correct
solution?:

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        continue  # instead of break
    else:
        print("Nope, try again...")

We're back to having a variable while condition,
not a boolean constant, but this time we actually
exit by means of it, thanks to continue or...

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
    else:
        print("Nope, try again...")

... thanks to no continue.  This last one is getting
a thumbs up, but then I'd pause here and say
"continue" can be easier on the eyes.  It's
unambiguous where it takes you, in contrast
to having to scan on down the gauntlet, looking
for possibly other open doors.  "What happens
next" should not require scanning ahead too
far.  Help us not to get lost.  Be a civic-minded
coder.

I'm thinking of a programming style that advises
two things:

(a) if you use a while condition that's variable,
that's expected to change, then your goal should
be to always exit because of that, i.e. that should
be your only exit point.  Even if some other
criterion suggests exiting, you have the option
to flip that "lid" at the top, to crack that front
door, and bounce the ball out.

(b)  which is why 'continue' is your friend.  You
are showing the user where your 'break' statements
are, except you don't use "break" statements, as
you've given a non-constant condition, and your
aim is to make that your ONLY exit point.

In short:  never use break to exit a while loop
unless your condition is while True.

Instead, always flip the condition and exit
through the font door.

However, as soon as I make that rule I can
think of good reasons to break it.  The other
programmers in the room are shaking their
heads.  Won't we lose information, needed
elsewhere in the program, if we "artificially"
force a True condition to False.  Aren't we, in
effect, lying?  That concern could be addressed.
Keep all the info true, just treat the "lid
condition" (it "keeps a lid on it") as a flag.
Go ahead and remember the user's guess.

allowed = 5
tries = 1
exit = False

while not exit:  # no other way out

    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        exit = True  # instead of break
        continue

    print("Nope, try again...")
    tries += 1
    if tries == allowed:
        print("You've maxed out")
        exit = True
        continue


I think we all understand the main issue:
writing reader-friendly code, and rules for doing
so.  There's something comforting about approaching
a while loop and knowing its not a leaky sieve,
riddled with back doors, maybe even an exit( )
time bomb.  But in the recursion world we want
a minimum of two exits usually:  when another
round is called for versus when we've "hit bottom".
Can we have it both ways?

Conclusions:

Lets not be too hasty with rules of thumb

and:

Lets keep the reader in mind when writing code.

Just because the interpreter knows to compute
the flow unambiguously, doesn't mean all ways
of writing it are equally reader-friendly.

What may seem a gratuitous gesture, an
unnecessary flourish, may actually promote
reader comprehension of your code, and that
should be a goal as much as satisfying the
interpreter.

Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

From john.zelle at wartburg.edu  Sat Apr 21 16:18:24 2012
From: john.zelle at wartburg.edu (John Zelle)
Date: Sat, 21 Apr 2012 14:18:24 +0000
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>
Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F300D3D13@MSEXCHMB01.wartburg.edu>

Oops, I think I have an off by one error in my last example. I would change the conditional at the bottom to:

if guess == secret:
    print("You guessed it!")
else:
    print("You maxed out.")

That's clearer anyway.


John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of John Zelle [john.zelle at wartburg.edu]
Sent: Saturday, April 21, 2012 8:11 AM
To: kirby urner; edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

Kirby,

There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false.

That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop:

guess = int(input("Guess? "))
while(guess != secret):  // as long as the user didn't get it, get another guess
    print("Nope, try again")
    guess = int(input("Guess? "))
// Here we know the condition is false
print("You guessed it")

There's no reason for the re-test of the loop condition to either break or continue.

This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit:

allowed = 5

guess = int(input("Guess? "))
tries = 1

while guess != secret and tries < allowed:   //user gets to try again
     print("Nope, try again")
     guess = int(input("Guess? "))
     tries += 1

if tries <= allowed:
    print("You guessed it")
else:
    print("You've maxed out.")

I like having the loop condition telling us exactly what the loop accomplishes. Using something like an "exit" or "done" variable obscures that because it does not announce what is required in order for the loop to be done.

Of course the cost of this style is the repeated input statement, but a priming read is a standard part of a sentinel loop, and both examples are shorter than the versions that retest or assign a conditional inside the loop.

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 2:45 AM
To: edu-sig at python.org
Subject: [Edu-sig] a short essay about programming

A common "error" (not too serious) that I see in
beginning Python (and no doubt other languages,
but Python is the one I'm teaching), is having a
while condition that appears to put a lid on things,
but then the flow all leaks away through break
statements, such that the "front door" condition
is never revisited.

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

What's messed up about the above code is you
never really go back to the top in the case
where you'd get to leave.  Rather, you exit by
the back door, through break.

So in that case, wouldn't have been simpler and
more elegant, even more "correct" (dare I say it)
to have gone:

while True:  # no ifs ands or buts
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        break
    else:
        print("Nope, try again...")

I see lots of heads nodding, and that could be
the end of the matter, but then a next question
arises:  wouldn't this also be a more correct
solution?:

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        continue  # instead of break
    else:
        print("Nope, try again...")

We're back to having a variable while condition,
not a boolean constant, but this time we actually
exit by means of it, thanks to continue or...

while guess != secret:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
    else:
        print("Nope, try again...")

... thanks to no continue.  This last one is getting
a thumbs up, but then I'd pause here and say
"continue" can be easier on the eyes.  It's
unambiguous where it takes you, in contrast
to having to scan on down the gauntlet, looking
for possibly other open doors.  "What happens
next" should not require scanning ahead too
far.  Help us not to get lost.  Be a civic-minded
coder.

I'm thinking of a programming style that advises
two things:

(a) if you use a while condition that's variable,
that's expected to change, then your goal should
be to always exit because of that, i.e. that should
be your only exit point.  Even if some other
criterion suggests exiting, you have the option
to flip that "lid" at the top, to crack that front
door, and bounce the ball out.

(b)  which is why 'continue' is your friend.  You
are showing the user where your 'break' statements
are, except you don't use "break" statements, as
you've given a non-constant condition, and your
aim is to make that your ONLY exit point.

In short:  never use break to exit a while loop
unless your condition is while True.

Instead, always flip the condition and exit
through the font door.

However, as soon as I make that rule I can
think of good reasons to break it.  The other
programmers in the room are shaking their
heads.  Won't we lose information, needed
elsewhere in the program, if we "artificially"
force a True condition to False.  Aren't we, in
effect, lying?  That concern could be addressed.
Keep all the info true, just treat the "lid
condition" (it "keeps a lid on it") as a flag.
Go ahead and remember the user's guess.

allowed = 5
tries = 1
exit = False

while not exit:  # no other way out

    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        exit = True  # instead of break
        continue

    print("Nope, try again...")
    tries += 1
    if tries == allowed:
        print("You've maxed out")
        exit = True
        continue


I think we all understand the main issue:
writing reader-friendly code, and rules for doing
so.  There's something comforting about approaching
a while loop and knowing its not a leaky sieve,
riddled with back doors, maybe even an exit( )
time bomb.  But in the recursion world we want
a minimum of two exits usually:  when another
round is called for versus when we've "hit bottom".
Can we have it both ways?

Conclusions:

Lets not be too hasty with rules of thumb

and:

Lets keep the reader in mind when writing code.

Just because the interpreter knows to compute
the flow unambiguously, doesn't mean all ways
of writing it are equally reader-friendly.

What may seem a gratuitous gesture, an
unnecessary flourish, may actually promote
reader comprehension of your code, and that
should be a goal as much as satisfying the
interpreter.

Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

From litvin at skylit.com  Sat Apr 21 22:50:57 2012
From: litvin at skylit.com (Litvin)
Date: Sat, 21 Apr 2012 16:50:57 -0400
Subject: [Edu-sig] MemoryError?
Message-ID: <7.0.1.0.2.20120421163831.0403fda0@skylit.com>

Can someone please explain why

n = 50000000
lst = [i for i in range(n)] # or xrange(n) in Python 2

crashes with MemoryError on a 32-bit system, while

n = 50000000
lst = n*[0]
for i in range(n):  # or xrange(n) in Python 2
     lst[i] = i

works?

Thanks,

Gary Litvin
www.skylit.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120421/b1fed961/attachment.html>

From calcpage at aol.com  Sun Apr 22 00:04:49 2012
From: calcpage at aol.com (A. Jorge Garcia)
Date: Sat, 21 Apr 2012 18:04:49 -0400
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F300D3D13@MSEXCHMB01.wartburg.edu>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D13@MSEXCHMB01.wartburg.edu>
Message-ID: <aa5b9e4f-0fd1-4f90-be6f-70835b04db03@email.android.com>

I always teach my kids about sentinel loops. I have them avoid breaking loops at all costs! What about do loop untils?
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

John Zelle <john.zelle at wartburg.edu> wrote:

Oops, I think I have an off by one error in my last example. I would change the conditional at the bottom to:

if guess == secret:
print("You guessed it!")
else:
print("You maxed out.")

That's clearer anyway.


John Zelle, PhD
Professor of Computer Science
Wartburg College


_____________________________________________

From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of John Zelle [john.zelle at wartburg.edu]
Sent: Saturday, April 21, 2012 8:11 AM
To: kirby urner; edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

Kirby,

There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false.

That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop:

guess = int(input("Guess? "))
while(guess != secret): // as long as the user didn't get it, get another guess
print("Nope, try again")
guess = int(input("Guess? "))
// Here we know the condition is false
print("You guessed it")

There's no reason for the re-test of the loop condition to either break or continue.

This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit:

allowed = 5

guess = int(input("Guess? "))
tries = 1

while guess != secret and tries < allowed: //user gets to try again
print("Nope, try again")
guess = int(input("Guess? "))
tries += 1

if tries <= allowed:
print("You guessed it")
else:
print("You've maxed out.")

I like having the loop condition telling us exactly what the loop accomplishes. Using something like an "exit" or "done" variable obscures that because it does not announce what is required in order for the loop to be done.

Of course the cost of this style is the repeated input statement, but a priming read is a standard part of a sentinel loop, and both examples are shorter than the versions that retest or assign a conditional inside the loop.

John Zelle, PhD
Professor of Computer Science
Wartburg College


_____________________________________________

From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 2:45 AM
To: edu-sig at python.org
Subject: [Edu-sig] a short essay about programming

A common "error" (not too serious) that I see in
beginning Python (and no doubt other languages,
but Python is the one I'm teaching), is having a
while condition that appears to put a lid on things,
but then the flow all leaks away through break
statements, such that the "front door" condition
is never revisited.

while guess != secret:
guess = int(input("Guess?: ")
if guess == secret:
print("You guessed it!")
break
else:
print("Nope, try again...")

What's messed up about the above code is you
never really go back to the top in the case
where you'd get to leave. Rather, you exit by
the back door, through break.

So in that case, wouldn't have been simpler and
more elegant, even more "correct" (dare I say it)
to have gone:

while True: # no ifs ands or buts
guess = int(input("Guess?: ")
if guess == secret:
print("You guessed it!")
break
else:
print("Nope, try again...")

I see lots of heads nodding, and that could be
the end of the matter, but then a next question
arises: wouldn't this also be a more correct
solution?:

while guess != secret:
guess = int(input("Guess?: ")
if guess == secret:
print("You guessed it!")
continue # instead of break
else:
print("Nope, try again...")

We're back to having a variable while condition,
not a boolean constant, but this time we actually
exit by means of it, thanks to continue or...

while guess != secret:
guess = int(input("Guess?: ")
if guess == secret:
print("You guessed it!")
else:
print("Nope, try again...")

... thanks to no continue. This last one is getting
a thumbs up, but then I'd pause here and say
"continue" can be easier on the eyes. It's
unambiguous where it takes you, in contrast
to having to scan on down the gauntlet, looking
for possibly other open doors. "What happens
next" should not require scanning ahead too
far. Help us not to get lost. Be a civic-minded
coder.

I'm thinking of a programming style that advises
two things:

(a) if you use a while condition that's variable,
that's expected to change, then your goal should
be to always exit because of that, i.e. that should
be your only exit point. Even if some other
criterion suggests exiting, you have the option
to flip that "lid" at the top, to crack that front
door, and bounce the ball out.

(b) which is why 'continue' is your friend. You
are showing the user where your 'break' statements
are, except you don't use "break" statements, as
you've given a non-constant condition, and your
aim is to make that your ONLY exit point.

In short: never use break to exit a while loop
unless your condition is while True.

Instead, always flip the condition and exit
through the font door.

However, as soon as I make that rule I can
think of good reasons to break it. The other
programmers in the room are shaking their
heads. Won't we lose information, needed
elsewhere in the program, if we "artificially"
force a True condition to False. Aren't we, in
effect, lying? That concern could be addressed.
Keep all the info true, just treat the "lid
condition" (it "keeps a lid on it") as a flag.
Go ahead and remember the user's guess.

allowed = 5
tries = 1
exit = False

while not exit: # no other way out

guess = int(input("Guess?: ")
if guess == secret:
print("You guessed it!")
exit = True # instead of break
continue

print("Nope, try again...")
tries += 1
if tries == allowed:
print("You've maxed out")
exit = True
continue


I think we all understand the main issue:
writing reader-friendly code, and rules for doing
so. There's something comforting about approaching
a while loop and knowing its not a leaky sieve,
riddled with back doors, maybe even an exit( )
time bomb. But in the recursion world we want
a minimum of two exits usually: when another
round is called for versus when we've "hit bottom".
Can we have it both ways?

Conclusions:

Lets not be too hasty with rules of thumb

and:

Lets keep the reader in mind when writing code.

Just because the interpreter knows to compute
the flow unambiguously, doesn't mean all ways
of writing it are equally reader-friendly.

What may seem a gratuitous gesture, an
unnecessary flourish, may actually promote
reader comprehension of your code, and that
should be a goal as much as satisfying the
interpreter.

Kirby
_____________________________________________

Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_____________________________________________

Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_____________________________________________

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120421/5181296c/attachment-0001.html>

From macquigg at ece.arizona.edu  Sun Apr 22 01:02:00 2012
From: macquigg at ece.arizona.edu (David MacQuigg)
Date: Sat, 21 Apr 2012 16:02:00 -0700 (PDT)
Subject: [Edu-sig] MemoryError?
In-Reply-To: <7.0.1.0.2.20120421163831.0403fda0@skylit.com>
References: <7.0.1.0.2.20120421163831.0403fda0@skylit.com>
Message-ID: <1335049320.25951.YahooMailNeo@web34503.mail.mud.yahoo.com>

No problem with Python 2.7.3 on a MacBookPro with 2GB memory and a light load of other programs. ?Could it be dependent on how much memory you have available? ?

There might be slight differences in the memory consumption in computing the two different forms. ?I would guess the second form might take less memory because it allocates exactly what it needs, not some larger amount based on a dynamic allocation algorithm for expanding lists.




>________________________________
> From: Litvin <litvin at skylit.com>
>To: edu-sig at python.org 
>Sent: Saturday, April 21, 2012 1:50 PM
>Subject: [Edu-sig] MemoryError?
> 
>
>Can someone please explain why 
>
>n = 50000000
>lst = [i for i in range(n)] # or xrange(n) in Python 2
>
>crashes with MemoryError on a 32-bit system, while
>
>n = 50000000
>lst = n*[0]
>for i in range(n):? # or xrange(n) in Python 2
>??? lst[i] = i
>
>works?
>
>Thanks,
>
>Gary Litvin
>www.skylit.com
>
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120421/69ec201a/attachment.html>

From kirby.urner at gmail.com  Sun Apr 22 03:51:18 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 21 Apr 2012 18:51:18 -0700
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3CF9@MSEXCHMB01.wartburg.edu>
Message-ID: <CAPJgG3Qd6c9KuNgS50r+3D5ncdwtL1ZGRz5WuaW+nJwOFjkN+A@mail.gmail.com>

On Sat, Apr 21, 2012 at 6:11 AM, John Zelle <john.zelle at wartburg.edu> wrote:
> Kirby,
>
> There are some nice thoughts here that I don't really disagree with, but your code examples don't use the while conditions well. If you put a condition on the loop, there should be no reason to retest the same condition inside the loop. Think of the loop condition as a guard, inside the loop it is true, outside the loop it has become false.
>


Ah now there's a good rule of thumb maybe.

Whatever sentinel condition let you into the loop should not be
retested inside the loop.

That sounds cogent.

A related but somewhat contrary mental picture is:  only let live fish
into the fish tank, but some die once already inside the tank.

Are there cases where you need a preview, aren't ready to exit yet, so
need to re-test inside?

> That suggests the more elegant (in my eyes) way to write your first example as a sort of sentinel loop:
>
> guess = int(input("Guess? "))
> while(guess != secret): ?// as long as the user didn't get it, get another guess

Pausing here:  I see this style quite often, of parens crammed right
up against the while keyword.  I

'm always worried when I see that in beginner Python that they're
imagining while is a callable, and their feeding it some kind of
argument.

Same with if:  I'll get if(x>5):

You're an experienced Pythonista though...

> ? ?print("Nope, try again")
> ? ?guess = int(input("Guess? "))
> // Here we know the condition is false
> print("You guessed it")
>
> There's no reason for the re-test of the loop condition to either break or continue.
>

Or is there sometimes?  I'm thinking this is an excellent rule of
thumb of the kind that needs to be broken.

Python in particular is interesting because it tries to stay simple -
economical in providing control over flow.

Other languages gorge themselves on all imaginable kinds of loop
syntax, bulking up their keyword vocabulary in the process sometimes
(e.g. 'until').

I agree your examples look more elegant and economical than mine
featuring a re-test.

> This applies to the second example as well, but a post-loop conditional will still be required to figure out why the loop quit:
>
> allowed = 5
>
> guess = int(input("Guess? "))
> tries = 1
>
> while guess != secret and tries < allowed: ? //user gets to try again
> ? ? print("Nope, try again")
> ? ? guess = int(input("Guess? "))
> ? ? tries += 1
>
> if tries <= allowed:
> ? ?print("You guessed it")
> else:
> ? ?print("You've maxed out.")
>

This is where the while statement's option else suite proves useful,
if you want to execute a block precisely because the while condition
has flipped.

I tend to find this useful in conjunction with 'break' though,
exploding my earlier hypothesis that while loops should have only one
entrance and one exit.

while guess != secret:  # front door
    if tries > allowed:
        print("Bummer")
        break  # back door
    tries += 1
    guess = input ("Guess? ")
else:
    print("Congratulations!")

Most public spaces have multiple exits, including a fire escape for
emergencies.  We haven't even touched on try: / except: as a way to
escape a while loop.

Mostly I just want these considerations to rise to the surface and
ruffle the surface awareness of the beginner mind programmer.

This is being a good thread for that.

Kirby

From kirby.urner at gmail.com  Sun Apr 22 04:12:09 2012
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 21 Apr 2012 19:12:09 -0700
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
Message-ID: <CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>

... another useful contribution to this thread.

---------- Forwarded message ----------
From: Richard Pattis <pattis at ics.uci.edu>
Date: Sat, Apr 21, 2012 at 6:53 PM
Subject: I'm not allowed to post
To: kirby urner <kirby.urner at gmail.com>


Feel free to post this for me, which got returned. Probably
because I use a mail alias and never tried to post before.

Rich


I replied to Kirby privately, and he suggested I post to the listserv,
so I have. Because UCI is starting to teach Python next year, I might
be on the listserv (more than you want) over the summer as I learn
Python and how to program in it and teach it: a tall order for a few
months. As Charles McCabe (SF Examiner) said, "Any clod can
have the facts; having opinions is an art." - rep


Kirby,

I'm a long time Java teacher (heck, I started teaching Fortran in
1976) who will soon be teaching Python. We (here at UC Irvine)
are switching to a 3 quarter introduction to programming sequence
all in Python (and then on to Java and C++ for upper division courses,
although Python could leak upwards).

I've been subscribing to edu-sig Python for a while and appreciate
your efforts (and have learned from them).

I'm a big fan in Java of teaching beginners only
for(;;) -I call it for-ever- and if/break termination (although some
colleagues accuse me of teaching machine language in Java).

I like forever if/break for a few reasons, among them are I
teach ifs right before looping, so students get a chance to
immediately use ifs; I think it is easier to state the
condition in which to break instead of the condition in which
to continue (although we discuss how to compute one from
the other by DeMorgan's laws later); there is only one looping
form, so students aren't faced with the up-front decision of what
kind of loop to use; and finally, they can fully write the loop and
its body and then worry about termination later (unlike a while
loop, where syntactically the first thing you must write is the
continuation test -although some computer scientists would
consider this a feature, not a bug).

So my students don't have to think of which Java loop to use:
while or do/while. They code everything (early in class) using
forever if/break, although later I illustrate the semantics of Java's
other looping forms, using forever if/break (which they are familiar
with), tell them if the pattern fits, do the transformation to simplify
their code, and if you do this enough, later in the course you will
write the "right" pattern first, without thinking about the transformation.

I'm not a big fan of continue here. I conceptualize this as an
N=1/2 loop (sentinel loops are also of this form) and am happy
with forever if/break; The question I'd have for a while loop, is
where does guess come from the first time the test is evaluated;
if the answer is some initialization that is not equal to secret, I'd
say yuck: guess should store the user's guesses only, not some crazy
value to make things work the first time the loop is entered.

Another reason I don't like continue is that it isn't local; you have to
"go around the loop again to exit".; and will you exit the next time
around, it doesn't jump out at me (same, but a little less so, for your
exit = True code in the later example; more soon). With break, you recognize
termination and perform the action immediately (like return). Also,
you have to have the condition stated twice in your final code, in two
opposite forms (guess != secret) and also (guess == secret); confusing
and double yuck.

Now in Java you could write this as a do/while,but you still have the
"repeat the test in two opposite forms" problem.

In your summary

> In short:  never use break to exit a while loop
> unless your condition is while True.


I agree with this, and argue this should be your loop form always
for beginners. I also require (for most of the quarter) at most one
break per loop.

> However, as soon as I make that rule I can
> think of good reasons to break it.


Yes, I believe you should break that rule, not continue to use  it

In the next code you set exit = True then continue so the next
iteration terminates
the loop, which I think is also bad because of non-locality. You are
terminating indirectly all over the loop. I tell my students since
loop termination
is what the loop is all about, it should be obvious where you are
terminating and why. I start by making them put their break statements in
comment sandwiches, so they stand out:

   //////
   break;
   //////

OK, so how would I write your loop to match its semantics, but be
as simple as possible?  Before showing my code, I dislike the fact
that your code is impolite: it always says "try again" on a wrong guess,
but then sometimes doesn't let the user try again. So I'll fix this "feature".

In fact, your code infinite loops when allowed = 1 (because tries,
which is initialized
at 1, is incremented before it is tested == allowed); in other cases
it is impolite
and gives the user one fewer try than they should get; so I'll fix
those bugs (you
could fix them by setting tries to 0, which I think is right, because
the user hasn't
tried yet; I'd increment tries right before or after the user enters a
new guess: more
locality).

Moral, never post code to the internet: the bas**rds will tear you apart).
Here is my Java in Python code. I'm assuming that the user always gets
at least one guess.

allowed = 5
tries   = 0

while true:
   guess = int(input("Guess?: ")
   tries += 1

   if guess == secret:
       print("You guessed it!")
       break;                                        # terminate loop

   if tries == allowed:
       print("You've maxed out")
       break;                                        # terminate loop

   print("Nope, try again...")

one fewer variable (no exit; Sartre had good programming intuition)
two fewer (18%) statements in the loop body. Now, we can still do some things to
reduce the size (but possibly increase the complexity of understanding
this code, and requiring knowledge of an "advance" python feature)

while true:
  guess = int(input("Guess?: ")
  tries += 1
  if guess == secret or tries == allowed
      break                                          # terminate loop

  print("Nope, try again...")
print("You guessed it" if guess == secret else "You've maxed out")

Note the last statement cannot be if tries != allowed, because both
might be true,
but the secret test does what you want.

What I like about this solution is it localizes the termination test (one
break) and the final disposition of the game (one "you won/lost"
statement). What I dislike about it (I'm no Pygmalion) is the uncoupling
between the termination and printing, and it has "redundant " tests
(now three, instead of two: one of my big complaints in the code you
started this discussion with).

I admit, I didn't follow any "simple to state" rules when writing this code.
My rule of thumb is not to minimize the number of loop exits but to
minimize the complexity, and I'm not totally sure what that means.

Feel free to rip me for any mistakes I've made, but now I'm off to think about
"private" variables in Python classes.

Rich Pattis

[ trimmed off copy of Kirby's essay -- Kirby ]

From john.zelle at wartburg.edu  Sun Apr 22 05:13:10 2012
From: john.zelle at wartburg.edu (John Zelle)
Date: Sun, 22 Apr 2012 03:13:10 +0000
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>

Hi All,

Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions.

One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following.

Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV,  that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to.

--John

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 9:12 PM
To: edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

... another useful contribution to this thread.

---------- Forwarded message ----------
From: Richard Pattis <pattis at ics.uci.edu>
Date: Sat, Apr 21, 2012 at 6:53 PM
Subject: I'm not allowed to post
To: kirby urner <kirby.urner at gmail.com>


Feel free to post this for me, which got returned. Probably
because I use a mail alias and never tried to post before.

Rich


I replied to Kirby privately, and he suggested I post to the listserv,
so I have. Because UCI is starting to teach Python next year, I might
be on the listserv (more than you want) over the summer as I learn
Python and how to program in it and teach it: a tall order for a few
months. As Charles McCabe (SF Examiner) said, "Any clod can
have the facts; having opinions is an art." - rep


Kirby,

I'm a long time Java teacher (heck, I started teaching Fortran in
1976) who will soon be teaching Python. We (here at UC Irvine)
are switching to a 3 quarter introduction to programming sequence
all in Python (and then on to Java and C++ for upper division courses,
although Python could leak upwards).

I've been subscribing to edu-sig Python for a while and appreciate
your efforts (and have learned from them).

I'm a big fan in Java of teaching beginners only
for(;;) -I call it for-ever- and if/break termination (although some
colleagues accuse me of teaching machine language in Java).

I like forever if/break for a few reasons, among them are I
teach ifs right before looping, so students get a chance to
immediately use ifs; I think it is easier to state the
condition in which to break instead of the condition in which
to continue (although we discuss how to compute one from
the other by DeMorgan's laws later); there is only one looping
form, so students aren't faced with the up-front decision of what
kind of loop to use; and finally, they can fully write the loop and
its body and then worry about termination later (unlike a while
loop, where syntactically the first thing you must write is the
continuation test -although some computer scientists would
consider this a feature, not a bug).

So my students don't have to think of which Java loop to use:
while or do/while. They code everything (early in class) using
forever if/break, although later I illustrate the semantics of Java's
other looping forms, using forever if/break (which they are familiar
with), tell them if the pattern fits, do the transformation to simplify
their code, and if you do this enough, later in the course you will
write the "right" pattern first, without thinking about the transformation.

I'm not a big fan of continue here. I conceptualize this as an
N=1/2 loop (sentinel loops are also of this form) and am happy
with forever if/break; The question I'd have for a while loop, is
where does guess come from the first time the test is evaluated;
if the answer is some initialization that is not equal to secret, I'd
say yuck: guess should store the user's guesses only, not some crazy
value to make things work the first time the loop is entered.

Another reason I don't like continue is that it isn't local; you have to
"go around the loop again to exit".; and will you exit the next time
around, it doesn't jump out at me (same, but a little less so, for your
exit = True code in the later example; more soon). With break, you recognize
termination and perform the action immediately (like return). Also,
you have to have the condition stated twice in your final code, in two
opposite forms (guess != secret) and also (guess == secret); confusing
and double yuck.

Now in Java you could write this as a do/while,but you still have the
"repeat the test in two opposite forms" problem.

In your summary

> In short:  never use break to exit a while loop
> unless your condition is while True.


I agree with this, and argue this should be your loop form always
for beginners. I also require (for most of the quarter) at most one
break per loop.

> However, as soon as I make that rule I can
> think of good reasons to break it.


Yes, I believe you should break that rule, not continue to use  it

In the next code you set exit = True then continue so the next
iteration terminates
the loop, which I think is also bad because of non-locality. You are
terminating indirectly all over the loop. I tell my students since
loop termination
is what the loop is all about, it should be obvious where you are
terminating and why. I start by making them put their break statements in
comment sandwiches, so they stand out:

   //////
   break;
   //////

OK, so how would I write your loop to match its semantics, but be
as simple as possible?  Before showing my code, I dislike the fact
that your code is impolite: it always says "try again" on a wrong guess,
but then sometimes doesn't let the user try again. So I'll fix this "feature".

In fact, your code infinite loops when allowed = 1 (because tries,
which is initialized
at 1, is incremented before it is tested == allowed); in other cases
it is impolite
and gives the user one fewer try than they should get; so I'll fix
those bugs (you
could fix them by setting tries to 0, which I think is right, because
the user hasn't
tried yet; I'd increment tries right before or after the user enters a
new guess: more
locality).

Moral, never post code to the internet: the bas**rds will tear you apart).
Here is my Java in Python code. I'm assuming that the user always gets
at least one guess.

allowed = 5
tries   = 0

while true:
   guess = int(input("Guess?: ")
   tries += 1

   if guess == secret:
       print("You guessed it!")
       break;                                        # terminate loop

   if tries == allowed:
       print("You've maxed out")
       break;                                        # terminate loop

   print("Nope, try again...")

one fewer variable (no exit; Sartre had good programming intuition)
two fewer (18%) statements in the loop body. Now, we can still do some things to
reduce the size (but possibly increase the complexity of understanding
this code, and requiring knowledge of an "advance" python feature)

while true:
  guess = int(input("Guess?: ")
  tries += 1
  if guess == secret or tries == allowed
      break                                          # terminate loop

  print("Nope, try again...")
print("You guessed it" if guess == secret else "You've maxed out")

Note the last statement cannot be if tries != allowed, because both
might be true,
but the secret test does what you want.

What I like about this solution is it localizes the termination test (one
break) and the final disposition of the game (one "you won/lost"
statement). What I dislike about it (I'm no Pygmalion) is the uncoupling
between the termination and printing, and it has "redundant " tests
(now three, instead of two: one of my big complaints in the code you
started this discussion with).

I admit, I didn't follow any "simple to state" rules when writing this code.
My rule of thumb is not to minimize the number of loop exits but to
minimize the complexity, and I'm not totally sure what that means.

Feel free to rip me for any mistakes I've made, but now I'm off to think about
"private" variables in Python classes.

Rich Pattis

[ trimmed off copy of Kirby's essay -- Kirby ]
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

From mark.engelberg at gmail.com  Sun Apr 22 22:44:50 2012
From: mark.engelberg at gmail.com (Mark Engelberg)
Date: Sun, 22 Apr 2012 13:44:50 -0700
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
Message-ID: <CAORbMOPT+hgQyT6K2YegOTwN_M0Dvt4dvWw1m816M74sZqym0g@mail.gmail.com>

John Zelle wrote:
guess = int(input("Guess? "))
while(guess != secret):  // as long as the user didn't get it, get another
guess
   print("Nope, try again")
   guess = int(input("Guess? "))
// Here we know the condition is false
print("You guessed it")


I mostly find John Zelle's version to be more elegant, but I dislike that
the line:
guess = int(input("Guess? "))
occurs in two places.

In general, we should be discouraging writing the same line twice.  What if
you want to change the prompt?  What if you want to create more complex
error checking for the input.  Are you going to remember to change it in
both places?

One reasonable option is to break this out into a separate getGuess()
function.  You'd still end up with two calls to the getGuess() function,
but at least the logic of getting the guess could easily be changed in one
place.

This begs the question, though, as to whether it is possible to rework the
code to only have one line which gets the guess, without involving
continue, break, or while(True).

I don't believe there is a way.  If Python had tail recursion, one way to
rewrite this that satisfies all those constraints would be:

def repeatUntilSecretIsGuessed():
  guess = int(input("Guess? "))
  if (guess == secret):
    print("You guessed it")
  else:
    print("Nope, try again")
    repeatUntilSecretIsGuessed()

This would be bad form for Python, though.

One other thought about while/continue/break.  I am always thinking about
the fact that we're training kids for the languages and programming styles
that will emerge over the next 10+ years.  To better understand the future
we're preparing them for, I spend a lot of time studying emerging
languages, looking for clues about what styles will best "future-proof" my
students.

In the case of while loops, I think it's instructive to look at Scala, a
language that is currently being hailed as the most plausible successor to
Java.  Scala doesn't have break or continue at all.  The idea is that if
you have a loop that requires a break, it is far clearer to make that loop
into a separate helper function, and use return instead of break.  So for
example, looking at Kirby's code:

while True:  # no ifs ands or buts
   guess = int(input("Guess?: ")
   if guess == secret:
       print("You guessed it!")
       break
   else:
       print("Nope, try again...")

you'd instead write it as:

def repeatUntilSecretIsGuessed():
  while True:
    guess = int(input("Guess?: ")
    if guess == secret:
        print("You guessed it!")
        return
# It's a bit easier to understand this code because we see it completely
exits the function here, not  just the while loop
    else:
        print("Nope, try again...")

In this example, the distinction seems a little silly, but I would argue
that the vast majority of while loops are, semantically speaking,
"returning a value".  They do this by setting up some accumulator variable
before the while loop, and then pounding on the variable, changing it each
time through the while loop.  It can take a bit of analysis to determine
which is the variable(s) you care about, and what it contains at the time
you break out of a loop.  By breaking the loop into a separate function,
and actually returning the value you care about with a return statement,
the code becomes much easier to understand.

So for example, let's say you want to keep looping until you get a guess
from 1 to 10.

Standard way (using while True and break) would be something like this:

while True:
  guess = int(input("Guess a number from 1 to 10? "))
  if (guess < 1 or guess > 10):
     print ("Try again")
  else:
     break
# at this point we continue our code, and we know guess contains a number
from 1 to 10

Better way:

def getNumberFrom1To10():
  while True:
    guess = int(input("Guess a number from 1 to 10? "))
    if (guess < 1 or guess > 10):
       print ("Try again")
    else:
       return guess
# Now, it's really obvious what is the value that is being "set" by the
while loop.

In any case, whether you prefer Kirby's while True version or John's
version which requires asking for a guess both before the loop and inside
the loop, the main idea here is to get kids thinking each time they have a
loop, especially a loop that involves break, whether maybe the code would
be better if they factored out the loop into a separate function.

--Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120422/1b7214a9/attachment.html>

From david at handysoftware.com  Mon Apr 23 00:06:47 2012
From: david at handysoftware.com (david at handysoftware.com)
Date: Sun, 22 Apr 2012 18:06:47 -0400 (EDT)
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com> 
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
Message-ID: <1335132407.348530472@apps.rackspace.com>

Yes, interesting thread. I've been thinking about this statement:

"If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case."

What if condition C includes an expression like (datetime.datetime.now().hour) == x)?

What if condition C is (not q.empty()), where q is a queue.Queue object fed by other threads?

I think there has to be some constraints on C for that statement to be correct. Something like "and C does not refer to volatile attributes nor variables and doesn't contain method calls whose results vary over time" or something like that.

I guess that's why I think using "while True:" with "break" is Ok in many cases.

David H

-----Original Message-----
From: "John Zelle" <john.zelle at wartburg.edu>
Sent: Saturday, April 21, 2012 11:13pm
To: "kirby urner" <kirby.urner at gmail.com>, "edu-sig at python.org" <edu-sig at python.org>
Subject: Re: [Edu-sig] a short essay about programming

Hi All,

Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions.

One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following.

Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV,  that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to.

--John

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 9:12 PM
To: edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

... another useful contribution to this thread.

---------- Forwarded message ----------
From: Richard Pattis <pattis at ics.uci.edu>
Date: Sat, Apr 21, 2012 at 6:53 PM
Subject: I'm not allowed to post
To: kirby urner <kirby.urner at gmail.com>


Feel free to post this for me, which got returned. Probably
because I use a mail alias and never tried to post before.

Rich


I replied to Kirby privately, and he suggested I post to the listserv,
so I have. Because UCI is starting to teach Python next year, I might
be on the listserv (more than you want) over the summer as I learn
Python and how to program in it and teach it: a tall order for a few
months. As Charles McCabe (SF Examiner) said, "Any clod can
have the facts; having opinions is an art." - rep


Kirby,

I'm a long time Java teacher (heck, I started teaching Fortran in
1976) who will soon be teaching Python. We (here at UC Irvine)
are switching to a 3 quarter introduction to programming sequence
all in Python (and then on to Java and C++ for upper division courses,
although Python could leak upwards).

I've been subscribing to edu-sig Python for a while and appreciate
your efforts (and have learned from them).

I'm a big fan in Java of teaching beginners only
for(;;) -I call it for-ever- and if/break termination (although some
colleagues accuse me of teaching machine language in Java).

I like forever if/break for a few reasons, among them are I
teach ifs right before looping, so students get a chance to
immediately use ifs; I think it is easier to state the
condition in which to break instead of the condition in which
to continue (although we discuss how to compute one from
the other by DeMorgan's laws later); there is only one looping
form, so students aren't faced with the up-front decision of what
kind of loop to use; and finally, they can fully write the loop and
its body and then worry about termination later (unlike a while
loop, where syntactically the first thing you must write is the
continuation test -although some computer scientists would
consider this a feature, not a bug).

So my students don't have to think of which Java loop to use:
while or do/while. They code everything (early in class) using
forever if/break, although later I illustrate the semantics of Java's
other looping forms, using forever if/break (which they are familiar
with), tell them if the pattern fits, do the transformation to simplify
their code, and if you do this enough, later in the course you will
write the "right" pattern first, without thinking about the transformation.

I'm not a big fan of continue here. I conceptualize this as an
N=1/2 loop (sentinel loops are also of this form) and am happy
with forever if/break; The question I'd have for a while loop, is
where does guess come from the first time the test is evaluated;
if the answer is some initialization that is not equal to secret, I'd
say yuck: guess should store the user's guesses only, not some crazy
value to make things work the first time the loop is entered.

Another reason I don't like continue is that it isn't local; you have to
"go around the loop again to exit".; and will you exit the next time
around, it doesn't jump out at me (same, but a little less so, for your
exit = True code in the later example; more soon). With break, you recognize
termination and perform the action immediately (like return). Also,
you have to have the condition stated twice in your final code, in two
opposite forms (guess != secret) and also (guess == secret); confusing
and double yuck.

Now in Java you could write this as a do/while,but you still have the
"repeat the test in two opposite forms" problem.

In your summary

> In short:  never use break to exit a while loop
> unless your condition is while True.


I agree with this, and argue this should be your loop form always
for beginners. I also require (for most of the quarter) at most one
break per loop.

> However, as soon as I make that rule I can
> think of good reasons to break it.


Yes, I believe you should break that rule, not continue to use  it

In the next code you set exit = True then continue so the next
iteration terminates
the loop, which I think is also bad because of non-locality. You are
terminating indirectly all over the loop. I tell my students since
loop termination
is what the loop is all about, it should be obvious where you are
terminating and why. I start by making them put their break statements in
comment sandwiches, so they stand out:

   //////
   break;
   //////

OK, so how would I write your loop to match its semantics, but be
as simple as possible?  Before showing my code, I dislike the fact
that your code is impolite: it always says "try again" on a wrong guess,
but then sometimes doesn't let the user try again. So I'll fix this "feature".

In fact, your code infinite loops when allowed = 1 (because tries,
which is initialized
at 1, is incremented before it is tested == allowed); in other cases
it is impolite
and gives the user one fewer try than they should get; so I'll fix
those bugs (you
could fix them by setting tries to 0, which I think is right, because
the user hasn't
tried yet; I'd increment tries right before or after the user enters a
new guess: more
locality).

Moral, never post code to the internet: the bas**rds will tear you apart).
Here is my Java in Python code. I'm assuming that the user always gets
at least one guess.

allowed = 5
tries   = 0

while true:
   guess = int(input("Guess?: ")
   tries += 1

   if guess == secret:
       print("You guessed it!")
       break;                                        # terminate loop

   if tries == allowed:
       print("You've maxed out")
       break;                                        # terminate loop

   print("Nope, try again...")

one fewer variable (no exit; Sartre had good programming intuition)
two fewer (18%) statements in the loop body. Now, we can still do some things to
reduce the size (but possibly increase the complexity of understanding
this code, and requiring knowledge of an "advance" python feature)

while true:
  guess = int(input("Guess?: ")
  tries += 1
  if guess == secret or tries == allowed
      break                                          # terminate loop

  print("Nope, try again...")
print("You guessed it" if guess == secret else "You've maxed out")

Note the last statement cannot be if tries != allowed, because both
might be true,
but the secret test does what you want.

What I like about this solution is it localizes the termination test (one
break) and the final disposition of the game (one "you won/lost"
statement). What I dislike about it (I'm no Pygmalion) is the uncoupling
between the termination and printing, and it has "redundant " tests
(now three, instead of two: one of my big complaints in the code you
started this discussion with).

I admit, I didn't follow any "simple to state" rules when writing this code.
My rule of thumb is not to minimize the number of loop exits but to
minimize the complexity, and I'm not totally sure what that means.

Feel free to rip me for any mistakes I've made, but now I'm off to think about
"private" variables in Python classes.

Rich Pattis

[ trimmed off copy of Kirby's essay -- Kirby ]
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig



From calcpage at aol.com  Mon Apr 23 00:56:07 2012
From: calcpage at aol.com (A. Jorge Garcia)
Date: Sun, 22 Apr 2012 18:56:07 -0400
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <1335132407.348530472@apps.rackspace.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
	<1335132407.348530472@apps.rackspace.com>
Message-ID: <5ac7889a-4901-4082-a1b9-671dff6d47c4@email.android.com>

Give me loop invariants or give me death!
A. Jorge Garcia
Applied Math & CS
http://shadowfaxrant.blogspot.com
http://www.youtube.com/calcpage2009
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

david at handysoftware.com wrote:

Yes, interesting thread. I've been thinking about this statement:

"If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case."

What if condition C includes an expression like (datetime.datetime.now().hour) == x)?

What if condition C is (not q.empty()), where q is a queue.Queue object fed by other threads?

I think there has to be some constraints on C for that statement to be correct. Something like "and C does not refer to volatile attributes nor variables and doesn't contain method calls whose results vary over time" or something like that.

I guess that's why I think using "while True:" with "break" is Ok in many cases.

David H

-----Original Message-----
From: "John Zelle" <john.zelle at wartburg.edu>
Sent: Saturday, April 21, 2012 11:13pm
To: "kirby urner" <kirby.urner at gmail.com>, "edu-sig at python.org" <edu-sig at python.org>
Subject: Re: [Edu-sig] a short essay about programming

Hi All,

Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions.

One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following.

Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV, that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to.

--John

John Zelle, PhD
Professor of Computer Science
Wartburg College


_____________________________________________

From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 9:12 PM
To: edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

... another useful contribution to this thread.

---------- Forwarded message ----------
From: Richard Pattis <pattis at ics.uci.edu>
Date: Sat, Apr 21, 2012 at 6:53 PM
Subject: I'm not allowed to post
To: kirby urner <kirby.urner at gmail.com>


Feel free to post this for me, which got returned. Probably
because I use a mail alias and never tried to post before.

Rich


I replied to Kirby privately, and he suggested I post to the listserv,
so I have. Because UCI is starting to teach Python next year, I might
be on the listserv (more than you want) over the summer as I learn
Python and how to program in it and teach it: a tall order for a few
months. As Charles McCabe (SF Examiner) said, "Any clod can
have the facts; having opinions is an art." - rep


Kirby,

I'm a long time Java teacher (heck, I started teaching Fortran in
1976) who will soon be teaching Python. We (here at UC Irvine)
are switching to a 3 quarter introduction to programming sequence
all in Python (and then on to Java and C++ for upper division courses,
although Python could leak upwards).

I've been subscribing to edu-sig Python for a while and appreciate
your efforts (and have learned from them).

I'm a big fan in Java of teaching beginners only
for(;;) -I call it for-ever- and if/break termination (although some
colleagues accuse me of teaching machine language in Java).

I like forever if/break for a few reasons, among them are I
teach ifs right before looping, so students get a chance to
immediately use ifs; I think it is easier to state the
condition in which to break instead of the condition in which
to continue (although we discuss how to compute one from
the other by DeMorgan's laws later); there is only one looping
form, so students aren't faced with the up-front decision of what
kind of loop to use; and finally, they can fully write the loop and
its body and then worry about termination later (unlike a while
loop, where syntactically the first thing you must write is the
continuation test -although some computer scientists would
consider this a feature, not a bug).

So my students don't have to think of which Java loop to use:
while or do/while. They code everything (early in class) using
forever if/break, although later I illustrate the semantics of Java's
other looping forms, using forever if/break (which they are familiar
with), tell them if the pattern fits, do the transformation to simplify
their code, and if you do this enough, later in the course you will
write the "right" pattern first, without thinking about the transformation.

I'm not a big fan of continue here. I conceptualize this as an
N=1/2 loop (sentinel loops are also of this form) and am happy
with forever if/break; The question I'd have for a while loop, is
where does guess come from the first time the test is evaluated;
if the answer is some initialization that is not equal to secret, I'd
say yuck: guess should store the user's guesses only, not some crazy
value to make things work the first time the loop is entered.

Another reason I don't like continue is that it isn't local; you have to
"go around the loop again to exit".; and will you exit the next time
around, it doesn't jump out at me (same, but a little less so, for your
exit = True code in the later example; more soon). With break, you recognize
termination and perform the action immediately (like return). Also,
you have to have the condition stated twice in your final code, in two
opposite forms (guess != secret) and also (guess == secret); confusing
and double yuck.

Now in Java you could write this as a do/while,but you still have the
"repeat the test in two opposite forms" problem.

In your summary

> In short: never use break to exit a while loop
> unless your condition is while True.


I agree with this, and argue this should be your loop form always
for beginners. I also require (for most of the quarter) at most one
break per loop.

> However, as soon as I make that rule I can
> think of good reasons to break it.


Yes, I believe you should break that rule, not continue to use it

In the next code you set exit = True then continue so the next
iteration terminates
the loop, which I think is also bad because of non-locality. You are
terminating indirectly all over the loop. I tell my students since
loop termination
is what the loop is all about, it should be obvious where you are
terminating and why. I start by making them put their break statements in
comment sandwiches, so they stand out:

//////
break;
//////

OK, so how would I write your loop to match its semantics, but be
as simple as possible? Before showing my code, I dislike the fact
that your code is impolite: it always says "try again" on a wrong guess,
but then sometimes doesn't let the user try again. So I'll fix this "feature".

In fact, your code infinite loops when allowed = 1 (because tries,
which is initialized
at 1, is incremented before it is tested == allowed); in other cases
it is impolite
and gives the user one fewer try than they should get; so I'll fix
those bugs (you
could fix them by setting tries to 0, which I think is right, because
the user hasn't
tried yet; I'd increment tries right before or after the user enters a
new guess: more
locality).

Moral, never post code to the internet: the bas**rds will tear you apart).
Here is my Java in Python code. I'm assuming that the user always gets
at least one guess.

allowed = 5
tries = 0

while true:
guess = int(input("Guess?: ")
tries += 1

if guess == secret:
print("You guessed it!")
break; # terminate loop

if tries == allowed:
print("You've maxed out")
break; # terminate loop

print("Nope, try again...")

one fewer variable (no exit; Sartre had good programming intuition)
two fewer (18%) statements in the loop body. Now, we can still do some things to
reduce the size (but possibly increase the complexity of understanding
this code, and requiring knowledge of an "advance" python feature)

while true:
guess = int(input("Guess?: ")
tries += 1
if guess == secret or tries == allowed
break # terminate loop

print("Nope, try again...")
print("You guessed it" if guess == secret else "You've maxed out")

Note the last statement cannot be if tries != allowed, because both
might be true,
but the secret test does what you want.

What I like about this solution is it localizes the termination test (one
break) and the final disposition of the game (one "you won/lost"
statement). What I dislike about it (I'm no Pygmalion) is the uncoupling
between the termination and printing, and it has "redundant " tests
(now three, instead of two: one of my big complaints in the code you
started this discussion with).

I admit, I didn't follow any "simple to state" rules when writing this code.
My rule of thumb is not to minimize the number of loop exits but to
minimize the complexity, and I'm not totally sure what that means.

Feel free to rip me for any mistakes I've made, but now I'm off to think about
"private" variables in Python classes.

Rich Pattis

[ trimmed off copy of Kirby's essay -- Kirby ]
_____________________________________________

Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_____________________________________________

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


_____________________________________________

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20120422/0cd81b40/attachment.html>

From john.zelle at wartburg.edu  Mon Apr 23 05:07:22 2012
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 23 Apr 2012 03:07:22 +0000
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <1335132407.348530472@apps.rackspace.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>,
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>,
	<1335132407.348530472@apps.rackspace.com>
Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F300D3DE7@MSEXCHMB01.wartburg.edu>

Hi Again,

Of course, David is right here. My previous statement only applies to code where all state change is effected by the code itself. All bets are off in a multi-thread or multi-process situation. That is what makes concurrent programs devilishly hard to reason about. But I wouldn't use that as an excuse to make single-threaded code hard to reason about as well.

--John

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: david at handysoftware.com [david at handysoftware.com]
Sent: Sunday, April 22, 2012 5:06 PM
To: John Zelle
Cc: kirby urner; edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

Yes, interesting thread. I've been thinking about this statement:

"If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case."

What if condition C includes an expression like (datetime.datetime.now().hour) == x)?

What if condition C is (not q.empty()), where q is a queue.Queue object fed by other threads?

I think there has to be some constraints on C for that statement to be correct. Something like "and C does not refer to volatile attributes nor variables and doesn't contain method calls whose results vary over time" or something like that.

I guess that's why I think using "while True:" with "break" is Ok in many cases.

David H

-----Original Message-----
From: "John Zelle" <john.zelle at wartburg.edu>
Sent: Saturday, April 21, 2012 11:13pm
To: "kirby urner" <kirby.urner at gmail.com>, "edu-sig at python.org" <edu-sig at python.org>
Subject: Re: [Edu-sig] a short essay about programming

Hi All,

Interesting thread. Sorry about the extraneous parentheses in my initial post, I've just come off a semester of Java and am reflexively putting parentheses around my conditions.

One last thought. While I sometimes use the infinite loop form (while True:) I think the explicit loop condition is almost always preferable because of its value in clarifying what the loop is about and simplifying reasoning about the code. If the loop condition is C and there are no breaks, then you know after the loop that not C must be the case. When the loop condition is True (or a Boolean flag) or the loop contains breaks, you must mentally execute the loop in order to know the state of the computation immediately following.

Of course, the real bonus is when the explicit condition, C, is accompanied by a loop invariant, INV,  that describes what the loop is actually trying to accomplish. Together not C and INV should be sufficient to convince yourself (and others reading your code) that your loop has accomplished exactly what you wanted it to.

--John

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of kirby urner [kirby.urner at gmail.com]
Sent: Saturday, April 21, 2012 9:12 PM
To: edu-sig at python.org
Subject: Re: [Edu-sig] a short essay about programming

... another useful contribution to this thread.

---------- Forwarded message ----------
From: Richard Pattis <pattis at ics.uci.edu>
Date: Sat, Apr 21, 2012 at 6:53 PM
Subject: I'm not allowed to post
To: kirby urner <kirby.urner at gmail.com>


Feel free to post this for me, which got returned. Probably
because I use a mail alias and never tried to post before.

Rich


I replied to Kirby privately, and he suggested I post to the listserv,
so I have. Because UCI is starting to teach Python next year, I might
be on the listserv (more than you want) over the summer as I learn
Python and how to program in it and teach it: a tall order for a few
months. As Charles McCabe (SF Examiner) said, "Any clod can
have the facts; having opinions is an art." - rep


Kirby,

I'm a long time Java teacher (heck, I started teaching Fortran in
1976) who will soon be teaching Python. We (here at UC Irvine)
are switching to a 3 quarter introduction to programming sequence
all in Python (and then on to Java and C++ for upper division courses,
although Python could leak upwards).

I've been subscribing to edu-sig Python for a while and appreciate
your efforts (and have learned from them).

I'm a big fan in Java of teaching beginners only
for(;;) -I call it for-ever- and if/break termination (although some
colleagues accuse me of teaching machine language in Java).

I like forever if/break for a few reasons, among them are I
teach ifs right before looping, so students get a chance to
immediately use ifs; I think it is easier to state the
condition in which to break instead of the condition in which
to continue (although we discuss how to compute one from
the other by DeMorgan's laws later); there is only one looping
form, so students aren't faced with the up-front decision of what
kind of loop to use; and finally, they can fully write the loop and
its body and then worry about termination later (unlike a while
loop, where syntactically the first thing you must write is the
continuation test -although some computer scientists would
consider this a feature, not a bug).

So my students don't have to think of which Java loop to use:
while or do/while. They code everything (early in class) using
forever if/break, although later I illustrate the semantics of Java's
other looping forms, using forever if/break (which they are familiar
with), tell them if the pattern fits, do the transformation to simplify
their code, and if you do this enough, later in the course you will
write the "right" pattern first, without thinking about the transformation.

I'm not a big fan of continue here. I conceptualize this as an
N=1/2 loop (sentinel loops are also of this form) and am happy
with forever if/break; The question I'd have for a while loop, is
where does guess come from the first time the test is evaluated;
if the answer is some initialization that is not equal to secret, I'd
say yuck: guess should store the user's guesses only, not some crazy
value to make things work the first time the loop is entered.

Another reason I don't like continue is that it isn't local; you have to
"go around the loop again to exit".; and will you exit the next time
around, it doesn't jump out at me (same, but a little less so, for your
exit = True code in the later example; more soon). With break, you recognize
termination and perform the action immediately (like return). Also,
you have to have the condition stated twice in your final code, in two
opposite forms (guess != secret) and also (guess == secret); confusing
and double yuck.

Now in Java you could write this as a do/while,but you still have the
"repeat the test in two opposite forms" problem.

In your summary

> In short:  never use break to exit a while loop
> unless your condition is while True.


I agree with this, and argue this should be your loop form always
for beginners. I also require (for most of the quarter) at most one
break per loop.

> However, as soon as I make that rule I can
> think of good reasons to break it.


Yes, I believe you should break that rule, not continue to use  it

In the next code you set exit = True then continue so the next
iteration terminates
the loop, which I think is also bad because of non-locality. You are
terminating indirectly all over the loop. I tell my students since
loop termination
is what the loop is all about, it should be obvious where you are
terminating and why. I start by making them put their break statements in
comment sandwiches, so they stand out:

   //////
   break;
   //////

OK, so how would I write your loop to match its semantics, but be
as simple as possible?  Before showing my code, I dislike the fact
that your code is impolite: it always says "try again" on a wrong guess,
but then sometimes doesn't let the user try again. So I'll fix this "feature".

In fact, your code infinite loops when allowed = 1 (because tries,
which is initialized
at 1, is incremented before it is tested == allowed); in other cases
it is impolite
and gives the user one fewer try than they should get; so I'll fix
those bugs (you
could fix them by setting tries to 0, which I think is right, because
the user hasn't
tried yet; I'd increment tries right before or after the user enters a
new guess: more
locality).

Moral, never post code to the internet: the bas**rds will tear you apart).
Here is my Java in Python code. I'm assuming that the user always gets
at least one guess.

allowed = 5
tries   = 0

while true:
   guess = int(input("Guess?: ")
   tries += 1

   if guess == secret:
       print("You guessed it!")
       break;                                        # terminate loop

   if tries == allowed:
       print("You've maxed out")
       break;                                        # terminate loop

   print("Nope, try again...")

one fewer variable (no exit; Sartre had good programming intuition)
two fewer (18%) statements in the loop body. Now, we can still do some things to
reduce the size (but possibly increase the complexity of understanding
this code, and requiring knowledge of an "advance" python feature)

while true:
  guess = int(input("Guess?: ")
  tries += 1
  if guess == secret or tries == allowed
      break                                          # terminate loop

  print("Nope, try again...")
print("You guessed it" if guess == secret else "You've maxed out")

Note the last statement cannot be if tries != allowed, because both
might be true,
but the secret test does what you want.

What I like about this solution is it localizes the termination test (one
break) and the final disposition of the game (one "you won/lost"
statement). What I dislike about it (I'm no Pygmalion) is the uncoupling
between the termination and printing, and it has "redundant " tests
(now three, instead of two: one of my big complaints in the code you
started this discussion with).

I admit, I didn't follow any "simple to state" rules when writing this code.
My rule of thumb is not to minimize the number of loop exits but to
minimize the complexity, and I'm not totally sure what that means.

Feel free to rip me for any mistakes I've made, but now I'm off to think about
"private" variables in Python classes.

Rich Pattis

[ trimmed off copy of Kirby's essay -- Kirby ]
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig



From pgries at cs.toronto.edu  Mon Apr 23 10:49:35 2012
From: pgries at cs.toronto.edu (Paul Gries)
Date: Mon, 23 Apr 2012 04:49:35 -0400
Subject: [Edu-sig] a short essay about programming
In-Reply-To: <CAORbMOPT+hgQyT6K2YegOTwN_M0Dvt4dvWw1m816M74sZqym0g@mail.gmail.com>
References: <CAPJgG3R0KxgLCOt3PoPq6pKkLB=EQD-h-fB_UWeTg0oMbA16+Q@mail.gmail.com>
	<CAPJgG3QXT23HLAkhwkJNo8YwWcpMRN5SXYdku7syxD1EXK1jsA@mail.gmail.com>
	<5C3D88F9CF7A4B428F5A166760F5547F300D3D86@MSEXCHMB01.wartburg.edu>
	<CAORbMOPT+hgQyT6K2YegOTwN_M0Dvt4dvWw1m816M74sZqym0g@mail.gmail.com>
Message-ID: <3794B1D2-26F3-4AF0-97BB-232E1CA1135F@cs.toronto.edu>

Several people in this thread have mentioned repeat-until loops, and much of the discussion here seems to be about how to approximate them in Python. In readability dreamland:

tries_left = 5 # Must be > 0

repeat:
    guess = int(input("Guess? "))
    tries -= 1
until guess == secret or tries_left == 0

if guess == secret:
    print("You guessed it!")
else:
    print("You maxed out.")

A Racket friend of mine likes to point out the many times in our intro course where we state a problem by saying "do something until X", and then spend time figuring out how to shoehorn the problem into a while loop.

(Aside: Mark, I find your while-function approach to be thought provoking.)

-Paul Gries

On 2012-04-22, at 4:44 PM, Mark Engelberg wrote:

> John Zelle wrote:
> guess = int(input("Guess? "))
> while(guess != secret):  // as long as the user didn't get it, get another guess
>    print("Nope, try again")
>    guess = int(input("Guess? "))
> // Here we know the condition is false
> print("You guessed it")
> 
> 
> I mostly find John Zelle's version to be more elegant, but I dislike that the line:
> guess = int(input("Guess? "))
> occurs in two places.
> 
> In general, we should be discouraging writing the same line twice.  What if you want to change the prompt?  What if you want to create more complex error checking for the input.  Are you going to remember to change it in both places?
> 
> One reasonable option is to break this out into a separate getGuess() function.  You'd still end up with two calls to the getGuess() function, but at least the logic of getting the guess could easily be changed in one place.
> 
> This begs the question, though, as to whether it is possible to rework the code to only have one line which gets the guess, without involving continue, break, or while(True).  
> 
> I don't believe there is a way.  If Python had tail recursion, one way to rewrite this that satisfies all those constraints would be:
> 
> def repeatUntilSecretIsGuessed():
>   guess = int(input("Guess? "))
>   if (guess == secret):
>     print("You guessed it")
>   else:
>     print("Nope, try again")
>     repeatUntilSecretIsGuessed()
> 
> This would be bad form for Python, though.
> 
> One other thought about while/continue/break.  I am always thinking about the fact that we're training kids for the languages and programming styles that will emerge over the next 10+ years.  To better understand the future we're preparing them for, I spend a lot of time studying emerging languages, looking for clues about what styles will best "future-proof" my students.
> 
> In the case of while loops, I think it's instructive to look at Scala, a language that is currently being hailed as the most plausible successor to Java.  Scala doesn't have break or continue at all.  The idea is that if you have a loop that requires a break, it is far clearer to make that loop into a separate helper function, and use return instead of break.  So for example, looking at Kirby's code:
> 
> while True:  # no ifs ands or buts
>    guess = int(input("Guess?: ")
>    if guess == secret:
>        print("You guessed it!")
>        break
>    else:
>        print("Nope, try again...")
> 
> you'd instead write it as:
> 
> def repeatUntilSecretIsGuessed():
>   while True:  
>     guess = int(input("Guess?: ")
>     if guess == secret:
>         print("You guessed it!")
>         return            
> # It's a bit easier to understand this code because we see it completely exits the function here, not  just the while loop
>     else:
>         print("Nope, try again...")
> 
> In this example, the distinction seems a little silly, but I would argue that the vast majority of while loops are, semantically speaking, "returning a value".  They do this by setting up some accumulator variable before the while loop, and then pounding on the variable, changing it each time through the while loop.  It can take a bit of analysis to determine which is the variable(s) you care about, and what it contains at the time you break out of a loop.  By breaking the loop into a separate function, and actually returning the value you care about with a return statement, the code becomes much easier to understand.
> 
> So for example, let's say you want to keep looping until you get a guess from 1 to 10.
> 
> Standard way (using while True and break) would be something like this:
> 
> while True:
>   guess = int(input("Guess a number from 1 to 10? "))
>   if (guess < 1 or guess > 10):
>      print ("Try again")
>   else:
>      break
> # at this point we continue our code, and we know guess contains a number from 1 to 10
> 
> Better way:
> 
> def getNumberFrom1To10():
>   while True:
>     guess = int(input("Guess a number from 1 to 10? "))
>     if (guess < 1 or guess > 10):
>        print ("Try again")
>     else:
>        return guess
> # Now, it's really obvious what is the value that is being "set" by the while loop.
> 
> In any case, whether you prefer Kirby's while True version or John's version which requires asking for a guess both before the loop and inside the loop, the main idea here is to get kids thinking each time they have a loop, especially a loop that involves break, whether maybe the code would be better if they factored out the loop into a separate function.
> 
> --Mark
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig


From calcpage at aol.com  Thu Apr 26 18:28:26 2012
From: calcpage at aol.com (A. Jorge Garcia)
Date: Thu, 26 Apr 2012 12:28:26 -0400 (EDT)
Subject: [Edu-sig] Alternative SAGE sites?
In-Reply-To: <8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
References: <8CEE15504A7AF7D-DF0-FD74@webmail-d024.sysops.aol.com>
Message-ID: <8CEF1E0BD8AA7AA-2108-24A0@webmail-m019.sysops.aol.com>

I've been stuck for a week without internet access at my school!

http://shadowfaxrant.blogspot.com/2012/04/quarter-iv-week-1-screencasts.html

This was due to the fact that the tech guy redid our school network so 
he can track what everyone does when they are logged in. As a result, 
now that we have internet access back, a lot of sites are blocked 
including:

https://sagemath.clemson.edu:34567

I can get on the main SAGE sites like http://www.sagenb.org but that 
one is usually very busy. What other SAGE sites are out there that may 
not be so busy?

TIA,
A. Jorge Garcia
Applied Math and CompSci
http://shadowfaxrant.blogspot.com
http://www.youtube.com/calcpage2009