[Edu-sig] The fate of raw_input() in Python 3000
ms at cerenity.org
Thu Sep 7 00:55:54 CEST 2006
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
<built-in function raw_input>
~/Local> cat mymods.py
myinput = raw_input
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)
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.
More information about the Edu-sig