Language change and code breaks

Joal Heagney s713221 at student.gu.edu.au
Fri Jul 20 22:04:59 EDT 2001


Guido van Rossum wrote:
> 
> "Tim Randolph" <timothyrandolph at yahoo.com> writes:

> 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
> program.
> 
> > 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.
> 
> > 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.
> 
> Exactly.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Yes, but by your definition I'm a non-programmer (Though I do have three
versions of python floating on my machine at the moment.) and I prefer
case-sensitivity! I use it as a convention to remind me what is what.
(Note: Not to distinguish c and C *grins* well not all the time, but
between instance alpha and class FormattedText.)
Additionally as a BSc graduate I have a strong mathematical background
so as another poster has commented, I often use mixed cases for very
short code blocks.

for i in len(I):
	..........
	..........

When it's a simple block of code, especially when I'm in prototyping
mode, I prefer to not have to bother about thinking up clever names for
my code. *puts on his halo* Of course I clean things up later *grins*.

My vote would be in either giving IDLE TAB completion/correction that
recognises case errors, or more helpful NameErrors (Perhaps wrapped into
the IDLE code.) - if there's anything an occasional programmer can do to
help, I'd be glad to volunteer. Perhaps testing ...?

One of my python versions is the 2.2 prerelease - I haven't tested it
much, but it seems to work ok. I like the use of the yield keyword
(Though I'll be glad when the from __future__ etc requirement disappears
in 2.3.), and I assume the generator method returns values on the next()
function for a compatibility issue with something else, rather than just
calling the object directly? Additionally, yes the nested scopes DOES
make code behave more as I expect it to! *thumbs up*
-- 
      Joal Heagney is: _____           _____
   /\ _     __   __ _    |     | _  ___  |
  /__\|\  ||   ||__ |\  || |___|/_\|___] |
 /    \ \_||__ ||___| \_|! |   |   \   \ !



More information about the Python-list mailing list