On Jun 10, 3:38 am, Rainy <[EMAIL PROTECTED]> wrote:
> On Jun 9, 2:05 pm, "Sebastian \"lunar\" Wiesner"
>
> <[EMAIL PROTECTED]> wrote:
> > 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 ;)
>
> 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 ;-) ).
--
http://mail.python.org/mailman/listinfo/python-list
