473,394 Members | 2,002 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,394 software developers and data experts.

Case Sensitive, Multiline Comments

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

Jul 19 '05 #1
32 3100
"Elliot Temple" <cu****@gmail.com> writes:
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/pyt...ly/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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #2
Mike Meyer wrote:
"Elliot Temple" <cu****@gmail.com> writes:
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.


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

--
Paul McNett
http://paulmcnett.com

Jul 19 '05 #3
Mike Meyer wrote:
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
Jul 19 '05 #4
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.

Jul 19 '05 #5
"Elliot Temple" <cu****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
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


Thanks,
Elliot


Jul 19 '05 #6
Elliot Temple wrote:
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
Jul 19 '05 #7
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
declaimed the following in comp.lang.python:
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.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 19 '05 #8
Dennis Lee Bieber wrote:
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
declaimed the following in comp.lang.python:
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.

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.
Jul 19 '05 #9
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

Jul 19 '05 #10
Duncan Booth said unto the world upon 2005-05-27 04:24:

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

Jul 19 '05 #11
"Duncan Booth" <du**********@invalid.invalid> wrote in message
news:Xn*************************@127.0.0.1...
Dennis Lee Bieber wrote:
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
declaimed the following in comp.lang.python:
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.

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

Jul 19 '05 #12
John Roth wrote:
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.
Jul 19 '05 #13
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/
---
[This E-mail scanned for viruses by Declude Virus]

Jul 19 '05 #14
"Elliot Temple" <cu**@curi.us> wrote in message
news:ma**************************************@pyth on.org...
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

-- Elliot Temple
http://www.curi.us/
---
[This E-mail scanned for viruses by Declude Virus]


Jul 19 '05 #15
John Roth wrote:
"Elliot Temple" <cu**@curi.us> wrote in message
news:ma**************************************@pyth on.org...
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.


But those aren't keywords. (Well, None is a pseudo-keyword in Python
2.4, but...)
Jul 19 '05 #16
Dennis Lee Bieber <wl*****@ix.netcom.com> writes:
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
declaimed the following in comp.lang.python:
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.


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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #17
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
wrote:
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
Jul 19 '05 #18

On May 29, 2005, at 11:44 AM, Arthur wrote:
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <cu****@gmail.com>
wrote:

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.


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/
---
[This E-mail scanned for viruses by Declude Virus]

Jul 19 '05 #19
D H
Elliot Temple wrote:
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.
Jul 19 '05 #20
In article <z5********************@comcast.com>, D H <a@b.c> wrote:
Elliot Temple wrote:
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.


If it really bothers you that there's no multi-line comments, you could
always use triple-quoted strings.

I actually don't like multi-line comments. They're really just syntactic
sugar, and when abused, they can make code very difficult to understand.
Just wait until the day you're trying to figure out why some C++ function
is behaving the way it is and you don't notice that a 50-line stretch of
code is commented out with /* at the top and */ at the bottom.
Jul 19 '05 #21
On Thu, 26 May 2005 16:24:39 -0500, Mike Meyer <mw*@mired.org> wrote:
"Elliot Temple" <cu****@gmail.com> writes:
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/pyt...ly/054788.html >


As Guido's statement on his position on case sensitivity/insensitivity
cited above was in response to a post/provocation of mine, its gives
me, and I shall indulge myself in, an opportunity to partake of a
favorite pasttime - venting,

I will make it short:

It gauls the hell out of me that that the Python community mass "head"
was in such a strange place at that moment that I had to take the pose
of maniacal extremist to have a sensible converstaion.

Or that's the history I am writing, in any case.

Art

Jul 19 '05 #22
Roy Smith wrote:
Just wait until the day you're trying to figure out why some C++ function
is behaving the way it is and you don't notice that a 50-line stretch of
code is commented out with /* at the top and */ at the bottom.


The same thing's happened to me in Python when I accidentally included a
function's code in its docstring (don't ask me how I managed to do that
-- I don't know). But my editor's syntax highlighting helped me to find
the error very quickly.
Jul 19 '05 #23
D H
Roy Smith wrote:
In article <z5********************@comcast.com>, D H <a@b.c> wrote:

Elliot Temple wrote:
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.

If it really bothers you that there's no multi-line comments, you could
always use triple-quoted strings.


Where did I say that?
I actually don't like multi-line comments. They're really just syntactic
sugar, and when abused, they can make code very difficult to understand.
Just wait until the day you're trying to figure out why some C++ function
is behaving the way it is and you don't notice that a 50-line stretch of
code is commented out with /* at the top and */ at the bottom.


Same with triple quotes, btw.
Jul 19 '05 #24

"D H" <a@b.c> wrote in message news:z5********************@comcast.com...
Elliot Temple wrote:
Hi I have two questions. Could someone explain to me why Python is
case sensitive? I find that annoying.
I do too.


I don't.
As you've found, the only reason is because it is,


False. As someone else already pointed out in this thread, and as some
said years ago when Guido brought up the subject, standard math notation
*is* case sensitive and some people like Python because they can directly
translate math expressions into Python expressions.

I am annoyed by the disinformation and slander ('anti-newbie') repeated
indefinitely by some case-folding advocates. Difference annoyances for
different folks, I guess.

Terry J. Reedy

Jul 19 '05 #25
Terry Reedy wrote:
Difference annoyances for different folks, I guess.


IN MY EXPERIENCE, MANY PEOPLE ON THE INTERNET ARE
ANNOYED BY PEOPLE WHO DON'T USE CASE THE WAY THEY
ARE EXPECTED. IT ALSO SEEMS TO ME THAT LOWER CASE
TEXT IS OFTEN MORE EASY TO READ, AND ALSO THAT IT
IS EASIER TO SCAN TEXTS IF CASE IS CONSISTENT. WE
DO AFTER ALL SEE IMAGES ON THE SCREEN. EVEN IF WE
RELATE "IF" WITH "if", THEY DON'T LOOK THE SAME.
MY SON POINTED AT THE WORD "TOYOTA" IN A MAGAZINE
AND EXCLAIMED "TOTOTA" WHEN HE WAS ONLY THREE. HE
WAS CLEARLY TOO YOUNG TO READ, BUT HE RECOGNIZED
THE IMAGE OF THE LOGO HE HAD SEEN ON OLD TOYOTAS.
IN GENERAL, PYTHON "TRIES" TO FORCE A PARTICULAR
STYLE OF CODING ON PROGRAMMERS. WE HAVE TO INDENT
IN A PARTICULAR WAY. THE STYLE OF PROGRAMMING HAS
BEEN CODIFIED IN PEP 008, AND COWBOY PROGRAMMING
ISN'T REALLY APPRECIATED. YOU ARE NOT "SUPPOSED"
TO PROGRAM PYTHON "YOUR WAY". YOU ARE SUPPOSED TO
PROGRAM THE RIGHT WAY. IF YOU DON'T LIKE THAT, IT
IS PROBABLY BETTER TO USE ANOTHER LANGUAGE. PERL
IS MORE OF A COWBOY LANUGAGE. THE FUNNY THING IS
THAT EVEN PERL IS CASE SENSITIVE! EXPLAIN THAT!!!
IMO IT'S A STRENGTH OF PYTHON THAT PYTHON CODE IS
ALWAYS CONSISTENT IN CASE. IT IS PROBABLY A MINOR
FEATURE COMPARED TO THE BLOCK STRUCTURES ETC, BUT
I THINK IT ADDS TO THE EASE OF READING CODE WHICH
HAS BEEN WRITTEN BY OTHERS. I DO ALSO DISLIKE THE
ALTERNATIVES. NEITHER CODE WITH INCONSISTENT USE
OF CASE NOR THE STUPID "CASE CORRECTING" FEATURES
IN E.G. THE VISUAL BASIC IDE SEEMS TO BE ANYTHING
TO STRIVE FOR. IF YOU THOUGHT IT WAS ANNOYING TO
READ THIS, THEN YOU CAN AT LEAST APPRECIATE THAT
PYTHON CODE NEVER LOOKS LIKE SUCH A COMPACT BLOB!

Who am I kidding with this? Everybody knows that
case doesn't matter, right? The text below isn't
a bit easier to read than the text above, right?

In my experience, many people on the internet are
annoyed by people who don't use case the way they
are expected. It also seems to me that lower case
text is often more easy to read, and also that it
is easier to scan texts if case is consistent. We
do after all see images on the screen. Even if we
relate "IF" with "if", they don't look the same.
My son pointed at the word "TOYOTA" in a magazine
and exclaimed "Totota" when he was only three. He
was clearly too young to read, but he recognized
the image of the logo he had seen on old toyotas.
In general, Python "tries" to force a particular
style of coding on programmers. We have to indent
in a particular way. The style of programming has
been codified in PEP 008, and cowboy programming
isn't really appreciated. You are not "supposed"
to program Python "your way". You are supposed to
program the right way. If you don't like that, it
is probably better to use another language. Perl
is more of a cowboy lanugage. The funny thing is
that even Perl is case sensitive! Explain that!!!
IMO it's a strength of Python that Python code is
always consistent in case. It is probably a minor
feature compared to the block structures etc, but
I think it adds to the ease of reading code which
has been written by others. I do also dislike the
alternatives. Neither code with inconsistent use
of case nor the stupid "case correcting" features
in e.g. the Visual Basic IDE seems to be anything
to strive for. If you thought it was annoying to
read this, then you can at least appreciate that
Python code never looks like such a compact blob!

oF cOuRsE, wE sHoUlDn'T aSsUmE tHaT pEoPlE wIlL
aBuSe ThE fReEdOm ThEy GeT, bUt I'm RaThEr SaFe
ThAn SoRrY! ;^) I'm ReAlLy hApPy ThAt I'lL nEvEr
HaVe To SeE aLl-CaPs PyThOn PrOgRaMs!

Jul 19 '05 #26
What I want to know is how Mangus wrote an entire message fully
justified. I looked for extra spaces and other cheats but only
found a couple of superfluous exclamation marks. Well done! He
must be a justification wizard. I wish I could do that too. :)
--
Benji York
Jul 19 '05 #27
Benji York wrote:
What I want to know is how Mangus wrote an entire message fully
justified. I looked for extra spaces and other cheats but only
found a couple of superfluous exclamation marks. Well done! He
must be a justification wizard. I wish I could do that too. :)


I hadn't even seen it at first, since I use a proportional font for
reading my mail.

You haven't looked very well though: there are actually quite a lot of
extra spaces. Still, it's nicely done indeed.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven
Jul 19 '05 #28
On Mon, 30 May 2005 20:56:22 +0000, Roel Schroeven wrote:
You haven't looked very well though: there are actually quite a lot of
extra spaces. Still, it's nicely done indeed.


C-u M-q ?

Jul 19 '05 #29
On Mon, 30 May 2005 14:24:54 -0400, "Terry Reedy" <tj*****@udel.edu>
wrote:

"D H" <a@b.c> wrote in message news:z5********************@comcast.com...
Elliot Temple wrote:
Hi I have two questions. Could someone explain to me why Python is
case sensitive? I find that annoying.
I do too.


I don't.
As you've found, the only reason is because it is,


False. As someone else already pointed out in this thread, and as some
said years ago when Guido brought up the subject, standard math notation
*is* case sensitive and some people like Python because they can directly
translate math expressions into Python expressions.


False.

In the sense that it is the way it is only because Guido kept it the
way it is, but he did so without acknowledging that your argument or
anyone else's argument was in the least bit pursuasive to him.
I am annoyed by the disinformation and slander ('anti-newbie') repeated
indefinitely by some case-folding advocates. Difference annoyances for
different folks, I guess.


I am annoyed that Guido skated while those of us vocally annoyed that
Guido could be influenced into this substanceless "newbie" issue, and
influence so many others to contemplate it with such solemnity - did
not skate as well.

Art

Jul 19 '05 #30
Roel Schroeven wrote:
You haven't looked very well though: there are actually quite a lot
of extra spaces. Still, it's nicely done indeed.


Hmm. I only saw doubled spaces after commas and periods. That's
fairly standard practice, for the periods at least. I don't know
if people regularly put two spaces after commas though. I know I
don't. I did spot a couple of extra quotation marks, but I guess
I can give him those. :)
--
Benji York
Jul 19 '05 #31
Benji York wrote:
Roel Schroeven wrote:
> You haven't looked very well though: there are actually quite a lot
> of extra spaces. Still, it's nicely done indeed.


Hmm. I only saw doubled spaces after commas and periods. That's
fairly standard practice, for the periods at least. I don't know
if people regularly put two spaces after commas though. I know I
don't. I did spot a couple of extra quotation marks, but I guess
I can give him those. :)


Doubled spaces after commas are definitely not standard usage.

Doubled spaces after periods are fairly common (a holdover from
fixed-pitch typewriters, as I recall, where the period itself takes up a
full character width and so needs doubled space after it to make the
sentence breaks more noticeable).

Inconsistent use of doubled spaces after periods, however, is a sign of
a smart justification algorithm. <wink>

-Peter
Jul 19 '05 #32
> > > You haven't looked very well though: there are actually quite a lot
> of extra spaces. Still, it's nicely done indeed.

Hmm. I only saw doubled spaces after commas and periods.

Doubled spaces after commas are definitely not standard usage.


I guess the fact that *all* comments on my post only referred
to my formatting, tell us something about how distracted we can
get by purely "typographic" aspects of text. I think that might
strengthen my case. Text that visually looks different than we
are used to, distracts us from the content.

Another interpretation would be that the content of my previous
post was a bit thin, since I was to caught up with form... I guess
that *also* suggests that we should use standard Python formatting
and concentrate on content...

Of course, if you're used to typing If in other languages, Python
might initially feel annoying, just as C++ feels stupid when it
forces me to put a silly ; in the end of each line. On the other
hand, there are other things beyond syntactic details that differ
more between languages, and it's pretty easy to get used to Python.

I think the thing that bothered me most initially was the differnt
shape of the code, since there were no explicit block end markers
in Python.

I was really used to code looking like this:

xxxx
xxxx
xxx
xxxx
xxxx
xx
xxx
xxxx
xxx
xxx
xxxx
xx
xx

And now it looked:

xxxx
xxxx
xxx
xxxx
xxxx
xxx
xxxx
xxx
xxx
xxxx

It somehow felt very abrupt, and I missed the visual cues that
we were going back to a previous block level. After some time I
got used to it, and I very rarely hear anyone contest that code
written in Python usually is easier to read than code written
in other languages. The lack of block end markers, is one of
several Python features that promote clarity and a high signal/
noise ratio in the source code.
Jul 19 '05 #33

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Uwe Ziegenhagen | last post by:
Hello, my fellows and me implement a c++ tool that is able to divide blank/tab separated files into <number>, <text>, <c-singlelinecomment> and <multilinecomment>. So far it's not working bad,...
1
by: Laser Lu | last post by:
Hi, all, I'm now writing a program to compress JavaScript code. One puzzle is how to write a regular expression to find out and remove all the redundent blank spaces. However, those blank spaces...
40
by: Edward Elliott | last post by:
At the risk of flogging a dead horse, I'm wondering why Python doesn't have any multiline comments. One can abuse triple-quotes for that purpose, but that's obviously not what it's for and doesn't...
0
by: Ethan Furman | last post by:
Maric Michaud wrote: Actually, the OP said: -- So you're saying to ensure that stage_map's keys are initially -- lower-case to begin with? Well, I can't do this either since the -- *case of the...
11
by: Rafe | last post by:
Hi, I'm working within an application (making a lot of wrappers), but the application is not case sensitive. For example, Typing obj.name, obj.Name, or even object.naMe is all fine (as far as...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.