Re: Re: Re: Re[2]: Re: class proposal

Replying on an old topic, just by chance...

Lenard Lindstrom wrote:

...

> What I dislike about Python:
> 
> 1) Case sensitive identifiers. This is a C holdover. Many high level languages
>    - Pascal, Ada, PL/I - are case insensitive. Why not Prothon? Just rename
>    Object to root to remove the conflict with the object statement.

This is not a trivial subject. I have my personal preferences,
and I guess for 10 users, there are 15 preferences.

Ignoring my ALGOL86 roots, I come from the Pascal-style languages.
I always loved that case sensitivity was no issue.
At the same time, I really *hated* that these language allowed
me to write rpograms with different case than for instance the
author of a module intended.
This is not only because it makes it harder to scan Pascal
sources for certain identifiers, it is also that I dislike
people writing "sloppy source", just ignoring what I wrote
for them with care. So they either should use my way throughout
their source, or they should explicitly change it, by an option
for their source viewer, for instance.

What *I* would really like is this:
- A language that dis-allows co-existance of the same identifier
   with different case
- even disallowing co-existance of similar identifiers, using
   CamelCase and nocamel_case

I think this would remove a lot of hidden bugs in existing
Python code, as well. Simple mis-spellings of CaSe.

And this in combination with an editor which
- understands the different ways of variable markup
- has an automated renaming of identifiers to the "original"
   way to do it, or to "my way to do it" on module level.

So what I want is:

- Make it into a syntax error to use different style of the
   same identifier as different variables/attributes
- automagically replace different style with the original style
- make the equivalence rules for identifiers into a user option
- let the identifiers of a foreign module appear imported into
   my module with my preference of casing style.
- make this whole idea into a configurable option. The way a
   program is represented should be directed by the taste of the
   user, nothing else.

> 2) That colon terminating the first line of block statements. It makes python
>    blocks half delimited. It is only there for readability and to make life easier
>    for editor writers. It is an irritant to me. Either add a block terminator
>    or make the colon optional when the block starts on a new line.

I don't see much to change, here, because this is a single
character. My way would be to change the editors to just add
the colon when the keyword is seen.
If I don't have to type it, I don't care about it.

> 3) The inequality operator != . Lets either adopt Pascal's <> for not equal and :=
>    for assignment, or C's &&, ||, and !.

Not understood. "!=" is in C as "&&", "||" et al. are.
What is the problem?

cheers - chris
-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/