[Edu-sig] The fate of raw_input() in Python 3000

Post by Andre Roberge
Thoughts?
Andr?

I tend to agree with you. sys.stdin feels like some musty academic
coming in, trying to "prettify" in the sense of nail down according to
some vogue theory. Takes away a raw edge. Most think that's a *good*
thing, but I'm not so sure. Feels like creeping bureaucracy.

But remember, we can always pick a "golden age" version and stick to
it. Maybe it's 2.5 for all I know. This 3000 thing could be an "over
the hill" version for party hacks and kiss asses (trying to ingratiate
themselves with an ancient BDFL). ;-)

On the other hand, this is my first time to give the matter much thought.

Remember too, can't we always write and include a module like "retro"
wherein we go raw_input = sys.stdin.readline and then continue on our
merry way? Call it a "soft fork"?

Kirby

Dethe Elza

2006-09-05 01:56:00 UTC

Post by kirby urner
raw_input = sys.stdin.readline

While I don't think anyone can argue that this removal makes a major
difference for Python as a programming language, I believe it makes a
significant difference for using Python as a learning language, adding
a non-trivial barrier to learning.

Removing this from built-ins isn't going to be any more confusing or
off-putting than trying to understand the difference between input
and raw_input in the first place. I remember being tripped up by
*that* when I was first learning Python.

Post by Andre Roberge
Consider the following fake sessions at the interpreter prompt, where
I use extra parentheses to turn print as a function (as is also
proposed in Python 3000) - these parentheses can of course be used
with today's Python.

The standard prompt is great, but not the best learning environment.
I would recommend that students use IPython instead, and since
IPython already adds lots of convenience methods to the global
namespace, there's nothing to stop it from pre-populating globals
with input and raw_input.

That is:

1. It isn't necessary for global functions at the command-line prompt
to be in builtins
2. It possible (and desirable) to have different command-line prompts
for different purposes
3. It isn't necessary to clutter the builtins with every convenience
function, even if we're used to it

Now, all that given, I do hope Python doesn't start going down the
road that Java has taken and replace

Post by kirby urner
open('myfilename.txt')

with

Post by kirby urner
open(BufferedStream(InputStream(FileStream('myfilename.txt')

but I don't think the loss of raw_input is quite on that scale.

--Dethe

Art is either plagiarism or revolution. --Paul Gauguin

John Zelle

2006-09-05 02:36:44 UTC

Post by kirby urner
raw_input = sys.stdin.readline

This is simply not equivalent. readline does not take a prompt as an argument.
You'll have to write the function.

Post by Andre Roberge
While I don't think anyone can argue that this removal makes a major
difference for Python as a programming language, I believe it makes a
significant difference for using Python as a learning language, adding
a non-trivial barrier to learning.

My hunch is that your confusion came because of your experience with other
languages. Having an input statement that evaluates just like what you type
into the code is a _wonderful_ teaching tool. An input is just a "delayed
expression." value = input("Enter an expression: ") where the input is 3+4*5
is just like the line of code value = 3+4*5. Students find that very easy to
understand.

Sure, there are better learning environments. But the standard prompt is _the
sole arbiter_ of what _Python_ actually does. Whenever you want students to
figure out a feature of the language, the interactive prompt is the way to
go. Let's see how Python interprets that. Using some other environment with
built-in defs is not giving you Python.

Post by Dethe Elza
1. It isn't necessary for global functions at the command-line prompt
to be in builtins

But it's useful. See my message that passed yours in cyberspace.

Post by Dethe Elza
2. It possible (and desirable) to have different command-line prompts
for different purposes

sure.

Post by Dethe Elza
3. It isn't necessary to clutter the builtins with every convenience
function, even if we're used to it

Built-ins should not be cluttered with _every convenience_, but requiring an
import to do _any_ input is silly. Input is not a convenience, it's virtually
part of the definition of a useful program.

Post by Dethe Elza
Now, all that given, I do hope Python doesn't start going down the
road that Java has taken and replace

Post by kirby urner
open('myfilename.txt')

with

Post by kirby urner
open(BufferedStream(InputStream(FileStream('myfilename.txt')

This looks like a step in that direction to me. I would like to see a "Zipf
diagram" that shows an analysis of the prevelance of various built-ins in
extant Python code. I'm betting input has been used over the years as a core
feature. It's part of what makes Python Python. While we're at it, isn't
opening a file something that really happens at a system or OS level? Perhaps

files.PythonFile(os.open(BufferedStream(InputStream(FileStream('myfilename.txt')))))

Why should file opening be any more of a "convenience" than asking the user
for input, after all?

Post by Dethe Elza
but I don't think the loss of raw_input is quite on that scale.

It may not be on that scale, but it would certainly cause me to survey the
language landscape again to see if there are better languages for teaching.
I/O is a core concept in programming, period. Don't make me introduce
extended libraries (via import) in order to teach a core concept.

--John

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Arthur Siegel

2006-09-06 13:00:25 UTC

Post by John Zelle
It may not be on that scale, but it would certainly cause me to survey the
language landscape again to see if there are better languages for teaching.
If you want to expose your students to the full horror of a
syntactically complete language, why not switch to C++, where you can
run programs in the compiler?
Its hard to say for sure, but if I had seen that in order to get
user
input I had to import sys and explain to students who are seeing
their first programming language what sys.stdin was all about.... I
don't think I would have explored Python much further.
Me too :-) I would like to see both input and raw_input preserved.
Replacing these with more complicated (from pedagogical perspective)
methods would probably give an additional reason for educators to look
at alternative languages, such as Ruby.

*
Being dispassionate on the issue itself - I have *never* used
raw_input() and, as it happens, I am generally literate enough at this
point so that the intentions of sys.stdin.readline is *clearer* to me
than is raw_input() - I am disturbed by the tone of the discussion.

Guess I prefer the all-in-the-family temper tantrum, then the calm and
dispassionate threat - explicit or implicit.

I guess I view it also as an example of the result of Python promoting
itself to the educational community in the wrong way, and on the wrong
footing, from day one - as the easy alternative, rather then as the
literate and productive alternative, the *best* alternative for getting
a certain class of problems solved in the least circuitous way.

In particular, the kinds of real world problems a student might want to
solve or explore.

Since sys.stdin.readline seems to me *more* literate, I'm OK with it.

And will maintain my apparently cloistered, unreal world view of how a
motivated student might want most to be approached, and her fragility.

Art

John Zelle

2006-09-06 13:53:20 UTC

Post by Arthur Siegel
Being dispassionate on the issue itself - I have *never* used
raw_input() and, as it happens, I am generally literate enough at this
point so that the intentions of sys.stdin.readline is *clearer* to me
than is raw_input() - I am disturbed by the tone of the discussion.
Guess I prefer the all-in-the-family temper tantrum, then the calm and
dispassionate threat - explicit or implicit.

I have no idea what you mean here. Speaking only for myself, I am simply
stating that a language that requires me to use an extended library to do
simple input is less useful as a teaching tool than one that does not. I also
gave arguments for why, as a programmer, I find it less useful. You have not
addressed those arguments.

Post by Arthur Siegel
I guess I view it also as an example of the result of Python promoting
itself to the educational community in the wrong way, and on the wrong
footing, from day one - as the easy alternative, rather then as the
literate and productive alternative, the *best* alternative for getting
a certain class of problems solved in the least circuitous way.

So you are saying it's less circuitious when writing a simple script that
needs a bit of user interaction that I have to include an import statement
and split a single logical operation (asking a user for input) into two
steps: first printing a prompt and then calling on my imported library to do
the input? I can't say as I follow that logic.

To me, one of the beauties of Python is how it mirrors the way I think about
algorithms and how I teach my students to think about algorithms. "Get a
number from the user" is a primitive operation in my thinking, having a
built-in that allows this makes for a straightforward translation from
thought to code. That's efficent both in terms of programmer productivity and
student learning.

Post by Arthur Siegel
In particular, the kinds of real world problems a student might want to
solve or explore.

Again, I would like to see the distribution breakdown of this feature in
extant code. I think it is widely and heavily used because others view it as
I do. That's the real world of problem solving. My _point_ is that input and
raw_input meet exactly this criteria, it helps students to directly solve or
explore the types of real-world problems that new programmers often want to
solve.

Post by Arthur Siegel
Since sys.stdin.readline seems to me *more* literate, I'm OK with it.

First up, you ignored my note pointing out that this is not equivalent to
raw_input, as I have to type another line of code for the prompt. You also
ignore the fact that you must import sys in order to use this. If by more
literate, you mean less convenient to use, then I agree with you. My deeper
philosophical point is that operations essential to computing (input and
output) should be part of the core language, not things that are imported
from the library. That's just as true for plain old programmers as it is for
teaching.

Post by Arthur Siegel
And will maintain my apparently cloistered, unreal world view of how a
motivated student might want most to be approached, and her fragility.

Just because a motivated student can (and should be able to) learn something
is not an argument to go out of our way to put up hurdles, no matter how
small, to their learning. Both input and raw_input are part of the language
now (and always have been). Many of us in education see them as being useful
to new programmers and real world programmers and are outlining our reasons
for such. If you want to convince us otherwise, then you should have a
reasoned argument about how this incompatible change significantly _improves_
the language for solving your real world problems. I don't really think this
particular case fits your model of promoting Python for the wrong reasons (a
case I generally agree with).

Of course, I'm just a unreal ivory-tower academic, feel free to dismiss my
opinions regardless of the reasoning behind them, pedagogical or otherwise.

--John

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Arthur

2006-09-06 18:24:09 UTC

/I think I have.

In the decorator discussion on python-list I became the self-appointed
founder and chairman of the CLA - Chicken Little Anonymous. Which was
some self-deprecation in connection with my role in the int/int and
case-sensitivity ddiscussions. And allowing me some freedom to
adamantly voice my opinions on the introduction of decorators - I was
adamantly against - while letting it be known that I thought Python
would well survive the outcome, whatever it ended up being.

My opinion here is that you are probably right in some senses, probably
wrong in others - and that Python will be not be *significantly* less
useful for pedagogical purposes, whatever the outcome of the issue.

So I choose to speak to the tone of the discussions as more to the
substance of the issue, than is the substance of the tissue itself. And
as the more important issue.

A strange role to find myself in, sure enough.

Art

/

John Zelle

2006-09-06 21:51:40 UTC

Post by John Zelle
I have no idea what you mean here. Speaking only for myself, I am simply
stating that a language that requires me to use an extended library to do
simple input is less useful as a teaching tool than one that does not. I
also gave arguments for why, as a programmer, I find it less useful. You
have not addressed those arguments.

/I think I have.
In the decorator discussion on python-list I became the self-appointed
founder and chairman of the CLA - Chicken Little Anonymous. Which was
some self-deprecation in connection with my role in the int/int and
case-sensitivity ddiscussions. And allowing me some freedom to
adamantly voice my opinions on the introduction of decorators - I was
adamantly against - while letting it be known that I thought Python
would well survive the outcome, whatever it ended up being.
My opinion here is that you are probably right in some senses, probably
wrong in others - and that Python will be not be *significantly* less
useful for pedagogical purposes, whatever the outcome of the issue.
So I choose to speak to the tone of the discussions as more to the
substance of the issue, than is the substance of the tissue itself. And
as the more important issue.

Fair enough. But I still think you are having a hasty reaction here. This
discussion (as I have read it) has not been about making Python or
programming easy. It's been about what makes Python useful both for
programmers and for the education of new programmers. Please see the actual
arguments made in this thread. Sometimes I think you
dismiss opinions based on pedagogical foundations a bit too quickly and
off-handedly. In my experience, a good language for teaching is a good
language, period. A barrier for pedagogy is very often a barrier to
natural/useful conceptualizations, and that speaks to language design for all
users.

People often say that Pascal was designed as a "teaching language." I remember
a written interview with Nicklaus Wirth where he was asked what makes Pascal
a good teaching language, and his reponse, as I remember it, was something
like: Pascal is not a teaching language and was never intended to be; it was
designed to be a good programming language. The features of its design that
make it a good programming language are what make it a good teaching languge.

I believe that a good language is one that provides a natural way to express
algorithms as we think about them. Python is one of the very best I have
found for that. I believe (for reasons already stated) it is less good
without raw_input and input. That is and was the "tone" of the discussion,
so I'm finding it hard to figure out what you take exception to.

--John

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Joshua Zucker

2006-09-06 22:18:31 UTC

Post by John Zelle
People often say that Pascal was designed as a "teaching language." I remember
a written interview with Nicklaus Wirth where he was asked what makes Pascal
a good teaching language, and his reponse, as I remember it, was something
like: Pascal is not a teaching language and was never intended to be; it was
designed to be a good programming language. The features of its design that
make it a good programming language are what make it a good teaching languge.

As someone coming here from the Scheme community, specifically PLT
Scheme and the DrScheme programming environment (http://htdp.org), I
half-agree with the above.

I agree, in that what makes Scheme powerful for "real" users also
makes it powerful for "student" users.

But I disagree, in that one of the key innovations of the PLT team was
to make several different languages -- I think about 5 or 6 -- which,
at the beginner level, have greatly reduced expressivity compared to
standard R5RS Scheme. The tradeoff is that the language can then give
very informative error messages. I think for a beginning student,
this is a very worthwhile tradeoff!

In my own very limited experience, what's great about Python is that
it allows many different sorts of approaches: you can think like a C
programmer, or an OOP, or even almost like a LISP programmer, and
still find that your thinking maps naturally onto reasonably clean and
concise code. However, this flexibility makes it very hard for the
language to produce error messages that are informative to a beginner!

But I stray rather far from the main thread of this discussion.

The main reason that I don't choose Java for an intro course is my
feeling - backed up by what I see in several otherwise very good
textbooks - that it just isn't right to start your programming course
by telling students "here's a program, and I know you don't understand
2/3 of it. Just treat those parts like a magic incantation,
understand this part here, and let's modify that." I don't teach Java
because I don't want to have to explain "static public void main" on
the first day. [Though actually some environments, like BlueJ for
example, have an interactive mode in which you don't need a main
method, so you can avoid this problem.] To me, it would be a
noticeable minus if in the early days of the course I had to talk
about import, and dot notation, and so on ... to me it feels like
being forced into a Java/OOPish mindset for how to structure a
program, instead of being able to use functional programming or even
just plain old C-like style. I think I'm only talking about maybe the
first week of a course here, but still, that first week can do a lot
to affect people's impressions of the language or even of programming
as a whole.

--Joshua Zucker

dblank

2006-09-06 22:47:39 UTC

I think John and Joshua both hit the nail on the head (below). In trying
to figure out what exactly it is that Pascal and Python have (and most
other tools do not), I came up with the idea of "pedagogical scalability".
Simply, these tools allow the user to do a lot early, but does not impose
any particular framework or special knowledge.

Yet, as the user gains in experience, there are additional frameworks,
syntax, and semantics waiting in the wings.

Sometimes when a change such as "remove input" is proposed, the subtle
difficulties that result (such as requiring an import, and some knowledge
about streams and strings) are not realized.

To keep Python pedagogically scalable, it needs methods like input, and
raw_input. The only question I think that remains is: what should their
names be?

-Doug

Post by Joshua Zucker

As someone coming here from the Scheme community, specifically PLT
Scheme and the DrScheme programming environment (http://htdp.org), I
half-agree with the above.
I agree, in that what makes Scheme powerful for "real" users also
makes it powerful for "student" users.
But I disagree, in that one of the key innovations of the PLT team was
to make several different languages -- I think about 5 or 6 -- which,
at the beginner level, have greatly reduced expressivity compared to
standard R5RS Scheme. The tradeoff is that the language can then give
very informative error messages. I think for a beginning student,
this is a very worthwhile tradeoff!
In my own very limited experience, what's great about Python is that
it allows many different sorts of approaches: you can think like a C
programmer, or an OOP, or even almost like a LISP programmer, and
still find that your thinking maps naturally onto reasonably clean and
concise code. However, this flexibility makes it very hard for the
language to produce error messages that are informative to a beginner!
But I stray rather far from the main thread of this discussion.
The main reason that I don't choose Java for an intro course is my
feeling - backed up by what I see in several otherwise very good
textbooks - that it just isn't right to start your programming course
by telling students "here's a program, and I know you don't understand
2/3 of it. Just treat those parts like a magic incantation,
understand this part here, and let's modify that." I don't teach Java
because I don't want to have to explain "static public void main" on
the first day. [Though actually some environments, like BlueJ for
example, have an interactive mode in which you don't need a main
method, so you can avoid this problem.] To me, it would be a
noticeable minus if in the early days of the course I had to talk
about import, and dot notation, and so on ... to me it feels like
being forced into a Java/OOPish mindset for how to structure a
program, instead of being able to use functional programming or even
just plain old C-like style. I think I'm only talking about maybe the
first week of a course here, but still, that first week can do a lot
to affect people's impressions of the language or even of programming
as a whole.
--Joshua Zucker
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

Arthur

2006-09-08 00:27:06 UTC

Post by Joshua Zucker
noticeable minus if in the early days of the course I had to talk
about import, and dot notation, and so on ... to me it feels like
being forced into a Java/OOPish mindset for how to structure a
program, instead of being able to use functional programming or even
just plain old C-like style. I think I'm only talking about maybe the
first week of a course here, but still, that first week can do a lot
to affect people's impressions of the language or even of programming
as a whole.

Is it reasonable to expect Guido to design his 100 year language around
a one week problem?

Art

Paul Gries

2006-09-07 13:04:09 UTC

Is it reasonable to expect Guido to design his 100 year language around
a one week problem?

Is it reasonable to call it a one week problem if it happens three
times a year for dozens of instructors and thousands of students?

--
Paul Gries
Senior Lecturer, Dept. of Computer Science
University of Toronto

Peter Chase

2006-09-07 19:32:55 UTC

Is it reasonable to expect Guido to design his 100 year language around
a one week problem?
Art
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
!DSPAM:518,450012d7175085519597328!

Hey! Just because my car key doesn't work doesn't mean that the car is
not functional...oops! Sorry! Wrong argument. Never mind.

Peter Chase

Michael

2006-09-06 22:55:54 UTC

I've been watching this discussion and wondering - how much of the problems
people complain about would go away if here was a "teaching" distribution of
python. That is one that did the equivalent of

from teaching import *

to put things in the global namespace at start time. Generally this wouldn't
be wanted, but would be useful for putting back the things which people are
worried about losing.

ie something akin to:
~/Local> python -i mymods.py

myinput

<built-in function raw_input>
~/Local> cat mymods.py
#!/usr/bin/python

myinput = raw_input
~/Local>

That way you'd get the same default "experience" for beginners (and I think
this is vitally important myself "raw_input" and "print" are *absolutely*
*without a shadow of a doubt* *must haves* inside the default namespace for a
user (however this is implemented - preferably inside an overrideable library
rather than as language keywords).

Byt that's my tuppence worth. Given we could fake the existance of raw_input
today, how useful would a teaching mode be?

(think bicycle stabilisers for an analogy as to when they come off)

Michael

I have no idea what you mean here. Speaking only for myself, I am simply
stating that a language that requires me to use an extended library to
do simple input is less useful as a teaching tool than one that does
not. I also gave arguments for why, as a programmer, I find it less
useful. You have not addressed those arguments.

/I think I have.
In the decorator discussion on python-list I became the self-appointed
founder and chairman of the CLA - Chicken Little Anonymous. Which was
some self-deprecation in connection with my role in the int/int and
case-sensitivity ddiscussions. And allowing me some freedom to
adamantly voice my opinions on the introduction of decorators - I was
adamantly against - while letting it be known that I thought Python
would well survive the outcome, whatever it ended up being.
My opinion here is that you are probably right in some senses, probably
wrong in others - and that Python will be not be *significantly* less
useful for pedagogical purposes, whatever the outcome of the issue.
So I choose to speak to the tone of the discussions as more to the
substance of the issue, than is the substance of the tissue itself. And
as the more important issue.

Fair enough. But I still think you are having a hasty reaction here. This
discussion (as I have read it) has not been about making Python or
programming easy. It's been about what makes Python useful both for
programmers and for the education of new programmers. Please see the actual
arguments made in this thread. Sometimes I think you
dismiss opinions based on pedagogical foundations a bit too quickly and
off-handedly. In my experience, a good language for teaching is a good
language, period. A barrier for pedagogy is very often a barrier to
natural/useful conceptualizations, and that speaks to language design for
all users.
People often say that Pascal was designed as a "teaching language." I
remember a written interview with Nicklaus Wirth where he was asked what
makes Pascal a good teaching language, and his reponse, as I remember it,
was something like: Pascal is not a teaching language and was never
intended to be; it was designed to be a good programming language. The
features of its design that make it a good programming language are what
make it a good teaching languge.
I believe that a good language is one that provides a natural way to
express algorithms as we think about them. Python is one of the very best I
have found for that. I believe (for reasons already stated) it is less good
without raw_input and input. That is and was the "tone" of the discussion,
so I'm finding it hard to figure out what you take exception to.
--John

Lloyd Hugh Allen

2006-09-07 08:54:15 UTC

How about

from __past__ import raw_input

? Especially as a line that can be included in the IDLE initialization
for your students?

Post by Michael
I've been watching this discussion and wondering - how much of the problems
people complain about would go away if here was a "teaching" distribution of
python. That is one that did the equivalent of
from teaching import *
to put things in the global namespace at start time. Generally this wouldn't
be wanted, but would be useful for putting back the things which people are
worried about losing.
~/Local> python -i mymods.py

myinput

<built-in function raw_input>
~/Local> cat mymods.py
#!/usr/bin/python
myinput = raw_input
~/Local>
That way you'd get the same default "experience" for beginners (and I think
this is vitally important myself "raw_input" and "print" are *absolutely*
*without a shadow of a doubt* *must haves* inside the default namespace for a
user (however this is implemented - preferably inside an overrideable library
rather than as language keywords).
Byt that's my tuppence worth. Given we could fake the existance of raw_input
today, how useful would a teaching mode be?
(think bicycle stabilisers for an analogy as to when they come off)
Michael

I have no idea what you mean here. Speaking only for myself, I am simply
stating that a language that requires me to use an extended library to
do simple input is less useful as a teaching tool than one that does
not. I also gave arguments for why, as a programmer, I find it less
useful. You have not addressed those arguments.

/I think I have.
In the decorator discussion on python-list I became the self-appointed
founder and chairman of the CLA - Chicken Little Anonymous. Which was
some self-deprecation in connection with my role in the int/int and
case-sensitivity ddiscussions. And allowing me some freedom to
adamantly voice my opinions on the introduction of decorators - I was
adamantly against - while letting it be known that I thought Python
would well survive the outcome, whatever it ended up being.
My opinion here is that you are probably right in some senses, probably
wrong in others - and that Python will be not be *significantly* less
useful for pedagogical purposes, whatever the outcome of the issue.
So I choose to speak to the tone of the discussions as more to the
substance of the issue, than is the substance of the tissue itself. And
as the more important issue.

Fair enough. But I still think you are having a hasty reaction here. This
discussion (as I have read it) has not been about making Python or
programming easy. It's been about what makes Python useful both for
programmers and for the education of new programmers. Please see the actual
arguments made in this thread. Sometimes I think you
dismiss opinions based on pedagogical foundations a bit too quickly and
off-handedly. In my experience, a good language for teaching is a good
language, period. A barrier for pedagogy is very often a barrier to
natural/useful conceptualizations, and that speaks to language design for
all users.
People often say that Pascal was designed as a "teaching language." I
remember a written interview with Nicklaus Wirth where he was asked what
makes Pascal a good teaching language, and his reponse, as I remember it,
was something like: Pascal is not a teaching language and was never
intended to be; it was designed to be a good programming language. The
features of its design that make it a good programming language are what
make it a good teaching languge.
I believe that a good language is one that provides a natural way to
express algorithms as we think about them. Python is one of the very best I
have found for that. I believe (for reasons already stated) it is less good
without raw_input and input. That is and was the "tone" of the discussion,
so I'm finding it hard to figure out what you take exception to.
--John

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

Dethe Elza

2006-09-07 13:30:17 UTC

Post by Lloyd Hugh Allen
How about
from __past__ import raw_input

+1

ROTFL %-)

--Dethe

Post by Lloyd Hugh Allen
? Especially as a line that can be included in the IDLE initialization
for your students?

Post by Michael
I've been watching this discussion and wondering - how much of the problems
people complain about would go away if here was a "teaching"
distribution of
python. That is one that did the equivalent of
from teaching import *
to put things in the global namespace at start time. Generally this wouldn't
be wanted, but would be useful for putting back the things which people are
worried about losing.
~/Local> python -i mymods.py

myinput

<built-in function raw_input>
~/Local> cat mymods.py
#!/usr/bin/python
myinput = raw_input
~/Local>
That way you'd get the same default "experience" for beginners (and I think
this is vitally important myself "raw_input" and "print" are
*absolutely*
*without a shadow of a doubt* *must haves* inside the default
namespace for a
user (however this is implemented - preferably inside an
overrideable library
rather than as language keywords).
Byt that's my tuppence worth. Given we could fake the existance of raw_input
today, how useful would a teaching mode be?
(think bicycle stabilisers for an analogy as to when they come off)
Michael

I have no idea what you mean here. Speaking only for myself, I am simply
stating that a language that requires me to use an extended library to
do simple input is less useful as a teaching tool than one that does
not. I also gave arguments for why, as a programmer, I find it less
useful. You have not addressed those arguments.

/I think I have.
In the decorator discussion on python-list I became the self-
appointed
founder and chairman of the CLA - Chicken Little Anonymous.
Which was
some self-deprecation in connection with my role in the int/int and
case-sensitivity ddiscussions. And allowing me some freedom to
adamantly voice my opinions on the introduction of decorators - I was
adamantly against - while letting it be known that I thought Python
would well survive the outcome, whatever it ended up being.
My opinion here is that you are probably right in some senses, probably
wrong in others - and that Python will be not be *significantly* less
useful for pedagogical purposes, whatever the outcome of the issue.
So I choose to speak to the tone of the discussions as more to the
substance of the issue, than is the substance of the tissue
itself. And
as the more important issue.

Fair enough. But I still think you are having a hasty reaction here. This
discussion (as I have read it) has not been about making Python or
programming easy. It's been about what makes Python useful both for
programmers and for the education of new programmers. Please see the actual
arguments made in this thread. Sometimes I think you
dismiss opinions based on pedagogical foundations a bit too
quickly and
off-handedly. In my experience, a good language for teaching is a good
language, period. A barrier for pedagogy is very often a barrier to
natural/useful conceptualizations, and that speaks to language design for
all users.
People often say that Pascal was designed as a "teaching
language." I
remember a written interview with Nicklaus Wirth where he was asked what
makes Pascal a good teaching language, and his reponse, as I
remember it,
was something like: Pascal is not a teaching language and was never
intended to be; it was designed to be a good programming
language. The
features of its design that make it a good programming language are what
make it a good teaching languge.
I believe that a good language is one that provides a natural way to
express algorithms as we think about them. Python is one of the very best I
have found for that. I believe (for reasons already stated) it is less good
without raw_input and input. That is and was the "tone" of the discussion,
so I'm finding it hard to figure out what you take exception to.
--John

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

When laws are outlawed, only outlaws will have laws.

kirby urner

2006-09-07 22:04:33 UTC

Post by Lloyd Hugh Allen
How about
from __past__ import raw_input

+1
ROTFL %-)
--Dethe

+1

Kirby

Dethe Elza

2006-09-06 23:22:54 UTC

Post by John Zelle
I believe that a good language is one that provides a natural way to express
algorithms as we think about them. Python is one of the very best I have
found for that. I believe (for reasons already stated) it is less good
without raw_input and input. That is and was the "tone" of the discussion,
so I'm finding it hard to figure out what you take exception to.

I understand the arguments for input() and raw_input(), and agree
with them (despite my playing Devil's Advocate earlier in this
thread). I would like to see them renamed to be more descriptive of
what they actually do (input() and eval_input() ?), but on the whole
I agree that they are useful, especially if sys.stdin.readline is not
equivalent anyway (but see below about that).

But I do understand where Arthur is coming from on this one. A
substantial part of the conversation has consisted of phrases like,
"if Python does this, I'll look elsewhere," and "I wouldn't have
chosen Python if not for input()." Things like that do read like a
threat, and they are overblown to say the least. Python has a lot
going for it besides input(), to say the least. If anyone really
intended to stop using Python over that one, trivial, feature
(useful, yes, but still trivial), then I don't see why they would
stay with Python because of it.

It sure stirred up a lot of commentary though.

Post by kirby urner
raw_input = sys.stdin.readline

This is simply not equivalent. readline does not take a prompt as
an argument.
You'll have to write the function.

Well, no, you don't really. You could teach students to use print()
or sys.stdout.write() for output (including the prompt) and
sys.stdin.readline() for input. Or you could write it:

def raw_input(prompt=""):
sys.stdout.write(prompt)
return sys.stdin.readline()

Heck, writing that (without having to understand it all) could be a
great introduction to programming, by creating their own utility that
they can use all the time they learn that there's nothing magic about
programming. Anyone can do it. And the system isn't perfect, but if
you're missing something, you have permission and ability to add it.
My son learned to draw using perspective when he was three, not
because he understood it, but because he watched what his older
sister did and imitated her. I don't understand the idea that we
can't introduce things to students until they've understood all the
underlying concepts--that's not how we learn anything else in life.

To be honest, in thinking about teaching my nine-year-old and her
classmates Python it never occured to me to teach them to use input()
or raw_input(). I was going to go straight to PyGame, like LiveWires
without the religion. Do you really teach students using the command-
line for programs? I live at the command-line myself, but I don't
expect that of others. I would teach them how to build a GUI or at
least use dialogs for user input--something that they can recognize
and relate to. I would certainly introduce the command-line at some
point, but not so early that they'd be scared by a little dot notation.

Of course, I'm a parent and an amateur teacher. Your mileage may vary.

--Dethe

Young children play in a way that is strikingly similar to the way
scientists work --Busytown News

John Zelle

2006-09-07 00:46:39 UTC

I would want to keep the original names if only for historical reasons.

Post by Dethe Elza
But I do understand where Arthur is coming from on this one. A
substantial part of the conversation has consisted of phrases like,
"if Python does this, I'll look elsewhere," and "I wouldn't have
chosen Python if not for input()." Things like that do read like a
threat, and they are overblown to say the least.

I take exception to the word "threat" here. These are statements of intention.
There are more Python-like languages all the time. If one of those ends up
with a better constellation of features than Python for building a
pedagogically sound curriculum, then folks will begin to switch. I think you
will find that serious CS educators are always surveying the programming
language landscape. These were honest opinions about input and raw_input
helping attract us to Python. As I said, losing these takes away some of its
charm. It's only a threat if you think we really have some influence over
Guido :-). I've been trying to lay out rational arguments on a number of
fronts.

Post by Dethe Elza
Python has a lot
going for it besides input(), to say the least. If anyone really
intended to stop using Python over that one, trivial, feature
(useful, yes, but still trivial), then I don't see why they would
stay with Python because of it.

It's a constellation of features. No language is perfect for everyone or every
application. However, people with experience teaching have learned that
language does matter when it comes to introductory programming. We are
arguing for keeping these particular features in the constellation. Does one
feature make or break? Of course not, unless it's the only real difference
between two languages.

Post by Dethe Elza
It sure stirred up a lot of commentary though.

Post by kirby urner
raw_input = sys.stdin.readline

This is simply not equivalent. readline does not take a prompt as
an argument.
You'll have to write the function.

Well, no, you don't really. You could teach students to use print()
or sys.stdout.write() for output (including the prompt) and
sys.stdout.write(prompt)
return sys.stdin.readline()

Look at my previous comments, I said you'd have to write a function for it,
which is what you did.

Post by Dethe Elza
Heck, writing that (without having to understand it all) could be a
great introduction to programming, by creating their own utility that
they can use all the time they learn that there's nothing magic about
programming.

No, you've done just the opposite. You've taught them there's a magic
incantation they don't yet understand. Students (at least at the level I see)
are frustrated and feel patronized by things they are supposed to do without
understanding. Then they think their job is to memorize. I don't want them to
memorize, I want them to understand.

Post by Dethe Elza
Anyone can do it. And the system isn't perfect, but if
you're missing something, you have permission and ability to add it.

That's an argument for teaching functions (and later classes), which of course
we do. You might be surprised to learn that functions are one of the most
difficult concepts for my students to grasp. It always surprises me the
difficulty they have with this idea, even though it seems trivial to us.
Again, a good feature of Python is that they don't have to tackle functions
on day 1.

Post by Dethe Elza
My son learned to draw using perspective when he was three, not
because he understood it, but because he watched what his older
sister did and imitated her. I don't understand the idea that we
can't introduce things to students until they've understood all the
underlying concepts--that's not how we learn anything else in life.

I don't think this is analogous, as drawing in perspective is not an
analytical skill. Tiger Woods learned to golf at 3 without understanding
anything about the golf swing or the physics of the game. Some skills can be
learned (are best learned) by imitation. But imitating a computer programmer
(at that level anyway) is just typing. Being able to type a program is not
the same as programming.

Meeting the students where they're at, building on what they can already do,
brick by brick, and allowing them to have success is the best way to
motivate, in my experience.

Post by Dethe Elza
To be honest, in thinking about teaching my nine-year-old and her
classmates Python it never occured to me to teach them to use input()
or raw_input(). I was going to go straight to PyGame, like LiveWires
without the religion.

I have no experience teaching 9 year olds (my daughter's only 8, and I have no
intention of teaching her programming at the moment, as she has more
important things to learn like how to read fluently and add and subtract with
ease, not to mention multiply). I do have lots of experience teaching college
students. There is very little of _practical use_ I can teach them day 1 with
something like PyGame. I _can_ teach them _and have them understand_ a
program that will help them with their accounting homework. Or one that will
answer a question about the risks of gambling. That's a program that they
can't buy a better version of off-the-shelf. It's something specific to a
problem at hand. It's something most of them couldn't do before I opened
their eyes to a new tool. Or they can write a program to investigate a little
chaotic function... Those things are conceptually and practically simpler at
the command line. Basic bread and butter programming is input-process-output.
Sure it's not flashy, but it's useful and they can understand it. Those two
things can be strong motivators.

Post by Dethe Elza
Do you really teach students using the command-
line for programs? I live at the command-line myself, but I don't
expect that of others. I would teach them how to build a GUI or at
least use dialogs for user input--something that they can recognize
and relate to. I would certainly introduce the command-line at some
point, but not so early that they'd be scared by a little dot notation.

Basic text-io is the simplest, least mysterious way to start programming. Any
kind of GUI environment introduces tremendous intellectual overhead. You will
have a hard time convincing me it's better to start with more complicated
things and move on to the simpler. It just doesn't make sense. Even your
three year old probably didn't start drawing in perspective by looking at a
painting of the last supper.

Post by Dethe Elza
Of course, I'm a parent and an amateur teacher. Your mileage may vary.

It does. But I would also be the first to admit that there is no
one-size-fits-all solution to education. I'm sure many students would groove
on a PyGame curriculum. I don't think it would best serve the majority of the
students that I see in my classes, and there's not enough of me to tailor the
curriculum to be a best fit for every single student.

It has been an interesting discussion. Now I need to get back to work figuring
out how to educate my students tomorrow :-)

--John

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Peter Chase

2006-09-06 15:37:41 UTC

Post by Arthur Siegel

*
Being dispassionate on the issue itself - I have *never* used
raw_input() and, as it happens, I am generally literate enough at this
point so that the intentions of sys.stdin.readline is *clearer* to me
than is raw_input() - I am disturbed by the tone of the discussion.
Guess I prefer the all-in-the-family temper tantrum, then the calm and
dispassionate threat - explicit or implicit.
I guess I view it also as an example of the result of Python promoting
itself to the educational community in the wrong way, and on the wrong
footing, from day one - as the easy alternative, rather then as the
literate and productive alternative, the *best* alternative for getting
a certain class of problems solved in the least circuitous way.
In particular, the kinds of real world problems a student might want to
solve or explore.
Since sys.stdin.readline seems to me *more* literate, I'm OK with it.
And will maintain my apparently cloistered, unreal world view of how a
motivated student might want most to be approached, and her fragility.
Art
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig
!DSPAM:518,44fec68267041915216640!
Dost thou think, because thou art virtuous, there shall be no more cakes and ale?

John Zelle

2006-09-05 02:17:48 UTC

I agree whole-heartedly with Andre on this (except that I also want to
preserve input, see below). I understand the rationale for eliminating
the "redundancy" of these statements, but of course the same argument holds
for the print statement. Why not do away with it and just use sys.stdout?

The reason is that programs, almost by definition, do input and output.
Indeed, one very frutiful way of viewing programs is as a mapping from input
to outputs. Given that, any language that does not include both input and
output in its core functionality just feels wrong to me. It's one of the
weaknesses of languages like C++ and Java that the simplest possible programs
(ones that do lowly text IO) require "extra" machinery beyond the standard
built-ins. This isn't just another barrier for novices either; it's also an
extra burden for the average script writer. Looking at my own code, this
change "breaks" virtually everything I have written while at the same time
adding extra bulk and decreasing clarity and intent.

Post by Andre Roberge
The following is something I have been pondering for quite a while now
and am wondering what other people on this list think.
According to PEP 3100
(http://www.python.org/dev/peps/pep-3100/ )
raw_input() [as well as input()] is recommended for removal from the
built-in namespace, to be replaced by sys.stdin.readline().
While I don't think anyone can argue that this removal makes a major
difference for Python as a programming language, I believe it makes a
significant difference for using Python as a learning language, adding
a non-trivial barrier to learning.
Consider the following fake sessions at the interpreter prompt, where
I use extra parentheses to turn print as a function (as is also
proposed in Python 3000) - these parentheses can of course be used
with today's Python.
# First ever program

print("Hello world!")

Hello world!
# More complicated example from the first interactive session using
today's version

name = raw_input("Enter your name: ")

Enter your name: Andre

print("Hello " + name + "!")

Hello Andre!
# More or less the same example using the proposed changes.

import sys
print("Enter your name: ")
name = sys.stdin.readline()

<-- Andre

print("Hello " + name + "!")

Hello Andre!
1. to introduce the import statement
2. to introduce the dot notation (something Kirby would be happy with ;-)
Furthermore, the flow is not the same as with today's raw_input().
I don't like it.
While I totally agree with the proposed removal of input() [anything
using eval() in a hidden way is *bad*], my preference would be to keep
raw_input()'s functionality, perhaps renaming it to user_input() or
ask_user().

No! Keep input too! It's the single handiest input statement from any language
I've ever used. Dangerous? You bet. But also very, very handy -- especially
for simple introductory programs. By the time students are writing production
code, they should have a very good handle on what input does behind the
scenes. I also like the naming of input and raw_input as they stand. It
provides a perfect vehicle for explaining what eval is all about.

Post by Andre Roberge
Thoughts?

Of course, Guido has always been right in the past :-) But this change just
feels wrong to me. It brings a certain consistency at the cost of both
efficiency (requiring more code) and charm. Perhaps our BDFL will yet see the
light on this one.

--John

John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

dblank

2006-09-05 03:38:39 UTC

I also agree with y'all, but there is a subtlety that I don't like with
the current names and which might explain the confusion: raw_input() does
less than input(), but looks and sounds like it does more. I might like

name = ask("What is your name? ")

What is your name? John

seconds = askexp("What is your age, in days? ")

What is your age, in days? 43 * 365

or read(), and readeval(); or prompt(), and eval(prompt()).

But, I really hope that they keep an easy-to-use version.

-Doug

Post by John Zelle
I agree whole-heartedly with Andre on this (except that I also want to
preserve input, see below). I understand the rationale for eliminating
the "redundancy" of these statements, but of course the same argument holds
for the print statement. Why not do away with it and just use sys.stdout?
The reason is that programs, almost by definition, do input and output.
Indeed, one very frutiful way of viewing programs is as a mapping from input
to outputs. Given that, any language that does not include both input and
output in its core functionality just feels wrong to me. It's one of the
weaknesses of languages like C++ and Java that the simplest possible programs
(ones that do lowly text IO) require "extra" machinery beyond the standard
built-ins. This isn't just another barrier for novices either; it's also an
extra burden for the average script writer. Looking at my own code, this
change "breaks" virtually everything I have written while at the same time
adding extra bulk and decreasing clarity and intent.

print("Hello world!")

Hello world!
# More complicated example from the first interactive session using
today's version

name = raw_input("Enter your name: ")

Enter your name: Andre

print("Hello " + name + "!")

Hello Andre!
# More or less the same example using the proposed changes.

import sys
print("Enter your name: ")
name = sys.stdin.readline()

<-- Andre

print("Hello " + name + "!")

Post by Andre Roberge
Thoughts?

Of course, Guido has always been right in the past :-) But this change just
feels wrong to me. It brings a certain consistency at the cost of both
efficiency (requiring more code) and charm. Perhaps our BDFL will yet see the
light on this one.
--John
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

Toby Donaldson

2006-09-05 04:03:35 UTC

Let me add my voice to the chorus: removing raw_input() hurts
beginners, and, for beginners, it is far preferable than the proposed
alternative, which is cryptic and overly specific.

I saw Guido's Python 3000 talk at the Vancouver Python Workshop this
summer, and I am pretty sure he did not mention this (it was on my
mind --- I had read the PEP earlier). I

If raw_input were removed, then I expect we would see what happened in
the Java world in the early days: every teacher and textbook uses
their own home-rolled simple IO package. I hope Python 3000 does not
repeat Java's mistake!

I don't care about "input". Its there now and hasn't ever been useful
to me (eval(raw_input("...")) is a fine alternative), and, more
importantly, has apparently not caused confusion among students.

Toby

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

John Zelle

2006-09-05 13:15:10 UTC

Post by Toby Donaldson
I don't care about "input". Its there now and hasn't ever been useful
to me (eval(raw_input("...")) is a fine alternative), and, more
importantly, has apparently not caused confusion among students.

Again, for similar reasons to those being mentioned, I would like to keep
input as well as raw_input. From a pedagogical perspective, it's best to meet
students "where they're at." Most of my students have studied algorithms and
computation before, but in the context of mathematics. The most
straightforward way to start them out is to take their math background and
turn it into programs. This has the additional motivation of taking some of
the drudgery out of the math.

Given that starting point, it's very natural to write programs that "get a
number from the user". That's what input allows us to do, it interprets any
literal (more generally, expression) provided. Forcing them to use
eval(raw_input()) requires introducing strings as a data type, if they are to
understand it. While strings are simple and easy to introduce early, they are
not as intuitive to my students as numbers. They have never "manipulated"
strings before. They've been crunching numbers since second grade. Numbers,
then strings is the natural progression.

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Brad Miller

2006-09-05 14:54:57 UTC

I too will add one more voice to this chorus, in the hope that
numbers will influence Guido. The fact that input and raw_input
existed in Python was one important factor in our decision to move
our introductory curriculum to Python a couple years ago. I can
clearly remember excitedly telling my colleagues: "Look, you can do
input with one statement, its easy!"

Its hard to say for sure, but if I had seen that in order to get user
input I had to import sys and explain to students who are seeing
their first programming language what sys.stdin was all about.... I
don't think I would have explored Python much further.

I do not like the solution of staying with a 'golden age' version of
Python. For beginners its nice that they can just go to
www.python.org, download one file, run an installation wizard and
have the latest version on their Windows machines. Mac users have it
even easier. Having to tell them we are using an old version of the
language just seems wrong. Much less to tell Mac/Linux users that
they need to ignore the modern version that comes on their system.

Brad

Andre Roberge

2006-09-05 15:51:07 UTC

Again, for similar reasons to those being mentioned, I would like to keep
input as well as raw_input. From a pedagogical perspective, it's best to meet
students "where they're at." Most of my students have studied algorithms and
computation before, but in the context of mathematics. The most
straightforward way to start them out is to take their math background and
turn it into programs. This has the additional motivation of taking some of
the drudgery out of the math.
Given that starting point, it's very natural to write programs that "get a
number from the user". That's what input allows us to do, it interprets any
literal (more generally, expression) provided. Forcing them to use
eval(raw_input()) requires introducing strings as a data type, if they are to
understand it. While strings are simple and easy to introduce early, they are
not as intuitive to my students as numbers. They have never "manipulated"
strings before. They've been crunching numbers since second grade. Numbers,
then strings is the natural progression.

I don't teach CS, nor do I have formal CS "training" (so, take my
comments, including the original issue I raised, with a grain of
salt). However, this progression from number to strings makes sense
to me ... but I don`t like the idea of using input() in its current
form, given the huge potential for misuse. I think some other form,
that takes a string and attempts to extract a number (int or float)
from it would be better suited in a teaching environment - however, it
would have to remain a built-in.

Just to explore some alternative, what about having different names such as
input_number() and input_string()
or
get_number() and get_string()
or
ask_number() and ask_string()
?

Andr?

Post by John Zelle
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

Toby Donaldson

2006-09-05 17:23:40 UTC

As I say, *I* don't find the "input" function useful, but I am happy
to keep it around for those free-spirits who do.

Toby

Again, for similar reasons to those being mentioned, I would like to keep
input as well as raw_input. From a pedagogical perspective, it's best to meet
students "where they're at." Most of my students have studied algorithms and
computation before, but in the context of mathematics. The most
straightforward way to start them out is to take their math background and
turn it into programs. This has the additional motivation of taking some of
the drudgery out of the math.
Given that starting point, it's very natural to write programs that "get a
number from the user". That's what input allows us to do, it interprets any
literal (more generally, expression) provided. Forcing them to use
eval(raw_input()) requires introducing strings as a data type, if they are to
understand it. While strings are simple and easy to introduce early, they are
not as intuitive to my students as numbers. They have never "manipulated"
strings before. They've been crunching numbers since second grade. Numbers,
then strings is the natural progression.
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

Peter Chase

2006-09-05 14:45:23 UTC

I've been using Python for CS1. It goes down a lot easier, since there
are fewer magical incantations (include, import, using, etc., etc.) .
Further, it is definitely not a toy language. Naturally, I'm against
removing raw_input.

If you want to expose your students to the full horror of a
syntactically complete language, why not switch to C++, where you can
run programs in the compiler? I ask that, even though I like C++ better
than Java. (The C++ library templates seem better organized and less
confusing than the Java API, once the major concepts are understood.
But then, I mourn for Delphi.)

Christian Mascher

2006-09-05 16:33:40 UTC

Post by Andre Roberge
Furthermore, the flow is not the same as with today's raw_input().
I don't like it.
While I totally agree with the proposed removal of input() [anything
using eval() in a hidden way is *bad*], my preference would be to keep
raw_input()'s functionality, perhaps renaming it to user_input() or
ask_user().

I agree. Apart from the name raw_input() is a nice thig to have. It was
the first annoyance when I started with Java in school, to find it
doesn't have anything like it. Even sys.stdin is impractical in Java.

ask_user() or user_input() are good names.

Christian

Radenski, Atanas

2006-09-05 16:50:47 UTC

-----Original Message-----
Behalf Of Brad Miller
I too will add one more voice to this chorus, in the hope that
numbers will influence Guido.

Me too :-) I would like to see both input and raw_input preserved.
Replacing these with more complicated (from pedagogical perspective)
methods would probably give an additional reason for educators to look
at alternative languages, such as Ruby.

There were questions in this list of the appropriateness of the names of
the two functions. To me, the names of input and raw_input seem just
fine. One can tell students that the input function is more general and
interprets the input character sequence as a Python expression, finally
delivering its value. In contrast, raw_input is simpler and interprets
nothing - simply delivers the input string as a character string. It is
logical.

Just my ten cents.

Atanas

Atanas Radenski
mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/

There are wavelengths that people cannot see, there are sounds that
people cannot hear, and may be computers have thought that people cannot
think -- Richard Hamming

Dan Crosta

2006-09-05 17:28:37 UTC

Post by Radenski, Atanas
Me too :-) I would like to see both input and raw_input preserved.
Replacing these with more complicated (from pedagogical perspective)
methods would probably give an additional reason for educators to look
at alternative languages, such as Ruby.

I realize this is the education SIG list, but it's important to remember
that Python is not just for educators and students (though I believe it
makes a great language for those demographics). I used Python
extensively for scripting system administration tasks and interactive
scripts that our users would use. While hiding the input functions
inside the sys module wouldn't make life substantively harder for the
sysadmins, it might prove just enough hurdle to look at other options.

I will, for the sake of sanity and on-topic-ness, refrain from recanting
some of the great Python/Perl battles that the SCCS [1] has suffered
over the years.

- d

[1] Swarthmore College Computer Society, the group at which I was an
admin for 3 years. http://www.sccs.swarthmore.edu/

Radenski, Atanas

2006-09-06 23:34:03 UTC

-----Original Message-----
From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org]

Behalf Of Michael
Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000
I've been watching this discussion and wondering - how much of the
problems
people complain about would go away if here was a "teaching"

distribution

of
python. That is one that did the equivalent of
from teaching import *

Nowadays, college students want to do "real programming". You call a
language 'teaching' - you loose. I actually have to work hard to
convince my students that Python is not just a teaching language, but a
language for real work. I show them various rankings based on use,
salaries, jobs, etc.

A great thing about Python is that it is popular in commercial projects
and at the same time, you can teach beginners with it. IMHO, this is one
of the most distinguishing features of Python in comparison to other
languages

from teaching import *

This will immediately create two difficulties.
1. You implicitly declare to your students you are not dealing with
"real programming".
2. You most likely have to tell your entry-level students that you
cannot explain what the above thing means, but you will tell them later.
People switch form Java to Python to *avoid* this kind of situations.

Michael

Atanas

Toby Donaldson

2006-09-07 01:53:32 UTC

Post by Michael
I've been watching this discussion and wondering - how much of the
problems
people complain about would go away if here was a "teaching"

distribution

Post by Michael
of
python. That is one that did the equivalent of
from teaching import *

Nowadays, college students want to do "real programming". You call a
language 'teaching' - you loose. I actually have to work hard to
convince my students that Python is not just a teaching language, but a
language for real work. I show them various rankings based on use,
salaries, jobs, etc.
A great thing about Python is that it is popular in commercial projects
and at the same time, you can teach beginners with it. IMHO, this is one
of the most distinguishing features of Python in comparison to other
languages

Post by Michael
from teaching import *

What if instead of naming the package "teaching", it was called
something less offensive, like "simpleIO" or "userinput" or
"interactive" or "convenience"?

Toby

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

Liow, Dr. Yihsiang

2006-09-07 02:15:09 UTC

Hi everyone,

I've been reading postings in thie group a long time but have not really posting much.

Anyway, I have a question.

I'm planning to start a high school programming club and I'm looking for materials. I've been programming Python for 4 years and have used PyGame, VPython in some of my CS classes. But the plan for the high school programming club is to attract high school students with no background in programming at all. I'm also planning to start small and grow slowly. So I'm thinking of going an *8-week* intro to programming using Python. The club might meet for 1 to 1.5 hours. I'll try to revive it again in Spring. Perhaps for the weeks between the two 8-week sessions, I'll try to stay in touch with the high school students using a message board. I might involve senior CS students as mentors.

That's roughly the plan. The next step is just to find suitable teaching or lab material. I've already looked at LiveWire.

Do you have any recommendations? Again this is for high school students with no background in programming and they might meet only 1-1.5 hours/week for 8 weeks.

Also, if you have suggestions and tips for such a set up, please *do* let me know. (If you think 8 weeks of 1.5 hours is too little, then please *do* persuade me to modify my plan.)

Thanks in advance.

- yihsiang

Radenski, Atanas

2006-09-07 13:58:09 UTC

-----Original Message-----
From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org]
On Behalf Of Toby Donaldson
What if instead of naming the package "teaching", it was called
something less offensive, like "simpleIO" or "userinput" or
"interactive" or "convenience"?

This is a plausible way to remove the 'teaching' label. I would prefer
'stdin'.

Now imagine a beginner who is looking at her very first Python program.
The first line she will see in her first program ever will be this:

from stdin import *

This person and her instructor will have to deal with modules and import
FIRST, although the student is not likely to develop multi-modular
programs at the very beginning.

I wonder how is the instructor going to tell her what is the meaning of
'from stdin import *'? I guess, in the same way instructors tell what
'public static void main (...) is'. In this way we are going to the Java
nonsense (nonsense from the perspective of teaching beginners, of
course, otherwise Java is a wonderful language).

This discussion is difficult because people speak form tow different
perspective: the teacher's perspective vs the developer's.

In this thread I have a teacher's perspective. I would like to see
Python keep, rather than loose its edge as a beginner's language. John
Zelle explained what that means very well - several times in this thread
only.

Let us have more teachers teach Python, and more beginners study and
enjoy it. Then we will probably have more Python developers as well.

Toby

Atanas

Brian Blais

2006-09-07 19:06:18 UTC

print("Hello world!")

Hello world!
# More complicated example from the first interactive session using
today's version

name = raw_input("Enter your name: ")

Enter your name: Andre

print("Hello " + name + "!")

Hello Andre!
# More or less the same example using the proposed changes.

import sys
print("Enter your name: ")
name = sys.stdin.readline()

<-- Andre

print("Hello " + name + "!")

I think that both should stay, perhaps with different names as suggested by others.
It would seem that eval(stdin.readline()) is far more confusing to beginners. I
don't see input() as dangerous at all, because no serious developer is going to
include it in an end-product, and a beginner would never be in a position to do any
real harm. On the other hand, input() is extremely useful, and concise.

So, is this removal a done-deal, or is there some effective way of reversing the
decision? Does Guido read this list?

bb

--
-----------------

bblais at bryant.edu
http://web.bryant.edu/~bblais

Dethe Elza

2006-09-07 21:51:06 UTC

Post by Brian Blais
So, is this removal a done-deal, or is there some effective way of reversing the
decision? Does Guido read this list?

It's a done deal (the ToDo list item for it marked [Done]), but it
could still be reversed. Public outcry caused Guido to reverse on
lambda. I can't remember offhand if map and reduce were spared or
not. Guido does read this list, but I don't know how often. If you
want his attention, the better way would be to post to the
python-3000 list with a message that the edu-sig list has achieved
rough consensus that input/rawinput should be kept, although possibly
renamed, with a pointer to this thread.

No guarantees that will work (and there may be a hue and cry over my
use of "consensus"), but it is the most likely way to get input()'s
head retroactively off the chopping block.

--Dethe

"I can't recommend global variables, literals, or reliance on side
effects
to anyone, but they've always worked for me." --Denis Richie

Arthur

2006-09-07 23:36:15 UTC

Post by Dethe Elza
No guarantees that will work (and there may be a hue and cry over my
use of "consensus"), but it is the most likely way to get input()'s
head retroactively off the chopping block.
--Dethe

I'll throw in a pledge of 3 weeks of silence on edu-sig as adiitional
incentive for Guido to find a way to accommodate the will of the professors.

Art

dblank

2006-09-08 00:55:38 UTC

[Does this capture the essense of the discussion? I know some said that
they don't use them, and this would not stop them from not using them :)
-Doug]

Core Python maintainers,

Over on the Python edu-sig, we have been discussing a small aspect of PEP
3100 and its effects on teaching and classroom use. What is at issue is
input() and raw_input(), which have been targeted for removal, and marked
[done]:

http://www.python.org/dev/peps/pep-3100/

Guido suggested in his 2002 "Python Regrets" talk that
eval(sys.stdin.readline()) and sys.stdin.readline() can be used for these,
respectively. That's not quite true of course, because they also have a
prompt. But even that aside, we believe that we would like to keep them
as-is.

I think that we have consensus among (the teachers of edu-sig) that many
of us rely on the ease-of-use of the input() and raw_input() functions for
one simple reason: input() and raw_input() can be used on day-1 of class,
before discussing imports, streams, strings, eval, or functions. Complete
replacement solutions require discussions of all of those topics.

We believe that their removal goes against the spirit of Python in the
classroom, and Python will be more complicated on the first day of class
because of it.

There were some suggestions that there could be better names for them,
including "ask()" and "askexp()". In any event, we'd rather have them the
way they are than not at all. Of course it is easy to add as a site.py
implementation, but those of us that teach would rather use 100% Pure
Python.

For the complete edu-sig discussion, see:

http://mail.python.org/pipermail/edu-sig/2006-September/006967.html

Thank you for considering leaving this as is,

The Teachers of Python edu-sig

kirby urner

2006-09-08 01:08:16 UTC

I will add, maybe just to stir the pot, that I usually teach Python
interactively in the shell for quite some time before writing any
"scripts" and or if my students write stuff, it's for the purpose of
importing said stuff into said shell.

Ergo, I'm not one of those who uses "raw_input" from "day one". I
rarely use it, and given I'd have gone over importing and namespaces
in some depth before doing so, I'd accommodate the switch to importing
from sys for stdin/stdout i/o w/ few problems (as long as either can
still be redirected).

I think some of us here maybe grew up in the days of early BASIC, when
"a first program" was some loop with a menu, and users prompted with
ans = raw_input("Selection?: ") type stuff. I rarely think that way
anymore myself. Treating an entire module as interactive, with no
looping menu overhead, is far more conducive to transitioning to the
GUI event loop later.

In some, maybe it's OK to get rid of raw_input if it prevents another
generation of lame menu loop programming. Those should be banned
except in upper level "lets think like a 1960s mainframer" course
(esoteric, not for newbies).

Still, that sys.stdin.readline thing looks a lot like Java -- but also
C#. Sheesh, why am I worried? IronPython is setting the standard.
That should be OK.

So seriously, from __past__ import is my preferred solution (I called
it 'retro'). I'm not wanting to sign on any petition, in any case --
not my style (except sometimes (signed a "get Shockwave on Linux!" web
thingy, also "Bring Duckman cartoons to DVD!")).

Kirby

Arthur

2006-09-08 01:51:49 UTC

Post by kirby urner
So seriously, from __past__ import is my preferred solution (I called
it 'retro').

Probably an uphill battle.

My understanding - based on a short conversation I had with Guido at
PyCon 2004, and perhaps other references I have come across - is that he
does not support the idea of these kinds of toggles as permanent
language features.

OTOH, if I recall correctly, Tim Peters has expressed some admiration
for the Dr. Scheme scheme of things - which would presumably implies a
positive view about its ability to toggle language features.

Tim does not strike one as the petition signer type, in any case.

I of course think the issue is blown way out of proportion in any case -
cannot understand the hesitancy to introduce the concept of import on
Day One, thinking it can be explained adequately in one or two succinct
sentences (and probably should be in any case), and if it sounds strange
on Day One, well so does everything else sound strange on Day One. So
the idea that no one is coming back for Day Two for that reason is
unreasonable.

import

is in fact the most exciting statement we have.

import OpenGL
import VPython
import Numarray
import some kid's bright idea from yesterday
import CandyStore as yummies

I would not have been back for Day Two of Python if I didn't understand
from Day One, what import could do for me.

I think the professors are very wrong here.

Art

Post by kirby urner
I'm not wanting to sign on any petition, in any case --
not my style (except sometimes (signed a "get Shockwave on Linux!" web
thingy, also "Bring Duckman cartoons to DVD!")).

dblank

2006-09-08 03:08:37 UTC

Post by Arthur
I think the professors are very wrong here.

This isn't about "I'm right; you're wrong"; it's about making a decsion
that can effect the way that *others* want to use Python. Removing input()
FORCES people to have to address import, streams, dot notation, functions,
and strings.

The whole point of keeping input() is to give the teachers a choice to do
interesting things without introducing (in their mind) unnecessary topics
or syntax.

Personally, I have to address import fairly early for other reasons, and
have never really used input(). But I don't want to make John Zelle teach
the way that I do. In fact, I might want to leave some flexibility for me
to adapt in the future. (Just this year, we are teaching Python in our
intro courses at Bryn Mawr College, and so is Swarthmore College,
Haverford College, and several other colleagues have picked it up. Python
is on the move!)

Java gives us no choice at all. Talk about "there's one way to do it." You
must deal with too much stuff to make the computer do something, anything.

I'll revise the letter to include some of the other points, especially
those points that make input() BETTER than it is. Revision later...

-Doug

Post by Arthur
Art

Post by kirby urner
I'm not wanting to sign on any petition, in any case --
not my style (except sometimes (signed a "get Shockwave on Linux!" web
thingy, also "Bring Duckman cartoons to DVD!")).

kirby urner

2006-09-08 04:25:55 UTC

Post by dblank

Post by Arthur
I think the professors are very wrong here.

OK, you've persuaded me: remove it, by all means.

Kirby

dblank

2006-09-08 11:15:31 UTC

Post by dblank

Post by Arthur
I think the professors are very wrong here.

OK, you've persuaded me: remove it, by all means.

:) Of course, I meant that it forces people to use those topics before
they want to.

I assume that you don't really want to dictate to other teachers the order
that these items are addressed, right? Just checking...

-Doug

Post by kirby urner
Kirby

kirby urner

2006-09-08 14:31:44 UTC

Post by dblank
:) Of course, I meant that it forces people to use those topics before
they want to.
I assume that you don't really want to dictate to other teachers the order
that these items are addressed, right? Just checking...
-Doug

I think there's more to this picture than we're discussing here. How
does this removal of 'raw_input' and 'input' relate to the proposal to
remove 'print'? Will that capability be in sys.stdout or something?

As for dictating to teachers, you're right that I don't want to do
that. But nor do I want teachers to have the power to freeze features
in place just on the basis of what sequence they've trained themselves
to use over the years. Inertia in and of itself is just as able to
kill and language as keep it lively.

For example, I think the way mathematics is taught in most USA public
schools these days is a disaster. We should have more phi and less
pi. I regard my primary constituency as the end user, but a lot of
these kids are too young to vote and/or feel inarticulate when it
comes to representing their own long term best interests to adults, so
I can't count on them to agree with me. Anyway, you can count on me
to recruit for new ways of teaching within a dramatically redesigned
curriculum (I call it gnu math).

Likewise, I think "future generations" are where Guido should be
looking, not at entrenched special interests, be those teachers,
astronomers, number crunchers, former C programmers, Perl refugees,
dabblers, Schemers or whathaveyou. Python 3000 is Guido's big chance
to address weaknesses with the benefit of decades of hindsight. We
knew stuff would break, so just telling me such and such will be
inconvenient if changed, is not a deterrent (I relish breaking things
that need breaking).

In the case of raw_input, I haven't had enough time to think about it,
nor do I feel I have the whole picture. I recall John Zelle likewise
requesting a more detailed roadmap of all proposed changes around i/o.
I feel it's an inadequate process for us to just pick this one
feature out of the bag, and crystalize as "teachers" around it, either
pro or con.

I think the best process is for those of us with a strong interest
and/or strong opinions about Python 3000, to work directly with the
dev people, and not turn edu-sig into some kind of spectator bleechers
with block voting. We should remain as individuals and operate the
community API effectively in that capacity, not band together in
poliltical factions based on which lists we happen to have joined.

So I will encourage all subscribers here to avoid any "petition"
nonsense. If you wanna talk Pydev, join pydev why not? I also
encourage teachers to explore IronPython, as I do think we'll be
wanting the shared VMs, whoever is making them (this is *not* a MSFT
plug per se). Having multiple languages targeting the same runtime
architecture at a software level is too big an advantage to ignore.
In retrospect, we'll likely view CPython as a prototype (one that
built its own VM, so also bold and pioneering -- something for Guido
to always be proud of).

Kirby

Ian Bicking

2006-09-08 14:42:34 UTC

I believe the plan isn't that print be removed, just turned into a
builtin function, like print('x=', x)

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

Douglas S. Blank

2006-09-08 14:54:29 UTC

Kirby,

As a teacher, I don't have time to argue over on python-dev what should
and should not be included in the language. And don't want to! I am
thinking of our "petition nonsense" as a data point for those people
that do take the time over on python-dev to figure out the best thing to
do next, and I'll trust them.

It seemed to at least a few people on the list that python-dev'ers may
not have fully considered the ramifications of this particular change in
regards to teaching. We simply want to let them know about this
oversight. John has written probably the best-selling textbook for intro
Python; if he is concerned, then they should at least take a second look
at it (whatever "it" might be.)

As far as I understood the discussion about removing "print", it was to
remove it as an expression and add it as a function. This is a good move
(in my opinion) because it is now even more parallel with input(), and
makes more sense, and makes it more useful. If the discussion was to
turn "print" into "sys.stdout.write()" then I think some teachers would
again be upset, and rightly so. Maybe they should rename it output()
though. :)

Now, it's time for the semester to begin... ACK

-Doug

I think there's more to this picture than we're discussing here. How
does this removal of 'raw_input' and 'input' relate to the proposal to
remove 'print'? Will that capability be in sys.stdout or something?
As for dictating to teachers, you're right that I don't want to do
that. But nor do I want teachers to have the power to freeze features
in place just on the basis of what sequence they've trained themselves
to use over the years. Inertia in and of itself is just as able to
kill and language as keep it lively.
For example, I think the way mathematics is taught in most USA public
schools these days is a disaster. We should have more phi and less
pi. I regard my primary constituency as the end user, but a lot of
these kids are too young to vote and/or feel inarticulate when it
comes to representing their own long term best interests to adults, so
I can't count on them to agree with me. Anyway, you can count on me
to recruit for new ways of teaching within a dramatically redesigned
curriculum (I call it gnu math).
Likewise, I think "future generations" are where Guido should be
looking, not at entrenched special interests, be those teachers,
astronomers, number crunchers, former C programmers, Perl refugees,
dabblers, Schemers or whathaveyou. Python 3000 is Guido's big chance
to address weaknesses with the benefit of decades of hindsight. We
knew stuff would break, so just telling me such and such will be
inconvenient if changed, is not a deterrent (I relish breaking things
that need breaking).
In the case of raw_input, I haven't had enough time to think about it,
nor do I feel I have the whole picture. I recall John Zelle likewise
requesting a more detailed roadmap of all proposed changes around i/o.
I feel it's an inadequate process for us to just pick this one
feature out of the bag, and crystalize as "teachers" around it, either
pro or con.
I think the best process is for those of us with a strong interest
and/or strong opinions about Python 3000, to work directly with the
dev people, and not turn edu-sig into some kind of spectator bleechers
with block voting. We should remain as individuals and operate the
community API effectively in that capacity, not band together in
poliltical factions based on which lists we happen to have joined.
So I will encourage all subscribers here to avoid any "petition"
nonsense. If you wanna talk Pydev, join pydev why not? I also
encourage teachers to explore IronPython, as I do think we'll be
wanting the shared VMs, whoever is making them (this is *not* a MSFT
plug per se). Having multiple languages targeting the same runtime
architecture at a software level is too big an advantage to ignore.
In retrospect, we'll likely view CPython as a prototype (one that
built its own VM, so also bold and pioneering -- something for Guido
to always be proud of).
Kirby

kirby urner

2006-09-08 15:12:22 UTC

As a teacher, I don't want other teachers meddling with our snake on a
"don't have time" basis -- except in their individual capacities. As
"petition signers" I have no interest in them.

Post by Douglas S. Blank
It seemed to at least a few people on the list that python-dev'ers may
not have fully considered the ramifications of this particular change in
regards to teaching. We simply want to let them know about this
oversight. John has written probably the best-selling textbook for intro
Python; if he is concerned, then they should at least take a second look
at it (whatever "it" might be.)

John gets my respect and attention, but that doesn't mean he adds any
weight to his views by circulating a petition (which, for the record
*he has not done*). The minute he politicizes it in this way, I start
to lower my opinion.

Post by Douglas S. Blank
As far as I understood the discussion about removing "print", it was to
remove it as an expression and add it as a function. This is a good move
(in my opinion) because it is now even more parallel with input(), and
makes more sense, and makes it more useful. If the discussion was to
turn "print" into "sys.stdout.write()" then I think some teachers would
again be upset, and rightly so. Maybe they should rename it output()
though. :)

I'm sick of these "teachers" you keep talking about. They should all
just go away, and let the real programmers have their jobs. Don't
even *think* about teaching Python if you haven't coded in it
professionally and made real money off it. That's closer to my
attitude than "oh, the teachers are upset, we should care."

Post by Douglas S. Blank
Now, it's time for the semester to begin... ACK
-Doug

I hope we continue ignoring "teachers" completely, but not John Zelle.
I also listen to Arthur and Dethe.

Kirby

Douglas S. Blank

2006-09-08 15:39:42 UTC

kirby urner wrote:

[snip]

Post by kirby urner
I'm sick of these "teachers" you keep talking about. They should all
just go away, and let the real programmers have their jobs. Don't
even *think* about teaching Python if you haven't coded in it
professionally and made real money off it. That's closer to my
attitude than "oh, the teachers are upset, we should care."

Wow. What list was this again? This response seems just a tad beyond
"passionate." Some might find it even hostile. I think I must have
misunderstood the goals of this mailing list.

Individuals can send their own comments, whatever they may be, to
python-dev. I'm going away, as requested. The noise to signal ratio here
is pretty high, and now I fear I have contributed to that.

You can find me over at edupython at googlegroups.com.

-Doug

Post by Douglas S. Blank
Now, it's time for the semester to begin... ACK
-Doug

I hope we continue ignoring "teachers" completely, but not John Zelle.
I also listen to Arthur and Dethe.
Kirby

kirby urner

2006-09-08 16:13:05 UTC

Post by Douglas S. Blank
You can find me over at edupython at googlegroups.com.
-Doug

Who said we couldn't be passionate and hostile as teachers? As long
as we have it under control.

I'm just registering my attitude, risking no one's reputation but my
own, on a list set aside for teachers (which is what I am).

I think the petition process would set a dangerous precedent, if it
were in any way considered a way to get around already established
machinery. It'd be just like many teachers I know to think they
should get special privileges.

I say we give them zero extra power, simply on the basis of their
being teachers. That'd be unfair to other constituencies.

As a teacher, I'd be deeply ashamed to have my name on a Python
Petition of any kind, unless Guido had already signed off on that as a
viable community process. To my knowledge, he hasn't. Maybe I'm out
of date.

Kirby

Ian Bicking

2006-09-08 16:29:47 UTC

Post by kirby urner
As a teacher, I'd be deeply ashamed to have my name on a Python
Petition of any kind, unless Guido had already signed off on that as a
viable community process. To my knowledge, he hasn't. Maybe I'm out
of date.

I don't understand your strong reaction. OK -- saying "if Python 3k
takes away input() then I'm going to use Ruby" is pretty lame and will
keep an opinion from being taken seriously. But all Doug was talking
about was registering the opinion of people on edu-sig, who are not on
the py-dev, and who care about these functions where most everyone else
is merely indifferent. There's no formal process one way or the other;
all you can do is register your opinion, there's no vote, it's not a
democracy, but that doesn't mean that participation doesn't matter.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

kirby urner

2006-09-08 16:41:38 UTC

Post by Ian Bicking
I don't understand your strong reaction. OK -- saying "if Python 3k
takes away input() then I'm going to use Ruby" is pretty lame and will
keep an opinion from being taken seriously. But all Doug was talking
about was registering the opinion of people on edu-sig, who are not on
the py-dev, and who care about these functions where most everyone else
is merely indifferent. There's no formal process one way or the other;
all you can do is register your opinion, there's no vote, it's not a
democracy, but that doesn't mean that participation doesn't matter.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

We have PEPs, forums for debating them, venues in which it's the job
of professionals to pay attention. What is someone to make of a
"petition" showing up in an inbox, somehow stamped was belonging to
Edu-Sig, which is native Python infrastructure. What's it supposed to
mean? "Take me seriously just because I'm a Python SIG?" Why?

If someone wants to circulate a petition, fine, but don't drag edu-sig
into it, is my attitude. That's not what edu-sig is about. It's not
a political forum for teachers who are too lazy or otherwise
preoccupied, to avoid doing their homework as to how Python's
development process is already managed.

Do people send petitions to Linus Torvalds about what they'd like in
the kernel? Maybe they do. Sounds pretty lame to me if they do.

I would hate to see edu-sig debased into some spectator group that
sees its mission as kibbitzing about Python 3000, second guessing what
the core language developers are up to. That'd just kill the worth of
this group to me. I'd hate too see so much good work destroyed by
politicians.

Kirby

John Zelle

2006-09-08 18:17:13 UTC

OK, I lied: one last post. I see no problem with posting a message to whatever
group seems most appropriate and including a pointer to the discussion on
this thread. That's not "dragging edu-sig into a political role" it's simply
avoiding rehashing what I think has been a fruitful discussion. This is a
public forum, and we should be willing to bring the discussion that occurs
here to others who might (should?) have an interest.

--John

We have PEPs, forums for debating them, venues in which it's the job
of professionals to pay attention. What is someone to make of a
"petition" showing up in an inbox, somehow stamped was belonging to
Edu-Sig, which is native Python infrastructure. What's it supposed to
mean? "Take me seriously just because I'm a Python SIG?" Why?
If someone wants to circulate a petition, fine, but don't drag edu-sig
into it, is my attitude. That's not what edu-sig is about. It's not
a political forum for teachers who are too lazy or otherwise
preoccupied, to avoid doing their homework as to how Python's
development process is already managed.
Do people send petitions to Linus Torvalds about what they'd like in
the kernel? Maybe they do. Sounds pretty lame to me if they do.
I would hate to see edu-sig debased into some spectator group that
sees its mission as kibbitzing about Python 3000, second guessing what
the core language developers are up to. That'd just kill the worth of
this group to me. I'd hate too see so much good work destroyed by
politicians.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

kirby urner

2006-09-08 19:54:27 UTC

Post by John Zelle
OK, I lied: one last post. I see no problem with posting a message to whatever
group seems most appropriate and including a pointer to the discussion on
this thread. That's not "dragging edu-sig into a political role" it's simply
avoiding rehashing what I think has been a fruitful discussion. This is a
public forum, and we should be willing to bring the discussion that occurs
here to others who might (should?) have an interest.
--John

I completely agree with bringing threads to one anothers' attention.
I do the same, all the time.

Kirby

Ian Bicking

2006-09-08 16:01:47 UTC

Post by Douglas S. Blank
Kirby,
As a teacher, I don't have time to argue over on python-dev what should
and should not be included in the language. And don't want to! I am
thinking of our "petition nonsense" as a data point for those people
that do take the time over on python-dev to figure out the best thing to
do next, and I'll trust them.
It seemed to at least a few people on the list that python-dev'ers may
not have fully considered the ramifications of this particular change in
regards to teaching. We simply want to let them know about this
oversight. John has written probably the best-selling textbook for intro
Python; if he is concerned, then they should at least take a second look
at it (whatever "it" might be.)

I think this is a good idea; this entire discussion will be rather
useless if no one on py-dev or py3k sees it. You don't have to
necessarily speak for everyone or for edu-sig, except to note that many
people want both input() and raw_input(), and point people at the
discussion, and let the discussion progress however it does. The
py-dev/py3k lists have a limited audience with a very specific
perspective and set of interests, and outside perspectives are useful.
Maybe not always appreciated, but at least useful ;)

I don't think the email has to be perfect. Maybe change "consensus" to
"fairly wide agreement", send it off as you wrote it, and then you and
edu-sig can let it go from there without further comment.

[I suspect that input() in its current form will not remain, but
raw_input() may, but it entirely depends on whether anyone expresses
interest in it]

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

Radenski, Atanas

2006-09-08 14:37:19 UTC

________________________________

From: edu-sig-bounces at python.org on behalf of Arthur
Sent: Thu 9/7/2006 6:51 PM

import
is in fact the most exciting statement we have.
import OpenGL
import Python
import Numarray
import some kid's bright idea from yesterday
import CandyStore as yummies
I would not have been back for Day Two of Python if I didn't understand
from Day One, what import could do for me.

Art, this is indeed a very smart example.

You are obviously way more intelligent than the average student whom we need to teach. Our job is to teach Python programming to anyone who may happen to be in our classes. What is good for you may not be good for ordinary beginners. Ordinary mortals usually do not find the meaning of life in the beausty of import statements :-)

I think the professors are very wrong here.

May be there are, or may be they are not.

Art

Atanas

kirby urner

2006-09-08 15:07:05 UTC

You are obviously way more intelligent than the average student whom we need to teach. > Our job is to teach Python programming to anyone who may happen to be in our
classes. What is good for you may not be good for ordinary beginners. Ordinary mortals > usually do not find the meaning of life in the beausty of import statements :-)

Ordinary mortals should. I don't like pandering to beginners, dumbing
it all down for their sake. Arthur, a paradigm beginner at one point
(an articulate one though) made it clear that *he* doesn't want
dumbing down "to make it easier for newbies" either. He *hates* being
condescended to (and I appreciate that).

So I, for my part, as a teacher (professionally, I get paid), do NOT
regard it as my job to dilute Python to whatever extent necessary. I
talk about namespaces immediately, on the very first day, as I've
chronicled in this archive. Teachers who don't: I compete with them,
I say "here, you learn Kung Fu, there, they treat you like you'll
never have skills."

Post by Arthur
I think the professors are very wrong here.

May be there are, or may be they are not.

Post by Arthur
Art

Atanas

And I *certainly* champion the right to take issue with "professors"
even within their realm of maximum expertise (teaching, supposedly,
but we many times discover otherwise).

Kirby

ajsiegel

2006-09-08 18:33:35 UTC

From: "Radenski, Atanas"

Post by Radenski, Atanas
You are obviously way more intelligent than the average student
whom we need to teach.

Standardized testing seems to indicate me to be a good deal to the better spectrum of the bell curve.

But I honestly believe all that buys me is the ability to be a run-of-the-mill-programmer.

I certainly have no feeling of being anything other than within the middle of pack in terms
of native intelligence among those who actually eventually get some grasp.

I honestly feel that curriculum geared to some a population substanitally different than
myself can only being some form of busywork for all concerned -

as unpleasant as that might sound to those who percieve that to be their employment.

Art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060908/acac4912/attachment.html

John Zelle

2006-09-08 18:50:54 UTC

Post by ajsiegel
From: "Radenski, Atanas"

Post by Radenski, Atanas
You are obviously way more intelligent than the average student
whom we need to teach.

Standardized testing seems to indicate me to be a good deal to the better
spectrum of the bell curve.
But I honestly believe all that buys me is the ability to be a
run-of-the-mill-programmer.

Perhaps, but no where near a run-of-the-mill student.

Post by ajsiegel
I certainly have no feeling of being anything other than within the middle
of pack in terms of native intelligence among those who actually eventually
get some grasp.
I honestly feel that curriculum geared to some a population substanitally
different than myself can only being some form of busywork for all
concerned -
as unpleasant as that might sound to those who percieve that to be their employment.

That's assuming that the goal of said education is to produce professional
programmers. I believe that everyone has something to gain from learning what
software is really all about. Most will not rise to the level of professional
(or even competent) programmer. Similary, most students taking English
classes will never become successful novelists. Does that mean all the others
are just doing busywork? I've always thought you a champion of liberal
learning, don't all students deserve to have their intellectual worlds
expanded to the extent possible?

--John

ps. That's really, really, my last post. Unless someone actually wants to
discuss the substance of the arguments I've made earlier. If challenged, I'll
probably take the bait...

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

ajsiegel

2006-09-08 19:04:12 UTC

----- Original Message -----
From: John Zelle
Date: Friday, September 8, 2006 2:51 pm
Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000
To: edu-sig at python.org

Post by ajsiegel
From: "Radenski, Atanas"

Post by Radenski, Atanas
You are obviously way more intelligent than the average student
whom we need to teach.

Standardized testing seems to indicate me to be a good deal to

the better

Post by ajsiegel
spectrum of the bell curve.
But I honestly believe all that buys me is the ability to be a
run-of-the-mill-programmer.

Perhaps, but no where near a run-of-the-mill student.

Post by ajsiegel
I certainly have no feeling of being anything other than

within the middle

Post by ajsiegel
of pack in terms of native intelligence among those who

actually eventually

Post by ajsiegel
get some grasp.
I honestly feel that curriculum geared to some a population

substanitally> different than myself can only being some form of
busywork for all

Post by ajsiegel
concerned -
as unpleasant as that might sound to those who percieve that

to be their

Post by ajsiegel
employment.

That's assuming that the goal of said education is to produce
professional
programmers. I believe that everyone has something to gain from learning what
software is really all about. Most will not rise to the level of professional
(or even competent) programmer. Similary, most students taking
English
classes will never become successful novelists. Does that mean
all the others
are just doing busywork? I've always thought you a champion of
liberal
learning, don't all students deserve to have their intellectual worlds
expanded to the extent possible?
--John
ps. That's really, really, my last post. Unless someone actually wants to
discuss the substance of the arguments I've made earlier. If
challenged, I'll
probably take the bait...
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
_______________________________________________
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/20060908/759a0890/attachment.htm

ajsiegel

2006-09-08 19:22:24 UTC

From: John Zelle

Post by John Zelle
That's assuming that the goal of said education is to produce
professional
programmers. I believe that everyone has something to gain from learning what
software is really all about. Most will not rise to the level of professional
(or even competent) programmer. Similary, most students taking
English
classes will never become successful novelists. Does that mean
all the others
are just doing busywork? I've always thought you a champion of
liberal
learning, don't all students deserve to have their intellectual worlds
expanded to the extent possible?

Part of what would be nice if we each didn't reduce the others ideas/statements to their
most absurd interpretation.

The fact of the matter is that I *was* an English student, at a very unfancy commuter school and
all I remember is being challenged - Chaucer *must* be read in Middle English, Joyce is Joyce,
and Shakespeare is Shakespeare, nothing that can be done about that. Modern criticism is
erudite, drawing upon deeper notions derived from the serious study of history, philosophy, psychology. Nothing that can be done about that either.

I guess there was Composition101 - required course for engineering students.

But we couldn't be asking that Guido put designing for that near the top of his agenda,
could we?

I guess that would be CP4E - which I have felt from the beginning was a miscue -
and have never been very shy about saying so, as you well know.

Art

Post by John Zelle
--John
ps. That's really, really, my last post. Unless someone actually wants to
discuss the substance of the arguments I've made earlier. If
challenged, I'll
probably take the bait...
--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
_______________________________________________
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/20060908/c5e66e9f/attachment.html

ajsiegel

2006-09-08 20:30:05 UTC

From: John Zelle

Post by ajsiegel
But I honestly believe all that buys me is the ability to be a
run-of-the-mill-programmer.

Perhaps, but no where near a run-of-the-mill student.

For the record, I think that is really only a matter of degree of motivation.

Alice's "lessons", for example, might be valid within the domain of people who don't
give a shit about learning to program. But then again, the chances of teaching someone who
doesn't give a shit about learning to program, to program - without the slight-of-hand
of changing the meaning of the word - is zero.

And for the record, my own motivation for learning to program was always as
a means to an ends. At some level I perceive the details of what it means to
be able to program as largely artifical construct in any case - whether it be the
Python, Java, Scheme construct. And therefore not compelling, in and of itself.

Realizing, as well, that is what is inevitable within these constructs -
i.e. what I guess computer science is *really* about - is not something I see
as accessible to me, at least without more motivation then I have to dig into it,
or the level of the kind of technical intelligence where things might pop out to
me more effortlessly.

I like to think that in other realms,.something other might be truer, but in the
technical realm I see myself as a middle brow, at best.

So I have not hesitated to consider my own learning curve as typical, and
suggestions from that experience as within the range of what would, should
be of interest to professional educators teaching at introductory levels.

Art

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060908/8bf34b12/attachment.html

Andre Roberge

2006-09-08 01:49:46 UTC

Post by dblank
[Does this capture the essense of the discussion? I know some said that
they don't use them, and this would not stop them from not using them :)
-Doug]

Since I raised the issue in the first place, I'll just mention again
one additional point I raised which may have been overlooked. It is
generally recognized that input() == eval(raw_input()) is "not safe"
and therefore not a good example to give to beginners. Furthermore,
in the context of teaching, input() is, I believe, primarily used to
extract a number from a string. Thus, I would suggest that input
should be replaced by something like

def get_number(prompt):
s = raw_input(prompt)
try:
n = int(s)
except:
try:
n = float(s)
except:
print s + " is not a valid number."
return None
return n

Otherwise, while I am not using Python in a classroom, I certainly
agree with the summary below and support it.

Andr?

Post by dblank
Core Python maintainers,
Over on the Python edu-sig, we have been discussing a small aspect of PEP
3100 and its effects on teaching and classroom use. What is at issue is
input() and raw_input(), which have been targeted for removal, and marked
http://www.python.org/dev/peps/pep-3100/
Guido suggested in his 2002 "Python Regrets" talk that
eval(sys.stdin.readline()) and sys.stdin.readline() can be used for these,
respectively. That's not quite true of course, because they also have a
prompt. But even that aside, we believe that we would like to keep them
as-is.
I think that we have consensus among (the teachers of edu-sig) that many
of us rely on the ease-of-use of the input() and raw_input() functions for
one simple reason: input() and raw_input() can be used on day-1 of class,
before discussing imports, streams, strings, eval, or functions. Complete
replacement solutions require discussions of all of those topics.
We believe that their removal goes against the spirit of Python in the
classroom, and Python will be more complicated on the first day of class
because of it.
There were some suggestions that there could be better names for them,
including "ask()" and "askexp()". In any event, we'd rather have them the
way they are than not at all. Of course it is easy to add as a site.py
implementation, but those of us that teach would rather use 100% Pure
Python.
http://mail.python.org/pipermail/edu-sig/2006-September/006967.html
Thank you for considering leaving this as is,
The Teachers of Python edu-sig
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

John Zelle

2006-09-08 14:04:22 UTC

First up, I support the "petition"/ suggestion whatever you want to call it.

I'm somewhat disappointed that our discussion here seems to have gotten
derailed by Arthur's comments that it's all about ease of teaching. I think I
put forward a number or solid arguments about IO being core to programming
and the expressiveness of input/raw_input that no one has bothered to
address. Whether you want to teach import day 1 is only one small point in
the discussion as far as I'm concerned, and that seems to be the only point
that is picked up in certain circles.

Anyway, I also strongly support keeping the input statement, and I have to
respectfully disagree with the comments below.

Post by dblank
[Does this capture the essense of the discussion? I know some said that
they don't use them, and this would not stop them from not using them :)
-Doug]

Since I raised the issue in the first place, I'll just mention again
one additional point I raised which may have been overlooked. It is
generally recognized that input() == eval(raw_input()) is "not safe"
and therefore not a good example to give to beginners. Furthermore,
in the context of teaching, input() is, I believe, primarily used to
extract a number from a string. Thus, I would suggest that input
should be replaced by something like
s = raw_input(prompt)
n = int(s)
n = float(s)
print s + " is not a valid number."
return None
return n

There is _nothing_ untoward about allowing a beginner to use input as is.
Input is most easily conceptualized as "allowing a user to type an expression
at runtime" or as I like to call it a "delayed expression" (see earlier
post). It's very easy to grasp that in a program I can write x = 3 or x
= "foo" or x = [1,2,3]; if I want to replace the righthand side of that
statement with input at runtime, I just do that: x = input("Enter a value for
x: "). In other words, I am letting the user write the code. That's a simple
concept; saying it's dangerous is just making the statement that "programming
is dangerous". Of course it is! But that's exactly what we're giving our
students the power to do: be dangerous by programming.

This proposal strips input of much of its power. I use input to get all kinds
of data, not just numbers. It's a very expressive feature of Python, and it
happens also to be padagogically useful. Proposals that turn input into some
typed scanning statement ala Java (or C or C++ or Pascal) rob it of it's
dynamic nature and make it unpythonic in my book. Python is a dynamic
language, let's keep dynamic input.

I am more comfortable with Ian's proposal to only allow Python literals (not
expressions), but now you've made input more complicated by putting
restrictions on it. Why can't I enter exactly what I would put in the
assignment statement if I were writing the code? I often fire up Python, type
a little loop and use it to evaluate expressions as a calculator.

Perhaps I am tainted by my association with languages such as Lisp and Prolog
that are beautiful for experimentation because they allow the freedom to
intermingle programs and data. I would really miss input as a day-to-day user
of Python, not just as an educator. I will have to carry my custom IO module
with me and load it on every Python 3000 bearing computer I come across. What
a pathetic waste of my time that will be.

--Johnny Inputseed

ps. That's my last entry on this thread; I've got more pressing things to
worry about right now. See Arthur, I do understand it's not a life or death
issue :-).

Post by Andre Roberge
Otherwise, while I am not using Python in a classroom, I certainly
agree with the summary below and support it.
Andr?

Post by dblank
Core Python maintainers,
Over on the Python edu-sig, we have been discussing a small aspect of PEP
3100 and its effects on teaching and classroom use. What is at issue is
input() and raw_input(), which have been targeted for removal, and marked
http://www.python.org/dev/peps/pep-3100/
Guido suggested in his 2002 "Python Regrets" talk that
eval(sys.stdin.readline()) and sys.stdin.readline() can be used for
these, respectively. That's not quite true of course, because they also
have a prompt. But even that aside, we believe that we would like to keep
them as-is.
I think that we have consensus among (the teachers of edu-sig) that many
of us rely on the ease-of-use of the input() and raw_input() functions
for one simple reason: input() and raw_input() can be used on day-1 of
class, before discussing imports, streams, strings, eval, or functions.
Complete replacement solutions require discussions of all of those
topics.
We believe that their removal goes against the spirit of Python in the
classroom, and Python will be more complicated on the first day of class
because of it.
There were some suggestions that there could be better names for them,
including "ask()" and "askexp()". In any event, we'd rather have them the
way they are than not at all. Of course it is easy to add as a site.py
implementation, but those of us that teach would rather use 100% Pure
Python.
http://mail.python.org/pipermail/edu-sig/2006-September/006967.html
Thank you for considering leaving this as is,
The Teachers of Python 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

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Andre Roberge

2006-09-08 14:10:30 UTC

Post by John Zelle
First up, I support the "petition"/ suggestion whatever you want to call it.
I'm somewhat disappointed that our discussion here seems to have gotten
derailed by Arthur's comments that it's all about ease of teaching. I think I
put forward a number or solid arguments about IO being core to programming
and the expressiveness of input/raw_input that no one has bothered to
address. Whether you want to teach import day 1 is only one small point in
the discussion as far as I'm concerned, and that seems to be the only point
that is picked up in certain circles.
Anyway, I also strongly support keeping the input statement, and I have to
respectfully disagree with the comments below.

And I certainly defer to John's greater experience in teaching Python
- so I rally to and support the viewpoint expressed by John below.
Andr?

Post by dblank
[Does this capture the essense of the discussion? I know some said that
they don't use them, and this would not stop them from not using them :)
-Doug]

Since I raised the issue in the first place, I'll just mention again
one additional point I raised which may have been overlooked. It is
generally recognized that input() == eval(raw_input()) is "not safe"
and therefore not a good example to give to beginners. Furthermore,
in the context of teaching, input() is, I believe, primarily used to
extract a number from a string. Thus, I would suggest that input
should be replaced by something like
s = raw_input(prompt)
n = int(s)
n = float(s)
print s + " is not a valid number."
return None
return n

There is _nothing_ untoward about allowing a beginner to use input as is.
Input is most easily conceptualized as "allowing a user to type an expression
at runtime" or as I like to call it a "delayed expression" (see earlier
post). It's very easy to grasp that in a program I can write x = 3 or x
= "foo" or x = [1,2,3]; if I want to replace the righthand side of that
statement with input at runtime, I just do that: x = input("Enter a value for
x: "). In other words, I am letting the user write the code. That's a simple
concept; saying it's dangerous is just making the statement that "programming
is dangerous". Of course it is! But that's exactly what we're giving our
students the power to do: be dangerous by programming.
This proposal strips input of much of its power. I use input to get all kinds
of data, not just numbers. It's a very expressive feature of Python, and it
happens also to be padagogically useful. Proposals that turn input into some
typed scanning statement ala Java (or C or C++ or Pascal) rob it of it's
dynamic nature and make it unpythonic in my book. Python is a dynamic
language, let's keep dynamic input.
I am more comfortable with Ian's proposal to only allow Python literals (not
expressions), but now you've made input more complicated by putting
restrictions on it. Why can't I enter exactly what I would put in the
assignment statement if I were writing the code? I often fire up Python, type
a little loop and use it to evaluate expressions as a calculator.
Perhaps I am tainted by my association with languages such as Lisp and Prolog
that are beautiful for experimentation because they allow the freedom to
intermingle programs and data. I would really miss input as a day-to-day user
of Python, not just as an educator. I will have to carry my custom IO module
with me and load it on every Python 3000 bearing computer I come across. What
a pathetic waste of my time that will be.
--Johnny Inputseed
ps. That's my last entry on this thread; I've got more pressing things to
worry about right now. See Arthur, I do understand it's not a life or death
issue :-).

Post by Andre Roberge
Otherwise, while I am not using Python in a classroom, I certainly
agree with the summary below and support it.
Andr?

Post by dblank
Core Python maintainers,
Over on the Python edu-sig, we have been discussing a small aspect of PEP
3100 and its effects on teaching and classroom use. What is at issue is
input() and raw_input(), which have been targeted for removal, and marked
http://www.python.org/dev/peps/pep-3100/
Guido suggested in his 2002 "Python Regrets" talk that
eval(sys.stdin.readline()) and sys.stdin.readline() can be used for
these, respectively. That's not quite true of course, because they also
have a prompt. But even that aside, we believe that we would like to keep
them as-is.
I think that we have consensus among (the teachers of edu-sig) that many
of us rely on the ease-of-use of the input() and raw_input() functions
for one simple reason: input() and raw_input() can be used on day-1 of
class, before discussing imports, streams, strings, eval, or functions.
Complete replacement solutions require discussions of all of those
topics.
We believe that their removal goes against the spirit of Python in the
classroom, and Python will be more complicated on the first day of class
because of it.
There were some suggestions that there could be better names for them,
including "ask()" and "askexp()". In any event, we'd rather have them the
way they are than not at all. Of course it is easy to add as a site.py
implementation, but those of us that teach would rather use 100% Pure
Python.
http://mail.python.org/pipermail/edu-sig/2006-September/006967.html
Thank you for considering leaving this as is,
The Teachers of Python 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

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Arthur

2006-09-08 14:50:28 UTC

I think that we can credit us all with understanding the range of issues.

I said at the beginning that I have never used raw_input, its function
was not very clear to me, while sys.stdin.readline *is*. So my
disagreement seems to extend to the issue of expressiveness. But it also
extends to my view of the role of Python as an introductory language, as
glue, as promoting technical literacy. I prefer sys.stdin.readline as
the more generally literate alternative. Unless you are telling me that
stdin, stdout, stderr are themselves obsolete concepts.

I am also trying to say that I do not discount your point as a
reasonable, and as expressive of your own aesthetics. Nor do I discount
your role in the community as a serious and significant one - one that
has earned, on its merits a serious hearing, IMO.

I am - in my usual clumsy way perhaps - trying to position this issue
like so many other of these kinds of issues, as one on which
reasonable people can disagree. And encouraging you to pursue your
purpose with some better indication that you have this issue in some
reasonable perspective - win or lose.

Art

Ian Bicking

2006-09-08 01:51:46 UTC

Post by dblank
I think that we have consensus among (the teachers of edu-sig) that many
of us rely on the ease-of-use of the input() and raw_input() functions for
one simple reason: input() and raw_input() can be used on day-1 of class,
before discussing imports, streams, strings, eval, or functions. Complete
replacement solutions require discussions of all of those topics.

I meant to interject a suggestion somewhere, but was only half-tracking
the thread. I think a compromise for input() might be possible, that
only allows for Python literals, but not expressions. So you could
input ``1`` and get the number 1, or ``"1"`` and get the string "1", and
allow lists and all that. This actually is more featureful than just
eval(raw_input()), which is all input() does now.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

Toby Donaldson

2006-09-08 17:22:45 UTC

Removing input() FORCES people to have to address import, streams, dot notation,
functions, and strings.

How does using the input function avoid the use of functions? :-)

Keep in mind that most students have no problem *using* unexplained
features if there is a good reason to use them. For instance, most
don't freak out because we don't actually tell them how "print" or "+"
works.

The whole point of keeping input() is to give the teachers a choice to do
interesting things without introducing (in their mind) unnecessary topics
or syntax.

To be honest, even though input() doesn't really matter to me, I find
the arguments against it stronger than those for it. I think your
letter needs strong arguments for keeping input. I think two points
win the day:

- it does not appear to be used by as many teachers as raw_input
- it is trivial to simulate if you have raw_input

Personally, I have to address import fairly early for other reasons, and
have never really used input(). But I don't want to make John Zelle teach
the way that I do.

I think it is okay, however, for a language to make questionable
programming practices harder to use. It seems like a good way to
prevent errors for everyone who uses the language.

Java gives us no choice at all. Talk about "there's one way to do it." You
must deal with too much stuff to make the computer do something, anything.

Actually, Java has many ways to do most things ... for example,
reading input can be done with the Scanner class, or various other
combinations of IO classes.

If what you mean is that Java requires the use of a lot of syntax for
simple programs, then I agree. But in my experience in teaching Java,
I think that problem is vastly over-stated by most people who use that
argument. It is an annoyance of Java to be sure, but most students are
able to use things before they completely understand them.

Toby

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

Toby Donaldson

2006-09-08 17:54:01 UTC

Post by Toby Donaldson
What if instead of naming the package "teaching", it was called
something less offensive, like "simpleIO" or "userinput" or
"interactive" or "convenience"?

This is a plausible way to remove the 'teaching' label. I would prefer
'stdin'.

'stdin' is probably meaningless to beginners. I think beginners would
prefer clear, simple names that don't require experience with Unix or
Java. :-)

Post by Radenski, Atanas
Now imagine a beginner who is looking at her very first Python program.
from stdin import *

Yes, that would be awful. Don't do that. :-)

By using a better package name and a more explicit import you could
get something that reads better like

from userinput import raw_input

Or another approach would be to have a package named "user" or
"keyboard", so you could write things like

import keyboard

answer = keyboard.raw_input("Morbo demands an answer: ")

Another possibility, is to follow Java's Scanner class:

import java.util.Scanner;
...
Scanner sc = new Scanner(System.in);
System.out.printf("Enter the circle's radius: ");
double radius = sc.nextDouble();

A Python version could put the scanner in the main namespace, and
allow code like this:

print "Enter the circle's radius: "
radius = scanner.next_double()
print "Enter the circle's name: "
name = scanner.next_line()

I would prefer a name other than "scanner", but this gives the main
idea. This approach has a couple of nice features:

- the code is explicit and easy to read --- you can tell just by
looking where a double is wanted and where a string is wanted
- meaningful, custom error messages can be supplied, i.e. if the
next input is not a valid double, then next_double can say it expected
a double but found none, next_int could say it expected an int, etc.;

input("Enter radius: ")

Enter radius: 4
4

input("Enter radius: ")

Enter radius: four
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<string>", line 0, in ?
NameError: name 'four' is not defined

input("Enter radius: ")

Enter radius: for
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<string>", line 1
for
^
SyntaxError: unexpected EOF while parsing

Post by Radenski, Atanas
This person and her instructor will have to deal with modules and import
FIRST, although the student is not likely to develop multi-modular
programs at the very beginning.

In the Python course I teach, students need to import .py files they
write into the interpreter (for testing), so they very soon need to
write statements like

from lab2 import *
import turtle

It is not hard to explain this in a way so that beginners can
understand it well enough to use it. More details and subtleties of
modules and imports come later, as needed.

Post by Radenski, Atanas
I wonder how is the instructor going to tell her what is the meaning of
'from stdin import *'? I guess, in the same way instructors tell what
'public static void main (...) is'. In this way we are going to the Java
nonsense (nonsense from the perspective of teaching beginners, of
course, otherwise Java is a wonderful language).

Its kind of like the nonsense explanations you see for the Python
"print" statement and "+" operator. :-)

Teaching is filled with IOUs. We often use things before we completely
understand them.

Toby

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

kirby urner

2006-09-08 20:04:02 UTC

Post by Toby Donaldson
Teaching is filled with IOUs. We often use things before we completely
understand them.
Toby

I would like a deeper discussion of why we still need to prompt
ourselves for input.

I think the model today is "a person writing code for him or herself"
i.e. "self as client" -- at least in an early context. We're not
guiding the unknowing through a menu tree. We're computer literate,
fluent.

Why would we ask ourselves for raw_input, when it's much easier to
just pass arguments to functions?

If you're *really* coding for a complete newbie, then learn GUI
programming, meet them where they want to be met. Otherwise, just
import and use a namespace, like a real grownup. All this "ask myself
for degrees centigrade" stuff is just too 1970s, too BASIC (yech!).

Hey, I'd think about putting self-prompting I/O in a more obscure
context, like copy (also out of reach as a built-in), maybe making it
part of sys or something. :-D

Look how C# handles I/O. That's a good example I think.
System.console -- would that have been better? No one asked me, I
offered no opinion. End of story then. The work is done.

Python3000 shouldn't be derailed by politicians, some of whom would,
in their heart of hearts, like Python to fail (just as many USA
congressman actually *hate* what the USA is exposing about them).

As soon as I thought "C#" I felt better. CPython -> C -> C# ->
IronPython looks like a dynamite CS sequence.

I'm looking forward to seeing which schools have guts enough to try it.

Kirby

Dan Crosta

2006-09-08 20:30:41 UTC

Post by kirby urner
I would like a deeper discussion of why we still need to prompt
ourselves for input.
I think the model today is "a person writing code for him or herself"
i.e. "self as client" -- at least in an early context. We're not
guiding the unknowing through a menu tree. We're computer literate,
fluent.
Why would we ask ourselves for raw_input, when it's much easier to
just pass arguments to functions?

When I think back to when I was learning to program in 9th grade (I'm
not a professional software devel) I know that it was really exciting to
be able to twiddle with the computer for a bit, then call my mom over
and have her work with my program -- simple guessing games, then
eventually moving on to more sophisitcated things like memory, card
games, etc. At the time I was learning QBasic, so console-oriented input
was what you had.

Granted QBasic had no notion of an interactive console -- or rather it
did, but that was not a predominant way of interacting with it. But even
though it did, it would not have been as exciting to sit my mom down
with it and let her play around, and I wouldn't want to have to explain
to her (even now with a nearly infinitely more sophisticated
understanding of computers and programming than I did in my first
months) what a function is, how to interact with it, what arguments are,
etc.

It may not be how you like to teach computer programming or interacting
with computers, but I think there's a very important case to be made for
"other as client" at the very beginning, as a way of keeping it
interesting, when someone else is going to see it.

Post by kirby urner
If you're *really* coding for a complete newbie, then learn GUI
programming, meet them where they want to be met. Otherwise, just
import and use a namespace, like a real grownup. All this "ask myself
for degrees centigrade" stuff is just too 1970s, too BASIC (yech!).

I don't think programming with, eg, raw_input() is programming for a
newbie, but it is programming *at the level of a newbie* for someone
else who may or may not be -- in my mom's case, sure, if I had made a
GUI that might have been easier for her. but the goal was not to make a
program for her, the goal was to make a program, and having someone else
who could use it was a really powerful motivator that got me to explore
ways to extend it beyond the beginning code that was assigned by my teacher.

- d

kirby urner

2006-09-08 21:15:14 UTC

Post by Dan Crosta
It may not be how you like to teach computer programming or interacting
with computers, but I think there's a very important case to be made for
"other as client" at the very beginning, as a way of keeping it
interesting, when someone else is going to see it.

This is a good example, of showing off new skills to one's mother.
But maybe CP4E is about having one's mother learn to program, in which
case maybe the first thing you say is "mom, when you import, you bring
in a namespace, which is like stuff you might interact with, like go

from zoo import Monkey

and then go

mymonkey = Monkey("Curious George")

To me, this sounds like you're really educating your mother, not
making it be about you and your new skills, but about cluing her in,
letting her be a part of your world of Python namespaces, where
knowing about import is absolutely key.

You're not making a monkey out of your mom, by making her loop through
some little menu, oblivious of the language underneath, its logic and
design. You're "protecting you mother" (aka paradigm end user) from
knowing *anything* about Python. That's your goal, that's the whole
point (i.e. end user = not a programmer).

I'm saying CP4E is here to change all that. Your mom knows how to
program, learned how to when she was your age. She's been writing
little programs for her kids for decades, plus others for the
microwave, light dimmers, heater, plant waterer, and car. Not because
she's friggin genius or anything, but because this is 2006, and moms
have skills, aren't like in the 1950s (nothing wrong with the 1950s,
but nothing improving in 56 years would be laughably stupid).

Post by Dan Crosta

You should just write for yourself at first, and find that satisfying.
You shouldn't need this hypothetical guinea pig other. OK, maybe a
few times (and mom is proud).

Start thinking like a professional really early. Code for the back
office if it's back office (don't need no bells and whistles).

Don't waste your life polishing API skills no job market will ever
need (i.e. some raw_input based dialog, menu tree, looks like a 1960s
mainframe). Or rather, don't *start* with that.

Even most moms these days know that unless junior learns GUI
programming, there's nothing much here, as far as "code for end user"
skills. She's secretly unimpressed, but doesn't show it.

Kirby

kirby urner

2006-09-08 21:27:41 UTC

Post by kirby urner
You're not making a monkey out of your mom, by making her loop through
some little menu, oblivious of the language underneath, its logic and
design. You're "protecting you mother" (aka paradigm end user) from
knowing *anything* about Python. That's your goal, that's the whole
point (i.e. end user = not a programmer).

Just to clarify: I think it *is* condescending to newbies to force
them through a lot of raw_input scripts, since this is:

(a) not state of the art from and end user's point of view nor is it (not GUI)

(b) not state of the art "coding for self" idiom (which'd be more
shell interactive)

As teachers, we shouldn't be propagating the hidden assumptions that
go with raw_input, i.e. that there's this class if people out there
"too dumb" to know anything about namespaces or functions.

I'm saying this'll all be common knowledge soon.

We'll know about 'strings' just as surely as we know about 'numbers'.

Why? Because "computer literacy" is not just for some tiny inner
circle. It's just basic fluency. Like my friend Gene Fowler puts it
(paraphrasing): any poet worth his or her salt should know about XML
already. http://controlroom.blogspot.com/2006/08/more-cast.html

Kirby

Brad Miller

2006-09-09 12:31:59 UTC

Just to clarify: I think it *is* condescending to newbies to force
(a) not state of the art from and end user's point of view nor is it (not GUI)
(b) not state of the art "coding for self" idiom (which'd be more
shell interactive)
As teachers, we shouldn't be propagating the hidden assumptions that
go with raw_input, i.e. that there's this class if people out there
"too dumb" to know anything about namespaces or functions.
I'm saying this'll all be common knowledge soon.
We'll know about 'strings' just as surely as we know about 'numbers'.
Why? Because "computer literacy" is not just for some tiny inner
circle. It's just basic fluency. Like my friend Gene Fowler puts it
(paraphrasing): any poet worth his or her salt should know about XML
already. http://controlroom.blogspot.com/2006/08/more-cast.html

I doubt many people on this list would claim that computer literacy
is just for some inner circle. But its clear to me that we are not
in the same world.

In my world I get first year college students that want to major in
computer science that have zero experience with programming. We get
good bright young students from small towns and small schools. They
don't have Saturday Academy. They don't even have computer classes
to take in their high schools. If they do, computer class is about
how to use Word and Excel. Unfortunately, In this world having
strings and xml and modules be common knowledge isn't going to happen
anytime soon.

Brad

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

Bradley Miller
Assistant Professor Computer Science
Luther College
Decorah, IA 52101
http://www.cs.luther.edu/~bmiller

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060909/e790c33c/attachment.htm

kirby urner

2006-09-09 17:06:52 UTC

In my world I get first year college students that want to major in computer
science that have zero experience with programming. We get good bright
young students from small towns and small schools. They don't have Saturday
Academy. They don't even have computer classes to take in their high
schools. If they do, computer class is about how to use Word and Excel.
Unfortunately, In this world having strings and xml and modules be common
knowledge isn't going to happen anytime soon.
Brad

RIght, in your model, we will have another generation or two of
wallowing, before high schools in rural areas either disband (why keep
'em if they're so crummy) or get with it. It'll be easy for college
professors to assume a "know nothing" clientelle and get away with
that.

However, my model of South Africa is different. We have Kusasa, with
curriculum maps, high level screencasting and mathcasting, some of the
content made right here in Portland. We get to the rural areas, with
jeep-loads of DVDs (if the cell net isn't working). NGOs are working
alongside us. Every kid will know OO by age 18, know Python.

Of course that's just a model (mine), not the reality. But that's the
direction we're moving in. But in the USA it's: we're this backward
ignorant country and are likely to stay this way for at least another
generation. My school's answer: fight me then, because we're about
changing all that here too (but if not, then at least South Africa
isn't a lost cause).

Kirby

John Zelle

2006-09-09 15:18:40 UTC

Just to clarify: I think it *is* condescending to newbies to force
(a) not state of the art from and end user's point of view nor is it (not GUI)

This is like saying that Physics students have to start with General
Relativity and Quantum Mechanics, because those are state of the art. No one
is denying that it's good to teach GUI programming at some point. Is that the
simplest way to introduce programming? My learning philosophy is to always
search out the simplest thing that illustrates the principles I want my
students to learn at the moment. Anything more complex is just adding noise
and complicating the learning process.

Post by kirby urner
(b) not state of the art "coding for self" idiom (which'd be more
shell interactive)

While I accept the power of twiddling in the shell particularly as an
educational tool (again, I come from a Lisp/Prolog tradition), this statement
is just silly. How can you define "state of the art" for any "self" but your
own. When I write a script to automate some routine task, I virtually always
use interactive text input. Why? Because the whole point is to make something
routine and automatic. Why would I write a program that forces me to:
Start Python
Import a module
Recall what I'm suppose to invoke and what information it needs.

Instead I can write an incredibly simply script that I just click on, and when
it needs information it prompts me for it. That's _my_ state of the art in
programming for myself. And it's something I can teach students to do for
themselves in very short order.

Whether I'm writing for myself or whether I want my students to be able to
write the simplest possible useful programs for themselves and others, that
involves textual input. I'll say it one more time: IO is fundamental to
programming; the simplest universal form of IO deserves to be in the core
language so that it is easily accessible and available everywhere the
language runs. Pascal got that right and Python (pre 3000) has it right.

Post by kirby urner
As teachers, we shouldn't be propagating the hidden assumptions that
go with raw_input, i.e. that there's this class if people out there
"too dumb" to know anything about namespaces or functions.

Translate this to any other discipline. Running with my physics example: "As
teachers, we shouldn't be propogating the hidden assumptions that go with
Newtonian mechanics, i.e. that there's this class of people out there 'too
dumb' to know anything about quantum physics or general relativity." Does
that really make sense? The fact that there is more advanced stuff that they
will surely learn in due course is in no way a justification for not teaching
simpler, useful concepts first.

Post by kirby urner
I'm saying this'll all be common knowledge soon.

Define "soon." I see the same demographic as Brad Miller. My students are
freshman in college who have never programmed. And frankly, I'm OK with that.

Post by kirby urner
We'll know about 'strings' just as surely as we know about 'numbers'.
Why? Because "computer literacy" is not just for some tiny inner
circle. It's just basic fluency. Like my friend Gene Fowler puts it
(paraphrasing): any poet worth his or her salt should know about XML
already. http://controlroom.blogspot.com/2006/08/more-cast.html

None of the poets I know care a twiddle about XML. I guess we just move in
different circles.

--John

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

kirby urner

2006-09-09 17:35:50 UTC

Post by John Zelle
This is like saying that Physics students have to start with General
Relativity and Quantum Mechanics, because those are state of the art. No one
is denying that it's good to teach GUI programming at some point. Is that the
simplest way to introduce programming? My learning philosophy is to always
search out the simplest thing that illustrates the principles I want my
students to learn at the moment. Anything more complex is just adding noise
and complicating the learning process.

I believe in "cave paintings" which means grossly simplified demos
that nevertheless give a sense of what's involved in the production
setting.

So a little show and tell around GUI programming in the intro session
is in order. Not saying they'll be tested. Just the teacher clicking
around, writing a quick "Hello World" box, filling in some blanks or
whathaveyou -- the kind of thing MSFT would showcase when advertising
Visual Studio to CEOs who'll probably never touch the stuff (CTO's
problem).

But mostly I'm advocating going to the other extreme: drop GUI as a
topic and just code up a namespace, reach into the grab bag for
functions, like f(x) or cos(x). We pretend kids don't have the
background, but if they did *any* work with a TI calculator or an
algebra course, they know about functions, at least tacitly.

My prerequisite for my Saturday Academy class is algebra only, and
typing above 30 a minute really helps (a lot of 'em are getting that
from chat rooms these days, buy a typing drill for home).

Post by John Zelle
While I accept the power of twiddling in the shell particularly as an
educational tool (again, I come from a Lisp/Prolog tradition), this statement
is just silly. How can you define "state of the art" for any "self" but your
own. When I write a script to automate some routine task, I virtually always

I can define it for my gnu math teachers, the people I work with in
South Africa for example.

Post by John Zelle
use interactive text input. Why? Because the whole point is to make something
Start Python
Import a module
Recall what I'm suppose to invoke and what information it needs.

Sounds like your "program" is one of these top-to-bottom
glued-together script thingys. We don't teach that way. Modules are
grab bags, perhaps containing rich data structures (lat/long
dictionary say). Modules define namespaces, like boxes of chocolates
(Forest Gump understands).

This need to glue it all together with some main() -- why? We compete
with that idea of "programming." We're not a part of *that*
particular conspiracy.

Last week, we were working on phi and the fibonaccis. Let's get back
to that now. Pull out a file drawer (import) and behold: all our
favorite specimens (even the bugs are back).

Post by John Zelle
Instead I can write an incredibly simply script that I just click on, and when
it needs information it prompts me for it. That's _my_ state of the art in
programming for myself. And it's something I can teach students to do for
themselves in very short order.

Yeah, we don't like that style. OK for you, works for your students,
I think you're probably a dynamite teacher. But... we still don't
like that style.

Later on maybe, if/when they're committed to CS. But this is just
basic numeracy here, and they already know about functions from
calculators.

import math
math.cos( 90 * math.degrees)

-- that's what a first class might include. If what stops 'em isn't
the Python syntax, but the trig, then we go over the trig. Basic
numeracy. All as a bundle. Not your grandfathers math class (but
some hoped it'd be for their kids -- remember when the future was,
well, futuristic?).

Post by John Zelle
Whether I'm writing for myself or whether I want my students to be able to
write the simplest possible useful programs for themselves and others, that
involves textual input. I'll say it one more time: IO is fundamental to
programming; the simplest universal form of IO deserves to be in the core
language so that it is easily accessible and available everywhere the
language runs. Pascal got that right and Python (pre 3000) has it right.

And I'm saying using the shell to trigger namespace events is (a)
closer to what a GUI is doing and (b) is fully usable I/O. Use doc
strings to remind about inputs. raw_input prompts are the new goto
(to be avoided if possible).

Right, but I see that as a self-serving analogy. You're *defending*
the status quo. Notice how CP4E goes for like "riding a bicycle" and
"driving a car". Anyone can do it, no big deal.

I think CS has a reflex to fight "debasement" of programming into a
"what your grandmother knows" skill. But that's what I *want* to have
happen, and expect grandmothers *will* have those skills in the not
too distant future.

Latin moms in Rio will tell The Monkey to block those Evil Toons
(point and click yes, but they custom-skinned the GUI, know how it
works from hours study. What, working class folk with the free time to
study what they used have to pay for, plus hold down a job? What a
concept!

Post by John Zelle
that really make sense? The fact that there is more advanced stuff that they
will surely learn in due course is in no way a justification for not teaching
simpler, useful concepts first.

Nothing much simpler than import math, using the names. Raw_input is
difficult by contrast.

Why don't calculators have raw_input? They can't do I/O? How about
dashboards? Cockpit of an airplane.

We use control surfaces all day long. That's what a namespace is, an
API. You don't need to tie it all together with some main(). This
isn't a script. It's a place to do work. Namespaces are like
studios. Event driven. More GUI, less "programming" (in the 1960s
sense).

Post by kirby urner
I'm saying this'll all be common knowledge soon.

Define "soon." I see the same demographic as Brad Miller. My students are
freshman in college who have never programmed. And frankly, I'm OK with that.

And frankly, I'm not. High school too wasteful. If it's really about
sports, which is OK with me, lets do more sports camps. But for kids
who want academic rigor (another kind of sport), it's just not OK to
not even *offer* OO by the end of high school.

If USA voters want to keep that status quo, fine, but don't think the
rest of the world will think twice about thrashing us in the job
market if so. Or were we planning to use the Pentagon to keep the
rest of the world stone aged, while we went on being mental couch
potatoes. If so, think again.

Praise the Lord we have television. If the schools have decided to
rust in irrelevance, letting it be OK that globalization passes us by,
then we can do what we did in Sesame Street, except at a much higher
level (still using puppets though -- some of them CGI).

Our Snake with __rib__ syntax makes fun cartoons on TV. It slithers
around like Kaa, eating stuff (eat method). Hah hah, the 3rd graders
laugh. Gnu math is just better.

None of the poets I know care a twiddle about XML. I guess we just move in
different circles.
--John

Guess we do. But that's how it is with poets (few and far between).

Kirby

Arthur

2006-09-09 19:30:26 UTC

Post by kirby urner
import math
math.cos( 90 * math.degrees)
-- that's what a first class might include. If what stops 'em isn't
the Python syntax, but the trig, then we go over the trig. Basic
numeracy. All as a bundle. Not your grandfathers math class (but
some hoped it'd be for their kids -- remember when the future was,
well, futuristic?).

How you manage to tangle your sensible and salable ideas into a
rhetorical jumble that makes them sound a lot more dazed, dazzling,
and unsaleable they then are on their merits - confounds me.

I am convinced that the problem is that you have engaged the wrong
enemy. It is not the school board of Hodunk, Missouri..Talked to with
respect for your joint mission of the welfare of their charges, and your
sensible ideas presented without your form of Princetonian arrogance -
I see a team.

Your problem is the radical constructivists. You believe in *typing*,
you talk about *mathematical ideas* - trigonometry, even - rather than
"analytical skills", which of course means everything and nothing at the
same time.

They are better funded. You cannot afford your arrogance if you are at
all serious about competing. But then I don't believe you are actually
trying to win. Would take a kind of discipline that you exhibit does
not interest you.

Just getting your rocks off?

Art

Arthur

2006-09-09 20:06:23 UTC

I am convinced that the problem is that you have engaged the wrong
enemy.

Another way to put it is that I see you as a victim.

The substance of "your" ideas, I think you know at some level, are
almost apparent to many of us who are literate in ways similar to the
ways that you are literate - and whether or not we happen to be mentored
by Buckminster Fuller.

Computers come into to play - everyone is ready for that. Your
grandmother, my great uncle, everyone's Aunt Tillie. Big deal.

Stripped of the rhetorical flourishes, what is being suggested is a
sensible, logical next step - no radical departure from existing
practices and standards.

Marginal and necessary improvement to what now exists.

What others are offering is what America *really* loves. A Potion. The
quick fix. The eat 'til it hurts diet plan.

And that is why you fear being bypassed, left in the dust. And why you
think you need the costuming.

We are, of course, all heros.

I go mano vs. mano with the Big Boys at MIT ;)

You seem to be up against one nut you found on a math list somewhere.
That don't pass as visionary credentials, in my book.

Art

kirby urner

2006-09-09 20:56:25 UTC

Post by Arthur
I go mano vs. mano with the Big Boys at MIT ;)

Sounds awfully sumo. Hope yer doin' some good eatin'!

Post by Arthur
You seem to be up against one nut you found on a math list somewhere.
That don't pass as visionary credentials, in my book.
Art

I don't know what this is about, but I know we often differ in our
assessments. Given your track record, I'm feeling pretty upbeat about
all you just said.

Thanks for the morale booster.

Kirby

kirby urner

2006-09-09 20:52:22 UTC

How you manage to tangle your sensible and salable ideas into a
rhetorical jumble that makes them sound a lot more dazed, dazzling,
and unsaleable they then are on their merits - confounds me.

What's so unsensible about using Python as a calculator in math class
for starters? That's how Guido's tutorial begins. You don't do

Post by Arthur
I am convinced that the problem is that you have engaged the wrong
enemy. It is not the school board of Hodunk, Missouri..Talked to with
respect for your joint mission of the welfare of their charges, and your
sensible ideas presented without your form of Princetonian arrogance -
I see a team.

I never mentioned fighting a school board in Missouri, now did I.
Trying to pull the wool, hey?

Post by Arthur
Your problem is the radical constructivists. You believe in *typing*,
you talk about *mathematical ideas* - trigonometry, even - rather than
"analytical skills", which of course means everything and nothing at the
same time.

I'm willing to compete in this rarified rhetorical way, sure, but more
I'm just into making raw_input seem ridiculous and unsophisticated.
Combat that however you may. Maybe Ruby has raw_input?

Post by Arthur
They are better funded. You cannot afford your arrogance if you are at
all serious about competing. But then I don't believe you are actually
trying to win. Would take a kind of discipline that you exhibit does
not interest you.
Just getting your rocks off?
Art

You presume I'm fighting some school board, whereas in Portland we're
just seeing more and more ways to get our open source capital on the
map, *and* to save a bundle, by going with free software (not taking
credit for all this momentum by the way -- maybe why you think I'm
arrogant is because you live on the other coast, the more backward
one. :-D).

Kirby

Arthur

2006-09-09 21:04:14 UTC

How you manage to tangle your sensible and salable ideas into a
rhetorical jumble that makes them sound a lot more dazed, dazzling,
and unsaleable they then are on their merits - confounds me.

What's so unsensible about using Python as a calculator in math class
for starters? That's how Guido's tutorial begins.

I'm quoting the sensible part.

And the part that does not belong to you, and which you are relentlessly
trying to trademark.

Funny how Bucky has been accused of the same thing.

The surrounding grandiose rhetoric is the nonsense..

Art

kirby urner

2006-09-09 21:40:38 UTC

Post by Arthur
I'm quoting the sensible part.
And the part that does not belong to you, and which you are relentlessly
trying to trademark.

Hmmm, trademark, now *there's* an idea. Python as a Calulator [tm].

But seriously, when you have a lot of Objects (like Monkeys and Dogs)
and want to puppet them, by triggering methods ( mydog.bark() ), you
don't want to drill down through some menus.

You say I'm just pushing what'll happen by natural evolution if I just
abandoned my to-your-ears arrogant tone. Just let the invisible hand
do the job, so no one gets all the credit.

I don't want all the credit, but I will claim a lion's share in some
corners, in some niche markets where I really excel and deserve high
ranking. But yes, we'll let the students decide. It's vote with your
feet time. CP4E or something both dumber *and* more elitist (not a
winning combo in my book).

Post by Arthur
Funny how Bucky has been accused of the same thing.

Yeah, by the same cast of wannabees.

Post by Arthur
The surrounding grandiose rhetoric is the nonsense..
Art

Is that how you lick 'em over at MIT?

I'll be quiet down now. We might lose that signal-to-noise ratio of
Perfect Phi, that I try to maintain.

I think I've made all the points I need to make re raw_input. End of
thread, as far as me needing a soap box.

I thank the Crunchy Frog for introducing us to that whole terrain.
Very fertile. I learned plenty.

Kirby

Arthur

2006-09-09 21:48:29 UTC

Post by kirby urner
You say I'm just pushing what'll happen by natural evolution if I just
abandoned my to-your-ears arrogant tone. Just let the invisible hand
do the job, so no one gets all the credit.

No.

I think I am saying that unless folks like you and I find some way to
work together where we substantively agree - we will lose to the Big
Boys at MIT.

Which is no big deal ...except that the last nail is in the coffin of
the American educational system. Evolutionary, in itself, and who
knows, maybe for the best.

But for someone trying to maintain some hope it might end up otherwise,
it does seem a pity I am not shaped like a regular tetrahedron, or
willing to do battle under the CP4E flag, Kirby interpretation.

Close, but no cigar.

Art

Post by kirby urner
I don't want all the credit, but I will claim a lion's share in some
corners, in some niche markets where I really excel and deserve high
ranking. But yes, we'll let the students decide. It's vote with your
feet time. CP4E or something both dumber *and* more elitist (not a
winning combo in my book).

Post by Arthur
Funny how Bucky has been accused of the same thing.

Yeah, by the same cast of wannabees.

Post by Arthur
The surrounding grandiose rhetoric is the nonsense..
Art

Is that how you lick 'em over at MIT?
I'll be quiet down now. We might lose that signal-to-noise ratio of
Perfect Phi, that I try to maintain.
I think I've made all the points I need to make re raw_input. End of
thread, as far as me needing a soap box.
I thank the Crunchy Frog for introducing us to that whole terrain.
Very fertile. I learned plenty.
Kirby

kirby urner

2006-09-09 23:57:31 UTC

Post by Arthur
But for someone trying to maintain some hope it might end up otherwise,
it does seem a pity I am not shaped like a regular tetrahedron, or
willing to do battle under the CP4E flag, Kirby interpretation.
Close, but no cigar.
Art

We don't want to be lock step, that's just scare everybody. Better
that Kirby and Arthur stay at loggerheads (about what is sometimes
unclear).

My model is I come to Python from my Fuller School (with all those
tetrahedrons you don't need to care about) and shop for stuff I can
use. I go home with a car load, very happy with my purchases, and
ready to fly a CP4E banner over my Castle Keep (octahedrons also).

My knights (mostly female) fan out across the land, recruiting. They
flash a Python insignia now and then, but other logos too. Red Bull.
Maybe Pixar?

You, Arthur of Pygeo, go shopping too, and like what you've found.
VPython is getting stronger (doesn't wipe out the old IDLE any more
does it?), Pygeo is getting stronger, and you feel emboldened to take
on the Big Boys of various description, @ MIT of wherever.

Sounds familiar, i.e. we over in our castle recognize that you feel
boosted, like you got a shot in the arm from our Shared Snake. Good
for you, good for us.

Now, turns out you maybe don't want to fly the CP4E banner, or
champion tetrahedra the way I do, how should that matter? Even if you
fly CP4E, you don't want that confused with Buckydom's Castle. Hey,
people are smart, know brand X from brand Y (all that market research
is good for *something* anyway).

People know Sears isn't Wal*Mart, Ford isn't Chevy. Yes, with the oil
companies it's harder to tell. They all look alike somehow -- but I'm
sure they see differences in Texas, where they care.

The Fuller School is like this game engine, but now with Python
bindings (4D/4D++).

Wanna play with the buckaneers? Visit Kirby why not, or check in with
SNEC. Wanna play against MIT, maybe team with Klein well then, Arthur
of Pygeo is likely your man.

For hexapents, I recommend Adrian of Packinon.

There're any number of schools that might find Python fortifying, a
positive ingredient.

I'm not upset if you're not on board with the Bucky stuff. That's not
how you choose to paint your castle. No one said you had to. You've
got other fish to fry.

Quite frankly, I expect to recruit *very few* buckaneers to my school
by saying such horrifying things as I dare say to those here
assembled. I am *not* preaching to some choir on edu-sig, quite
obviously.

Brad is grossed out and disgusted, others think I'm just being
ridiculous. That's all just fine fine, just peachy. I'm not running
for political office or win any popularity contest. I'm just being
direct about what I see as a positive direction. I want at least to
be clear -- much better than diplomatic, at the cost of unclear.

Back in my castle, Igor and I are putting the finishing touches on our
Monster Curriculum (the way our detractors paint us).

Post by Arthur
From my perspective, our Silicon Forest needs a dynamite curriculum

with teeth, so our kids have a decent shot at the promising lifestyles
our economy offers, and/or may offer down the road.

Your economy is different? Why should that be a problem?

And if the USG chooses to syndicate some of our ideas through the
public school system, why should that be any more evil than how TI
*already* permeates the culture, likewise through public schools?

Better Oregon than Texas.

Another slogan: YOU be the glue.

(refers to how we see you at the shell prompt -- it's *your* job to
keep it together, not some "script").

Kirby

Arthur

2006-09-10 01:11:28 UTC

Post by kirby urner
Quite frankly, I expect to recruit *very few* buckaneers to my school
by saying such horrifying things as I dare say to those here
assembled. I am *not* preaching to some choir on edu-sig, quite
obviously.

Yuo can choose to be horrifying.

I do, at times, as we all know.

Post by kirby urner
import math
math.cos( 90 * math.degrees)

It doesn't belong to you, it doesn't belong to Fuller, it ain't "gnu
math" because there ain't no such thing. Except to you and six guys in
some Mecca called Portland.

You choose to remain at the margins, and martyred as being at being
marginalized. It's a game that ain't so funny any more.

You are in the process helping marginalize some very sound ideas - not
just of your own, that is your business and your psyche - but of others.

This is an announcement.

Post by kirby urner
import math
math.cos( 90 * math.degrees)

has less than nothing to do with Kirby Urner. He couldn't make it
happen if his life depended upon it.

Art

Post by kirby urner
Brad is grossed out and disgusted, others think I'm just being
ridiculous. That's all just fine fine, just peachy. I'm not running
for political office or win any popularity contest. I'm just being
direct about what I see as a positive direction. I want at least to
be clear -- much better than diplomatic, at the cost of unclear.
Back in my castle, Igor and I are putting the finishing touches on our
Monster Curriculum (the way our detractors paint us).

Post by Arthur
From my perspective, our Silicon Forest needs a dynamite curriculum

with teeth, so our kids have a decent shot at the promising lifestyles
our economy offers, and/or may offer down the road.
Your economy is different? Why should that be a problem?
And if the USG chooses to syndicate some of our ideas through the
public school system, why should that be any more evil than how TI
*already* permeates the culture, likewise through public schools?
Better Oregon than Texas.
Another slogan: YOU be the glue.
(refers to how we see you at the shell prompt -- it's *your* job to
keep it together, not some "script").
Kirby

kirby urner

2006-09-10 01:25:56 UTC

Post by kirby urner
import math
math.cos( 90 * math.degrees)

It doesn't belong to you, it doesn't belong to Fuller, it ain't "gnu
math" because there ain't no such thing. Except to you and six guys in
some Mecca called Portland.

Did you understand the discussion? I shouldn't presume.

I was explaining how I don't like "scripting" as a first exposure to
programming.

I like "stars in the sky" where you build up a namespace of stuff
depending on other stuff.

Or just use a ready-made, like math or string.

import myhousehold
myDog = Dog("Sarah Angel")
import animalcontrol
animalcontrol.register(myDog)

OK, done

Better? I used my own dog instead of cosine, and now it's OK?

I don't understand this "doesn't belong" thing.

I have access to the metaphysical heritage of all humanity. I think
the trig people *wanted* our Mecca to have a bright future (OK, so
they didn't know about Portland -- but I don't see the copy protection
or EULA I'm supposed to sign or kowtow to before I deploy it as a part
of my infrastructure).

Post by Arthur
You choose to remain at the margins, and martyred as being at being
marginalized. It's a game that ain't so funny any more.

What marginalized. I feel we're slaughtering the competition, but
they're mostly too big and lumbering to notice. But some see what
we're up to, and even enjoy the experience of finding out they're
dinos in our eyes (how cute!).

Post by Arthur
You are in the process helping marginalize some very sound ideas - not
just of your own, that is your business and your psyche - but of others.

Oh, like I'm not entitled to use cosine all of a sudden? Where do you
get off bossing me like that? Remind me to use as much trig as I
want, any time I want, especially when you're watching.

Because yes, doing convergent sequences is Big Time in my curriculum.
What do we converge to? Values of sine and cosine. Do we credit
Euler? You betcha. Synergetics is all about Euler and Gibbs, Euler
and Gibbs. Some people cup their ears, because they *can't stand* to
see genius credit genius, instead of themselves (don't worry, I'm
nowhere in Published Synergetics, know to look to my betters (not you
though)).

Post by Arthur
This is an announcement.

Post by kirby urner
import math
math.cos( 90 * math.degrees)

has less than nothing to do with Kirby Urner. He couldn't make it
happen if his life depended upon it.
Art

Duh?

Nothing to do with Arthur Siegel either, whoever that is.

Kirby

kirby urner

2006-09-10 01:38:11 UTC

import myhousehold
myDog = Dog("Sarah Angel")

Sorry:

myDog = myhousehold.Dog("Sarah Angel")

we might imagine a SOAP service, plus myDog automatically aquires all
kinds of tags, thanks to an SQL lookup inside her parent Multnomah
County Licensed Pet class.

<commercial logo="4D Studios">

The way we teach

in the Silicon Forest.

<slogan method="flash">

Gnu Math is just better

</slogan>

</commercial>

Kirby
4D Studios

John Zelle

2006-09-09 19:52:25 UTC

On Saturday 09 September 2006 12:35 pm, you wrote:
<snip>

Post by kirby urner
But mostly I'm advocating going to the other extreme: drop GUI as a
topic and just code up a namespace, reach into the grab bag for
functions, like f(x) or cos(x). We pretend kids don't have the
background, but if they did *any* work with a TI calculator or an
algebra course, they know about functions, at least tacitly.
My prerequisite for my Saturday Academy class is algebra only, and
typing above 30 a minute really helps (a lot of 'em are getting that
from chat rooms these days, buy a typing drill for home).

As I said below, I'm all for this kind of interaction, and when input and
raw_input go away, I'll probably do more of it.

Post by John Zelle
While I accept the power of twiddling in the shell particularly as an
educational tool (again, I come from a Lisp/Prolog tradition), this
statement is just silly. How can you define "state of the art" for any
"self" but your own. When I write a script to automate some routine task,
I virtually always

I can define it for my gnu math teachers, the people I work with in
South Africa for example.

This, of course, misses my whole point that you can't define "state of the
art" in "programming for self" for others (me, for example).

Post by John Zelle
use interactive text input. Why? Because the whole point is to make
something routine and automatic. Why would I write a program that forces
me to: Start Python
Import a module
Recall what I'm suppose to invoke and what information it needs.

First up, I was not talking about the way I teach, but the way I program to
automate my environment. To use your terms: defining state of the art in
programming for myself. Your model is less convenient for these tasks than
the one I describe.

Further, I highly doubt that the script I'm writing for those purposes are any
less modular than they should be to get the job done. Namespaces are a
wonderful tool (which I use liberally), but don't confuse being modular with
being good. There's plenty of bad modularity too.

Post by kirby urner
This need to glue it all together with some main() -- why? We compete
with that idea of "programming." We're not a part of *that*
particular conspiracy.

Umm, the point of my program is to automate something. That's why I glue it
together. If I don't do that, I haven't solved the problem I set out to
solve. I'm only 'conspiring' to solve the problems I have at hand.

Post by kirby urner
Last week, we were working on phi and the fibonaccis. Let's get back
to that now. Pull out a file drawer (import) and behold: all our
favorite specimens (even the bugs are back).

Great. Fantastic. It has nothing to do with what I was describing. I have
plenty of these experimental evnrionments as well.

Post by John Zelle
Instead I can write an incredibly simply script that I just click on, and
when it needs information it prompts me for it. That's _my_ state of the
art in programming for myself. And it's something I can teach students to
do for themselves in very short order.

Yeah, we don't like that style. OK for you, works for your students,
I think you're probably a dynamite teacher. But... we still don't
like that style.

Again, I'm talking about writing a useful tool to automate some mundane task.
What's "not to like about that style"? Should I make automating that task
harder so as to fit your pedagogical style? My arguments had nothing to do
with how you or I go about teaching math.

Post by kirby urner
Later on maybe, if/when they're committed to CS. But this is just
basic numeracy here, and they already know about functions from
calculators.
import math
math.cos( 90 * math.degrees)
-- that's what a first class might include. If what stops 'em isn't
the Python syntax, but the trig, then we go over the trig. Basic
numeracy. All as a bundle. Not your grandfathers math class (but
some hoped it'd be for their kids -- remember when the future was,
well, futuristic?).

Again, this sounds great. I like it, and I'm glad you're doing it. And you
don't need raw_input (or input). But having input available in no way impedes
this, and for the tasks I'm describing, lack of the same is a hindrance.

Post by John Zelle
Whether I'm writing for myself or whether I want my students to be able
to write the simplest possible useful programs for themselves and others,
that involves textual input. I'll say it one more time: IO is fundamental
to programming; the simplest universal form of IO deserves to be in the
core language so that it is easily accessible and available everywhere
the language runs. Pascal got that right and Python (pre 3000) has it
right.

But it's less convenient and therefore less useful for producing real tools
that automate tasks. You are talking about a different form of programming
and pedagogy. Docstrings do not solve the problem I describe, because they
are passive. I have to go look at them again to remind myself how to use the
tool. If I write a program, the program itself knows what it needs and when.

"As teachers, we shouldn't be propogating the hidden assumptions that go
with Newtonian mechanics, i.e. that there's this class of people out
there 'too dumb' to know anything about quantum physics or general
relativity." Does

Right, but I see that as a self-serving analogy. You're *defending*
the status quo. Notice how CP4E goes for like "riding a bicycle" and
"driving a car". Anyone can do it, no big deal.

Well far be it for me to suggest an anology that supports what I'm
defending :-). Is it true that anyone can write a working GUI program? I
don't know if that's any more true than that anyone can comprehend quantum
mechanics.

But let's use your example: does the fact that we expect everyone to be able
to drive a car mean that we _shouldn't_ teach them to ride a bicycle? And
shouldn't we even go a step further and take bicycles away because they might
learn this useful mode of transportation which is _not_ car driving? Because
it sounds to me like this is exactly the argument you are making w.r.t.
input.

Post by kirby urner
I think CS has a reflex to fight "debasement" of programming into a
"what your grandmother knows" skill. But that's what I *want* to have
happen, and expect grandmothers *will* have those skills in the not
too distant future.

I hope what you want comes to pass. I can assure you that CS academics have
nothing whatsoever against programming as a universal skill, since we profess
to believe that CS is much more than programming and say so at every
opportunity. I, for one, can't wait to add a bunch more upper-level courses
to the major when programming is taken for granted. I'm just not holding my
breath...

Post by kirby urner
Latin moms in Rio will tell The Monkey to block those Evil Toons
(point and click yes, but they custom-skinned the GUI, know how it
works from hours study. What, working class folk with the free time to
study what they used have to pay for, plus hold down a job? What a
concept!

OK, now I just have no idea what you're talking about. Probably that's because
I'm stuck in my dino-world.

Post by John Zelle
that really make sense? The fact that there is more advanced stuff that
they will surely learn in due course is in no way a justification for not
teaching simpler, useful concepts first.

Nothing much simpler than import math, using the names. Raw_input is
difficult by contrast.

For Gnu-math maybe, but not for the types of useful artifacts I suggested
above. And Input is no more difficult than typing expressions (as I've
explained) which I assume is the starting point for your Gnu-math.

Post by kirby urner
Why don't calculators have raw_input? They can't do I/O? How about
dashboards? Cockpit of an airplane.

You are confusing what's easy for the user with what's easy for the
programmer. Underneath, of couse, a modern calculator _does_ have the
equivalent of raw_input. It grabs the string constructed in the display,
parses and evaluates it. The user interface is all extra baggage built on top
of that. From the programmer's standpoint, that extra baggage is more effort.
If I already have a console, I can get the useful tool without the extra
effort.

Post by kirby urner
We use control surfaces all day long. That's what a namespace is, an
API. You don't need to tie it all together with some main(). This
isn't a script. It's a place to do work. Namespaces are like
studios. Event driven. More GUI, less "programming" (in the 1960s
sense).

Right on. But what I'm talking about _is_ a script.

Post by kirby urner
I'm saying this'll all be common knowledge soon.

Define "soon." I see the same demographic as Brad Miller. My students are
freshman in college who have never programmed. And frankly, I'm OK with that.

What if they're not interested in it? I know in your world the schools are
hopelessly outdated because they don't teach Gnu math and OO. I'm happy if
they teach our children to read and write well and to do some mathematics. I
don't even care much what math they do, just as I don't care much what they
read and write about. Throw in a basic understanding of science, and a
healthy dose of getting along with others, and you've got a curriculum. Of
course, one can argue schools are not doing this now, but I don't see how
teaching them to program frees up more time for what I consider fundamental
skills. If your Gnu-math is better at teaching them some mathematics, that's
great; I'm all for it. But I don't care if it teaches them OO.

One of the reasons for the conservatism of the educational establishment is
that it can be devilishly hard to determine what the core skills are that all
educated people should have (unlike other countries, our K-12 system attempts
to be universal). You specifically mention OO and Python, but education
(currently in the US) is a 13 year program. Will OO still be the dominant
paradigm in a dozen years? I have a hunch not. OO institutionalizes
side-effects (state change), and side-effects are a bane to managing
concurrency. With multi-core, multi-processing machines seeming the most
obvious routes to increased computing power, it could be that OO looks as
old-fashioned as gotos in a dozen years. Is OO some fundamental/essential
skill? I don't think you can measure the value of an education in terms of
what specific technologies are learned (and OO is just a technology).

Fundamental education is not about what technologies we teach or what
technologies we teach with; it's about what kind of citizens we raise. Give
my children a good teacher that can really communicate and get the kids
excited about _learning_, and what in particular they learn doesn't matter so
much. They have their whole lives ahead of them to become great at whatever
is meaningful to them.

Post by kirby urner
If USA voters want to keep that status quo, fine, but don't think the
rest of the world will think twice about thrashing us in the job
market if so. Or were we planning to use the Pentagon to keep the
rest of the world stone aged, while we went on being mental couch
potatoes. If so, think again.
Praise the Lord we have television. If the schools have decided to
rust in irrelevance, letting it be OK that globalization passes us by,
then we can do what we did in Sesame Street, except at a much higher
level (still using puppets though -- some of them CGI).

This is an interesting juxtaposition of paragraphs. Many studies suggest that
TV is the number one contributor to mental couch potatoism. I'd much rather
have my kids spending time in our current (backwards, dino-era) schools (at
least the ones we have here in Iowa) than watching television, no matter what
show is on. Real interactions with live caring people in a social setting is
what children need most. No truckloads of DVDs, screencasts, or electronic
curriculum of the foreseeable future will change that truth. Until we have
truly intelligent machines, there is no substitute authentic interpersonal
interaction in terms of communication bandwidth. Education is at its core
just communication.

Post by kirby urner
Our Snake with __rib__ syntax makes fun cartoons on TV. It slithers
around like Kaa, eating stuff (eat method). Hah hah, the 3rd graders
laugh. Gnu math is just better.

I have no idea what that paragraph is about. Anyway, this is really, really my
last post on this thread.

--John

ps. And I mean it.

--
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360

Dan Crosta

2006-09-08 22:30:51 UTC

This is a good example, of showing off new skills to one's mother.
But maybe CP4E is about having one's mother learn to program, in which
case maybe the first thing you say is "mom, when you import, you bring
in a namespace, which is like stuff you might interact with, like go
from zoo import Monkey
and then go
mymonkey = Monkey("Curious George")
To me, this sounds like you're really educating your mother, not
making it be about you and your new skills, but about cluing her in,
letting her be a part of your world of Python namespaces, where
knowing about import is absolutely key.
You're not making a monkey out of your mom, by making her loop through
some little menu, oblivious of the language underneath, its logic and
design. You're "protecting you mother" (aka paradigm end user) from
knowing *anything* about Python. That's your goal, that's the whole
point (i.e. end user = not a programmer).
I'm saying CP4E is here to change all that. Your mom knows how to
program, learned how to when she was your age. She's been writing
little programs for her kids for decades, plus others for the
microwave, light dimmers, heater, plant waterer, and car. Not because
she's friggin genius or anything, but because this is 2006, and moms
have skills, aren't like in the 1950s (nothing wrong with the 1950s,
but nothing improving in 56 years would be laughably stupid).
[...]
You should just write for yourself at first, and find that satisfying.
You shouldn't need this hypothetical guinea pig other. OK, maybe a
few times (and mom is proud).

Well in that case I agree with you -- it would be great if my mom knew
how to program.

But let's be realistic: my mom has only recently learned to understand
email, she's not about to go out and program her own spam filter. It's
just not in her skillset, and more importantly, her interest set. I
think you're projecting a bit onto the entire world to think that people
are going to program their dimmer switches.

Let me draw a related example: it has recently become more or less
impossible to own any content sold by the MPAA and television industry,
and, less so, by the RIAA. HDMI makes it impossible to do anything other
than watch what your cable box records on an expensive HDTV. If you were
right, there'd be a million light switch-programming mom march on
Washington and Hollywood protesting this insult to their rights.

Now wake up: there isn't. People want their technology to do what it
needs to do at a basic level, but aren't really out there extending it;
whether we like it or not, we're the exception, not the rule, us people
more comfortable at a keyboard than a mouse, more comfortable knowing
how it works than just knowing that it *does* work.

As I said before, I think it's great that you're training the next
generation to love the interactive interpreter rather than the monkey
menus, if you will. I think it's great you're training people to be
self-reliant and program for themselves first, then for others as a job
but always still for themselves. Very Snow Crash. But not realistic, and
not now. Maybe in 2036 when my generation (I'm 22) grows up and has kids
of our own, maybe when I'm Dad, not Dan, people really will be able to
program their light switch and microwave -- but I'm not sure what
that'll really have gained us, my light switch and microwave work fine.
Do yours?

Post by kirby urner
Start thinking like a professional really early. Code for the back
office if it's back office (don't need no bells and whistles).
Don't waste your life polishing API skills no job market will ever
need (i.e. some raw_input based dialog, menu tree, looks like a 1960s
mainframe). Or rather, don't *start* with that.

It's hard to claim that anything you learn in CS1 (or equivalent) is
either polished or a skill. Instead, I think the point is to become
familiar and comfortable with computers as more than a user, and if that
happens to take the form of baby steps, menu monkies, GUI programming,
or whatever, as long as it happens it's good. It's evident to all of us
that menu monkeying works, because that's how we all got trained
programming and look where we are today. It seems fair to say that
teaching through the interactive shell using functions and classes will
accomplish the same goal.

Post by kirby urner
Even most moms these days know that unless junior learns GUI
programming, there's nothing much here, as far as "code for end user"
skills. She's secretly unimpressed, but doesn't show it.

Well, first of all, you evidently don't know my mom at all. Actually,
that's a good thing, I don't think she'd like you.

But more importantly, I don't think moms (at least not moms like mine)
expect junior to learn anything career-relevant in 9th grade. I think
the point of primary and secondary education, and to a great extent
higher education (I went to a small liberal arts college), is to learn
to think critically and creatively, and to problem solve primarily, and
secondarily to gain training for a career.

--- break ---

I want to apologize before this goes any further, I realize my tone is a
aggressive, and I should acknowledge that I really don't have that much
at stake here in this argument, I'm neither a student learning Python
nor a teacher (nor likely to become one any time soon). I was merely
trying to voice another kind of opinion in favor of not making
impossible a class of programming for the sake of ... well, it really
sounds like you've got revolution on your mind. And that's fine, it's
important to have your voice, just try not to drown out the rest of us.

- d

kirby urner

2006-09-08 23:02:37 UTC

Post by Dan Crosta
But let's be realistic: my mom has only recently learned to understand
email, she's not about to go out and program her own spam filter. It's
just not in her skillset, and more importantly, her interest set. I
think you're projecting a bit onto the entire world to think that people
are going to program their dimmer switches.

Well, at one time the ability to type above 30 words a minute was
considered a highly specialized office skill. Only a few people knew
how to drive cars (you had to be a pretty good mechanic, or count on
getting stranded).

Why *does* our culture assume these two classes: those who know how
to program, and those who just use other peoples' programs?

CP4E at least raises this as a question. To assume this dichotomy as
a given, and design curriculum around it, is to my way of thinking,
contrary to the goals of CP4E.

CP4E is not about *making* people become programmers (in the sense of
forcing), but nor is it about passively allowing Python to become the
tool of those who believe programming is only for the few.

I letting Python's good name get dragged through the mud by such "two
culture" elitists is contrary to our BDFL's fond hopes for his
language (and mine too -- really a lot of peoples').

I'd like to see basic programming and basic math taught as one and the
same subject.

I call it gnu math but others might call it something else.

If you know what F(x) means, and that F(x) = x^2, means a domain of
[1,2,3...] becomes a range of [1,4,9...] then how big a leap is it to

Post by Dan Crosta

def F(x): return x*x
domain = range(10)
output = [F(x) for x in domain]

etc.

It's really the same content, isn't it, just expressed in an interactive way.

Why should any 8th grader have any trouble at the above?

Why do we put up with a system that thinks this is "too hard" for
newbie X, and yet in *math class* that's precisely what newbie X is
expected to know.

We test and fail people for not getting math, not making the grade,
then we do extensive hand-holding as soon as the computer is involved.
Why?

Seems hypocritical to me, for us to insist on math savvy as a
condition for a degree, but on computer literacy as an esoteric art
that one's mother should never have to know.

Very strange, very twisted.

Post by Dan Crosta
Let me draw a related example: it has recently become more or less
impossible to own any content sold by the MPAA and television industry,
and, less so, by the RIAA. HDMI makes it impossible to do anything other
than watch what your cable box records on an expensive HDTV. If you were
right, there'd be a million light switch-programming mom march on
Washington and Hollywood protesting this insult to their rights.

Yes, a wonderful development. I promote the future you just described.

Post by Dan Crosta
Now wake up: there isn't. People want their technology to do what it
needs to do at a basic level, but aren't really out there extending it;
whether we like it or not, we're the exception, not the rule, us people
more comfortable at a keyboard than a mouse, more comfortable knowing
how it works than just knowing that it *does* work.

That's precisely the "us versus them" attitude I'm fighting. Now I
grant you: the status quo is on your side. But that doesn't mean I
support it. I see Python as a *powerful* tool for making this state
of affairs go away.

Pretty much anyone can drive a car. Maybe in a few years pretty much
anyone might import bedroom.dimmer from DwellingMachine and write a
few lines to put it on a timer.

True, not everyone will. But if she's middle-aged and looks like a
mom, *is* a mom, yet does the, I hope you won't act surprised.

Python turned out to be that good. They're not scared of computers
anymore, not leaving it to the guy geeks to explain it to 'em.

A Renaissance happened.

Post by Dan Crosta
As I said before, I think it's great that you're training the next
generation to love the interactive interpreter rather than the monkey
menus, if you will. I think it's great you're training people to be
self-reliant and program for themselves first, then for others as a job
but always still for themselves. Very Snow Crash. But not realistic, and

Thank you. I like the "Very Snow Crash" identification.

Very science fiction. Very futuristic.

Compare with my other thought: Guido should be focusing on *coming
generations* with Python3000, not the needs of today's computer
illiterate, likely a dying species.

Post by Dan Crosta
not now. Maybe in 2036 when my generation (I'm 22) grows up and has kids
of our own, maybe when I'm Dad, not Dan, people really will be able to
program their light switch and microwave -- but I'm not sure what
that'll really have gained us, my light switch and microwave work fine.
Do yours?

Maybe not the best example, but I *do* want my DwellingMachine to have
an API. I presumed it'd be Java a long time ago, when doing a
write-up for OMSI (our favorite science museum), but that was before
I'd discovered The Snake and its much simpler __rib__ syntax.

Post by Dan Crosta

But model any given school as "in competition" with other schools.

While yours trained you in raw_input menu trees, these other students
were going crazy in open range namespaces, and learning to teach their
peers the same way, even without any computer science teachers in the
room (Project Kusasa model).

I worry we're too plodding in CS0/CS1, too like the UK (dangerously
slow when it comes to change sometimes, not at all out here on the
Pacific Rim, where we compete with Singapore daily).

Post by Dan Crosta
that menu monkeying works, because that's how we all got trained
programming and look where we are today. It seems fair to say that
teaching through the interactive shell using functions and classes will
accomplish the same goal.

Just why protest if raw_input, and the 1970s style of menu tree
prompting, is going away? That was a passing phase, no? Good thing
we're beyond it today.

Post by Dan Crosta
Well, first of all, you evidently don't know my mom at all. Actually,
that's a good thing, I don't think she'd like you.

That's OK. I have a 76 year old mom of my own, whom I recently taught
HTML, other webmastering. She now is a full time webmaster with her
own site, using DreamWeaver. She's in London right now, probably
managing her site from there.

Post by Dan Crosta
But more importantly, I don't think moms (at least not moms like mine)
expect junior to learn anything career-relevant in 9th grade. I think
the point of primary and secondary education, and to a great extent
higher education (I went to a small liberal arts college), is to learn
to think critically and creatively, and to problem solve primarily, and
secondarily to gain training for a career.
I want to apologize before this goes any further, I realize my tone is a
aggressive, and I should acknowledge that I really don't have that much
at stake here in this argument, I'm neither a student learning Python
nor a teacher (nor likely to become one any time soon). I was merely
trying to voice another kind of opinion in favor of not making
impossible a class of programming for the sake of ... well, it really
sounds like you've got revolution on your mind. And that's fine, it's
important to have your voice, just try not to drown out the rest of us.

I don't believe I'm capable of drowning out others in this particular
format. I do post frequently, but others may skip, work around me,
create and sign petitions, do whatever they like. I develop these
strong attitudes from time to time, and act like I'm prosecuting some
major war. Those who've been here awhile know I'm somewhat
unpredicatable.

But I have no listowner powers, don't have the power to cut anyone
off. A real bully shoves kids around. Here we're all safe in our
cubicles, workstations or whatever, reading some guy sound off from
Portland. How is that really bullying? What can I do to you, really?

Real bullies, on the other hand, have control over your grades, plus
teach you stupid math tricks you'll never need, plus don't teach you
Python, other useful skills. Yet they have you where they want you:
depending on their school and its curriculum.

That, in my view, is where the abuse often lies. And yet these
teachers may be the model of politeness, telling you why *these*
particular kids will never need any programming skills (like, not in
*this* neighborhood they won't need 'em).

Kirby

Toby Donaldson

2006-09-08 22:12:57 UTC

Post by Toby Donaldson
Teaching is filled with IOUs. We often use things before we completely
understand them.
Toby

I would like a deeper discussion of why we still need to prompt
ourselves for input.

Blank screens confuse end users.

Post by kirby urner
I think the model today is "a person writing code for him or herself"
i.e. "self as client" -- at least in an early context.
We're not guiding the unknowing through a menu tree. We're computer literate,
fluent. Why would we ask ourselves for raw_input, when it's much easier to
just pass arguments to functions?

I have no idea what you are talking about.

I have a hard time getting through your rhetoric.

Post by kirby urner
Hey, I'd think about putting self-prompting I/O in a more obscure
context, like copy (also out of reach as a built-in), maybe making it
part of sys or something. :-D
Look how C# handles I/O. That's a good example I think.

Then write a Python library that emulates it and make the world a better place.

Post by kirby urner
System.console -- would that have been better? No one asked me, I
offered no opinion. End of story then. The work is done.

Yep, all done. No need to keep posting about. :-)

Post by kirby urner
Python3000 shouldn't be derailed by politicians, some of whom would,
in their heart of hearts, like Python to fail (just as many USA
congressman actually *hate* what the USA is exposing about them).

Good grief. Why do I subscribe to this list?

Post by kirby urner
As soon as I thought "C#" I felt better. CPython -> C -> C# ->
IronPython looks like a dynamite CS sequence.
I'm looking forward to seeing which schools have guts enough to try it.

Good for you. Have fun.

Toby

--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

kirby urner

2006-09-08 22:28:00 UTC

I have no idea what you are talking about.

In the old days, the end user was confronted with a list of menu
choices, usually numbered, and then a flashing prompt. You'd put in a
number, corresponding to your chosen menu selection, and thereupon be
taken to a "submenu" and so on. Very like these infernal "phone
trees" of today ("please listen carefully, as our menu options have
changed...").

If you don't remember these days, you must be rather new to the end
user experience.

I have a hard time getting through your rhetoric.

I think it's quite expressive. I'm trying to denegrate a style of
"learning to program" which I think shouldn't count any more, as a
quality intro to the subject. Much better, go to a shell (Ruby,
Python, J or whatever... Scheme) and start using the tools you're
given.

It's a rather large vocabulary sometimes, but the sense of a
namepaces, perhaps augmentable (definitely augmentable in Python) is
the "first encounter" we want to promote. That's the environment we
also target when writing our first programs, e.g. code up a bag of
sequence generators for triangular, tetrahedral, fibonacci and so on
(just one example -- the math module is the paradigm, or the string
module, which I'll be sad to see go).

Then write a Python library that emulates it and make the world a better place.

That's your advice, on the record. I have other preferences, also
chronicled here.

Post by kirby urner
System.console -- would that have been better? No one asked me, I
offered no opinion. End of story then. The work is done.

Yep, all done. No need to keep posting about. :-)

That *is* my attitude about raw_input -- it's going away, the work is
done. But now I'd like to talk more about why.

Of course Guido might come on the list and say he's persuaded, by all
the high level arguments, to reopen the discussion. Would that
surprise me. Yes, it would. But stranger things have happened.

Good grief. Why do I subscribe to this list?

Maybe for no good reason? I couldn't tell ya.

If you're objecting to my glancing reference to USA politics, then I
think you're awfully stringent. We're pretty free ranging around
here, like uncaged egg layers.

Is that bad?

Good for you. Have fun.

I intend to.

Sorry you couldn't understand my verbiage. There's obviously some
kind of language barrier between us.

Post by Toby Donaldson
Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

Kirby
CEO, 4D Studios
Silicon Forest
Portand (Oregon)

kirby urner

2006-09-08 22:31:20 UTC

Post by kirby urner
Kirby
CEO, 4D Studios
Silicon Forest
Portand (Oregon)

um, Portland.

Kirby

myspace.com/4dstudios for more re my ToonTown enterprise.

Toby Donaldson

2006-09-08 23:17:55 UTC

Post by Toby Donaldson
I have a hard time getting through your rhetoric.

I think it's quite expressive.

:-)

Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

Michael

2006-09-09 10:01:15 UTC

Post by kirby urner
It's a rather large vocabulary sometimes, but the sense of a
namepaces, perhaps augmentable (definitely augmentable in Python) is
the "first encounter" we want to promote.

NO IT'S NOT. You are not the world.

It's a first encounter that YOU (and a few others maybe) want to promote.

You are not the world.

Also, different people learn differently. Forcing a single approach to
teaching because you're too pigheaded to recognise that you are not the
world is disgusting to see.

You are not the world. You are a reason I don't talk about the reason I
subscribed to this list in the first place though.

Michael.

kirby urner

2006-09-09 17:01:01 UTC

Post by Michael

Post by kirby urner
It's a rather large vocabulary sometimes, but the sense of a
namepaces, perhaps augmentable (definitely augmentable in Python) is
the "first encounter" we want to promote.

NO IT'S NOT. You are not the world.

Sounds like Wittgenstein.

Post by Michael
It's a first encounter that YOU (and a few others maybe) want to promote.
You are not the world.

No, I'm a school of thought in competition with other schools of
thought. My colleagues and I would like our students to avoid some
brain dead menu tree 1960s mainframer approach (that might come later,
for a more specialized audience), and just learn what they've
//already learned// in math class: that functions may be defined and
remembered, variables too.

That, they already know, since like elementary school.

We want to *leverage* what's in math class, and *apply it* in ways
they don't ever seem to get around to, when just sticking with TIs (no
colorful polyhedron cartoons on Google Video; oh I get it, the culture
is sick (not the whole world, mind you)).

What's maybe new for these South African kids, studying on their own
in TuxLabs, is OO, though that's going to be commonplace even in USA
high schools before long.

Won't it be nice for community college profs, when 90% of the incoming
already know Python, Ruby or something vaguely similar? Heaven.

Post by Michael
Also, different people learn differently. Forcing a single approach to
teaching because you're too pigheaded to recognise that you are not the
world is disgusting to see.

This is a "recruit for my school" model, not a "you must take my
course" model. A student with your attitude might be enouraged to
sign up with the brain dead competition. Fight us, don't join us
(then join if you turn out to be any good?).

Post by Michael
You are not the world. You are a reason I don't talk about the reason I
subscribed to this list in the first place though.
Michael.

Just ignore my stupid posts, set a spam filter whatever. I'm a school
of thought with views. I'm *not the only one* who thinks "Namepaces
on Day One" -- or probably your teacher is clueless. At least do
'import this' fer gosh sake.

I say that not because "I'm the world" but because I'm trying to steal
you students (that is, if they think my approach might work better for
them).

Kirby

Michael

2006-09-09 10:03:27 UTC

Post by kirby urner
If you're objecting to my glancing reference to USA politics, then I
think you're awfully stringent. ?We're pretty free ranging around
here, like uncaged egg layers.
Is that bad?

Yes, less than 4% of the world's population live in the USA and learns in a
completely different environment.

Michael.

kirby urner

2006-09-09 18:46:57 UTC

Post by Michael

Post by kirby urner
Is that bad?

Yes, less than 4% of the world's population live in the USA and learns in a
completely different environment.
Michael.

More advanced, I would hope. The USA is crawling with slow-goer
bullies, who want to keep the kids in the dark about way too many key
topics. I fight them, tooth and nail.

I grew up outside the USA during formative years, so I *do* know that
the USA is far from being an advanced nation. But it has potential.
Better living standards *could* be ours, with some work.

Not a superpower though. Not even close.

Kirby

Joshua Zucker

2006-09-09 02:57:48 UTC