By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,235 Members | 1,008 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,235 IT Pros & Developers. It's quick & easy.

Separators inside a var name

P: n/a
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?
Jun 27 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Rainy wrote:
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.)
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?
--
http://mail.python.org/mailman/listinfo/python-list
Jun 27 '08 #2

P: n/a
On Jun 9, 1:42*pm, Gary Herron <gher...@islandtraining.comwrote:
Rainy wrote:
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?
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.
>
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.)
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.
Jun 27 '08 #3

P: n/a
Rainy <an********@gmail.comat 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)
Jun 27 '08 #4

P: n/a
On Jun 9, 7:29 am, Rainy <andrei....@gmail.comwrote:
... 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 :-)
Jun 27 '08 #5

P: n/a
On Jun 9, 2:05*pm, "Sebastian \"lunar\" Wiesner"
<basti.wies...@gmx.netwrote:
*Rainy <andrei....@gmail.comat 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.
>
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.
>
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...
>
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.
>
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 ;-) ).

Jun 27 '08 #6

P: n/a
Rainy <an********@gmail.comwrites:
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
Jun 27 '08 #7

P: n/a
On 9 juin, 20:05, "Sebastian \"lunar\" Wiesner"
<basti.wies...@gmx.netwrote:
Rainy <andrei....@gmail.comat Montag 09 Juni 2008 19:29:
(snip)
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.
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)

Jun 27 '08 #8

P: n/a
Lie
On Jun 10, 3:38*am, Rainy <andrei....@gmail.comwrote:
On Jun 9, 2:05*pm, "Sebastian \"lunar\" Wiesner"

<basti.wies...@gmx.netwrote:
*Rainy <andrei....@gmail.comat 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 easyto
type would be a fairly significant advantage.
Names shouldn't be long, they should be expressive. *If you can't givean
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 ;-) ).
Jun 27 '08 #9

P: n/a
On Jun 9, 5:45*pm, Lie <Lie.1...@gmail.comwrote:
>
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 inthat
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 :-).

Jun 27 '08 #10

P: n/a
On Jun 9, 5:34*pm, Alexander Schmolck <a.schmo...@gmail.comwrote:
Rainy <andrei....@gmail.comwrites:
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).
~ is terrible, imho, I'd much rather disallow a - b for subtraction
(and all
math ops).
>
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|
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..
>
"some long variable name", 'just a string', or maybe using 2 spaces: onevar
+ 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.
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 know I'm probably being too obsessive about this, but that didn't stopme
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
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!

Jun 27 '08 #11

P: n/a
Rainy wrote:
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?
--
http://mail.python.org/mailman/listinfo/python-list
Groovy allows spaces in method names. See following request and thread:

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

--
Kam-Hung Soh <a href="http://kamhungsoh.com/blog">Software Salariman</a>

Jun 27 '08 #12

P: n/a
br*****************@gmail.com <br*****************@gmail.comat Montag 09
Juni 2008 23:39:
On 9 juin, 20:05, "Sebastian \"lunar\" Wiesner"
<basti.wies...@gmx.netwrote:
> Rainy <andrei....@gmail.comat Montag 09 Juni 2008 19:29:
(snip)
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.

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

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)
Jun 27 '08 #13

P: n/a
Rainy <an********@gmail.comat Dienstag 10 Juni 2008 02:53:
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.

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)
Jun 27 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.