Separators inside a var name

R

Rainy

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. From what I understand,
scheme can have variables like var-name. I'm curious about reasons
that python chose to disallow this. Another question I have is what
other languages allow this naming scheme? Were there any languages
that allowed space as a separator? 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 think being able to easy have very long names
for vars that are easy to type would be a fairly significant
advantage. I know I'm probably being too obsessive about this, but
that didn't stop me from posting. Comments?
 
G

Gary Herron

Rainy said:
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. From what I understand,
scheme can have variables like var-name. I'm curious about reasons
that python chose to disallow this.

Because we'd prefer var-name to mean subtraction of values: var minus
name. If you want to use a that character in names, what syntax would
you prefer for subtraction? Do you consider lisp/scheme (- a b) to be
reasonable in Python?
Another question I have is what
other languages allow this naming scheme? Were there any languages
that allowed space as a separator?

Fortran used to. (Haven't checked in on it in years though so I don't
know now). And it not so much as allowed spaces as it *ignored* all
spaces. This was now-a-days considered a *really* bad idea, and is
rumored to be responsible for a bug that crashed a satellite. (At least
that's the way a nice urban legend tells it.)
 
R

Rainy

Because we'd prefer var-name to mean subtraction of values: var minus
name.  If you want to use a that character in names, what syntax would
you prefer for subtraction?  Do you consider lisp/scheme (- a b) to be
reasonable in Python?

I would make it that var - var2 would be subtraction and var-name
would be
a var name. I don't like (- a b) but I might have preferred it if it
allowed dashes inside var names, if I got used to it. Hard to say.
Fortran used to.  (Haven't checked in on it in years though so I don't
know now).  And it not so much as allowed spaces as it *ignored* all
spaces.  This was now-a-days considered a *really* bad idea, and is
rumored to be responsible for a bug that crashed a satellite.  (At least
that's the way a nice urban legend tells it.)

Well, if I understand right, fortran used caps for many things? I'm
not sure
how it separated things if it ignored all spaces. I'll trust you that
it's
not a good idea :). However that's not what I meant, I'd just like to
use
(or rather try using) spaces inside var names.
 
S

Sebastian \lunar\ Wiesner

Rainy said:
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?
 
R

Roger Miller

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

The most widely used such language would probably be COBOL,
where you write things like

SUBTRACT DISCOUNT FROM LIST-PRICE GIVING AMOUNT-DUE

I doubt that syntax would catch on in Python :)
 
R

Rainy

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


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


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.
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...
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.
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 ;-) ).
 
A

Alexander Schmolck

Rainy said:
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. From what I understand,
scheme can have variables like var-name. I'm curious about reasons
that python chose to disallow this.

Legacy -- mathematical notation is broken and conflates negation and
subtraction (causing all sorts of annoyances including this one). Thus if you
want to be able to name a variable ``a-b`` you either have to write ``a - b``
to disambiguate subtracton from the variable name ``a-b`` or you need to chose
a different symbol for subtraction (writing "a ~ b" would likely be the best
choice).
Another question I have is what other languages allow this naming scheme?

All lisps. Dylan. Rebol. Postscript. Forth. I'm sure there are a few others.
Were there any languages that allowed space as a separator?
Sure.

What would be a practical way to separate variables from keywords in that
case?

Lisp allows you to use pretty much anything in a variable name, you just have
to quote it, either

like\ this

or

|like this|

"some long variable name", 'just a string', or maybe using 2 spaces: one var
+ other var + third var ? I think being able to easy have very long names
for vars that are easy to type would be a fairly significant advantage.

I assume you haven't programmed too much? The problem with long names is that
they obscure structure, so they are only worthwhile for rarely used and fairly
obscure concepts where the added descriptiveness yields a net advantage.
I know I'm probably being too obsessive about this, but that didn't stop me
from posting. Comments?

I think you're right -- the common naming convention's suck and "python's" is
particularly bad (HtmlFrob HTMLFrob htmlFrob html_frob htmlfrob HTML_FROB
HTMLFROB -- which one will it be? No way to know without looking at the rest
of the code, the only consistency is that the last two are mostly used for
constants; everything else is completely up for grabs). You'd better get used
to it though, it's become "standardized".

'as
 
B

bruno.desthuilliers

Rainy <[email protected]> at Montag 09 Juni 2008 19:29:
(snip)

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

Nope. Scheme and most lisps AFAICT allow such names because of lisp's
syntax, period. Scheme being (more or less) a functional language is
mostly unrelated. FWIW, there are pure functional languages that use
an infix operator syntax just like Python (and FWIW, Python itselfs
uses functions to implement operators) and don't accept dashes in
identifiers for the same reasons as Python : parsing ambiguity.

(snip)
 
L

Lie

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.





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

Rainy

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.

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.
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 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 :).
 
R

Rainy

Legacy -- mathematical notation is broken and conflates negation and
subtraction (causing all sorts of annoyances including this one). Thus if you
want to be able to name a variable ``a-b`` you either have to write ``a - b``
to disambiguate subtracton from the variable name ``a-b`` or you need to chose
a different symbol for subtraction (writing "a ~ b" would likely be the best
choice).

~ is terrible, imho, I'd much rather disallow a - b for subtraction
(and all
math ops).
All lisps. Dylan. Rebol. Postscript. Forth. I'm sure there are a few others.


Lisp allows you to use pretty much anything in a variable name, you just have
to quote it, either

 like\ this

or

 |like this|

This is actually pretty nice. I think I like this much better
than C/Java/etc convention. I wouldn't use pipes but I'd pick
something that's easy to type and is nicely readable. Not
sure what..
I assume you haven't programmed too much? The problem with long names is that
they obscure structure, so they are only worthwhile for rarely used and fairly
obscure concepts where the added descriptiveness yields a net advantage.

Only about 8 years, but it may be that I'm just
not very good ;-). I'm not sure that's the case.
My problem with long names is that they look
ugly, and the longer they are, the uglier they
look when you use underscores or caps. Other
than that, I'd like to have an option to use
longer names. Maybe it won't be used all the
time, but still..
I think you're right -- the common naming convention's suck and "python's" is
particularly bad (HtmlFrob HTMLFrob htmlFrob html_frob htmlfrob HTML_FROB
HTMLFROB -- which one will it be? No way to know without looking at the rest
of the code, the only consistency is that the last two are mostly used for
constants; everything else is completely up for grabs). You'd better get used
to it though, it's become "standardized".

'as

Well, I agree, this is terrible. If I were Guido I'd
make a very explicit rule that a certain naming
scheme is preferred and other schemes are very bad.
And I'd get it in the beginning of official tutorial,
libref, in books, etc. Mostly it's ClassName and func_name
and var_name and so on, but very often it's something else.
BUT even if that was the rule and everyone followed it,
though it would be much better than what we have now,
it would still offend my taste. Just saying!
 
K

Kam-Hung Soh

Rainy said:
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. From what I understand,
scheme can have variables like var-name. I'm curious about reasons
that python chose to disallow this. Another question I have is what
other languages allow this naming scheme? Were there any languages
that allowed space as a separator? 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 think being able to easy have very long names
for vars that are easy to type would be a fairly significant
advantage. I know I'm probably being too obsessive about this, but
that didn't stop me from posting. Comments?

Groovy allows spaces in method names. See following request and thread:

http://jira.codehaus.org/browse/GROOVY-2857
 
M

MRAB

This is actually pretty nice. I think I like this much better
than C/Java/etc convention. I wouldn't use pipes but I'd pick
something that's easy to type and is nicely readable. Not
sure what..

I think the only available punctuation mark left for Python is the ?
-- though didn't I read something about ` becoming free (probably for
Python 4000)

Access/JET uses [xx xxx] for table/column names

There are also ! and $, although you couldn't really use ! as an infix
operator because != already has a meaning. How about using $ or %% for
Python 3's new string formatting? :)
 
S

Sebastian \lunar\ Wiesner

Nope. Scheme and most lisps AFAICT allow such names because of lisp's
syntax, period. Scheme being (more or less) a functional language is
mostly unrelated. FWIW, there are pure functional languages that use
an infix operator syntax just like Python (and FWIW, Python itselfs
uses functions to implement operators) and don't accept dashes in
identifiers for the same reasons as Python : parsing ambiguity.

Of course, you're right. My words were badly chosen, I just wanted to point
out, that scheme can allow such names, because it doesn't use operators but
functions for things like subtraction. My bad, sorry
 
S

Sebastian \lunar\ Wiesner

Rainy said:
Well, I agree, this is terrible. If I were Guido I'd
make a very explicit rule that a certain naming
scheme is preferred and other schemes are very bad.

FWIW, there is a preferred naming scheme outlined in PEP 8.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top