Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Case Sensitivity: Survey Results

1 view
Skip to first unread message

Sheila King

unread,
Aug 18, 2001, 2:24:56 AM8/18/01
to
In response to this message:
http://mail.python.org/pipermail/python-list/2001-July/054788.html

which continued the discussion about case sensitivity in the Python
language, I announced my intention to conduct a survey of computer
science teachers on this issue, here:
http://mail.python.org/pipermail/python-list/2001-July/055020.html

The survey is now complete and results are available.
I received a total of 129 responses.

For summaries and to read the actual responses, you can go here:
http://www.thinkspot.net/sheila/computers/case/casesurvey.html

My take on the whole thing, is this:

The overwhelming majority of teachers surveyed on this topic felt it was
a non-issue (well over 80% of them). They felt that students have either
little or no difficulty due to case-sensitivity.

Perhaps, if one were designing a language from scratch (which is no
longer the case with Python), it would be reasonable to adopt
case-insensitivity. It seems there is little benefit to be derived from
case-sensitivity (although some respondents felt that precision in
approach and thinking, richness in language and naming choices, plus
compiler efficiency made sensitivity preferable). So, in the interest of
generating fewer error messages, insensitivity may be preferable.

However, given that this was felt to be an extremely minor issue, I see
no reason to entertain the issue of changing an already existing
programming language either from case-sensitive to case-insensitive or
vice-versa. There would be little to be gained, and certainly it would
not justify backward compatibility issues with already existing code.
Time would be better spent developing better error messages, or more
friendly programming environments for the beginner.

As I said, that is my take on this issue, and I feel that it is
supported by the survey results.

More details on the results of the survey, including all responses to
the survey, are online here:
http://www.thinkspot.net/sheila/computers/case/casesurvey.html

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/


Martijn Faassen

unread,
Aug 18, 2001, 6:30:56 AM8/18/01
to
Neat survey; of course I also like it as it's similar to my own intuitions. :)

Sheila King <she...@spamcop.net> wrote:
[snip]

> Perhaps, if one were designing a language from scratch (which is no
> longer the case with Python), it would be reasonable to adopt
> case-insensitivity. It seems there is little benefit to be derived from
> case-sensitivity (although some respondents felt that precision in
> approach and thinking, richness in language and naming choices, plus
> compiler efficiency made sensitivity preferable). So, in the interest of
> generating fewer error messages, insensitivity may be preferable.

There's one other potential benefit of case-sensitivity in a language,
which would be case-consistency; just like indentation-sensitivity in
Python results in indentation-consistency.

Anyway, I don't want to start an entire case sensitivity thread again
in response to this, so I shouldn't have written this anwer, perhaps. :)

Thanks for the survey, that's useful input into the whole discussion.

Regards,

Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?

DR

unread,
Aug 18, 2001, 11:33:45 AM8/18/01
to
(although some respondents felt that precision in
> approach and thinking, richness in language and naming choices, plus
> compiler efficiency made sensitivity preferable).


Talking about compiler efficiency, is there any way to write an extension
that would allow python to be optionally strongly typed?


Courageous

unread,
Aug 18, 2001, 12:26:56 PM8/18/01
to

>Talking about compiler efficiency, is there any way to write an extension
>that would allow python to be optionally strongly typed?

Python already _is_ strongly typed. What you mean is optional _static_ typing.

It wouldn't be too hard to alter the python parser to accept static type information
and to allow for declarations, but this is only a small part of getting a compiler
to compile efficiently for a dynamic language. I think the folks who keep on asking
for this are quite myopic about it. For performance, it's not nearly as important as
you think.

The main argument in favor of static typing is that static typing reveals coding
errors up front. This argument, however, has no real place in Python, which is
a _dynamic_ language designed for programmers who _like_ dynamic
languages. In other words, you're barking up the wrong language tree (IMO).

Lisp has had optional _static_ declarations for years; they tend not to be used,
as most Lisp programmers don't even think that way, would rather not think that
way, find it too limiting.

C//

Alex Martelli

unread,
Aug 18, 2001, 1:03:16 PM8/18/01
to
"DR" <de...@valtronics.co.za> wrote in message news:3b7e8d15$0$222@proctor...

Python IS strongly typed. If you mean STATICALLY typed, how
do you think an 'extension' could possibly alter the syntax of
the language, not to mention code generation &c?


Alex

Roman Suzi

unread,
Aug 18, 2001, 1:54:13 PM8/18/01
to pytho...@python.org
On 18 Aug 2001, Martijn Faassen wrote:

>Neat survey; of course I also like it as it's similar to my own intuitions. :)
>
>Sheila King <she...@spamcop.net> wrote:
>[snip]
>> Perhaps, if one were designing a language from scratch (which is no
>> longer the case with Python), it would be reasonable to adopt
>> case-insensitivity. It seems there is little benefit to be derived from
>> case-sensitivity (although some respondents felt that precision in
>> approach and thinking, richness in language and naming choices, plus
>> compiler efficiency made sensitivity preferable). So, in the interest of
>> generating fewer error messages, insensitivity may be preferable.
>
>There's one other potential benefit of case-sensitivity in a language,
>which would be case-consistency; just like indentation-sensitivity in
>Python results in indentation-consistency.

I don't like the idea of case-insensitive language, filesystem, etc. I
think, it is much simpler to distinguish identifiers and files with
symbols, without adding equivalence classes {A,a}, {B,b}, ... in
comparisons. This ways it is always clear that A and a are different.

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Saturday, August 18, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "I am Homer of Borg. Prepare to be... ooooh donuts..." _/


Guido van Rossum

unread,
Aug 22, 2001, 4:48:03 AM8/22/01
to
Thanks for all the effort you put into this, Sheila! This sure helps
to put this issue to rest.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

Sheila King

unread,
Aug 22, 2001, 11:35:55 AM8/22/01
to
On Wed, 22 Aug 2001 08:48:03 GMT, Guido van Rossum <gu...@python.org>
wrote in comp.lang.python in article
<cpsnekc...@cj20424-a.reston1.va.home.com>:

:Thanks for all the effort you put into this, Sheila! This sure helps


:to put this issue to rest.

Great. Glad to know it was useful. (I got to learn a lot of Python along
the way, for managing the results--putting them into a DB and counting--
and HTML'ing them up. So, very good for me, too.)

0 new messages