Rainy <[EMAIL PROTECTED]> 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,
imho).
> 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)
--
http://mail.python.org/mailman/listinfo/python-list
