Optional Underscores (py3k)?

[Pete Shinners]

i thought i posted something about this a day or two ago,
but i never saw the message come up. sorry  if this just
annoys anyone.

with all the talk case insensitive python. i was thinking
about it and realized this is very similar to allowing
optional underscores on object names as well.

ok, this may be taking things to far, but think about it.
it seems most of the arguments that can be used for loose
case sensitivity can be used for loose underscore sensitivity.

the biggest advantage for case insensitivity for me would
be able to import other's modules and packages, and allow
it to conform to my programming style.

if a user prefers the "Words Separated By Caps" style
(GetValue, ClearScreen) they are welcomed to it. but if
another user prefers "Words Separated With Underscores"
(get_value, clear_screen)

now obviously in current python, leading and trailing
underscores are __very__ important to the meaning of
the word. i also suspect this is a bad feature, and wonder
if there are more explicit ways to define your classes
and functions. either way, it is likely that leading and
trailing underscores would need to be preserved, even in
an loose-underscore environment.

in the end i'm not advocating the future either way, but
i do believe if python becomes case-insesitive it might
also behoove things to become underscore-insensitive

do underscores fall into the argument of not effecting
a human's reading of a word??

i'm curious what people think about this. the biggest
advantage (for me) with case-insensitivity would be the
flexibity of style. why not take things a little farther?
or do underscores "cross the line"?

-- 
_____Pete Shinners______
   pete at visionart.com