[PATCH] A compromise on case
jnc at ecs.soton.ac.uk
Wed May 24 10:59:18 CEST 2000
On Tue, 23 May 2000 17:18:25 GMT, nickm at mit.edu (Nick Mathewson)
>"Everybody's always talking about the weather, but nobody seems to do
> anything about it."
>So I wanted to see how hard it would be to make Python's error
>messages friendlier to case-insensitive newbies, without breaking
>existing programs that rely on 'Guido', and 'GUIdo' being different
>names. I decided the best way to do this was to patch the code that
>raises NameError and AttrError.
I've been thinking about this (case sensitivity) overnight and feel
that this is really an issue of who uses python and what for. For
example, I find that I often operate in two different mode,
hacking/learning and then designing/coding.
In the first mode, case sensitivity is not an issue, and often gets in
the way, but once I've worked out how to solve a problem then writing
a module is a different process. Here being able to control variable
names, use uppercase for CLASS names etc is a useful discipline.
Thinking about my own work, there are arguments for both sides of this
issue, and I don't really want to chose, or rather I would like to
chose when i write the code.
In some ways this issue is like the discussion on typing, and also
Pythons lack of enforced public/private variables in Classes.
(Colleagues with a more formal understanding of Computer Language and
Software Engineering often throw this one back at me). There are times
when a strict python is appropriate, and vice versa.
Lecturer in Electronics and Computer Science.
More information about the Python-list