[Edu-sig] The fate of raw_input() in Python 3000
Dethe Elza
delza at livingcode.org
Thu Sep 7 15:30:17 CEST 2006
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 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
>>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
When laws are outlawed, only outlaws will have laws.
More information about the Edu-sig
mailing list