Separators inside a var name

Sebastian "lunar" Wiesner basti.wiesner at
Mon Jun 9 20:05:50 CEST 2008

 Rainy <andrei.avk at> at Montag 09 Juni 2008 19:29:

> I have a stylistic question. In most languages words in var. name are
> separated by underscores or cap letters, resulting in var names like
> var_name, VarName and varName. I don't like that very much because all
> 3 ways of naming look bad and/or hard to type.

Then you better get used to such names, as they are common for many widely
spread languages including C, C++, C#, Java, Python, Ruby, Perl and many
more ;)  You may like these or dislike these names, but you won't come
around them ;)

> From what I understand, scheme can have variables like var-name. I'm
> curious about reasons that python chose to disallow this.

"-" is an operator in Python.  How should the parser know,
whether "var-name" means "the object bound to var_dash_name" or "subtract
the object bound to name from the object bound to var"?

Scheme can allows such names, because its a functional programming language. 
Subtracting in this language is not done through operators, but through
functions.  Therefore there is a clear difference between referencing a
name or subtracting two ones: var-name vs (- var name).

> Another question I have is what other languages allow this naming scheme?

Other lisp dialects do, due to the same reasons as scheme.  

> Were there any languages that allowed space as a separator?

None that I know of.  Probably one could use unicode characters, that look
like a space in languages, which allow unicode characters in identifiers
(as Java or C#, iirc), but I doubt this.  Anyway, even if allowed, this
would be silly, since it obscures code to the eyes of the reader.

> What would be a practical way to separate variables from keywords in that
> case? "some long variable name", 'just a string', or maybe using 2 spaces:
> one var  +  other var  +  third var ? 

I can't image a practical way to allow a space as character in names, while
still maintaining it syntactic element for separation of names.  Quotes are
normally used for string or characters literals and a double space is hard
to distinguish from a single space, and things like ${a name with spaces}
is a lot nastier than names with underscores (which aren't bad at all,

> I think being able to easy have very long names for vars that are easy to
> type would be a fairly significant advantage.

Names shouldn't be long, they should be expressive.  If you can't give an
object a _short_, but _expressive_ name, your object is too complicated ;)

Btw, I don't really understand your refusal of underscores.  In my opinion
such names are harder to read than underscores, which look more like a real
space, because the leave a space in the middle of a line, that you look at. 
If they are too hard for you to type, whats the point in swapping the dash
and the underscore in your keyboard layout?

Freedom is always the freedom of dissenters.
                                      (Rosa Luxemburg)

More information about the Python-list mailing list