- accomodate any changes, since i'm not vested in the old style,
- mouth off from the bliss of inexperience.
Ie, i'm in no position to judge on the merits of python coding
But i have a strong hunger for dealing with readable, sensible code,
so i have to chime in. I'll try to be succinct.
The current constrained, spread-out python coding style really appeals
to me. However, i can think of three, very general contingencies that
would tilt me in the direction of the more elaborate, less constrained
(and less appealing) syntax:
(1) Function - is there some important semantic capability that
cannot be concisely expressed in the current syntax, but that would
be concisely expressable in the (a) new one?
The other two are human-engineering issues.
(2) Scaling - Does the current syntax not scale up? Eg, even with
good modularization, does the indentation wind up forcing wrap
around the right margin? Or lots of finagling with strings, to
get them to flow together right without line-wrapping?
(3) Dispersion - Does code wind up being too spread out, so that i
often cannot comfortably arrange to see a significant portion of a
function using one 60-line emacs window?
Re (1) Function - the only substantial new semantic feature that i've seen
mentioned is concise expression of nested binding scopes. I'm a
lisper, and i use a lot of small routines yet also use a lot of
'let's. So that feature seems useful. However, offhand, it seems
like this feature could be implemented without betraying the current
syntax constraints (and without introducing semicolons, are drastic
nesting). And maybe it's not a good idea - seems like python keeps
the lexical scoping to two levels, and i haven't heard complaints
about that. ??
Re (2) Scaling - has anyone really been forced to the right margin?
Is it a pain in the butt, or a non-problem? Are there ways around it,
without introducing noisy syntax?
Re (3) Dispersion - ask yourself, have you been frustrated by too
dispersed code? I went through a period of lisp coding of trying to
pack lots of code on line (you are drastically *un*constrained in
lisp), and i think that often made it extremely more difficult to deal
with the code. I am inclined to think that less is better, when
It's because of that last reason/lesson that i'm hoping that the
current syntax is viable, and can be retained.
Note - i don't work directly with Mike, and only heard his arguments
through the newsgroup. I think expressed a few things in a more
severe way than necessary, but i respect his judgement, and hope that
if any changes are made, they are made out of real necessity, rather
than mere appeal.
Ken Manheimer 301 975-3539
firstname.lastname@example.org FAX: 301 963-9137
Computer Systems and Communications Division
Nat'l Institute of Standards and Technology
Gaithersburg, MD 20899