Separators inside a var name

[Lie]

On Jun 10, 3:38 am, Rainy <andrei.... at gmail.com> wrote:
> On Jun 9, 2:05 pm, "Sebastian \"lunar\" Wiesner"
>
> <basti.wies... at gmx.net> wrote:
> >  Rainy <andrei.... at gmail.com> 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 ;)
>
> Well, I was thinking of using some obscure language for personal
> projects
> that may not need good libs, etc. But of course I agree that there are
> no mainstream widely used languages that allow this.
>
>
>
> > > 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"?
>
> As I mentioned in another post, differentiate between var1 - var2 and
> var-name.

As Sebastian have said, it just can't work like that in python and
most languages. var1-var2 is a subtraction, because - is an operator.
Operator must allow spaces and lack of spaces, how would you want
these to be interpreted then: a+b, a-b, a/b, a*b, a**b? In Lisp/Scheme
there is no room for ambiguity since their syntax made it impossible
that a-b means subtraction. Translated to python, your idea would mean
we have to do this: sub(a, dashed-name) for all subtraction.

[1] Lisp/Scheme have syntax like this: (- a b) for subtraction, (+ a
b) for addition

>
>
>
> > 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.
>
> Yes, that's of course out. I meant using real space.

Real space or space-lookalike, allowing blank characters for variable
names is a bad idea. It hurts readability by a factor of twenty.

> > > 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 agree about ${name with spaces}. I would be interested in the
> approach
> of using something else for strings and using quotes for var names.
> Not
> perfect either but might be better than underscores...

Err.. what's actually your problem with underscore? Quoting names is
the worse idea ever, I'm sure he only reference it as a joke.
Especially since it would be ambiguous whether the thing in the quote
is a name or a string

>
> > > 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 ;)
>
> I'm not sure, I often find myself needing to use 4 words for var name,
> and
> then underscores I think don't look too good, I would say that
> underscores
> are kind of ok for 2 words, not very good for 3 words and bad for 4+
> words.
> I think if spaces were allowed, I would sometimes use 5 word
> variables.

I think you need to think simple. KISS principle.
Add documentation then use short, expressive names.
Generally a shorter the name is more readable than 5-words names.

Which ones is clearer:
class Math(object):
    def add(a, b):
        return a + b
    def sub(a, b):
        return a - b

and:
class Mathematic(object):
    def addition(left_hand_side_operand, right_hand_side_operand):
        return left_hand_side_operand + right_hand_side_operand
    def subtraction(left_hand_side_operand, right_hand_side_operand):
        return left_hand_side_operand - right_hand_side_operand

and short names also saves some typing.

> > 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?
>
> To me, underscores_look_very_ugly. What_if_I_typed
> part_of_every_sentence
> with_an_underscore? Ugly! Swapping the dash and underscore are not a
> bad
> idea, it doesn't fix uglyness, though, and it adds a problem if you
> have
> to work on another system, because you will always type dash by
> mistake
> (which will look nice but won't work ;-) ).