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

[Douglas S. Blank]

Kirby,

As a teacher, I don't have time to argue over on python-dev what should 
and should not be included in the language. And don't want to! I am 
thinking of our "petition nonsense" as a data point for those people 
that do take the time over on python-dev to figure out the best thing to 
do next, and I'll trust them.

It seemed to at least a few people on the list that python-dev'ers may 
not have fully considered the ramifications of this particular change in 
regards to teaching. We simply want to let them know about this 
oversight. John has written probably the best-selling textbook for intro 
Python; if he is concerned, then they should at least take a second look 
at it (whatever "it" might be.)

As far as I understood the discussion about removing "print", it was to 
remove it as an expression and add it as a function. This is a good move 
(in my opinion) because it is now even more parallel with input(), and 
makes more sense, and makes it more useful. If the discussion was to 
turn "print" into "sys.stdout.write()" then I think some teachers would 
again be upset, and rightly so. Maybe they should rename it output() 
though. :)

Now, it's time for the semester to begin... ACK

-Doug

kirby urner wrote:
> 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
> 
>