Separators inside a var name

Rainy andrei.avk at gmail.com
Tue Jun 10 02:44:40 CEST 2008


On Jun 9, 5:45 pm, Lie <Lie.1... at gmail.com> wrote:

>
> 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

Well, a couple of things could be done, I don't really care
either way. Mind you, I of course don't think Python will
be changed in this way, I'm just curious about reasons and
whether other languages do this. That said, it could either
be allowed to have +,-,/,*,** in var name, or disallow
them unless they're surrounded by spaces. Sometimes it's
nice to use them without spaces but that's not at all
important to me.


> > > 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.

I'm not sure that's the case.

>
>
>
> > > > 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

Well, that's a matter of taste, naturally, but
I don't like either to type or read underscores
between words. I think they look ugly. In regard
to strings, yes, strings would have to be
marked up differently. Maybe str(some 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

A well constructed strawman is always a pleasure
to behold but I think you could make a much better
strawman than this :-).




More information about the Python-list mailing list