The fate of raw_input() in Python 3000
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: ") Enter your name: name = sys.stdin.readline() <-- Andre print("Hello " + name + "!") Hello Andre!
To explain the above *simple* program to a beginner, we'd need: 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(). Thoughts? André
On 9/4/06, Andre Roberge <andre.roberge@gmail.com> wrote:
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
On 4-Sep-06, at 5:45 PM, Andre Roberge wrote:
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().
But it is trivial to add this back in:
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.
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
open('myfilename.txt')
with
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
On Monday 04 September 2006 8:56 pm, Dethe Elza wrote:
On 4-Sep-06, at 5:45 PM, Andre Roberge wrote:
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().
But it is trivial to add this back in:
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.
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.
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.
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.
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.
That is:
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.
2. It possible (and desirable) to have different command-line prompts for different purposes sure.
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.
Now, all that given, I do hope Python doesn't start going down the road that Java has taken and replace
open('myfilename.txt')
with
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 it should be something like:
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?
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@wartburg.edu (319) 352-8360
On Mon, 2006-09-04 at 21:36 -0500, John Zelle wrote:
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.
On Tue, 2006-09-05 at 09:45 -0500, Peter Chase wrote:
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?
On Tue, 2006-09-05 at 09:54 -0500, Brad Miller wrote:
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.
On Tue, 2006-09-05 at 09:50 -0700, Radenski, Atanas wrote: * 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
On Wednesday 06 September 2006 8:00 am, Arthur Siegel wrote:
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.
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.
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.
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.
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@wartburg.edu (319) 352-8360
John Zelle wrote:
On Wednesday 06 September 2006 8:00 am, Arthur Siegel wrote:
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.
/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 /
On Wednesday 06 September 2006 1:24 pm, Arthur wrote:
John Zelle wrote:
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@wartburg.edu (319) 352-8360
On 9/6/06, John Zelle <john.zelle@wartburg.edu> wrote:
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
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
On 9/6/06, John Zelle <john.zelle@wartburg.edu> wrote:
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 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Joshua Zucker wrote:
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
On Sep 7, 2006, at 8:27 PM, Arthur wrote:
Joshua Zucker wrote:
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?
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
Arthur wrote:
Joshua Zucker wrote:
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
_______________________________________________ Edu-sig mailing list Edu-sig@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
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 On Wednesday 06 September 2006 22:51, John Zelle wrote:
On Wednesday 06 September 2006 1:24 pm, Arthur wrote:
John Zelle wrote:
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
How about from __past__ import raw_input ? Especially as a line that can be included in the IDLE initialization for your students? On 9/6/06, Michael <ms@cerenity.org> wrote:
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
On Wednesday 06 September 2006 22:51, John Zelle wrote:
On Wednesday 06 September 2006 1:24 pm, Arthur wrote:
John Zelle wrote:
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@python.org http://mail.python.org/mailman/listinfo/edu-sig
On 7-Sep-06, at 1:54 AM, Lloyd Hugh Allen wrote:
How about
from __past__ import raw_input
+1 ROTFL %-) --Dethe
? Especially as a line that can be included in the IDLE initialization for your students?
On 9/6/06, Michael <ms@cerenity.org> wrote:
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
On Wednesday 06 September 2006 22:51, John Zelle wrote:
On Wednesday 06 September 2006 1:24 pm, Arthur wrote:
John Zelle wrote:
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@python.org http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
When laws are outlawed, only outlaws will have laws.
On 6-Sep-06, at 2:51 PM, John Zelle wrote:
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.
But it is trivial to add this back in:
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
On Wednesday 06 September 2006 6:22 pm, Dethe Elza wrote:
On 6-Sep-06, at 2:51 PM, John Zelle wrote:
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).
I would want to keep the original names if only for historical reasons.
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.
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.
It sure stirred up a lot of commentary though.
But it is trivial to add this back in:
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()
Look at my previous comments, I said you'd have to write a function for it, which is what you did.
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.
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.
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.
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.
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.
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@wartburg.edu (319) 352-8360
Arthur Siegel wrote:
On Mon, 2006-09-04 at 21:36 -0500, John Zelle wrote:
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.
On Tue, 2006-09-05 at 09:45 -0500, Peter Chase wrote:
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?
On Tue, 2006-09-05 at 09:54 -0500, Brad Miller wrote:
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.
On Tue, 2006-09-05 at 09:50 -0700, Radenski, Atanas wrote:
Me too :-) I would like to see both input and raw_input preserved. Replacing these with more complicated (from pedagogical perspective) methods would probably give an additional reason for educators to look at alternative languages, such as Ruby.
* 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@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?
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. On Monday 04 September 2006 7:45 pm, Andre Roberge wrote:
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: ")
Enter your name:
name = sys.stdin.readline()
<-- Andre
print("Hello " + name + "!")
Hello Andre!
To explain the above *simple* program to a beginner, we'd need: 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.
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@wartburg.edu (319) 352-8360
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 something similar to:
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
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.
On Monday 04 September 2006 7:45 pm, Andre Roberge wrote:
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: ")
Enter your name:
name = sys.stdin.readline()
<-- Andre
print("Hello " + name + "!")
Hello Andre!
To explain the above *simple* program to a beginner, we'd need: 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.
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@wartburg.edu (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Andre Roberge wrote:
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().
<snip>
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.)
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
Andre Roberge wrote:
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: ") Enter your name: name = sys.stdin.readline() <-- Andre print("Hello " + name + "!") Hello Andre!
To explain the above *simple* program to a beginner, we'd need: 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().
Thoughts?
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@bryant.edu http://web.bryant.edu/~bblais
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
Dethe Elza wrote:
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
[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
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
kirby urner wrote:
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
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!")).
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
Art
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!")).
On 9/7/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
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.
OK, you've persuaded me: remove it, by all means. Kirby
On 9/7/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
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.
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
Kirby
On 9/8/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
:) 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
kirby urner wrote:
On 9/8/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
:) 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?
I believe the plan isn't that print be removed, just turned into a builtin function, like print('x=', x) -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
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 kirby urner wrote:
On 9/8/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
:) 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
On 9/8/06, Douglas S. Blank <dblank@brynmawr.edu> wrote:
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.
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.
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.
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."
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 wrote: [snip]
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@googlegroups.com. -Doug
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
You can find me over at edupython@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
kirby urner wrote:
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@colorstudy.com | http://blog.ianbicking.org
On 9/8/06, Ian Bicking <ianb@colorstudy.com> wrote:
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@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
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 On Friday 08 September 2006 11:41 am, kirby urner wrote:
On 9/8/06, Ian Bicking <ianb@colorstudy.com> wrote:
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@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 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
On 9/8/06, John Zelle <john.zelle@wartburg.edu> wrote:
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
kirby urner wrote:
You can find me over at edupython@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 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
!DSPAM:518,450197d880009539417968!
Letting the mask slip so we could see the face underneath, eh Kirby? P. Chase
Hi all, I was going to do like John Zelle, and stop contributing to this point, but I have a lot less discipline than he does. A while ago, out of curiosity I bought "Python programming for the absolute beginner" by Michael Dawson to see his approach as it is considered an extremely newbie-friendly way to teach programming in general and programming with Python in particular. Mindful of copyright breaches (hey, I recommend the book!), I think I can safely reproduce his first example in its entirety here: =============== # Game Over # Demonstrates the print command # Michael Dawson - 12/26/02 print "Game Over" raw_input("\n\nPress the enter key to exit.") ========================== That's it. Dawson builds from this simple example, making better and better use of raw_input() as he goes along. Everything is built from extremely simple input/output like others have described: print gives info *to* the user, raw_input() sends information *from* the user to the program. Two core built-in commands, simple to explain, to which other instructions can be added to create more complex programs. I would really like to hear about Dawson's opinion on the removal of raw_input() from Python built-ins... I think that Dawson's book contributes a lot to the stated goals of CP4E. I would also be curious to hear the opinion of those involved in the writing/editing of "How to think like a computer scientist" regarding the same topic... raw_input() is used a lot there too... To the "Kirby"s out there, I am *very aware* that there are other approaches to teach programming/Python. For those that doubt this, have a look at rur-ple (rur-ple.sourceforge.net), a Python Learning Environment I designed based on "Karel the robot" type of approach. In addition to designing the environment, I have written 49 lessons so far ... NONE of which uses/introduces raw_input(): it is simply not required using a graphical environment like rur-ple. By the time I might need to introduce it (if only for completeness), learners will already be familiar with import, functions, etc., so that a user-defined raw_input() could be easily introduced instead. Yet, I think it is a mistake to remove it (as I have stated before). To those that disagree, I would ask: how do you propose in concrete terms (not pie-in-the-sky) to replace Zelle`s book, Dawson's book and How to think like a computer scientist, once raw_input() has disappeared from Python built-ins? Where`s the textbook? André
On 9/12/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Yet, I think it is a mistake to remove it (as I have stated before). To those that disagree, I would ask: how do you propose in concrete terms (not pie-in-the-sky) to replace Zelle`s book, Dawson's book and How to think like a computer scientist, once raw_input() has disappeared from Python built-ins? Where`s the textbook?
André
The computer book industry thrives on changes obsoleting earlier books. Change is what publishers like O'Reilly expect and/or like about this fast moving industry, so I wouldn't worry. Lots of job security. Teachers bring their own biases to their teachings. For me, it's always been about building within languages that offer an interactive command line (APL, dBase/VFP... Python, J). I've saved lots of autobio, to help make my influences obvious (in case anyone cares to know). I'm sorry if I was giving the impression I'm telling other professionals how to do their jobs. More, I'm not expecting others to change, just because I wrote something in an obscure archive. People will keep doing what they do. One or two might experiment with my recommended approach, maybe a few more. I likewise experiment with ideas others share here, incorporate them into by bag of tricks. I want my gnu math teachers to blend a functional approach to Python and ordinary algebra, to create a tastey healthy brew, suitable for enjoying a Silicon Forest lifestyle -- a namespace others elsewhere may find valuable and import. Our world is like this (and I'm sorry about that first line -- left over from a post to Synergeo of earlier today (29094 Re: Polytopes)): IDLE 1.2b2
"not his kissing butt".replace("his kissing","kissing his") 'not kissing his butt'
def f(x): return x ** 2
def g(x): return x + 7
def compose(fa, fb): def fc(x): return fa(fb(x)) return fc
f(10) 100 g(10) 17 h = compose(f,g) h(10) 289 k = compose(g,f) k(10) 107
Not waiting for textbooks. Just using the web. Kirby
Douglas S. Blank wrote:
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@colorstudy.com | http://blog.ianbicking.org
________________________________ From: edu-sig-bounces@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
On 9/8/06, Radenski, Atanas <radenski@chapman.edu> wrote:
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."
I think the professors are very wrong here.
May be there are, or may be they are not.
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
From: "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
On Friday 08 September 2006 1:33 pm, ajsiegel@optonline.net wrote:
From: "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.
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@wartburg.edu (319) 352-8360
----- 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@python.org
From: "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
On Friday 08 September 2006 1:33 pm, ajsiegel@optonline.net wrote: 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.
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@wartburg.edu (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
From: 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
--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@wartburg.edu (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
From: John Zelle
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
On 9/7/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
[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é
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
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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. On Thursday 07 September 2006 8:49 pm, Andre Roberge wrote:
On 9/7/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
[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
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 :-).
Otherwise, while I am not using Python in a classroom, I certainly agree with the summary below and support it.
André
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
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
On 9/8/06, John Zelle <john.zelle@wartburg.edu> wrote:
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é
On Thursday 07 September 2006 8:49 pm, Andre Roberge wrote:
On 9/7/06, dblank@brynmawr.edu <dblank@brynmawr.edu> wrote:
[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
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 :-).
Otherwise, while I am not using Python in a classroom, I certainly agree with the summary below and support it.
André
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
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
John Zelle wrote:
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.
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
dblank@brynmawr.edu wrote:
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@colorstudy.com | http://blog.ianbicking.org
participants (18)
-
ajsiegel＠optonline.net -
Andre Roberge -
Arthur
-
Arthur Siegel
-
Brian Blais -
Christian Mascher -
dblank＠brynmawr.edu -
Dethe Elza -
Douglas S. Blank
-
Ian Bicking -
John Zelle -
Joshua Zucker -
kirby urner -
Lloyd Hugh Allen -
Michael -
Paul Gries -
Peter Chase -
Radenski, Atanas