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

[kirby urner]

On 9/8/06, dblank at brynmawr.edu <dblank at 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