Language change and code breaks
cwebster at nevada.edu
Fri Jul 20 20:36:18 CEST 2001
In article <cppuawfqbm.fsf at cj20424-a.reston1.va.home.com>, Guido van
Rossum <guido at python.org> wrote:
> "Tim Randolph" <timothyrandolph at yahoo.com> writes:
> > > (2) Potentially, the group of non-programmers is much larger than
> > > the group of programmers (and it's easier to teach programmers
> > > an arbitrary rule than non-programmers).
> > I think the distinction between programmers and non-programmers
> > misses a third important group: "sometime programmers" -- people who
> > code occasionally to for fun or to solve problems, but aren't in the
> > trenches (or the cubes) day in and day out.
> Thanks for reminding me! This is in fact the group I have in mind
> when I say non-programmer -- true non-programmers of course wouldn't
> be using Python... :-). In my usage, a "programmer" is someone who
> is a professional code-slinger, 8-12 hours a day. A "non-programmer"
> is someone whose profession is something else (e.g. chemist, or
> webdesigner, or rocket scientist) but who occasionally needs to
I probably fall into this "non-programmer" mould: my main profession is
a mathematician, but I use Python to support my teaching and research.
To be fair, I am far from a "novice," having been programming for the
majority of my life, have had formal instruction in programming, and have
taught programming as a teaching assistant.
I very much appreciate the ability to distinguish between "n" and "N"
or "omega" and "Omega" when I am converting math to Python. I don't
recall ever having been bitten by confusing variables due to case, but
again, this may reflect the fact that I am used working with variables
in different cases (and, indeed, alphabets and scripts) possibly having
vastly different meanings.
It may be considered bad style to write something like:
sum = 0
for n in range(N):
sum += n**2
but it is useful when translating a mathematical expression like:
__ N-1 2
into a Python program.
Since one major audience for Python at present is the Numerical Python
community, I would think that case insensitivity would be a problem
for users in this context, and quite a number of these would be such
part-time programmers as you are trying to help with this proposal.
> > As a member of this group, who is especially fond of Python for how
> > easy it is to pick up where I left off days or weeks before, I would
> > very much prefer a case *insensitive* language with tools that
> > enforce *uniform* case usage.
> And that's of course what I have in mind.
I think a far better solution would be a case sensitive language with
tools that allow the user to enforce uniform case usage. Having taught
novice programmers, I can appreciate that case sensitivity can lead to
problems in that community (although I do not remember it being a major
obstacle for the students I taught, I can never-the-less see that it may
have caused some students confusion).
However, I think that the best way to deal with this is in the tools that
are provided with the language, such as IDLE, or by providing a case
insensitive version of the language for a teaching environment.
> > Nobody wants to see fOo and FOO and foo with the same meaning, but
> > nobody wants to see foo and FOO and foo at all in the same program
> > with distinct meanings. I also don't think the cutesy c=C() makes
> > for readable code -- at least for this sometime programmer.
And I have to disagree. While I don't want to see "oMegA" and "omega"
*at all* in the same program, I do want "omega" and "Omega" to be able
to refer to distinct (albeit probably related) objects.
More information about the Python-list