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