Language change and code breaks

[Roman Suzi]

On Tue, 17 Jul 2001, Guido van Rossum wrote:

> philh at comuno.freeserve.co.uk (phil hunt) writes:
> 
> > >I also don't want to fork the code base.  
> > 
> > Does that imply that you sare no longer interested in making 
> > radical changes to Python, such as case-insensitive identifiers
> > mentioned in CP4E?
> 
> I still have the same end goal, but I believe there must be a way to
> obtain it without too much disturbance.  Case-sensitivity, for
> example, may be a tool feature rather than a language feature, or it
> may be a user option or a langage-level choice.  (Not that I've
> figured out exactly how to do this, but TeachScheme makes this an
> option.)  Note that case-sensitivity is also controversial: the Alice
> folks found it a problem, but the VPython folks have not confirmed
> this (while they did confirm the integer division trap).

Probably, case{non,}sensitive and integer/fp division are the same analogy
as simple vs. engineer/scientific vs. programmable calculator (we recently
discussed in the other c.l.p thread: "Re: Bug in __imul__").

Python is in no way simple calculator ;-) It is in the "programmable"
category for sure. 

Then it must be real programming language. So the beginners 
will join real programming. Not just some funny Logo. ;-)

imul vs. fmul aren't necessary example here, but case sensitivity is.

I noted that Alice is Windows-only project and their view could
be narrowed.

Windows is case-insensitive and thus "easy to use" only before one needs
to put web-pages on the real (UNIX) web-server. Then they understand all
the troubles with mised case, national-charset filenames, abbr~ted
filenames, local file references "C:\Mydocs\lalala", bmp-images etc.

So, certain degree of wisdom must be preserved. CP4E is not 
"dumb P to nothing and it will be 4E".

If the product has internal integrity thus inherent simplicity it is
simpler than the product which ADDS something for "easy of use"
to hairly and underthought core.

Easiness/complexity must match problems under solution. DNS is complex
because NS is overly complex system. So, attempts to build better BIND
failed so far, because NS *is* BIND ;-)

Python is externally and internally simple and does not do special hook
for "easy of use". Lets leave it simple and coherent.


Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -