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

[Lloyd Hugh Allen]

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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>