Case Sensitive, Multiline Comments

[Elliot Temple]

Hi I have two questions. Could someone explain to me why Python is
case sensitive? I find that annoying. Also, why aren't there
multiline comments? Would adding them cause a problem of some sort?

Thanks,
Elliot

 

[Mike Meyer]

Hi I have two questions. Could someone explain to me why Python is
case sensitive? I find that annoying.

Because it comes from a language background of case sensitive
languages (C, shell, etc.). But read what the BDFL has to say about
it: <URL:
http://mail.python.org/pipermail/python-list/2001-July/054788.html >

Personally, I think anyone who has two variables whose names differ
only in case should be shot. No, let me extend that - anyone who has
two variables whose names would be pronounced the same should be
shot. I've had to debug such code, and it ain't fun.

Variables whose name differs from the class they are instance of only
in case is the only allowable exception. And should be used with care.

On the same note, anyone who spells a variable name with different
cases because the languge is case-insensitive should be shot. I want
to be able to use various source analysis tools without having to
worry about dealing with two different ascii strings being names for a
single variable.

Add those two together, and you'll see that *I don't care*. I consider
taking advantage of a language being case-sensitive or
case-insensitive to be a bad idea, so it doesn't matter what the
language does.

Also, why aren't there
multiline comments? Would adding them cause a problem of some sort?

Because no one every really asked for them. After all, there are two
formats for multi-line strings, which the interpreter will build and
then discard. There are tools that recognize multi-line strings after
function/method definitions and treat them as function documentation.

Adding multiline comments probably wouldn't be a problem - you'd just
have to come up with an introductory character sequence that can't
occur in the language (not that that stopped C). But you'd have to get
someone to write the code, then someone with commit privs to decide it
was useful enough to commit. That seems to be a lot of work for very
little gain.

<mike

 

[Paul McNett]

Because no one every really asked for them. After all, there are two
formats for multi-line strings, which the interpreter will build and
then discard. There are tools that recognize multi-line strings after
function/method definitions and treat them as function documentation.

Adding multiline comments probably wouldn't be a problem - you'd just
have to come up with an introductory character sequence that can't
occur in the language (not that that stopped C). But you'd have to get
someone to write the code, then someone with commit privs to decide it
was useful enough to commit. That seems to be a lot of work for very
little gain.

Don't we already have multi-line comments in the form of string literals?

 

[John Machin]

Personally, I think anyone who has two variables whose names differ
only in case should be shot. No, let me extend that - anyone who has
two variables whose names would be pronounced the same should be
shot. I've had to debug such code, and it ain't fun.

Here's a pair of targets for you:

From "Software Engineering with Modula-2 and Ada", by Wiener &
Sincovec, page 84:

WITH w^ DO
...
Col := column;
Row := row;

It turns out that 'Row' & 'Col' are module-global variables holding the
current cursor position, and 'row' & 'column' are elements of the record
to which 'w' points.

Here's another corollary for Meyer's Law: Anyone who has two variables
the name of one of which is, or could reasonably be understood to be, an
abbreviation of the name of the other should be shot.

Cheers,
John

 

[Elliot Temple]

Thanks for the link on case sensitivity. I'm curious about the person
who found case sensitivity useful though: what is it useful for?

The way I find multi-line comments useful is to quickly comment out a
block of code while debugging. A good development environment can
(mostly) solve that one though.

 

[John Roth]

Hi I have two questions.
....


Also, why aren't there
multiline comments? Would adding them cause a problem of some sort?

As a matter of fact, yes. First, consider that as soon as you have
multi-line comments, someone is going to request nested multi-line
comments. (In other words, the compiler should check that the
embedded comment is still correct.) That rapidly leads to madness.

Second, multi-line comments aren't really necessary; as someone
in the thread commented, a decent editor or IDE will allow adding
or removing comments from a block of code easily. Python's
philosophy is to only add features when there is a use case that
will improve the language significantly, and commenting out a block
of code for testing isn't it. (It's also not the world's best practice,
but that's another subject.)

John Roth

 

[Peter Hansen]

Thanks for the link on case sensitivity. I'm curious about the person
who found case sensitivity useful though: what is it useful for?

I wasn't that person, but I do find case sensitivity very useful.

Mainly it's useful in that it allows me not to spend any time at all
worrying that I just might have a collision in my naming of various
entities that are conceptually in different spaces but which -- due to
the nature of the language I'm using -- happen to co-exist in the same
namespace.

For example, although this contrived example suggests poor imagination
in picking names, I think it demonstrates the point.

INVENTORYCODE = 5 # in effect one item in a constant "enum"

class InventoryCode:
'''Might represent something to do with inventory codes... duh'''


def myfunc():
inventoryCode = someOtherFunction()


In other words, I have a CONSTANT, a Class, and an instance, and if the
set of code involved were large enough, these three things might be
defined far enough apart that the potential collision wouldn't be as
obvious as it is here.

More to the point, there might not be any relationship between these
things in my mind as I'm programming, and having to deal with an error
message from a compiler or, worse, a run time error resulting from this
collision would really annoy me.

Case sensitivity might not be something we should be deliberately
exercising on a daily basis, but there's no good reason (in my opinion)
for not having it available to allow one freedom in naming (assuming one
is sane and uses consistent convention for the case of things like
constants, classes, and instances) without the worry of pesky collisions.

-Peter

 

[Dennis Lee Bieber]

Thanks for the link on case sensitivity. I'm curious about the person
who found case sensitivity useful though: what is it useful for?

Making a language run faster on slow machines since the syntax
parsing doesn't have to do the equivalent of upper or lower casing
anything that is not a string literal before checking for keywords or
identifiers.

Consider the time spent by languages like Ada and Fortran when
they have to do case normalization every time you compile.

--

 

[Duncan Booth]

Making a language run faster on slow machines since the syntax
parsing doesn't have to do the equivalent of upper or lower casing
anything that is not a string literal before checking for keywords or
identifiers.

Consider the time spent by languages like Ada and Fortran when
they have to do case normalization every time you compile.

That isn't a good argument for case sensitivity. You really aren't going to
be able to measure a slowdown in compilation speed just because the
compiler has to lowercase all the identifiers before using them.

What I consider good arguments for case sensitivity are:

Consistency. I've used non-case sensitive languages where the same variable
was spelled sometimes with capitals and sometimes without. Forcing you to
choose one case and stick to it is, IMHO a good thing. Worse, I've used
Visual Basic where the editor will gratuitously change the case of a
variable you just typed in because there is another occurrence of the same
name somewhere else in a different case.

Conventions such as capitalising class names, or camelCasing can be useful.
Again this only applies if they are used consistently.

Interoperability. Like it or not, there are other case sensitive systems
out there. I once had the misfortune to use a Microsoft Access database
(where lookups on indexed fields are case insensitive) to store records
indexed by a case sensitive medical coding system. Codes in that system do
exist which differ from other completely unrelated conditions only by the
case of the code. The only way to handle this in a case insensitive system
is to somehow escape each case sensitive code.

That particular example wouldn't necessarily apply to a case insensitive
programming language, but plenty of others would: e.g. using a remote
procedure call system to call a (case sensitive) function on another
system.

In all such cases, the case insensitive system is the 'poor relation', it
is the one where you have to introduce workrounds in order to communicate
with the case sensitive system. Going in the other direction (calling a
case insensitive function from a case sensitive system) you simply have to
invent a convention (e.g. lowercase everything) and stick by it.

There are arguments that, especially for beginners, case sensitivity
introduces an extra level of complexity, but the cost of losing this
complexity would be to make Python a poor relation amongst programming
languages.

 

[Szabolcs Nagy]

i found case sensitivity very useful

1. variables can be stored in a dict (think about __dict__, globals())
and dict type should be case sensitive

2. It's necessary when i write short scripts and i use one letter
names. (eg. when i playing with linear algebra i always use a,b,c for
vectors and A,B,C for matrices). I dont want to think about "more than
one letter" names when i run that script only once. And usually this is
the case with python (at least when i use it in interpreted mode).

3. i write sometimes:
class Foo:
...
foo = Foo()

and i think it's readable and makes sense.

4. actually i never wanted to use 'foo', 'Foo' and 'FOO' for the same
variable and i can't imagine a situation when it's useful. it makes the
code less readable so i think the language should force the programmer
not to use different names for the same variable.

nsz

 

[Brian van den Broek]

Duncan Booth said unto the world upon 2005-05-27 04:24:

There are arguments that, especially for beginners, case sensitivity
introduces an extra level of complexity, but the cost of losing this
complexity would be to make Python a poor relation amongst programming
languages.

Well, this is just one man's anecdote, but Python was my first
language since some BASIC many moons ago, and the case sensitivity
neither got in my way, nor felt complex. Perhaps Python beginners with
background in case insensitive languages do experience it differently.

At any rate, since the sequence of characters 'somename' and
'SomeName' are different sequences, treating them as different names
strikes me as the obviously right thing to do.

Best to all,

Brian vdB

 

[John Roth]

That isn't a good argument for case sensitivity. You really aren't going
to
be able to measure a slowdown in compilation speed just because the
compiler has to lowercase all the identifiers before using them.

Actually it is, but you have to get out of ASCII into the wider world
of all of the real languages out there. Something I heard from one of the
people who invented XML is that it originally started out as case
insensitive, and they had quite an extensive discussion about it. When they
made it case sensitive, one of the basic tools sped up by a factor of three.
Doing case translations in Unicode following all of the rules for all of the
world's languages is, for want of a better world, a real bitch.

John Roth

 

[Duncan Booth]

Doing case translations in Unicode following all of
the rules for all of the world's languages is, for want of a better
world, a real bitch.

Fair point, although that is true for anything, not just case translations.
Fortunately, unlike Ecmascript, Python doesn't allow arbitrary unicode
characters in identifiers.

 

[Elliot Temple]

One other interesting thing about case sensitivity I don't think
anyone has mentioned: in Python keywords are all lowercase already
(the way I want to type them). In some other languages, they aren't...

-- Elliot Temple
http://www.curi.us/

 

[John Roth]

One other interesting thing about case sensitivity I don't think anyone
has mentioned: in Python keywords are all lowercase already (the way I
want to type them). In some other languages, they aren't...

Not quite. None, True and False are upper case.

John Roth

 

[Leif K-Brooks]

Not quite. None, True and False are upper case.

But those aren't keywords. (Well, None is a pseudo-keyword in Python
2.4, but...)

 

[Mike Meyer]

Making a language run faster on slow machines since the syntax
parsing doesn't have to do the equivalent of upper or lower casing
anything that is not a string literal before checking for keywords or
identifiers.

Consider the time spent by languages like Ada and Fortran when
they have to do case normalization every time you compile.

Hopefully, this should be minimal. You canonicalize them all as soon
as you realize you can. With proper language design, this may be as
soon as you recognize that they aren't in a string.

This brings to mind the reason I quit using Microsoft products. I was
writing z80 assembler, and habitually wrote everything in lower case,
including all the op codes.

The assembler refused to recognize the indexed instruction opcodes
that were present on the z80 but not the 8080. I double-checked the op
codes, did the "delete and retype" thing, and in general went crazy
trying to figure out what was wrong.

I eventually called Microsoft and asked. The answer was "Those have to
be in upper case." That told me enough about the insides of MS
software that I swore off it, and have never purchased an MS product
since.

<mike

 

[Arthur]

Thanks for the link on case sensitivity. I'm curious about the person
who found case sensitivity useful though: what is it useful for?

I am curious about why you find case sensitivity annoying. But just
mildly curious.

Martelli can tell you why Guido keeping case sensitivity in Python was
him bowing to the stupidity of the masses.

I have been neutral on the subject except to the extent the impetous
for going case insensitive would be to statisfy the needs - as Guido
uses the word - "non-programmers".

a) its probably better to design a programming language around the
needs of programmers than around those of non-porgrammers. that much
always seemed quite obvious to me.

b) it would only help non-programmers who were more comfortable with
case insensitivity but hurt non-progammers more comfortable with case
sensitivity.

That Martelli so strongly favors case insensitivity for his own use,
is one of many indications that this is not an issue that cuts along
the lines of quantity of programming experience..

That much also seemed pretty obvious, but it didn't seem to stop the
folks who wanted case insensitivity from making the non-programmer
accessibility issue paramount. and on the flimiest of evidence. Those
who prefer sensitivity were anti-accessbility elitists. Damn near
Republicans.

Classic politics.

Thankfully Guido seemed to have lost patience for the whole thing. I
think the position is pretty much that Python will be case sensitive
becasue it has been case sensitive.

Art

 

[Elliot Temple]

I am curious about why you find case sensitivity annoying. But just
mildly curious.

I'm glad you asked ;-)

Case insensitivity gives you more choice about how to type keywords
that you have no control over. if or If. for or For. i don't think
being inconsistent within a single program is a good idea, but having
your choice of which to do is nice. I personally think all lowercase
is good, but some languages have capitalised keywords, so apparently
other people prefer that.

I don't think the "case sensitivity hurts beginners" argument is
persuasive. Anyone who seriously wants to program can look up the
correct capitalisation of everything. *If* having to look up or keep
track of capitalisation is annoying, *then* that argument applies to
experienced programmers (who are devoting memory to the issue) just
as much as beginners.

-- Elliot Temple
http://www.curi.us/

 

[D H]

Hi I have two questions. Could someone explain to me why Python is
case sensitive? I find that annoying.

I do too. As you've found, the only reason is because it is, and it is
too late to change (it was even too late back in 1999 when it was
considered by Guido). I guess the most popular case-insensitive
language nowadays is visual basic (and VB.NET).

> Also, why aren't there
multiline comments? Would adding them cause a problem of some sort?

Again, just because there aren't and never were. There is no technical
reason (like for example a parsing conflict) why they wouldn't work in
python. That's why most python editors have added a comment section
command that prepends # to consecutive lines for you.