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 <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
