Case-insensitive: a new twise (underscores!)

Pete Shinners pete at visionart.com
Mon May 22 13:07:19 EDT 2000


well, i'm not 'voting' here, but i am interested in seeing
the topic covered further.

i see the point of using insensitive casing to make the language
more flexible. also allowing users to 'alter' the style of the
language to best fit with their project.

i do see the annoyance of working with a project, and then needing
to use a module which uses a strongly different capitialization
scheme that the rest of the project.

if you are considering loosening the 'case' requirements for
the language, consider also loosening the 'underscoring' of
object names.

it may sound like a honky wild idea, but it seems any arguments
used for case insensitive can also be used with 'optional' 
underscoring.

example. if i read in someone's module, and it uses the
popular "all words separated with capitals"
(GetValue, ClearScreen), but i prefer to use "all words
separated with underscores" (get_value, clear_screen)

(obviously optional underscores would be restricted to
 between letters, to preserve python's current special
 meanings for leading and trailing underscores.
 (perhaps this is up for discussion with python3k, heh))

if the argument is making the language more flexible to meet
different users styles, how far does that go? when do things
become too confusing?

i'm interested to see where this goes either way, but here's
certainly food for thought.

i've never used a case insensitive language. and actually,
i've never even thought about it. it's hard to imagine if
i would end up preferring it or not?

PS, no offense intended with my case insensitive writing
style :]



More information about the Python-list mailing list