Guido van Rossum wrote: > You must be misunderstanding. I don't think so. You appeared to say that the language changes too much because everyone wants different changes - that accumulate. I suggested a mechanism allowing people to see only the changes they want - or none at all - might be devised.
Regards, BB > The root problem is that people > (rightly) complain that the language changes too much. And you want to > "fix" this by adding a deep and fundamental change to the language? > What planet are you from? It reminds me of Jini, which was presented > as a new standard to address the problem of too many conflicting > standard. Get it? :-) > > --Guido > > On 7/14/06, Boris Borcic <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> ... >>> This is an illustration of the dilemma of maintaining a popular >>> language: Everybody hates change (me too!) but everybody also has one >>> thing that's bothering them so much they absolutely want it to be >>> changed. If you were to implement all those personal pet peeves, you'd >>> get a language that's more different from Python than Python is from >>> Fortran. >>> >>> So where's the middle ground? >> I feel some freedom could be reclaimed with a solution in the spirit of >> Turing >> equivalence. Or, to take a less grandiose comparison, web style sheets - >> separation of content and presentation. >> >> Suppose the standard required a (possibly empty) style-defining file prefix >> that >> constrains the python source code in the file, and concurrently defined >> (mostly) >> reversible and transparent source-to-source transforms that would map any >> source >> code file to an equivalent source code file with an arbitrary chosen prefix. >> Then users could chose their style of Python and either transform all source >> files they install to their own style, or setup their editor to do it >> back-and-forth for them. The choice of python presentation style would then >> become a private choice. >> >> To illustrate the idea, this already exists in very embryonic form with >> unicode >> encoding modelines. The current standard allows to imagine a Python editor >> that >> would permit to set a "local standard encoding modeline" and then present any >> source file as if it had been written while taking maximal profit from the >> chosen encoding. Which may also be simple ascii. >> >> Cheers, BB >> -- >> "C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
